With the coming release of Sophie and our recent attendence at the Access 2 Knowledge conference, I find myself thinking about open source software development. The operating system Linux is often used as the shining example of the open source software movement. Slashdot reported an interesting ZDNet UK article, which quoted the head maintainer of the Linux production kernal, Andrew Morton, saying that he is concerned about the large number of long standing bugs in the 2.6 kernal. Software always has bugs being worked out, even the long standing ones that Morton describes. Therefore, the statement is not all that shocking or surprising.
What intrigued me was this following statement:
“One problem is that few developers are motivated to work on bugs, according to Morton. This is particularly a problem for bugs that affect old computers or peripherals, as kernel developers working for corporations don’t tend to care about out-of-date hardware, he said. Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest.
“If you’re a company that employs a kernel maintainer, you don’t have an interest in working on a five-year-old peripheral that no one is selling any more. I can understand that, but it is a problem as people are still using that hardware. The presence of that bug affects the whole kernel process, and can hold up the kernel — as there are bugs, but no one is fixing them,” said Morton.
Keeping contributors motivated is crucial to open source endeavors. Reputation is a major factor in what drives people to submit code to the Linux development team. In retrospect, the importance of adding code for new features over adding mundane code for bug fixes, as part of reputation building makes sense. The street cred for fixing old bugs does not seem to be sexy enough; eventhough, some of these bugs could have long term effects on the quality of the Linux OS.
Are there solutions? One solution posited by Morton is to dedicate the entire next release to fixing long standing bugs. Although it is not clear to me how open source developers would react to this constraint. Another solution might try to expand the talent pool by encouraging young, gifted (even student) programmers to work on the bugs. Their motivations might be different from current developers, and any kind of participation might offer enough motivation.
Open source software development is still a fairly new phenomenon and is far from being completely understood. As we see more clearly how motivation factors work and what they produce in the open source production model, it will be increasingly important to document, analyze and learn from these observations. The future sustainability for open source software will rely on learning how to best maintain the developers’ incentives to contribute code. Therefore, we must remind ourselves that the open source development movement is something that must be continuously nurtured. And while we can cite Linux as a success story, the project itself is not on autopilot, nor will it ever be.