Angus Kidman30 January 2008, 7:47 AM
With 2,000 lines of code being added every single day, any lingering suggestion that Linux might suffer from a lack of support is clearly insane. But what lessons can the open-source OS teach its somewhat younger encyclopaedic cousin, Wikipedia?
linux.conf.au 2008, Melbourne | With 2,000 lines of code being added every single day, any lingering suggestion that Linux might suffer from a lack of support is clearly insane. But what lessons can the open-source OS teach its somewhat younger encyclopaedic cousin, Wikipedia?
In his customary linux.conf.au Kernel Report on the state of play in the Linux kernel, LWN.net co-founder and kernel contributor Jonathan Corbet gave an upbeat assessment of Linux's future.
The current kernel development model in which a large volume of patches are added (creating what Corbet described repeatedly as "API breakages and all that other good stuff"), followed by a feature freeze and intensive debugging until stability is achieved, appears to have proved productive after a few hiccups. "It took a few releases to really get that discipline into place," Corbet said.
Kernel release 2.6.24 came out on January 24, just before linux.conf.au began. Corbet estimates 2.6.25 will be finalised sometime around April.
That rapid cycle represents an astonishing volume of new code. "We are adding about 2000 lines of code to the kernel every single day of the year, without exception," Corbet said. "Nobody can really keep up with this [on their own] any more. It's an amazing process, and it seems to be working."
The project which those numbers immediately bring to mind is Wikipedia, which uses similar open source principles, along with an "anyone can contribute" ethos. That latter emphasis means that Wikipedia, in operation for less than half of Linux's lifespan, already has to deal with a far larger community and project base than Linux (more than 2.1 million articles on the English-language Wikipedia alone). Nonetheless, in listening to Corbet's presentation, some obvious parallels emerge.
Lesson #1: Reliance on individuals can lessen over time
It's widely assumed that voluntary projects tend to be spearheaded by a relatively small handful of hyper-enthused volunteers. That may still be the case at Wikipedia -- check the discussion page for any controversial article and it will tend be an argument between half-a-dozen highly passionate people -- but the Linux experience shows that doesn't always have to be the case.
"Ten years ago, the top 20 contributors contributed to the majority of changes that went into the kernel," Corbet noted. In 2007, however, more than 2000 individual developers offered code, and there was no clear dominance. Indeed, only eleven people contributed more than one per cent of the overall code base, while several hundred contributed a single patch. All of those patches are arguably essential, but someone getting run over by a bus clearly isn't going to stop the flow.
Lesson #2: Emphasising a single individual too much is dangerous
With that said, emphasising a single person (or group of people) as the face of a project can be risky. In the Linux community, Linus Torvalds remains the most visible personality, but excessive reliance on any individual can be tricky. "We're starting to see some 'Andrew Morton doesn't scale' issues," Corbet said (Morton helps coordinate Linux kernel contributions). "He does a lot of the integration work, and he has a hard time keeping up sometimes."
Wikipedia appears to have already absorbed that lesson, trying to reduce the emphasis on founder Jimbo Wales and regularly issuing announcements of its latest appointments.
Lesson #3: Getting spin-off projects to contribute can take time
One continuing challenge for Linux is getting people working on non-kernel projects, such as embedded systems, to contribute useful modifications back to the core kernel. "It's an ongoing problem, though I think it's getting better," Corbet said. "A lot of people aren't participating in this process, and their work isn't going into the mainstream."
Wikipedia faces a similar challenge in co-ordinating contributions from the single-topic Wikis run by its sister project Wikia. While some of these (such as the Star Wars-centred Wookipedia) have volumes of information on some topics that rival those in the central Wiki, processes to synthesise content between individual wikis are few and far between.
Lesson #4: You might need some corporate funding
The main pages of Wikipedia regularly feature exhortations to donate. While that can seem annoying at times, it's probably necessary. Wikipedia largely relies on volunteer contributions, but those can't help cover mounting server costs and the occasional legal bill.
Linux enjoys a more diverse support base (in part because big business has worked out ways of profiting from it). "The picture that people once portrayed of the kernel as the product of volunteers really isn't the case anymore," Corbet said. While the majority of kernel contributors (17%) aren't paid by an obvious employer, a large chunk are. Notable supporting corporations include Red Hat (employing people making 11% of code contributions), IBM (8%), Novell (7%), Intel (4%), Oracle (2%) and Google (1%).
Lesson #5 Persistence pays off.
Wikipedia abuse remains a popular sport, whether for perceived inaccuracies, a simple inability to understand how content can be kept stable, or ongoing arguments about the copyright of pictures and text on the site. Linux has also suffered through similar battles, ranging from arguments over whether source code has been stolen through to criticisms of its stability and long-term viability.
While such arguments are likely to continue for eternity, their force does tend to lessen over time. Corbet offered the example of closed source drivers, long a source of irritation to the Linux community for their limiting effect on distributions. "At this point, closed source drivers are irrelevant and unnecessary, and I think that's a great state of affairs," he said.