Open source contribution analysis

Open source contribution analysis is the practice of measuring who contributes to a project, how much, and how smoothly contributions move from first submission to merge. It treats contribution as a flow rather than a tally. A project with 500 commits a month that all come from one maintainer is in a very different state to one with 200 commits a month spread across 40 contributors. The analysis exists to tell those two states apart.

The reason it matters is sustainability and risk. A project that depends on a single person carries a bus-factor risk. If that person steps away, the project stalls. Contribution analysis surfaces this concentration early. It also reveals whether the project is welcoming. A long delay between a first-time contribution and its review is one of the most reliable predictors that newcomers will not come back.

The headline figure most teams track is community contribution share, the percentage of merged work that comes from outside the core team. But the share alone hides the dynamics underneath. A high share with a slow review queue can still mean a frustrating experience. Reading the metric properly means decomposing it into the stages a contribution passes through, much as you would decompose any throughput metric into its drivers.

There is no single equation for contribution health, because it is a composite of several signals. The most useful headline is community contribution share, but it should always be read alongside contributor breadth, review latency, and acceptance rate. Define each input clearly and measure it over a fixed period such as a calendar month.

1. 1

   Define core versus community contributors

   Decide who counts as a core maintainer, usually those with merge rights or a sustained history. Everyone else is a community contributor. This split underpins the community contribution share.

2. 2

   Count merged contributions

   Count contributions that were actually merged, not just opened. A merge is the signal that work crossed the quality bar and added value. Opened-but-rejected work belongs in acceptance rate, not the merge count.

3. 3

   Measure contributor breadth

   Count the number of distinct people who landed at least one merged contribution in the period. Breadth tells you how distributed the work is and is the direct counter to bus-factor risk.

4. 4

   Measure review latency

   Track the time from submission to first maintainer response, and from submission to merge. Slow first response is the friction point that drives contributors away before they ever land work.

5. 5

   Measure acceptance rate

   Divide merged contributions by total submitted contributions. A very low acceptance rate can mean a high bar or unclear guidelines, both of which deserve attention.

A worked example shows how the signals combine. In a month a project merges 120 contributions. Of these, 78 come from outside the core team, giving a community contribution share of 65 per cent. Those 120 merges come from 34 distinct contributors, so breadth is healthy. The median time to first response is 9 hours and the acceptance rate is 71 per cent. Read together, these say the project is open, responsive, and not over-reliant on any one person. Drop the response time to four days and the same community share would tell a much less encouraging story.

A metric tree decomposes contribution health into the stages a contribution moves through and the factors that govern each stage. This turns a vague sense of project momentum into a diagnosable structure.

The first level splits health into the journey of a contribution. Attraction covers whether new people show up and open work at all. Review covers how fast and fairly submissions are handled. Merge throughput covers how much actually lands. Retention covers whether contributors come back for a second and third time. Each branch then breaks into specific, ownable causes, such as documentation quality, reviewer availability, or the clarity of contribution guidelines.

The structure lets maintainers diagnose precisely. If community share is falling, the tree shows whether fewer people are arriving, whether the review queue is choking, or whether first-time contributors are not returning. Each answer points to a different and concrete action.

Benchmarks for contribution health vary with project size, governance model, and how mature the community is. A young project backed by one company looks very different to an established foundation project. Use these ranges as orientation, then track your own direction of travel.

Pair the share with review latency to read the benchmark honestly. A 60 per cent community share with a 9-hour first response is a thriving project. The same share with a two-week first response is a project leaking contributors faster than it can recruit them. The composition and speed matter more than the headline percentage.

Improving contribution health means lowering the friction a contributor meets at each stage, from finding something to work on to seeing it merged. The largest gains usually come from faster review and from making the path for newcomers obvious.

The metric tree approach starts by finding the stage with the biggest gap between current and achievable performance. If review latency is high, adding reviewers helps more than recruiting newcomers who will only wait in a slow queue. If attraction is low, better documentation and first issues come first.

KPI Tree makes this actionable by giving every branch a clear owner. Maintainers own review responsiveness and merge throughput. The community team owns attraction and retention. When a node moves, the change is pushed to the accountable owner, so a sudden rise in review backlog reaches the person who can clear it rather than hiding in a report. The verified impact loop then confirms whether the action, such as adding two reviewers, actually shortened the queue.

1. 1

   Counting commits instead of merged contributions

   A raw commit count rewards volume over value. Squashed merges, rebases, and trivial changes all distort it. Count merged contributions weighted by meaningful change instead.

2. 2

   Ignoring the core-versus-community split

   Without separating maintainer work from community work, a project run almost entirely by its founders can look thriving. The split is what reveals concentration and bus-factor risk.

3. 3

   Reading share without review latency

   A high community share can mask a queue that drives contributors away. Always pair the share with time to first response and time to merge.

4. 4

   Treating all contributors as equal

   A first-time contributor and a long-standing maintainer experience the project very differently. Segment by tenure so you can see whether newcomers are landing work and returning.

5. 5

   Optimising attraction while review stays slow

   Recruiting more contributors into a slow review process just creates more frustrated people. Fix the queue before pouring effort into the top of the funnel.