Maintainer Authority and the Fork as an Exit Mechanism

No open-source license grants authority over a project. Every one of them grants rights over copies, and none says who may merge a patch, cut a release, or decide what the project is for. Authority in a project is therefore practical and infrastructural rather than licensed: whoever controls the canonical repository, the release credentials, the publishing accounts for package managers, and the name controls the project. A license is a precondition for that arrangement rather than its source, and the arrangement is what the community argues about.

The separation has a visible consequence. Because the license permits anyone to publish modified copies, the only thing a project can hold that a competing fork cannot is the name and the distribution channels associated with it. Everything else is up for grabs, which is why governance disputes in open source tend to be about trademarks, hosting, and release keys rather than about permission.

Where authority is written down

The smallest unit of authority is the merge right on the default branch. Whether a change lands is decided by whoever has that right, and every other convention exists to tell contributors how to make landing likely. Around it sit files that encode the arrangement in machine-readable or near-machine-readable form. The Linux kernel keeps a MAINTAINERS file listing, for each subsystem, one or more maintainers, a mailing list, and a status for the entry; pattern matching on file paths turns an incoming change into a routed message to the right people. Reviewers attend to some subsystems without holding the merge right at all, which separates the review role from the authority role.

Hosted platforms add an equivalent mechanism in a single configuration file that maps glob patterns to reviewers or teams, used to request review automatically. That file is easy to mistake for a permission system: it produces requests, not vetoes, and enforcement depends on branch protection rules that refuse merges bypassing review. The controlled vocabulary a project can choose between is narrow, which is the point: an incoming change either reaches the one person with the merge right or it does not.

The mailing-list convention carries a parallel vocabulary of trailers that record other people’s judgement on a patch while granting no authority: a reviewer’s approval, an acknowledgement from a subsystem’s stakeholder, and a line marking a co-author of the change. The kernel’s documentation treats a sign-off as an assertion about the right to submit the change, described in contribution agreements, and the other trailers as statements about the change rather than about rights.

Consensus, votes, and vetoes

Decisions are made by one of three mechanisms, and the choice between them is a trade-off between speed and the cost of dissent. The first is a single decision-maker: a project where one person has final say, on the model of a long-serving founder. It is fast and it fails as an institution, because the mechanism has no answer for succession.

The second is a committee, typically a small technical steering body or a board appointed by a foundation. It scales past one person and introduces the problem of representing a community that no committee was elected by.

The third is consensus, which is the least self-explanatory of the three because it is often mistaken for voting. A standards-body document on the subject states the point directly: consensus in that context is not a majority and not unanimity, and the chair’s job is to judge whether an objection is a substantial technical objection the group has to answer or a preference held by one participant. The practice of testing the room by asking for a hum is a way of measuring the intensity of support without recording individual votes. The relevant feature for a code project is that consensus-based decisions require someone with the standing to call the question, which relocates authority from the vote into the chair’s judgement.

Voting systems that do exist in projects often include a veto rather than a majority rule: a single negative vote on a code change by someone with commit rights stops the change until the objection is answered. The design trades throughput for the guarantee that no substantive objection is overridden by arithmetic. Projects that adopt it accept slow merges as the price.

The awkward case for all three mechanisms is a project whose contributors are employed by competing companies. A committee seat then represents an employer’s interest in the result, and neutrality has to be built from procedure, which is where stewardship by an organisation with no product to sell enters the picture, covered under neutral stewardship.

The fork, and what it cannot take

Every open-source license permits modification and redistribution, so a fork is always procedurally available: copy the tree, change the name, publish. The last step is where the trademark bites. A license grants copyright permissions and, in the permissive and copyleft families alike, deliberately grants nothing over the project’s names or logos. The Apache License 2.0 states that no trademark license is granted by the license; the GPL does not transfer names either. A fork therefore ships under a different name, which is why forks rename rather than continue an identity.

The costs beyond the rename are the reasons forks are rare in relation to the disputes that precede them. The fork starts with none of the packaging integration that distributors maintain against the original project’s name, none of the release infrastructure, and none of the user base’s habits. Attention is the scarcest input: a fork splits the review capacity of the same set of contributors, and if it fails to attract maintainers it becomes an unmaintained copy that still consumes the original project’s contributors.

Historical forks show the mechanisms at work. GNU GCC split in 1997 when a set of developers who wanted faster release cycles and a more open process continued development as EGCS, and the two were re-merged in 1999 when the governance differences were settled, so the fork acted as leverage rather than as a permanent split. The XFree86 implementation of the X Window System was forked in the early 2000s after a licensing change, and the successor organisation’s tree became the reference upstream. The LibreOffice fork of OpenOffice.org in 2010 followed a governance dispute between a community and the vendor that held the trademark, and the fork took the community with it while leaving the name behind. The Jenkins fork of Hudson in 2011 followed a comparable dispute over who controlled the project, and the renamed successor became the project that development moved to. In each case the license made the fork possible; in most of them the decisive resource was not code but people.

Failure modes of authority

Three failures follow the structure rather than any individual mistake. The first is concentration: a project whose only person with release credentials becomes unavailable, and whose repository settings give nobody else the ability to publish, is effectively frozen while remaining installed everywhere. Bus factor is a statement about credentials and succession, not about code quality.

The second is abandonment without death. An upstream stops making releases while distributors continue to carry the last one, patching it locally, so the project’s effective governance moves to whoever maintains the packaging. Contributions have nowhere to go, and the last release’s license, frozen in place, is what downstream will hold indefinitely.

The third is capture of the operational assets: a hosting account, a package-publishing account, or a project’s name being transferred to a party the contributors did not choose. Because none of these are covered by the license, none of them can be recovered by the ordinary fork, and projects that care about it move the assets under a steward with a stated policy for who controls them, at which point the trade-offs become the ones described in what a foundation holds.

Succession is worth designing for before any of these failures appear, and it is an infrastructure question more than a social one. Merge rights on a hosted repository are granted per account, so a project whose default branch can only be written by one account has a single point of failure that no amount of contributor goodwill resolves. Release credentials have the same shape: signing keys, package-publishing tokens and domain registrar access are held by individuals, and the practical remedy is duplication, with several people able to publish and a documented process for who may do it. Projects that have exercised the handover once, by adding a second release manager while the first is still active, discover the undocumented dependencies in their process at a moment when discovering them is cheap.