Linux Grows Up and Gets a Job

Linux started as a hobby project. But it is now 17 years old and it has grown up, and a recent report by the Linux Foundation, which extends a series of investigations by Jonathan Corbett, shows that it is no longer a hobby, it is out in the working world.

The report looks at the Linux kernel, and so does ignores all those other pieces of the operating system (drivers, applications, desktop interfaces and so on). Still, the kernel is the heart of the OS and "one of the largest individual components on almost any Linux system. It also features one of the fastest-moving development processes and involves more developers than any other open source project." So this report, which "looks at how that process works, focusing on nearly three years of kernel history as represented by the 2.6.11 through 2.6.24 releases." is a valuable window on what may happen to successful open source projects as they mature.

One of the highlights: "over 70% of all kernel development is demonstrably done by developers who are being paid for their work". 14% is contributed by developers who are known to be unpaid and independent, and 13% by people who may or may not be paid (unknown), so the amount done by paid workers may be as high as 85%. The Linux kernel, then, is largely the product of professionals, not volunteers.

So Linux has become an economic joint venture of a set of companies, in the same way that Visa is an economic joint venture of a set of financial institutions. As the Linux Foundation report makes clear, the companies are participating for a diverse set of commercial reasons. Some want to make sure that Linux runs on their hardward. Others want to make sure that the basis of their distribution business is solid. And so on, and none of these companies could achieve their goals independently. In the same way, Visa provides services in many different locations around the world in different sizes and types of stores. Some banks need their service mainly in one country, some in another, but when they work together they all get to provide their services all around the world.

This does not mean that Linux was always a commercial venture, or that all open source projects are commercial ventures. To invoke another parallel, open source software is a creative venture like music. Many people create music for all kinds of reasons. Most people create music for an audience of one when they hum in the kitchen or sing in the shower. A smaller (but still huge) number of people get together to form groups or participate in orchestras or bands. They don’t earn a living from it, but they love doing it and enjoy their performances. Some might dream of hitting the big time, others are happy being part of their community. Then a much smaller set of people take it a step further. Maybe they are paid to be in an orchestra; maybe they are in a band with a manager and bar gigs around the country. And a lucky few, of course, hit the big time. They get a record deal, find a big audience, and make some real money.

So is music produced for love or for money? Both of course, in various proportions across the spectrum. Open source started off as a small-scale set of projects done mainly by volunteers. As the scale and scope of open source projects an increasing number have provided their contributors with some money (augmented perhaps by a waitressing job). Now a few of the most successful have hit the big time and become full-scale economically important commercial enterprises.

Things change. As open source software has matured and expanded it has become both more unlike the rest of the world and more like it. It will be fascinating to see what comes next, but the Linux Foundation report has made clear that open source has crossed its commercial Rubicon, and there is probably no going back.

Update: follow-up and response to some discussion here.

Bookmark the permalink.

4 Comments

  1. The high proportion of paid workers is of interest, but possibly not surprising.
    In IT developments in large companies, for example a trades database and lifecycle processing module in investment banks, individual departments are often faced with a decision whether to co-operate with other departments on continued development of a piece of common software, or to take the current version and go it alone.
    The advantage of going alone is that you have control on content and life cycle. In the above example, you can get your products in the db and managed in the way you think this is right, and you don’t have to wait on department X to complete their work before you can release your work.
    There are two main disadvantage of locking yourself out of further developments. Most obviously you may lose out on incorporating future beneficial developments which you would otherwise get for free. Less obvious but possibly far more important, is that if you do not co-operate on the standard version, someone else may get their own version of what you are doing in the main version. In the above decision, department X may release their versions of your asset class and in a less satisfactory format, and down the road you could find yourself forced to use this version rather than your local version as eveyone else will be using this version.
    So the decision for professional companies to participate in open source software is a difficult decision, but one for which standard game-theory-like considerations can give clear guides, and often may encourage participation. At no stage do altruistic principles come into consideration.

  2. Open source as corporate joint venture

    A new report from the Linux Foundation reveals the extent to which the most famous and successful open source software project – the development of the Linux operating system – has shifted from being a volunteer effort to being a corporate initiative. …

  3. I wonder how this professionalization of the community changes the politics of the community, and specifically under what circumstances the corporations might attempt a palace coup against the benevolent dictator, whose dictates may cease to seem benevolent to a firm whose profits are on the line.
    It strikes me, in short, that this increases the chance, down the road, of forking.

  4. To Nils’ comment, I don’t think it makes any difference. Forks happen in any industry. Things like kernel development are hard and require serious skills, its not realistic to expect it to continue as a ‘hobby’ for long. So there are profits on the line, have been for at least all of this century.
    If you look at any ‘industry standards’ from standardized nut and bolt threads, to 120V power in the US, you see that the players try to push and shape the ‘standards’ to best suit their company’s products. The small guys can’t aford to send talented Engineers to conferences to vote on standards through days of boring meetings. The big guys know that they have to. They have to get, say the Oracle enhancements accepted, while pushing out the MySql and Sybase equivalents.
    Sun didn’t pay a billion dollars (with a BEE) for MySql out of community good will.

Comments are closed