The Open Source Model Is About Organization, Not Who Signs Your Paycheck

from the peer-production dept

Nick Carr points out a report from the Linux Foundation that finds that most contributions to the Linux kernel come from people who work at companies. Nick Carr says this is a sign of a "shift from the volunteer to the corporate model," which I think misses the point on a couple of different levels. For starters, most of the people contributing to the kernel are professional programmers, and most professional programmers have jobs in the software industry. So it's totally unsurprising that most kernel contributors work for software companies.

But Carr's observation also misses the point in a deeper way. What makes the open source model unique isn't who (if anyone) signs the contributors' paychecks. Rather, what matters is the way open source projects are organized internally. In a traditional software project, there's a project manager who decides what features the product will have and allocates employees to work on various features. In contrast, there's nobody directing the overall development of the Linux kernel. Yes, Linus Torvalds and his lieutenants decide which patches will ultimately make it into the kernel, but the Red Hat, IBM, and Novell employees who work on the Linux kernel don't take their orders from them. They work on whatever they (and their respective clients) think is most important, and Torvalds's only authority is deciding whether the patches they submit are good enough to make it into the kernel. Carr suggests that the non-volunteer status of Linux contributors proves that the Internet "doesn't necessarily weaken the hand of central management," but that's precisely what the open source development model has done. There is no "central management" for the Linux kernel, and it would probably be a less successful project if there were.

Reader Comments

Central Management

I would argue that there is SOME central management for the Linux kernel. After all, Torvalds does decide what makes it to the kernel, which is therefore a form of management. If everyone just mashed all their stuff together with no one acting as a manager in any sense, I do not think it would be as successful. It is good to have people who manage, what is not good is when the people who manage make all the decisions (like what should be worked on). When this happens, it stifles innovation because the managers do not possess all the creativity and all the ideas of who they manage. I do agree with the rest of what you said, that it has nothing to do with a corporate shift.

To be clear here- Nick Carr isn't talking about professional software developers who also make contributions on their own time. He's talking about people who get paid by companies just to work on open source projects. This still isn't a big deal, though, as long as their output still goes back to the community.

As far as management goes, there most definitely are project managers for open source projects. I can't think of a single successful open source project that doesn't have a well-defined road map for features.

Re:

If you look at the report he cites, it says "The numbers presented are necessarily approximate; developers occasionally change employers, and they may do personal work out of the office. But they will be close enough to support a number of conclusions." So the 70 percent figure isn't the percent of people who have full-time jobs as Linux kernel hackers. It's the number of people whose employer the study authors could determine. For a lot of them, hacking the kernel may be a small part of their job, or even a personal hobby that their employer puts up with to keep an otherwise-productive employee.

And I think there's a big difference between an open-source roadmap—which is often developed by consensus and is rarely followed to the letter—and a traditional top-down development project, in which the boss tells programmers what they're going to be working on. If Linus thinks a new feature is a great idea, but he can't find anyone to implement it, then it won't get implemented. If Steve Ballmer thinks a new feature in Windows is a good idea, you can be sure they'll have somebody working on it the next day.

Management

"Torvalds's only authority is deciding whether the patches they submit are good enough to make it into the kernel."

Not really. I mean, he does "good enough", true, but he also holds a large degree of control over the approach and methodology used. And if he happens not to agree with your choice of algorithm, then odds are that your code is NOT making it into the kernel.

The same goes with other OSS projects. I made a set of modifications to an object-relational mapping system to support multiple databases, and offered those changes to the project's owner. But I was told that no one else needed it (untrue) and so those changes were ignored.

And yes, one COULD fork the project, but that's a tremendous amount of work, and the majority of such approaches fail, or have extremely limited market share.

Too many people view OSS as some sort of nirvana, filled with selfless altruistic types, spending their own time solely for the public good. But OSS developers are people, and OSS projects have pretty much the same politics, arguments, and in-fighting as any other endeavor managed by human beings.

Re: Management

Michael Long wrote:

I made a set of modifications to an object-relational mapping system to support multiple databases, and offered those changes to the project's owner. But I was told that no one else needed it (untrue) and so those changes were ignored.

No big deal. Put up your patches on your own website, mention them (where appropriate) in discussion forums, USENET etc, keep them in sync with updates to the mainline sources, maybe even provide prebuilt packages for one or more popular distros. If you accumulate a sufficient community of users, then maybe some of them can help you with the maintenance. It's not a full-fledged fork, just a set of "contributed patches".

There's lots of this sort of thing around, e.g. netfilter/iptables stuff on netfilter.org that's not in the mainline Linux kernel sources, bristuff patches for Asterisk etc. It's just another part of the ecosystem.