Would-Be Linux Contributors May Get a Leg Up
Page 1 of 1
While Microsoft Windows is built by an army of the software giant's paid engineers, Linux is written by a community of contributors. Yet joining that community isn't as easy e-mailing a piece of code to, say, Linus Torvalds, the OS's originator.
That fact has long dogged the Linux community, supporters say, fostering a belief that joining the effort is difficult owing to the fairly complex processes and procedures already in place for adding and reviewing code.
As a result, the Linux Foundation is aiming to simplify the task of contributing code, with a new guide to helping would-be contributors to the Linux kernel.
"The idea that working with the kernel community is hard, to me, is a myth or at least a misconception," Linux kernel contributor Jonathan Corbet told InternetNews.com. "It is only hard if you don't take the time to learn how the community works."
"Whenever you step into a large, organized operation, there are going to be some ground rules, and if you ignore those rules, you will find working with the community very hard," said Corbet, who authored the guide.
Considering that Linux is rapidly gaining momentum in the enterprise, understanding how to freely participate in kernel development could benefit developers, hardware vendors and others, who get a chance to work closely with the OS and get improved code quality. Additionally, by lowering the barriers to effective participation in the Linux community, the OS and its users also stand to benefit.
While the belief about the difficulty of contributing to Linux has persisted for some time, not everyone has bought into the idea. A recent study from the Linux Foundation reported that there are over 1,000 individual contributors to Linux, representing over 100 different companies.
Corbet said the new guide, which is available on the new Linux Developer Network, came about after discussion with the Linux Foundation and its membership.
"My goal was driven by talking with folks that wished they had something they could hand out to companies and developers to see how to participate and get their code into the kernel," he said.
A pitch to driver developers
The guide's initial topic is a discussion of why anyone would want to contribute code in the first place -- a portion of the guide that vendors of device drivers might want to take to heart, Corbet suggested.
"There is a lot of disagreement between the kernel development community and certain vendors who don't see the reasons or the need to incorporate their code," he said. "One reason is that code in the mainline kernel tends to be higher-quality code."
Corbet added that whenever a vendor has code that gets seen in public for the first time, it's often in need of significant improvement. That's where the kernel development review process helps, by having a number of participants looking at the code.
Additionally, Corbet said that once code is in the mainline Linux kernel, it is available to all Linux users. As a result, users do not have to go scrambling for drivers from third-party sites, since the code is already in Linux.
While increasing participation in the development effort has been a major concern for the community, some members have worries about the influx of new features, Corbet said.
"There are persistent concerns about quality control, with some people feeling that we're spending too much time merging new stuff into the kernel and perhaps not enough time fixing stuff that is already there," he said. "That's not a universally held opinion, and it's really hard to come up with objective metrics on whether the kernel is becoming more buggy or less so."
Still, Corbet added that having the discussion at all is beneficial, because it encourages the community to try and make things better.