A record built from merged work

LWN's per-release development statistics count the commits that land in each kernel version and attribute them to the individual developers and employers behind them. A recent cycle drew roughly fourteen thousand commits from over two thousand developers across more than two hundred organizations. The unit of record is the merged patch, logged as it happens rather than reconstructed after the fact. Source: https://lwn.net/Articles/989528/

How a merge-based process assigns credit

The kernel accepts changes through a review process in which a maintainer approves each patch before it enters a subsystem. Every accepted change is recorded against its author in a public commit history that anyone can read. Because contribution is captured at the moment of merge, the record is a byproduct of how the work already flows, not a separate bookkeeping task laid on top of it.

Authority that accrues from the log

In this model influence over a subsystem accumulates from a history of accepted changes rather than a title. A maintainer earns review authority by having shipped and reviewed relevant code, and that history sits in the same log everyone else reads. Compared with a conventional organization, where standing is assigned by role, position on a chart carries no weight the commit record does not already reflect.

• Merged patches are the unit of standing.
• Review authority accrues from accepted work.
• The public log is the shared source of truth.

The attribution most projects lack

The kernel keeps a continuous per-contributor account because its process demands one. The engineering difficulty for everyone else is that a comparable record does not appear on its own. Many smaller projects and teams operate without a running log of who did what, so contribution is remembered informally, which makes it harder to reconcile later when ownership or credit comes into question.

What an explicit record gives a team

A durable log of merged work lets collaborators answer questions about credit and standing from evidence rather than memory. When the record is explicit, attribution becomes something a team can point to instead of debate. Reconstructing that explicitness for a small group whose work is not public code is the open problem, and it is the one any contribution-aware system has to solve to make standing reflect delivered work rather than tenure.