December 21, 2005

Survey: Open source developers jump on bugs, open to closed tech

Author: Jay Lyman

It comes as no surprise that open source software developers are fixing bugs faster and faster, but the majority of Linux developers' willingness to use proprietary products -- a la the Bitkeeper debacle -- may be more likely to raise eyebrows. Both findings -- that open source developers find and repair severe bugs in less than four hours on average and that 64 percent of OSS developers would purchase a tool for Linux if it worked well even if it was not open source -- come from the Evans Data Fall 2005 developer survey.

The data comes from a survey of 456 developers working on open source projects during October 2005.

Evans Data President John Andrews told NewsForge the fast software fixes for open source follow a trend of improving time-to-fix response that rises 10 to 20 percent year over year. "It's a combination of more familiarity with open source and the communities around open source are getting better support," he said.

Apache developer and CollabNet founder and CTO Brian Behlendorf downplayed to a degree the bug fix findings, indicating they could be simple user misconfiguration errors rather than product issues that require debugging. Still, Behlendorf said, the open source response model has matured and advanced to the point that fixes are efficient and fast.

"Most open source projects have configured their bug reporting tools -- whether formal tools like Web-based databases or more informal tools like mailing lists -- to be easy for others in the community to reply to," Behlendorf said. "So rather than having a handful of full-timers bottlenecking on responding to reports for all customers, you have a potentially much larger group of part-timers who don't mind answering occasionally, and enjoy the credit and recognition of being the first to do so."

Behlendorf added that open source software users can better investigate their own software defects and bugs, and when reporting them can often give much richer information than might normally be available if the user had no access to source code.

"Demographically, open source users still trend toward the far more technical audience, who will do that investigation mentioned, rather than an average user complaining to Microsoft that their PC keeps freezing," he said. "Though as more complicated programs like Firefox and OpenOffice.org become more common and as the user base shifts toward the non-technical user, this may become less so. Still, those kinds of users will probably first seek support from technical organizations who act as a 'clue buffer' of sorts. Engineers at those organizations will then give a much more informed bug report to the upstream project."

Illuminata senior analyst Gordon Haff told NewsForge it is difficult to assess the significance of the Evans findings on bug response. He noted that a fix from an open source project that has gone dormant will likely never come. Still, Haff said Linux users who have support contracts with the Red Hats of the world are going to get bug fixes quickly, "one way or another, whether it's the community or Red Hat."

Communities are coming along

Evans also described an evolution of open source software communities, which are serving as "knowledge repositories for development."

"Number one, in terms of content and knowledge and overall numbers, we've seen these communities and ecosystems grow tremendously," Andrews said. "It's just all part of a maturation curve that proponents of open source were hoping for, and slowly but surely, you're seeing this evolution take place."

Behlendorf agreed, indicating CollabNet is striving to deliver this knowledge-sharing message to enterprise users. "It goes far beyond the usual knowledge management tools, beyond the 'asset reuse repositories' that were kind of popular," he said. "It's a living, breathing community 'attached' to assets and knowledge. Powerful stuff."

Haff had reservations over the use of the monolithic term "community." He pointed to the differences among Linux, Solaris, OpenOffice.org, SugarCRM, BugTraq, and other communities. "You have many communities of different sizes and different levels of investment," he said.

Nevertheless, Haff agreed that "the number of people involved in individual communities is growing."

Proprietary pragmatism?

Evans also indicated open source developers were largely unopposed to using non-open source tools, provided they work well. Only 6 percent of respondents said they would "absolutely not" purchase a non-open source tool for Linux.

"The driving factor there is performance," Andrews said. "If they can use it to improve productivity, that's what they'll use," he said referring to non-FOSS software.

Although Andrews added there was some willingness to sacrifice performance to go with open source, the bulk of developers use multiple development environments and choose those environments based on performance.

Behlendorf said the willingness to use non-open source tools was confirmed by his own experience. "Most coders are attracted to open source more for the flexibility and security and reliability and ability to collaborate, and less about a religious aversion to certain economic models. However, the non-open source tool will have to be significantly better than the free alternative in ways that matter to the user."

Illuminata's Haff said the willingness to use non-FOSS for Linux or open source development was "somewhat a reflection of a growing maturity and growing pragmatism by many people using open source."

"That certainly does say the majority of open source developers are at least willing to consider closed source or a proprietary tool, but it's a relatively small majority," Haff said of the Evans findings. "There clearly is a strong preference in the open source world for open source tools."

Click Here!