This Is How Linux Is Done: It's The Scientific Method of Peer Review
By Pamela Jones
November 26 2003OSDL has released an explanation [ http://www.osdl.org/newsroom/press_releases/2003/2003_11_26_beaverton.html ], with a handy graphic that Linus and Andrew Morton helped create, that illustrates how software code is contributed to the Linux kernel. The development process is not a "don't ask, don't tell" free-for-all, as Darl McBride would like you to believe. Rather, it's an organized arrangement which has been in place in essentially the same form for more than a decade. Here's the OSDL description of the process:
"'OSDL firmly believes that the Linux kernel development process, under the guidance of Linus Torvalds, has proven to be an extremely effective means to produce powerful software for more than 10 years now,' said Stuart Cohen, CEO of OSDL. 'Recent public criticism of the Linux development process shows a lack of understanding as to the rigor imposed by Linus himself and the development community at large. It is a process built on the scientific method of peer review.'
"The Linux operating system kernel is the result of the efforts of its creator, Linus Torvalds, and thousands of dedicated software developers from around the world. These developers are self-organized into specific subsystems defined by a developer's interests and technical expertise (for example, I/O, storage, networking). Each of these subsystems has a domain expert developer, called the subsystem maintainer, who oversees the work of others. Subsystem maintainers review the code submitted to them and orchestrate broader peer review of code to ensure its quality.
"All Linux code, both the current version and that submitted for future inclusion, is also available on-line for public examination. This allows literally thousands of interested parties to scrutinize submitted code in what amounts to a massive code review. Only when a subsystem maintainer accepts software code is it passed along to one of the two developers at the top of the Linux hierarchy, Torvalds himself or Andrew Morton.
"Torvalds maintains the "development kernel" where new features and bug fixes are tested. Morton maintains the "production kernel" which is the version release for public use. Torvalds is the final arbiter of what is included in Linux. OSDL, with the help of Torvalds and Morton, created a simplified Linux Development Process graphic to help illustrate these key points. The graphic is available at http://www.osdl.org/newsroom/graphics/linux_dev_process.jpg.
"Over the years Torvalds has enhanced the Linux development process itself to accommodate its increasing complexity and scope. The process is expected to continue to evolve in the future, but the basic structure has remained constant since the creation of Linux in 1991."
One advantage to proprietary software companies of this open method is that they too can look over the code to make sure that no proprietary code belonging to them has made its way into Linux. There are no hidden pieces, so it's open for their review 24/7. This is just the first in a series of outreach efforts OSDL plans, part of what they are calling their Linux kernel awareness initiative, to help people, including those who may not be techies, to understand Linux better.
Speaking of Andrew Morton, you may have seen an article on CRN [ http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=46317 ] about the 2.6 kernel. Morton was interviewed for the article, and he said some positive things about the integrity of the kernel, but there was one aspect of his remarks that struck an off note:
"Morton said the crew of open-source developers working on the Linux kernel are certain that no one has introduced thousands of lines of Unix code to the Linux kernel.Naturally I wondered what he was saying. What did he know? What did he mean? So I contacted him and asked him those questions. Here is what he tells me his actual position is:
"'We're a fairly tight-knit community who have been working together five years, and if a new person with 100,000 lines of code [tried to contribute], it would stick out like sore thumb,' Morton said. 'You can tell when something has grown up in a different environment and is ported over to another [platform]. We've gone though Linux and looked at all the major subsystems, and we couldn't come up with anything. We mentally took a walk though the kernel and came up with a blank.'
"He did, however, cite two possible exceptions that might apply to the litigation.
"'There was one obscure file system written by a person employed by SCO and Caldera, but he said he developed it on his own time,' Morton said, adding the person got his boss' approval via e-mail. 'We were quite comfortable with that.'
"Morton acknowledged that the XFS and JFS file systems, which were originally developed under a Unix license and then ported over to Linux, could be a sticky issue that lawyers can exploit. 'SGI did develop it. It could be [SCO] has a legitimate case there, not technically, but on the letter of the law,' Morton said."
'I believe the SCO claims which I have read in the press are without merit from a technological point of view.
"It is my understanding that XFS and JFS were developed by SGI and IBM under Irix and AIX. As a programmer, I do not expect that this procedure would have lead to leakage of technical knowhow from IRIX or AIX into Linux. However it could be that the law contains wording which make this an area which SCO lawyers could work on anyway.
"In my conversation with Paula my intent here was to disclaim my ability to predict any outcome with respect to that aspect of XFS and JFS. I am a technologist and this part of it is not a technical matter."
In other words, he was just saying he isn't a lawyer, so he can't say what could or couldn't happen with respects to the law, particularly with SCO in the picture. That is all he said and definitely all he meant, despite the odd way it ended up looking in the article. It happens. The poor guy did around 10 media interviews yesterday. Yes, in one day.
02:26 PM EST
Copyright 2003 http://radio.weblogs.com/0120124/ - http://creativecommons.org/licenses/by-nc-nd/3.0/