Typical open source project development strategies work well for free software but don’t flourish in commercial settings, according to one expert.
Professor Jim Herbsleb of Carnegie Mellon University’s International School of Computer Science, part of the Institute for Software Research, previously worked at Bell Labs at Lucent Technologies, where he studied why open source projects such as Apache have been so successful in employing a distributed development method.
Specifically, Herbsleb looked at cases where many developers from all over the world would successfully collaborate and coordinate to work on one piece of software. While looking at this, he also examined why this distributed development model has not thrived in industry. In fact, Herbsleb found that it takes companies more than twice as long to develop software in disparate locations than in one location.
One of the reasons why free and open source software (FOSS) development has been successful over disparate locations is because development work has been done by the users and these developer-users determine the functionality, Herbsleb said.
“Because work is done by the users, they’re more likely to get the functionality right, so a major class of errors is eliminated,” he noted, adding that with commercial software, the developers are rarely users of the software and the functionality is determined by project managers.
“Project managers tend to understand purchasing designs — why companies buy software — so they’ll build a project that plays into those hands,” Herbsleb explained. This means that commercial software can be created without fully meeting user requirements. Because FOSS developers are its users, they create the functions they specifically need.
But one of the drawbacks to the FOSS development model is that mainstream users often get left behind because the really technical people creating the software design functionality for themselves, not for the average user. The geek creed — if you can’t install it, you don’t deserve to use it — is still alive in many open source projects, said Nancy Frishberg, user-centered software design, software division at Sun Microsystems Inc. in Menlo Park, Calif.
As a result “it is sometimes said [that lack of] usability is the Achilles heel of open source,” said Steve Easterbrook, associate professor in the department of computer science and associate director of the Knowledge and Media Institute at the University of Toronto.
Additionally, Sun’s Frishberg said the open source mantra that “everyone can contribute,” is actually misleading because adding to an open source project is basically limited to code, bugs and patches.
She said even developers have to be assertive to get themselves into a FOSS development community and even though it is a meritocracy, often who you know can help you get your foot in the door. Also, “everyone” tends to mean people who are technically proficient with computers, so creative individuals who aren’t programming experts can’t contribute to FOSS undertakings.
But when designing FOSS, developers get to choose their own work assignments compared with a commercial project where the managers assign the work. This means that FOSS developers are working in an area of where they are experts and are motivated by their personal interest.
Additionally, the coordination of FOSS projects tends to emerge naturally from its workers sidestepping the bureaucratic clogs characteristic of commercial development, Herbsleb said. He added that FOSS projects tend to encourage open technical discussions, while commercial projects tend to close the door on participation by everyone.
IBM Corp. discovered this cultural rift between FOSS and commercial software development environments when it open-sourced its Eclipse development platform in February 2004.
Paul Buck, IBM’s director of Java Platform Strategy and Eclipse, said Big Blue’s Eclipse developers had to adjust their frame of mind from a proprietary development strategy to a FOSS development strategy facing the biggest change with code transparency.
Because users can see and and manipulate Eclipse code, the developers received a lot of feedback. In the proprietary model, developers just keep their head down and don’t have time to go around explaining things to users, Buck said. But when Eclipse went open, suddenly the developers were expected to adapt to the give-and-take element of FOSS creation.
That is, they were expected to take time every day to peruse and contribute to news groups, offer explanations to users and conduct demonstrations. They also had to examine the user feedback, including feature requests and examine the submitted patches and enhancements.
“It’s rewarding,” Buck said. “But it’s clear that the [Eclipse] user community is not shy — it’s demanding. But that drives the developers.”
