Three different levels of value
In my June 2021 GitHub case, I separated personal repository hosting, collaboration with an existing team, and contributions from the wider developer community. A user could get value from hosting before a large public network formed. An existing team could benefit before strangers contributed.
The founders invited Ruby community contacts and hosted their own projects, including Grit and God. Engine Yard provided hosting in exchange for a footer promotion; Merb, an Engine Yard project, became an early substantial project on GitHub. My account also described mirroring existing open-source projects. Those artifacts gave developers something to find and work on. These are historical mechanisms, not measured shares of GitHub’s growth.
Find the smallest useful group
I would draw the product at three sizes: one person, one existing group, and a much larger network. For each size, write down a result somebody can get today. If the first two boxes are empty, recruiting the next user has to compensate for a product that is not yet useful.
The smallest useful group is different from the smallest imaginable audience. A team that already works together brings context, trust, and a reason to return. A collection of unrelated signups may bring none of those things.
That distinction changes the invitation. “Move this shared project here” is easier to evaluate than “join our new community.” The first names the work and the people who need to do it.
Let the artifact explain the product
For a developer platform, a real project can make the service understandable in a way a feature tour cannot. A visitor sees the work, the people participating, and a possible next action.
I would choose seed projects for usefulness and fit, with their owners’ permission. Track whether visitors can understand the artifact and whether contributors can complete an appropriate first step. A famous name on a landing page is a weaker signal than a project people actually use.
Measure each layer on its own
Personal use, team collaboration, and wider network participation need separate measures. Hosting a repository does not prove a team collaborated. An invitation does not prove the recipient contributed. A public project does not prove it attracted outside contributors.
I would follow movement between those layers while keeping the first layer healthy. A user who stays for a useful individual workflow is still getting value. Forcing invitations too early can make that workflow worse.
Follow the artifact through the handoff
For a new developer collaboration product, I would follow a concrete sequence: a repository is created, a team member is invited, that person reaches the project, and useful work follows. Record the appropriate action—an issue, a contribution, or a clone—without pretending those actions have identical value.
Those are proposed measures, not results from the early GitHub case. The point is to see where the handoff stops. If people accept invitations but cannot contribute, another round of community promotion is unlikely to solve the immediate problem.
What I would keep
- Identify value available to one person.
- Name the smallest group that can benefit together.
- Seed useful artifacts with their owners’ permission.
- Measure personal, team, and wider-network activity separately.
The takeaway
A network can grow from useful small groups. Give those groups a complete job before asking them to make the network bigger.
Sources and original research
Adapted from my June 9, 2021 case study. Historical company claims come from that issue; the review questions are editorial guidance. This is not a current product audit or a measured causal growth result.
Updated September 20, 2026. Based on original First 1000 reporting and the sources listed above.