ypical open-source project development strategies work well for free software but don't flourish in commercial settings, according to one expert.
Jim Herbsleb, a professor at Carnegie Mellon University's International School of Computer Science, part of the Institute for Software Research, previously worked at Bell Labs at Lucent Technologies Inc., where he studied why open-source projects such as Apache have been so successful in employing a distributed development method. He spoke at the Open Source Conference in Toronto this week.
Herbsleb looked at cases where many developers around the world would successfully collaborate on one piece of software. He also examined why this distributed development model hasn't thrived in industry. In fact, Herbsleb said he 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 development has been successful over disparate locations is that the 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 developers of commercial software 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 free and open-source software developers are its users, they create the functions they specifically need.
But one of the drawbacks to the open-source software development model is that mainstream users often get left behind because the really technical people create 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 who works on user-centered software design in the software division at Sun Microsystems Inc.
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.
Sun's Frishberg added that 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 an open-source software development community, and even though it's a meritocracy, who you know can often 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 free and open-source software undertakings.
But when designing open-source software, developers get to choose their own work assignments, compared with a commercial project, where the managers assign the work. This means that open-source software developers are working in an area where they are experts and are motivated by their personal interests.
In addition, the coordination of open-source software projects tends to emerge naturally from its workers sidestepping the bureaucratic clogs characteristic of commercial development, Herbsleb said. He added that free and open-source software projects tend to encourage open technical discussions, whereas commercial projects tend to close the door on participation by everyone.
IBM discovered this cultural rift between open-source software 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 IBM's Eclipse developers had to adjust their frame of mind from a proprietary development strategy to an open-source software development strategy, facing the biggest change with code transparency.
Because users can see 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, the developers were suddenly expected to adapt to the give-and-take element of open-source software creation. That is, they were expected to take time every day to peruse and contribute to newsgroups, 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."
