The first Linux Plumbers Conference started on September 17, 2008; the
opening talk was a keynote by Greg Kroah-Hartman. He got the conference
going with with a provocative sermon on how the development ecosystem works
and the niche we all occupy within it. It was a fun talk - unless you
happen to work for Canonical.
He started with an apology to Canonical, though. In earlier talks, he had
said that only eight kernel patches had ever come from Canonical. In fact,
he has been corrected; the proper number is 100.
So, Greg asked, why is he picking on Canonical? His answer came in the
form of a table of contributors to the kernel. It looked like this:
Then Greg asked: does anybody from Canonical want to say anything? Nobody
Moving on to the Linux ecosystem. Greg put up a slide showing the larger
components of this ecosystem - the low-level stuff that makes Linux what it
is. Some of the largest components, beyond the kernel, were GCC,
binutils, X.org, and the man pages distribution. Looking at lines of
code, the kernel amounts to about 40% of the total. Other large components
are all significantly smaller.
It turns out that Greg has been doing repository data mining in a number of
projects beyond the kernel. So, for projects like GCC, X.org, and
binutils, he was able to put up tables listing the top contributors. The
results varied somewhat, but there were a number recurring themes. Red Hat
tends to be toward the top of the list on all of these projects; companies
like IBM and Novell also appear regularly. CodeSourcery is a significant
contributor to GCC and binutils. The U.S. National Security Agency
contributes 2.1% of the patches into X.org; why is not clear.
In all of these projects there are significant contributions from
unpaid developers, but those contributions are overshadowed by those from
And Canonical is always at the bottom of the chart - if it is there at all.
At this point Greg moved to a whiteboard to present his view of how the
community works. At the development level, you have developers
contributing to projects, which then release the code. There may be a few
users at that level who feed back information (and maybe patches), but, in
general, the biggest consumers of the project's releases are the
Distributors package everything and provide it to their users. At this
point, another feedback loop comes into play: users feed their experiences
and problems back to the distributor. Those distributors will respond to
the user feedback, improving their products. The amount of feedback from
the distributors to the upstream projects varies, but it tends to be
small. For enterprise distributions, it is quite small; they are running
ancient versions of everything and have little to do with current
upstream. The community-oriented distributions, such as Fedora or
openSUSE, tend to feed more changes back to their upstream sources.
Then, there is the matter of redistributors who base their products on
another distributor's work; these are distributors like Ubuntu or CentOS.
There are no contributions back to the community from that kind of
distributor at all. They are not functioning as a part of the Linux
Greg finished up with what appears to be the message he came to the Linux
Plumbers Conference to deliver: if you are a developer, if you want to be a
part of the ecosystem, and if you work for a non-contributing company:
quit. There are plenty of companies that understand the ecosystem and
which need good people; at least one company, it seems, had wanted to set
up a recruiting table at the conference. It is a very good time for people
with community participation skills; there is no reason for anybody who
wants to work in the community to stay on the outside.
[As a postscript, it is amusing to note that, while the conference did not
allow companies to set up recruiting tables, nobody has prevented
prospective employers from filling a prominently-placed whiteboard with
information about available positions.]
to post comments)