The speed and agility of open source projects benefit from lightweight and flexible governance. Their ability to run with such efficient governance is supported by the potential for project forking. That potential provides a discipline that encourages participants to find ways forward in the face of unanticipated problems, changed agendas, or other sources of disagreement among participants. The potential for forking is a benefit that is available in open source projects because all open source licenses provide needed permissions.
In contrast, standards development is typically constrained to remain in a particular forum. In other words, the ability to move the development of the standard elsewhere is not generally available as a disciplining governance force. Thus, forums for standards development typically require governance rules and procedures to maintain fairness among conflicting interests.
What do I mean by "forking a project"?
With the flourishing of distributed source control tools such as Git, forking is done routinely as a part of the development process. What I am referring to as project forking is more than that: If someone takes a copy of a project's source code and creates a new center of development that is not expected to feed its work back into the original center of development, that is what I mean by forking the project.
Forking an open source project is possible because all open source licenses permit making a copy of the source code and permit those receiving copies to make and distribute their modifications.
It is the potential that matters
Participants in an open source project seek to avoid forking a project because forking divides resources: the people who were once all collaborating are now split into two groups.
However, the potential for forking is good. That potential presents a discipline that drives people to find a way forward that works for everyone. The possibility of forking—others going off and creating their own separate project—can be such a powerful force that informal governance can be remarkably effective. Rather than specific rules designed to foster decisions that consider all the interests, the possibility that others will take their efforts/resources elsewhere motivates participants to find common ground.
To be clear, the actual forking of a project is undesirable (and such forking of projects is not common). It is not the creation of the fork that is important. Rather, the potential for such a fork can have a disciplining effect on the behavior of participants—this force can be the underpinning of an open source project's governance that is successful with less formality than might otherwise be expected.
The benefits of the potential for forking of an open source project can be appreciated by exploring the contrast with the development of industry standards.
Governance of standards development has different constraints
Forking is typically not possible in the development of industry standards. Adoption of industry standards can depend in part on the credibility of the organization that published the standard; while a standards organization that does not maintain its credibility over a long time may fail, that effect operates over too long of a time to help an individual standards-development activity. In most cases, it is not practical to move a standards-development activity to a different forum and achieve the desired industry impact. Also, the work products of standards activities are often licensed in ways that inhibit such a move.
Governance of development of an industry standard is important. For example, the development process for an industry standard should provide for consideration of relevant interests (both for the credibility of the resulting standard and for antitrust justification for what is typically collaboration among competitors). Thus, process is an important part of what a standards organization offers, and detailed governance rules are common. While those rules may appear as a drag on speed, they are there for a purpose.
Benefits of lightweight governance
Open source software development is faster and more agile than standards development. Lightweight, adaptable governance contributes to that speed. Without a need to set up complex governance rules, open source development can get going quickly, and more detailed governance can be developed later, as needed. If the initial shared interests fail to keep the project going satisfactorily, like-minded participants can copy the project and continue their work elsewhere.
On the other hand, development of a standard is generally a slower, more considered process. While people complain about the slowness of standards development, that slow speed flows from the need to follow protective process rules. If development of a standard cannot be moved to a different forum, you need to be careful that the required forum is adequately open and balanced in its operation.
Consider governance by a dictator. It can be very efficient. However, this benefit is accompanied by a high risk of abuse. There are a number of significant open source projects that have been led successfully by dictators. How does that work? The possibility of forking limits the potential for abuse by a dictator.
This important governance feature is not written down. Open source project governance documents do not list a right to fork the project. This potentiality exists because a project's non-governance attributes allow the work to move and continue elsewhere: in particular, all open source licenses provide the rights to copy, modify, and distribute the code.
The role of forking in open source project governance is an example of a more general observation: Open source development can proceed productively and resiliently with very lightweight legal documents, generally just the open source licenses that apply to the code.
Comments are closed.