Indeed, "Given enough eyeballs, all bugs are shallow.".

In this specific case there are rumors that there we probably only 4 eyeballs involved, which apparently was not enough ;-)

Whatever said and done, there is big responsibility with the various Enterprise distributions and various hardware/software vendors that relied on OpenSSL for their business without doing their due diligence. Whether it was because they all expected the other to have covered that space, or because the particular source code is not easy to audit is less relevant. And I am sure that many companies are looking what can be done to improve their processes in this space.

I expect in the coming months to see more fixes for new vulnerabilities because of new audits and security testing.

So if project A can handpick improvements from project B.
But project A creates 10x as many new improvements on its own.
And it has 10x as many contributors to its own project.
And project B is not allowed to merge back improvements (license-wise).

It simply means project A is going to win out in the long-run as long as the project stays as healthy as it is, no matter how healthy project B is. What project B can do in this case is make sufficient changes to the code-base so that improvements can not be easily merged into project A. Or make so many changes that project A runs out of resources to merge everything back into project A.

In this case specifically, it seems that AOO has the mindshare of the users and LO has the mindshare of the developers. It's more likely that a contributor knows what the difference is and where to contribute to. If ohloh.net does make something clear it is the divide between developers and users.

PS The 10x as many is taken for the sake of the argument, whether it is indeed 10x or 5x is irrelevant given enough time.

How about taking into account the holiday season ? I'd be interested to compare this with the trends for June, July, August and September the previous years, as I expect that browser-usage depends on sunny weather conditions, holiday-trips and people in the office browsing more with less work on their hands ? Maybe ?

On a global level this may mean not that much, but a 1% to 2% fluctuation could be addressed by this. So maybe we should wait until September or October before making any conclusions...

Nope, the Firefox usage numbers have always been higher in Europe than elsewhere. This has been a tendency for years. And Germany also has a historical aversion for Microsoft software and was in the past a big Linux proponent (think SuSE) and StarOffice (now OpenOffice) was bigger than Microsoft Office for years IIRC. I wouldn't be surprised if also OS/2 had a larger following to elsewhere (or at least US).

All this predates any anti-trust settlement, but I am sure that change will make a difference too, but the trend was always present.

Red Hat did not exit the desktop market, it always offered an Enterprise desktop Linux product and heavily invested in desktop development (which is what this article is about as well) and Fedora.

Red Hat also never said there was no future in Linux desktops, it basically said there is no money to be made in a consumer desktop offering at that moment, regardless of the investments they do.

Canonical is the living proof that you cannot survive on a consumer desktop Linux offering, that's why they are trying to leverage Ubuntu's installation base to get into the Enterprise server market, and are looking at different possibilities to sell you services on top of Ubuntu (think cloud).

So the Gnome census report shouldn't come as a surprise, regardless of how outspoken Mark Shuttleworth and Ubuntu's userbase is. Red Hat is the biggest contributor to Open Source and Linux, and they also have the most to gain from it too.

I am confident Canonical would like to trade places with Red Hat anytime, and until that happens they prefer to pretend they are leading Linux, rather than leading Linux development.

Not true, there is a whitelist kABI for interfaces that are guaranteed to not change. If I recall correctly, even the nvidia driver worked fine going from a RHEL5.4 kernel to a RHEL5.5 kernel. So it's not guaranteed that all drivers keep on working on any 2.6.18 kernel, but the large majority simply do.

Visit the ELRepo project page (http://elrepo.org/) or read the following document to learn how it works:

http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf

You could have saved yourself the embarrassment if you would have visited the ELRepo website (http://elrepo.org/) and tested it for yourself, or you could have googled for kABI or kABI-tracking modules. (Welcome in 2010 !)

The large majority of the drivers compiled against one kernel do indeed work for *all* 2.6.18 kernels. Only a few of them (those that do not use what's inside the kABI whitelist) have to be recompiled against a new major release kernel if an interface did change.

http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf

The kABI whitelist is an evolving list based on feedback from vendors, customers and the community.

As one of the members of the ELRepo project (http://elrepo.org/), I would like you to take a look at the collection of drivers (kernel modules) that the project has backported to the RHEL5 2.6.18 kernel. In total more than 400 drivers have been ported and a large majority of these drivers work for every 2.6.18 kernel that was released (from 2.6.18-8.el5 until 2.6.18-199.el5), thanks to the kABI whitelist. Including exotic stuff like nvidia or video4linux.

So I fail to see the worse of both worlds. But then again, I may be biased of actually using, deploying and working with those kernels.

Tell that to the Ubuntu guy that had filesystem problems and required Red Hat's assistance to get it fixed. Ubuntu was impacted, Fedora was impacted, Red Hat's kernel was not. Why ? Because they were not running the latest and greatest. But a kernel that has been selectively patched and improved, by kernel developers that know exactly what they are doing. It can't get better than that...

There are more systems running RHEL and CentOS kernels than there are systems running the latest. Not only because the total number of systems running RHEL/CentOS is much larger than any given distribution, but also because that kernel is the same kernel, while every Ubuntu or Fedora user is using their own kernel (9.10, 10.04, F11, F12) and not updating it at the same time. Whereas RHEL5 has had the same 2.6.18 kernel with the same track-record for the past 3 years.

So if you want to run what everyone else is running, you're better off with a patched and improved CentOS/RHEL 2.6.18 kernel.

Sorry the burst your bubble there...

What does this have to do with honesty ?

Red Hat is backporting the stuff their customers are demanding _and_ what they feel confident to support in a production environment _without_ breaking existing setups. That's the goal.

You don't do that by updating your complete kernel for one or two features you like to have. That would be insane.

Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.

The whole "backporting is ugly/dishonest" comes from people that have no clue about Enterprise computing or have hidden agendas. A bit of common sense goes a long way...