Enterprise lessons from open-source successes
By Tina Gasperson
May 1, 2008 —
(Page 1 of 4)
Related Search Term(s): HP, open source
Have you ever heard the phrase “subvert the dominant paradigm”? It instructs: Upset the apple cart of traditional thinking every chance you get. Indeed, paradigm subversion assumes there’s always something better hidden on the other side of tradition.
However, paradigm shifts don’t come easily. For example, when Newton’s gravitational theory came face to face with Einstein’s theory of relativity, Einstein was flatly dismissed. But, as more scientists investigated relativity and discovered its soundness, Newton’s dominant paradigm was subverted and replaced by Einstein’s superior theory. These days, open-source development process is sometimes seen as subversive, but open-source development doesn’t upset apple carts for the sheer fun of it, say proponents. It really is a better way to create software.
“Open-source software presents the richest example of the changes under way in the structure of our economic institutions,” say Richard Gabriel and Ron Goldman in their book “Innovation Happens Elsewhere.” The authors assert that the open-source development community is “pioneering the changes arising in our society from the transformation from industrial to informational economy.”
Today, more and more enterprise software development managers are taking a closer look at how open-source projects are run and discovering what many developers have known all along: The kind of disruption that open-source methodology creates is good for company morale and production. It produces much higher-quality software that is more secure, flexible, scalable and bug-free than software developed under the old paradigm.
For a long time, the dominant paradigm in enterprise software development has been the silo method, or what Eric Raymond calls “the cathedral.” It compartmentalizes different projects or teams in ways that discourage or prevent interaction at a meaningful level. Sometimes, even different job functions within the same development project are walled off from one another, with stages of development forced to progress in a strictly linear fashion from silo to silo.
Requirements analysis is separate from documentation, from engineering, from testing—and the strand of communication between these silos is never broad enough. This results in a sluggish response to feature requests or performance complaints. Even more entrenched is the notion that the individual project itself is a silo, wholly separate from the other company departments, which often are the intended end users of the software. And when the final product is a commercial application, there is even more separation between the project and the end users.