Three Levels of FOSS Governance

From P2P Foundation
Jump to: navigation, search

Three “Levels” of Institutions that may exist in FOSS projects

Studies of the institutional design of natural resource commons have focused on three institutional “levels” (Ostrom, et al., 1994; Ostrom, 2005; Schweik, 2005). The first level, the “Operational-level”, is a general name for rules that influence the everyday decisions and actions made by project participants. In a FOSS setting, these are the norms or rules that specify how the further development and support of the software may proceed. The type of FOSS license used and the collaborative platform used for version control (e.g., CVS, subversion) establish some operational-level rules.

The second institutional level, “Collective-Choice,” (Ostrom, et al., 1994) is the generic name for two types of rules. The first type defines who is eligible to undertake certain operational-level activities. For example, in most projects there is probably some kind of norm or rule that specifies who has authority to promote or “commit” some code to the “next release” library. In some projects, this authority might be highly centralized; in other projects, the authority might be quite distributed, allowing each developer to promote their code when they feel it is ready. The other type of collective-choice rules specifies who can change operational-level rules and the procedure to follow to make such a change. For instance, as more developers join a project, there may be a need to change the operational-level rule on how code is reviewed before being promoted. Collective-choice rules would determine how a new operational procedure would be agreed upon and changed.

Constitutional-level rules are the third tier of institutions. Constitutional-level rules specify who is allowed to change collective-choice rules and the procedures for making such changes. One example in a FOSS setting might be when the recognized leader of a project decides to move on to a new opportunity. Constitutional-level rules might specify who takes over in this person’s absence. Another example is the case where a FOSS project operating entirely by volunteer developers becomes “embraced” by a commercial firm. This entry by a firm may (or may not) change who is involved in collective-choice processes." (


Tragedy of the FOSS commons? Investigating the institutional designs of free/libre and open source software projects by Charles M. Schweik and Robert English. First Monday, volume 12, number 2 (February 2007),