451 CAOS Links 2009.12.01

Banking on open source. Open source as a business model. And more.

Follow 451 CAOS Links live @caostheory on Twitter and Identi.ca
“Tracking the open source news wires, so you don’t have to.”

For the latest on Oracle’s acquisition of MySQL via Sun, see Everything you always wanted to know about MySQL but were afraid to ask

Banking on open source
# CIOL.com reported on the benefits of Standard Chartered Bank’s open source-based core banking system.

Open source as a business model
The “open source has failed as a business model” debate reared its head again. First the New York Times reported on the apparently elusive nature of open source as a model for business, in the context of the Oracle-Sun acquisition. That prompted ComputerWorld to ask “Is Open Source dead as a business model?” Taking a contrary view, Stephen O’Grady asked “Is Open Source as a Model for Business Really That Elusive?” Meanwhile Matt Asay argued that there are two options for open source software businesses to make money from OSS, while Sebastian Rupley declared that “Open-Source Business Models Aren’t Dead-End Streets”. Finally, for now at least, Mike Masnick declared “If You’re Looking For The Open Source Business Model, You’re Looking For The Wrong Thing”.

Best of the rest
# OpenLogic introduced SLA support for CentOS.

# E-procurement and e-invoice management tools were published as open source by the EC’s Directorate General for Informatics.

# Sun released VirtualBox 3.1, including “teleportation” of virtual machines.

# rPath’s release automation platform now supports Red Hat Enterprise Linux 4 and 5.

# The Register reported that when it comes to mobile operating systems there is more to open than open source.

# Google’s Chromium OS is up and running on a Dell Mini 10v.

# The UK’s National Computing Centre published a white paper examining the advantages and hurdles related to OSS.

# Savio Rodrigues asked “what’s new with Acquia?”

# BusinessCar reported that an open-source car firm has proposed new business model. Yet another open source car, albeit with an interesting business model.

# Ukauthority reported that the UK govt’s new IT strategy will place greater emphasis on open source use and re-use.

# Roberto Galoppini published a discussion on the impact of Subversion becoming an Apache Incubator project.

# Ulteo introduced open source virtual desktop OVD 2.0.

# Glyn Moody reported on an interview with Greg Kroah-Hartman about how the Linux kernel is built.

# An EU Ministerial Declaration on eGovernment favoured open specifications and open source.

# Telecoms.com published an interview with John Forsyth, leadership team, Symbian Foundation.

# Squiz announced that its MySource Matrix open source CMS software is now available as a service.

LinuxCon corrals community, clouds, challenges

I attended the first LinuxCon this week and saw firsthand evidence of a growing, thriving Linux community. Notice I did not call it the Linux kernel community nor Linux development community since it’s much more than the kernel that is key to the fate and progress of Linux, with an increasing role for users as well.

