News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

There WILL be a JavaOne this year
JavaOne will happen in 2010, as a co-located event with Oracle's OpenWorld, on Sept. 19-23 in San Francisco.
01/27/2010 01:02 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Enterprise lessons from open-source successes




May 1, 2008 — 
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.

Open-source software development eliminates the barriers of the silo method, both inside the project and between the project and the users. In fact, in many ways, the users become part of the project, as integral to the process as the coders themselves, because the users test pre-release versions, report bugs, request features, evaluate upgrades and even write documentation.

The hierarchical distinctions become fuzzier still when the developer is also the end user—a common circumstance in open-source projects. The silos are deconstructed and the project is a hive of activity, or in Raymond’s terms, a “bazaar.” Everyone, even non-coders, contributes to the discussion, and all become part of a development community where there is still a definite process. But that process is much more flexible, democratic and, of course, open.

According to Gabriel and Goldman, sharing code inside a company is even easier than doing it in the wider world. After all, no licensing is required. Simply upload the code to the company file server and you’re done. Or are you? “It may take a very big shift in mindset to open up a project’s code to developers in other parts of the company,” they write. “In fact, one of the biggest benefits might be increased communication between different parts of the company.”

This communication boost can produce benefits that far outweigh the mindset and management adjustments that often must precede the implementation of open-source development methodologies. To make a transition from silos to hives, or from cathedrals to bazaars, managers must realize that this is much more a social paradigm shift than a technical one. Successful implementation will require leadership in embracing open-source philosophy and casting an open-source vision. Fortunately, enough a priori evidence exists to ease the job of convincing higher-ups that bazaar methodology is a good thing.

For example, and as Gabriel and Goldman note in their book, Hewlett-Packard has realized the benefits of internal open-source development. In its paper “Progressive Open Source,” by Jamie Dinkelacker, Pankaj K. Garg, Rob Miller and Dean Nelson, HP said that adoption of open-source methods addresses, and sometimes eliminates, corporate software development challenges resulting from departmental silos in huge companies, even those with tens of thousands of employees.

Challenges such as project launch difficulties, divergent coding standards, company reorganizations that see developers suddenly moved from one project to another, or timelines for existing projects squeezed to force completion by a new deadline are not merely the province of companies that sell software, HP asserts. But they also exist in large organizations that develop applications for internal use.  

One of the most ubiquitous open-source software development tools is the code repository, or version-control tracker. Closed-source projects use version control too, but again, those are silos that prevent access by concurrent or subsequent project groups and teams.

Corporations that remove silo boundaries by implementing a central code repository open to the entire organization find it easier to launch projects quickly because no one has to reinvent the wheel. Over time, the underlying code becomes more stable and reliable because improvements are not discarded after a single use. Rather, they are “checked in” to the repository and reused, which further shortens time-to-market. Meanwhile, developers become familiar with the code tree and, therefore, take less time to readjust to new projects when department changes and role reassignments become necessary.

On the testing side, bugs become easier to find and fix because more people look at the code. Open-source projects usually have an official means of communication: a mailing list or a wiki, or both. Large companies can easily implement these tools in addition to a code repository, allowing discussion and tracking of the project by all interested and affected employees.

With version-control software such as Concurrent Versions System or Subversion, users can work on files simultaneously, check the code back in to the version-control software, and the changes are merged overnight. That way, everyone working on the project is on the same page with the most recent updated version of the code. With an open development process, even testers and documentation writers will access and update the repository with their contributions to the project.

While some challenges are easily reduced and others are eliminated by adopting an open-source development process and using relevant tools, additional challenges frequently surface as a result of open-source methodologies. To a software development manager with no background in open source, the idea of an open and participatory process may sound scary, though intriguing. It’s easy to see how to maintain control of a project in the silo method, but overseeing the process is less clear in the community approach, where images of herding cats come to mind.

One of the biggest hurdles is the political and hierarchical infrastructure that exists in every corporation. Managers who are used to feathering their nests and plumping their resumes with pet projects must get used to sharing their resources, developers and even innovations with the new community. As that happens, there will still be a tendency for project participants to move within traditional and longstanding hierarchies, Gabriel and Goldman point out. Sometimes this is just habitual; other times, the company exerts pressure to keep doing things “the way we always have.” One way to avoid that problem is to see that upper management and C-Level executives are completely sold on open source.

As many companies have discovered, another challenge stems from the limited pool of developers available even within a large organization. In the broad world of open-source development, the best developer for the project at hand usually rises to the top. That’s because with an almost limitless pool of coders, someone with the right combination of desire, ability and dedication will emerge.

Finding the right person to lead a development project inside the limited scope of a corporation is more difficult. And even if the right person can be found, it can be tough to retain that person if a better job offer surfaces. On the other hand, with silo elimination, more people in the company will understand the project and will be able to work together to fill in the gaps if the project leader needs to be replaced.

The more or less unstructured approach of open-source development can be a huge challenge for hierarchically driven corporations. Relying on the enthusiasm of project participants to keep a project on track may not be the best solution in a deadline-driven business environment. Fortunately, some tools have emerged to encourage best practices in an open environment.

The Apache group created a tool, called Maven, that provides a uniform build system for Java-based projects and generates change logs, dependency lists and unit test reports. Fluid is a project that aims to “help improve the usability and accessibility of community open-source projects.” Tools like these make transitioning a company to an open development environment feel more secure. While weighing the challenges against the benefits is critical before undertaking a task of this magnitude, open-source development methods could usher in the productivity and quality increases that every project team seeks—whether the project itself is open source or not.

Technology writer Tina Gasperson focuses on enterprise applications of open-source software. Read her blog at www.gasperson.com.


Related Search Term(s): HPopen source


Share this link: http://www.sdtimes.com/link/32047
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading