Last week on ‘Linux Goes Corporate’: After Nick Carr mentioned my post on the Linux Foundation report and on Linux as corporate joint venture, Timothy Lee and Ed Cone/Clay Shirky responded and then Doc Searls put in his two cents worth. The main point of the responses is that the shift from hobbyists to professionals is not important. For example:
"the open source model is about organization, not who signs your paycheck" (Lee).
"the idea that the minute you pay people to do something, you have the right to manage them and the right to completely take over that work for the benefit of the company — that’s not true" (Shirky).
"in all the conversations I’ve had over the years with kernel
developers, none has ever copped to obeying commands from corporate
overlords to bias kernel development in favor of the company’s own
commercial ambitions. In fact, I’ve only heard stories to the contrary" (Searls).
The professionalization of Linux matters because it marks a change. Open source now is not the same as ten years ago when The Cathedral and the Bazaar was written.
Despite the historical revisionism of the "paycheck’s don’t matter" crowd, the absence of paychecks certainly mattered ten years ago. Eric Raymond opened his classic essay with these sentences:
Linux is subversive. Who would have thought even five years ago that
a world-class operating system could coalesce as if by magic out of
part-time hacking by several thousand developers scattered all over
the planet, connected only by the tenuous strands of the Internet?"
Ten years on what stands up? "several thousand developers scattered all over the planet" does – the number of participants in the Linux kernel is larger than ever. But the Linux kernel now is not developed by "part-time hacking". And Linux is no longer subversive, in that anything IBM is happy about is not, by definition, subversive.
And it mattered six years ago when Yochai Benkler wrote "Coase’s Penguin: Linux and the Nature of the Firm", which contains this statement:
Programmers do not generally participate in a project because someone who is their boss instructed them, though some do. They do not generally participate in a project because someone offers them a price, though some participants do focus on long-term appropriation through money-oriented activities, like consulting or service contracts.
So now programmers do participate in the Linux kernel because their boss instructed them to (or paid them to).
Now I can imagine people saying that just because the Linux programmers are paid, that doesn’t make their motivation financial and that doesn’t mean companies can tell them what to do. Here is Lee:
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.
This is a caricature. I work in a commercial, closed-source software company, and my job is very close to that of a project manager. But what an expert programmer spends his or her time on is always a negotiated thing. Partly it’s a matter of skill and expertise (who is best placed to identify algorithms or code-level weaknesses and areas for improvement?), partly it’s a matter of "what needs to be done" and partly it’s a matter of innovation. And as Joel Coehoorn says in a comment to Lee’s post, "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." Open source believers too often portray paid closed-source programmers as wage slaves, and paid open-source programmers as free agents working for love (to scratch an itch) who just happen to collect a paycheque. It’s a dichotomy that just doesn’t hold up.
Shirky argues that "the idea that the minute you pay people to do something, you have the right to manage them…that’s not true" but this statement applies to the employees where I work just as much as to IBM employees working on the Linux kernel, and there is nothing about the Linux kernel that gives Redhat programmers a special "ignore the boss" license. Shirky says that "If [a senior manager] announced a strategic change in the kernel they would be laughed out of the room" as if senior managers routinely dictate strategic changes in the Windows kernel or database kernels. More senior managers get laughed out of the room than Shirky would believe.
This leaves us with ownership. IBM and Redhat do not own and will never own Linux. But Redhat sells Linux, and the ability to sell something is one component of ownership. The distinction is more one of exclusive ownership. And here the Visa analogy I used originally holds up – Visa is now a separate company but it is also a collaborative venture and companies that helped to build it were simultaneously assisting their competitors. Industrial sponsorship of academic research – an activity the pharmaceutical industry relies on – has the same tensions about ownership and organization and direction.
Open source, like any new phenomenon, is changing. Our understanding of it has to change too. The Linux Foundation report prompts us to re-examine some of the neat and clean dichotomies that were floated around ten years ago and see if they still hold water. A few do, but many don’t.
“But what an expert programmer spends his or her time on is always a negotiated thing. Partly it’s a matter of skill and expertise (who is best placed to identify algorithms or code-level weaknesses and areas for improvement?), partly it’s a matter of “what needs to be done” and partly it’s a matter of innovation.”
This is the most important sentence I’ve read in years about managing professional software folks. The expert developer is 10 to 50 times more productive than the average programmer. (Some studies say 100 times.) Its an art. You have to get the artist to accept the commission as a collaboration. If you think that a command flowing down the hierarchy is going to work, you are as out of touch as Dilbert’s PHB.
They don’t work for money. They do want to get paid for their work, but its a target rich environment for the experts.
One of the most important characteristics of open source development is the durable relationship between the developer and the code. With proprietary software the programmer is alienated from the code. I am alienated from it: it belongs to someone else. No matter how much of myself I invest in proprietary work, I know that when I move on I must leave it behind.
With open source, the code remains associated with me. I own it. I am the world expert on it. But for open source, ownership means responsibility, not exclusive control. I can take the code with me; in a sense, it also takes me with it. The work I do locates me in a community. And communities are defined by the durability of their relationships. I have a relationship with whoever pays me, but I also have a relationship with whoever uses the software. Similarly, they have a relationship with me and the community. For example, when someone pays me to enhance open source software, my past clients also benefit.
In the market and in business, relationships are often contingent and temporary. Effective businesses must understand that a relationship with open source is not simply a business relationship: it means participation in a community. They may fear that the ties between developers and the community weaken their commitment to the company. This may be partly true – open source does change the relationship between programmers and their employers. In exchange, however, businesses gain by being linked into that community. This is what Apple recognized when they made an extra effort to support KHTML developers, and what I suspect Nicholas Negroponte may be failing to appreciate as his management of the OLPC project alienates open source developers and supporters.
Having read some of the comments I still feel that many comments come from a moralistic view about open source versus proprietory software, most are open source = good, proprietory = bad, but some the reverse.
But a simple game theory approach is sufficient to answer most questions on open source, such as fork or contribute.