Of course, LinuxCon and the accompanying Linux Plumbers Conference (held for the second time since last year are primarily a gathering of Linux kernel hackers and the developers that push the open source OS forward. So it was fitting to have some of the most significant contributors and maintainers gathered to discuss the state of Linux in front of the Linux faithful.

A highlight of the conference for many was a kernel panel featuring Linux creator Linus Torvalds himself, Jonathan Corbet, Chris Wright, Ted Ts’o and Greg Kroah-Hartman, moderated by James Bottomley.

The panel began with some discussion of improvements and efficiences in kernel development and incorporation of new branches and code, with Torvalds indicating his kernel life had gotten a bit more manageable. However, the discussion soon turned to some significant issues, particularly the size and fitness of Linux. What began as a lightweight OS (which is still stripped of parts and used for lightweight embedded and other uses) has grown dramatically over the last 10 years. In fact, in just the last year, 2.7m more lines of code were added to the kernel. Although there is certainly a great sense of vitality around Linux and the kernel, there was also agreement that Linux may be getting too fat. While there was no real solution that emerged, at least it’s clear kernel developers and Linux leaders are aware of the situation.

Another interesting topic and perhaps dilemma for the Linux kernel and its backers: the aging team of core contributors. Also, as highlighted by Linux Foundation Executive Director Jim Zemlin to open the conference, the Linux community needs to do a better job of reaching out and including women. I would add that there is also a need for greater diversity and geographic representation among kernel hackers, even though we already see a global Linux community with LinuxCon visitors from across Europe, Asia, South America, Australia and elsewhere.

The unmasking of the fake LT was fun, mostly for the rap music video with dancing penguin suit guy, but once again we saw Matt Asay take the prize (this after winning the open source license debate recently). I guess this open source advocate is on a roll.

For my part at LinuxCon, I gave a talk on community Linux — that is unpaid, self-supported Linux — and its impact on the enterprise, with a particular focus on cloud computing. This coincides with a 451 Group report on the same topic. When we wrote our report on community Linux a year ago, we highlighted how community distributions such as CentOS, Debian and Ubuntu are putting competitive pressure on commercial, subscription Linux, such as RHEL and SUSE. We see the presence of community Linux and its impact increasing, though we must point out there are also complimentary effects from community Linux, which grows users, support and the overall Linux ecosystem. Still, we see enterprise organizations using community Linux for some of the same reasons they look to Linux in general: cost savings, flexibility and greater utilization of developers and teams that are capable of supporting themselves.

We had indicated that technology trends such as virtualization and cloud computing tend to favor the established, paid Linux distributions and vendors. In fact, virtualization, cloud and interoperability are key areas where Linux vendors differentiate their paid versions. This continues to be the case, and there is ample room for Linux vendors to continue and deepen that differentiation. However, there will be more community Linux pressure coming from these ‘other’ distributions, and much of it appears to be coming from cloud computing.

We are hearing from vendors and end users that community Linux makes sense for cloud computing. Obviously cost is a big factor, and perhaps bigger give current economic conditions. Also, enterprise organizations are finding that they can support themselves in many situations. Technically, community Linux distributions may also be easier to strip of messaging and other parts for use in cloud building. Community Linux may be growing its presence in cloud computing, with vendors such as Convirture, rPath, RightScale and others incorporating it into their technologies and strategies. However, when it comes to offering Linux in the cloud, we again see this favoring the more established, more accepted commercial distributions of Linux.

Microsoft GPLv2 code – donation or obligation?

Earlier this week Microsoft announced that it was contributing driver code to the Linux kernel under the GPLv2, and we published a CAOS Theory Q&A to discuss the implications. It has subsequently become clear that there were two important questions that were not answered by our Q&A:

Q. Is this a donation, or an obligation?

A. In discussing the motivations for the Linux Integration Components (Linux IC) release, Microsoft cited enhancing the performance of Linux as a guest operating system where Windows Server is the host, and that the GPLv2 is “the Linux community’s preferred license”.

An alternative viewpoint began to emerge that suggested that perhaps Microsoft had little choice in the decision to release the code, however. It started with the publication of a post written by Stephen Hemminger, a principle engineer at Vyatta, which stated:

“This saga started when one of the user’s on the Vyatta forum inquired about supporting Hyper-V network driver in the Vyatta kernel. A little googling found the necessary drivers, but on closer examination there was a problem. The driver had both open-source components which were under GPL, and statically linked to several binary parts. The GPL does not permit mixing of closed and open source parts, so this was an obvious violation of the license. Rather than creating noise, my goal was to resolve the problem, so I turned to Greg Kroah-Hartman.”

Kroah-Hartman runs the Linux Kernel Driver Project and is working with Microsoft to introduce the Linux IC code to the Linux kernel. He appeared to confirm Hemminger’s perspective when he wrote “Steve gives a little more of the backstory of what caused me to start talking to Microsoft in the first place,” and then told Mary Jo Foley that her suggestion that “Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL” was “accurate”.

Cue stories such as “Linux community pushed Microsoft to hand over its code” and “Microsoft opened Linux-driver code after ‘violating’ GPL“.

Before commenting on these stories I took the opportunity to speak to Sam Ramji, who seemed genuinely surprised by the perspective that the driver code had violated the GPL and maintained that he was not aware of the account provided by Hemminger prior to its publication.

The two viewpoints are not necessarily mutually exclusive. In his exchange with Foley, Kroah-Hatmann notes that he “didn’t have to ‘suggest'” that Microsoft was in violation, he “only had to merely point out the obviousness of the situation”.

Additionally, Vyatta’s vice president of strategy and marketing, Dave Roberts, has noted that “nobody ‘accused’ anybody of anything. Stephen merely called the situation to Microsoft’s attention… There were no threats, no screaming, no broken fingers, no frothing at the mouth. Just a few calm phone-calls placed behind closed doors, out of the limelight and media focus. And that was that. Microsoft noodled on things. And then it decided to open source the drivers and contribute them to the kernel.”

I also put it to Ramji that if, *hypothetically*, Microsoft were to have discovered it was inadvertently in violation of the GPL, then from a PR standpoint, the company would have much more to gain by being seen to have responded appropriately than by trying to cover it up. He agreed.

(And I don’t think this can be understated actually, if you consider what the open source group within Microsoft is trying to achieve you begin to understand why they would be hyper-sensitive to the fact that trying to claim credit for something they didn’t do would be counter-productive).

Anyway, Ramji has subsequently posted his views on the issue, including:

“Microsoft’s decision was not based on any perceived obligations tied to the GPLv2 license. For business reasons and for customers, we determined it was beneficial to release the drivers to the kernel community under the GPLv2 license through a process that involved working closely with Greg Kroah-Hartman, who helped us understand the community norms and licensing options surrounding the drivers.

The primary reason we made this determination in this case is because GPLv2 is the preferred license required by the Linux community for their broad acceptance and engagement. For us to participate in the Linux Driver Project, GPLv2 was the best option that allowed us to enjoy the tremendous offer of community support.”

Q. So was Microsoft in violation of the GPLv2?

A. Of course, “not being accused of being in violation of the GPL” is not the same thing as “not being in violation of the GPL” but it is not completely clear whether that was actually the case.

Over on Cnet, Gordon Haff got some more technical details from Hemminger:

“According to Stephen, the issue revolves around a feature of the Linux kernel called EXPORT_SYMBOL_GPL that allows for interfaces to be marked as only available to modules with a GPL-compatible license. From Stephen’s perspective, Microsoft’s proprietary code had to use some of these interfaces that ‘the kernel did not want to offer to non-GPL [code].’

If that all seemed a bit geeky technical, well it is. Very possibly a violation of the GPL but hardly one that is simply flagrantly flouting the law.”

UPDATE – The Software Freedom Law Center’s Bradley Kuhn has told SDTimes that Microsoft *was* likely in violation of the GPL:

“It seems to me that Sam [Ramji] is likely correct when he says that talk inside Microsoft about releasing the source was under way before the Linux developers began their enforcement effort,” said Bradley Kuhn, a policy analyst and tech director at the SFLC.

“However, that talk doesn’t mean that there wasn’t a problem. As soon as one distributes the binaries of a GPL’d work, one must provide the source for those binaries, so Microsoft’s delay in this regard was a GPL violation.”

However, Ramji continues to deny that a GPL violation was the significant issue. “Greg’s coaching on how to get it contributed was invaluable, but it was not the original driver of our plan or decision,” he told SDTimes. “That’s the beauty of the real world. Different people have different perspectives, and that is what causes them to act. We appreciate Greg’s coaching regardless of his motivation.” – UPDATE

2ND UPDATE – Sam Ramji has once again denied that Microsoft violated the GPL. In a podcast published at Network World he points out (from 15.30) that the code did not statically link to libraries in the Linux kernel, but to the header files, and that Linux developers are split on whether that constitutes a violation of the GPL. “The act of compiling to a header file doesn’t generate a GPL obligation to my knowledge, that was never a consideration in our process.” – 2ND UPDATE

In his initial blog post, Hemminger stated that the saga was started by an inquiry about supporting Hyper-V network driver in the Vyatta kernel, presumably this one, from March, when Hemminger has said the issue was bought to his attention. Hemminger’s response at the time is that “Msft hyper-v driver is not open source, and redistributing it would require agreement with them”.

The driver cited in that query would appear to be the original Linux Integration Components for Hyper-V, which were released in September 2008, the same components that The H reported were previously withdrawn from release candidate distribution in July 2008 for a licensing review.

As Patrick O’Rourke noted at the time, “Licensing is tricky when open source and proprietary software are packaged.” No kidding.

A quick note while we are on the subject of timing, Hank Janssen says he proposed that Microsoft open source Linux IC driver code in October 2008. Sam Ramji told me Microsoft started seriously considering it in January this year and first heard from Greg Kroah-Hartman in May.

While Hemminger started that Microsoft’s release of the code under the GPLv2 “”took longer than expected”, Gordon Haff notes that Hemming “said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.”

Q. Anything more to add?

A. Probably. If anything new does arise, we’ll post details here.

Microsoft contributes to Linux kernel: a CAOS Theory Q&A

Microsoft has announced that it is to contribute code to the Linux kernel development effort under the GNU General Public License (GPL) v2. What on earth does it all mean? Here’s our take on the situation. With thanks to Jay Lyman for his contribution to the following:

Flying Pig

Q. This is a joke, right?

A. Not at all, although if any announcement is better suited to the image above, we can’t think of one. Microsoft has announced that it is going to contribute code to Linux under the GPLv2.

Q. What code is Microsoft contributing?

A. Microsoft is offering 20,000 lines of its own device drivers to the Linux kernel that will enable Linux to run as a guest on its Hyper-V virtualization technology. Specifically, the contributed loadable kernel modules enable Linux to run in ‘enlightened mode’, giving it efficiencies equivalent to a Windows virtual machine running on Hyper-V.

Q. Why is Microsoft doing this?

A. Red Hat and Novell’s Linux distributions already support enlightened mode, thanks to the development work done by both in partnership with Microsoft. One benefit for Microsoft of contributing to the kernel is that it reduces duplication of effort and the cost of supporting multiple, unique implementations of Linux. Once the code has been accepted into the kernel, Microsoft will use the kernel tree code as the basis for future virtualization integration development.

It also means that community Linux distributions will be able to use the code, which opens up more opportunities for Microsoft in the hosting market, where adoption of community Linux distributions such as Ubuntu, Debian and CentOS is significant. It also therefore slightly strengthens the challenge those community operating systems can make to Red Hat and Novell, which are more direct commercial challengers to Windows.

Make no mistake about it, Microsoft’s contribution is driven by its own interests. While it must serve and respond to enterprise customers that continue to drive the use of multiple operating systems and mixed environments, Microsoft also benefits by differentiating its Hyper-V virtualization technology from virtualization leader VMware. We believe Microsoft sees an opportunity to make virtualization with Windows more Linux-friendly than VMware.

Q. What’s in it for Linux?

A. The interoperability benefits previously reserved for ‘approved’ Microsoft partners will now be available licensed under the GPLv2, and available for all Linux distributions – commercial or community – without the need for a formal partnership.

The contribution of device drivers to the Linux kernel as been a sticking point for the Linux development community in the past as developers have struggled to encourage vendors to contribute driver code to the kernel. Microsoft is therefore setting something of a precedent and could encourage other vendors that have been reticent to contribute their drivers to do so.

The seal of approval Microsoft has given to the GPLv2 is also not to be overlooked. If Microsoft can find a way to contribute to Linux projects, many other organisations may also be encouraged to do so.

Q. I guess Linux is no longer “a cancer” then?

A. Exactly. Back in 2001 Steve Ballmer told the Chicago Sun-Times* “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That’s the way that the license works.”

Reviewing the statement in the context of today’s announcement demonstrates how much progress Microsoft has made in the intervening years to understand open source licenses. Contribution to Linux, or to any other project under the GPL, would have been unthinkable at the time, and is still barely believable today. The announcement is likely to challenge perceptions of Microsoft’s strategy when it comes to open source, Linux and the most popular open source license.

*The original article is no longer available online. Plenty of references are still available, however.

Q. What does this say about Microsoft’s overall strategy towards open source?

A. The contribution is a significant sign that Microsoft is now prepared to participate with open source projects on their own terms by using the chosen license of that project and making contributions directly to the chosen development forge of that project. Microsoft continues to use its own CodePlex project hosting site for code releases, but if an existing open source project uses SourceForge then Microsoft has acknowledged that the best way to engage with that community is on SourceForge. Don’t expect this to be the last contribution Microsoft does under the GPL.

Microsoft is now becoming more proactive in how it engages with open source under a strategy it describes as ‘Open Edge’ (which we have previously mentioned here and here. Whereas Open Core is used by commercial open source vendors to offer proprietary extensions to open source code, Open Edge is Microsoft’s strategy to encourage open source development and application deployment on top of its suite of commercial software: Windows, Office, Exchange, Sharepoint, SQL Server etc.

The Open Edge strategy is rooted in attempting to ensure Microsoft’s commercial products continue to be relevant to the ecosystem of developers and partners that the company has attracted to its software platform. It is also a continuation of the realization that if customers and developers are going to use open source software, Microsoft is more likely to retain those customers if it helps them use open source on Windows et al.

For more details on Microsoft’s strategy towards open source, its partnerships with open source vendors, and its contributions to open source projects, see The 451 Group’s formal report on the contribution to Linux (the report will shortly be available via this link ).

Q. How is the contribution to the Linux kernel being handled?

A. The contribution is being made via an alliance with the Linux Kernel Driver Project and its maintainer, Greg Kroah-Hartman, who will steward the contribution into the Linux kernel code base. (Greg has a post up about it here).

Q. What are the intellectual property issues?

A. The copyright for the code will remain with Microsoft, with the contributor credit going to its engineering lead, Hank Janssen, group program manager at Microsoft’s Open Source Technology Center.

Q. And patents?

A. If we were putting money on the most likely conspiracy theory to emerge in response to this news it would be that this is a Trojan horse and Microsoft is contributing code to Linux that it will later claim patent rights over. Whether that is even theoretically possible depends on your understanding of the GPLv2.

The GPLv2 contains an implicit patent promise that some would say makes a Trojan horse impossible. However, the FSF obviously thought it necessary to introduce a more explicit patent promise with the GPLv3 to remove any doubt.

Ultimately this is a question for a lawyer, or an eloquence of lawyers (yes it is ironic, apparently). In the meantime, it is our understanding that Microsoft’s understanding is that contributing code using the GPLv2 includes a promise not to charge a royalty for, or assert any patents covering, the code being contributed.

Q. What about Microsoft’s prior claim that Linux infringes its patents?

A. Microsoft really dropped the ball on its communication of the suggestion that free software infringes over 200 of its patents, and tensions with free and open source software advocates are likely to continue to be tested by Linux-related patent agreements, such as the one struck with Melco Holdings last week, which have driven scepticism and mistrust of Microsoft among some key open source supporters.

Absent the company giving up on software patents altogether, we believe that in order to convince those FOSS advocates that it is serious about co-existence, Microsoft needs to find a way to publicly communicate details about those 200+ patents in such a way that is not seen as a threat and would enable open source developers to license, work around, or challenge them. We also believe that the company is aware of this, although finding a solution to the problem will not be easy. But then neither was contributing code to Linux under the GPLv2.

UPDATE – It has subsequently become clear that there were two important questions that were not answered by our Q&A. Those have been covered by an addendum – UPDATE.

Pressure, progress flow at Linux Plumbers Conference

This week’s Linux Plumbers Conference in Portland was a great opportunity for many of the Linux kernel community people to get together, challenge one another, hash out some differences and hone their similarities and synergies. What strikes me as perhaps most interesting is that while there was some discord felt throughout the event among the different Linux camps, this conglomerate of developers representing a range of different vendors in a variety of different ways all do one thing common to all of them: push the kernel forward.

One of the biggest ripples at the three-day conference, which drew about 350 Linux plumbers (the developers who work on the kernel, libraries, utilities, interfaces and other code that are Linux), was Greag Kroah-Hartman’s opening keynote, which included some less than favorable references to Ubuntu distributor Canonical and its contributions to the kernel. Much of the discussion, like most of those from the LPC, centered on technicalities and distinctions. Talk about Canonical’s actual kernel system contribution, and it may be minimal compared to leaders Red Hat and Novell. However, consider Canonical’s work on Gnome, KDE, desktop packaging and installation, and its code contribtion is much more significant. So goes the reasoning of Canonical CTO Mark Zimmerman, who also complains that Kroah-Hartman was not prominently identifying himself as a Novell employee during his keynote and criticism of Canonical.

Kroah-Hartman — rightfully a respected kernel and Linux community contributor, participant and leader — does seem to be taking a bit of a confrontational approach to Canonical. Consider that much of the LPC discussion I heard and was involved in centered on his employer Novell, its partnership with Microsoft and lingering resentment and skepticism over the deal. While I think the partnership is proving beneficial to both vendors, particularly with a focus on interoperability over IP and patent issues, there is still some apprehnesion, particularly among up-and-coming developers, about what Microsoft’s involvement in Novell’s Linux business will mean. Novell continues to employ and support some of the brightest kernel hackers, including Kroah-Hartman and many others. It is the second largest contributor of changes to the Linux kernel, behind only Red Hat. Nevertheless, the developer focus of LPC offered a developer-centric view, and many of the people I talked to have higher regard for Red Hat, and some, yes, for Canonical because of Novell’s involvement with Microsoft. We must also consider other factors and contributions to fully appreciate the significance of the collaboration, multiple players and vendor-neuatral approach in Linux. As for Red Hat, it maintains perhaps the most enterprise-effective yet open Linux developer communities in the industry (including Fedora). Beyond its code contributions, Canonical has arguably done more for Linux usability than any other single entity, all while maintaining an open, active developer community.

In another example of free and open source software communities airing and ironing out their differences, we had the Firefox EULA brouhaha this week (subsequently resolved with little fanfare). Who was it urging calm, respect, practicality and patience: Canonical CEO Mark Shuttleworth. That alone speaks to not only his own leadership, but also to the leadership, positive impact and contribution of Canonical. It is one of many contributions made by many different organizations and individuals, all of which should be considered in the context of the larger Linux ecosystem and what they do for it.

Lack of Linux support is … lacking

Early last year, Greg Kroah-Hartman led a Linux kernel development effort to address lacking support for hardware devices and drivers in Linux. Kroah-Hartman even devoted more of his work to the driver project and then put out another call for companies to come forward with their Linux driver issues. This work is highly commendable and is the kind of thing that gives Linux staying power in a variety of uses, including server, mobile, embedded and desktop computing.

But now comes word from Kroah-Hartman that there is actually a dearth of devices that are not supported by Linux. Similar to a recent kernel development study, news on the lack of hardware support issues comes with a status report on the Linux Driver Project. It now has driver code in the kernel and the interest of more than 300 Linux developers. But the real story is that, as Kroah-Hartman says, ‘It turns out that there really isn’t much hardware that Linux doesn’t already support.’ More importantly, he adds, ‘Almost all new hardware produced is coming with a Linux driver already written by the company, or by the community with help from the company.’

This says a lot about how far Linux has come, and it also tells us that the future for Linux looks bright because the open source OS is emerging as just another checklist item for OEMs, device makers, ISVs and others. Given the overwhelming support of hundreds of Linux developers and the underwhelming vendor response, Kroah-Hartman searched for the reason(s) that the great Linux support shortage appeared to be a myth. Having already pointed out that Linux supports more different devices than any other OS in the world, Kroah-Hartman reports he found that nobody seemed to know why this was ranked as a big concern for Linux. Fast forward to today, and we see the Linux Foundation no longer has driver support among its top things to be addressed.

In response to the fact that most vendors report their hardware and devices are already supported by Linux, the Linux Driver Project is changing its main thrust into an effort of education, which has already proven critical to ‘cleaning up’ and actually moving driver code into the kernel, according to Kroah-Hartman. The idea is to educate vendors on becoming members of the Linux kernel community and getting driver support incorporated into the OS. Given Linux has managed to muster support for so many different devices already without that education, spreading the word will only increase the operating system’s advantages, yes advantages, in driver support.

The Linux lowdown from the source

The Linux Foundation has put out a fascinating study on Linux kernel development, who’s doing it and how fast things are moving. In reading through the report, I’ve picked out some of the statistics and points that stood out to me:

There have been almost 10,000 patches in each recent ~quarterly Linux kernel release. Releases include work from ~1,000 developers and ~100 companies. Since 2005, Linux has had more than 3,600 individual developers and more than 250 companies contributing to the kernel.

The individual development community has tripled in the last three years. The top 10 developers have contributed 15% of changes, and the top 30 developers have contributed 30% of changes to the kernel.

Linus Torvalds is 27th on the list of contributors with most changes over the last few years. He has 495 to his name. The list is led by Al Viro, with 1,571 changes, David S. Miller with 1,520 changes and Adrian Bunk with 1,441 changes. Andrew Morton is fifth with 1,222 changes and Greg Kroah-Hartman, co-author of the report, just edged out Linus to rank 26th in contributed changes at 496.

In terms of the companies contributing to Linux, the bulk of contributions come not from any individual companies, but in true Linux and open source fashion from community developers. More than 11,500 or 14% of kernel changes have come from developers with no commercial entity backing their Linux development. Another 13% of changes come from developers with ‘unknown’ commercial affiliation. When we get to actual companies, Red Hat leads with 9,351 kernel changes, or 11.2%. Next is Novell with 8.9%, IBM with 8.3% and Intel with 4.1% of kernel changes. Others with more than 1% of contributed kernel changes include: Linux Foundation, SGI, MIPS Technologies, Oracle and MontaVista.

As further evidence of increasing commercial support and contribution to Linux, the report authors said despite the large number of kernel changes coming from those with no or unknown commercial affiliation, more than 70% of all kernel development is demonstrably done by developers who are being paid for their work.

From the 2.6.11 kernel to the 2.6.24 release (1,140 days), there were an average of 2.8 accepted patches applied to the Linux kernel tree per hour. An average of more than 3,600 lines of code is added to the Linux kernel tree every day. Since 2005, the kernel has grown at a steady rate of 10% per year.

The Linux Foundation, which rightly points out that vendor participation is strategic and competitive rather than charitable, concludes that current work on server, desktop and embedded Linux should sustain the growth of Linux development. The latest Linux Foundation study serves as a good measure of where the OS is today and how it is progressing. It also highlights why Linux remains a shining example of how open source software development is supposed to work.