Modularity in Open Source

We have a general treatment of modularity in our wiki, which discusses modularity in the context of industry and culture.

Here, we continue our processing of a number of important essays on peer governance in open source communities, and specifically, the following essay:

Of Hackers and Hairdressers: Modularity and the Organizational Economics of Open-source Collaboration. By Richard N. Langlois (The University of Connecticut, [email protected]) and Giampaolo Garzarelli (Università degli Studi di Roma, [email protected]). Journal Industry & Innovation, Volume 15 Issue 2 2008

There is a draft version here, from which we quote. Published version is here.

The authors use the following definition:

a modular system is a nearly Decomposable System that preserves the possibility of cooperation by adopting a common interface. The common interface enables, but also governs and disciplines, the communication among subsystems.”

In lay people’s terms it means that in a modular system, the parts stand on their own, and are coordinated as a whole, but you can change the part by itself. By contrast in integral systems, the parts are intrically connected to the whole, and you cannot change the parts without central permission.

The authors show that open source is clearly based on modularity, starting with the very kernel development for Linux:

All in all, then, modularity seems a powerful and elegant solution to the problem of coordinating the intellectual division of labor. No less a figure than Linus Torvalds has testified to the value of modularity in the arena of opensource software.

“With the Linux kernel it became clear very quickly that we want to have a system [that] is as modular as possible. The [open-source] development model really requires this, because otherwise you can’t easily have people working in parallel. It’s too painful when you have people working on the same part of the kernel and they clash. Without modularity I would have to check every file that changed, which would be a lot, to make sure nothing was changed that would effect anything else. With modularity, when someone sends me patches to do a new filesystem and I don’t necessarily trust the patches per se, I can still trust the fact that if nobody’s using this filesystem, it’s not going to impact anything else. … The key is to keep people from stepping on each other’s toes. (Torvalds 1999, p. 108.)”

They then clearly outline both the costs and benefits of such an approach.

In our treatment of their article in our wiki, we highlight the following discussion points:

* 4.1 Modularity and Openness
* 4.2 Modularity and Decision Rights
* 4.3 Modularity and the Economics of Organization
* 4.4 Modularity and Innovation

Some salient points.

On openness: “As the community of open-source software developers clearly understands, openness does not mean only unfettered access to knowledge of the visible design rules of the system, though that may be a necessary condition. Rather, openness is about the right to take advantage of those design rules. More broadly, the degree of openness of a modular system is bound up with the overall assignment of decision rights within the intellectual division of labor. This is an organizational issue and – what may be the same thing – a constitutional issue.”

On decision rights: All other things equal, efficiency demands that the appropriate knowledge find its way into the hands of those making decisions. There are basically two ways to ensure such a “collocation” of knowledge and decision-making: “One is by moving the knowledge to those with the decision rights; the other is by moving the decision rights to those with the knowledge” (Jensen and Meckling 1992, p. 253). These two choices – as well as possible variants and hybrids – are “constitutions” that set out the assignment of decision rights. Such assignments can take place within firms or within wider networks of independent collaborators. In what follows, we distinguish three models: corporate, hybrid, and spontaneous. … For any division of intellectual labor we choose, behavior and performance will be different if we assign decision rights to some central authority rather than to the individual collaborators.

The opposite of a corporate model would a fully decentralized one in which the collaborators retain the ultimate decision rights. But just as the central holder of decision rights in a corporation must in practice cede de facto decision rights to others, so in a decentralized system the collaborators must give up some pieces of their rights in order to collaborate.”

For more, see also our entry on Governance Rights.

On organizational transaction costs and effort trading:

The only way to trade effort is by setting up a firm. Perhaps the most intriguing aspect of the
open-source model is that it flies in the face of this assumption: under the right circumstances, it is possible to cooperate spontaneously on the effort margin, not just the product margin.

Rather than giving up their decision rights to others, open-source collaborators combine effort “voluntarily.” Voluntarily here means not that the collaborators do not receive pecuniary compensation (though that may often be true) but rather that the collaborators choose their own tasks.

Assignment of individuals to tasks – and, to an extent we will explore, even the overall design of the division of labor itself – arises from these voluntary choices, in much the same way that assignment of sellers to products in a classic market arises from self-selection.”

An important point is that they reject Benkler’s triarchy of corporation / firm / social production, in favour of a dichotomy which argues effort trading is a market form.

Regarding their last discussion on modularity and innovation, an important conclusion is that open source production is good for autonomous innovation but bad at systemic innovation:

A modular system is good at modular or autonomous innovation, that is, innovation affecting the hidden design parameters of a given modularization but not affecting the visible design rules. But a modular system is bad at systemic innovation, that is, innovation that requires simultaneous change in the hidden design parameters and the visible design rules – simultaneous change in the parts and in the way the parts are hooked together.

For example, this may be way open source may not be good for an automobile, where the engine is crucially integrated in the whole car, not just a module that may be taken in our out.

If there is any strong conclusion in their treatment of the various issues, it is probably their insistence that pure open source is rare, and that hybrid models dominate because they can combine advantages from distribution and centralisation simultaneously.

Langlois and Garzarelli:

hybrid models are actually far more typical of opensource software development than are genuinely voluntary or spontaneous ones. Indeed, perhaps all models of open-source software development are hybrid models.

To the extent that innovative hybrid arrangements are able to inject some of the benefits of central design and integrality into a modular structure, such innovations will tend to make modular arrangements more valuable and more widespread.”

2 Comments Modularity in Open Source

  1. Pingback: 21st Century Spirituality · Life stream of 2008-08-26

  2. Pingback: P2P Foundation » Blog Archive » Why Open Source development models may not be optimal for systemic innovation

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.