Open Source Firms as Conduits for Local Knowledge

An insightful post by Don Marti on the economics of peer production:

Linux started as a peer production project in 1991, and got its first vendor-supported device driver in 1994 and its first full-time paid contributor (Leonard Zubkoff, VA Research) in 1997. Leonard started off writing SCSI drivers in his spare time, then got a job doing RAID support — so that VA could sell high-margin boxes with RAID, not just the commodity one-processor, one-drive machines they started with.

Today, there’s a flexible and socially connected interface between the kernel team and the hardware companies. A driver developer has to be part of both organizations. The payoffs for plugging into both your company’s management structure and a peer production project include that you get to eliminate a lot of duplication of effort by having other people help with the infrastructure that supports your driver, and you get free code reviews and developer training. Greg says that at one company, one person maintains the Linux driver, and 150 are needed to maintain the driver for a common proprietary OS.

Ed Cashin explains the process as it works today.

Firms benefit from peer production not by throwing money at the peer production project as a whole, but by dragging it in the direction the firm wants it to go. And much of what the project wants from firms is to teach it how to be useful. When firms have attempted to “be good community members” by throwing money at projects, they fail to send that signal, and much of the money ends up being wasted on trying to figure out what the project’s users want.

I hadn’t thought of that last point before. It’s a great example of the Hayekian explanation for the success of non-proprietary development models. Computer scientists like to sit in ivory towers thinking about how an ideal kernel ought to work. But in fact, developing a good kernel requires lots of local knowledge: you have to interact with real users and see what features they need. And companies can be an excellent conduit for that local knowledge, because they’re in direct, daily contact with real users, but they also have engineers with the sophistication to explain to other kernel developers exactly what’s wrong. Hence, it make sense that companies will often have the most to contribute to an open source project if they’re fixing the problems that will, by fortuitous coincidence, also do the most to make their own customers happy.

SHARE: