# Open Source Projects Are Not Communities by Default The open source world uses "community" as a default label for everyone associated with a project. Contributors, users, companies, casual visitors -- all get called "the community." This flattening hides a structural reality: most open source projects don't have communities at all. They have audiences. Jones and Vogl define community through specific criteria: members who share mutual concern for each other's welfare, a connected identity founded in shared values, and participation in shared experiences reflecting those values. By this standard, a GitHub project with 50,000 users and one maintainer fielding issues isn't a community. It's a stadium. Eghbal's taxonomy makes this concrete: the dominant open source pattern has high user growth and low contributor growth, producing a one-to-many social structure where the maintainer performs for an audience rather than participating in a group. "These developers aren't building communities; they're directing air traffic." The label matters because it determines governance expectations. Call something a "community" and people expect democratic input, shared ownership, mutual obligation, and collective decision-making. Apply those expectations to a stadium-model project and you get governance structures that slow down the maintainer, contributor onboarding programs that attract people who won't stay, and guilt about saying no to PRs from strangers. The community frame creates obligations the maintainer never signed up for. Spinks and Jones/Vogl both show that real community requires intentional architecture: boundaries that distinguish members from visitors, initiation that marks the transition, rituals that create shared meaning, and inner rings that provide depth. None of these happen by default in an open source project. If you want a community, you have to build it deliberately -- and that costs maintainer attention, which is already the scarcest resource. Some projects are better served by acknowledging they're stadiums and designing accordingly: protecting maintainer time, treating user requests as signal rather than obligation, and funding the individual rather than building governance for a collective that doesn't exist. <!-- atomicity: 1 idea ✓ --> ## Why This Matters Stop calling every open source project a "community" unless you've done the work to build one. The label creates expectations that burn out maintainers and disappoint users. If your project is a stadium, own it and design for that reality. ## Links - [[A Project Is the Community Not the Code]] — extends: if community is the durable project asset, then license, repository, users, and code remain insufficient until relationships and accountable participation form around them. - [[3. Resources/Permanent Notes/The Stadium Is the Dominant Open Source Pattern]] — evidence-for: a project can have a large audience and a tiny producer core without forming reciprocal community relationships. - [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] — extends: one-off participation remains use until sustained relationships and accountable contribution develop. - [[3. Resources/Permanent Notes/The Seven Principles Are a Community Diagnostic]] — applies-in: the diagnostic tests whether a repository has the structures of community rather than merely the label. - [[3. Resources/Permanent Notes/The Inverse Commons]] — evidence-for: open access can increase concentrated maintenance costs without creating the shared obligations of a commons community. - [[3. Resources/Permanent Notes/Belonging Requires Choice Connection and Progress]] — constrains: community begins only when participants can choose, connect, and advance toward a shared purpose. - [[3. Resources/Permanent Notes/Permissive Licenses Define a Floor But Don't Constitute a Community]] — extends: a license establishes the project's legal substrate, while relationships and governance determine whether a community exists above it - [[3. Resources/Literature Notes/Open Source Software Built by Programmers for Programmers]] — evidence-for: software made by programmers for programmers can still organize an audience without reciprocal participation or belonging. - [[3. Resources/MOCs/Commons & Community Governance MOC]] — applies-in: the MOC lists this note under Created. - [[3. Resources/MOCs/Open Source Governance MOC]] — applies-in: the MOC lists this note under Community Architecture. ## Source - [[3. Resources/Literature Notes/Community Architecture - What Makes Communities Thrive vs Extract - Literature Note]] - [[3. Resources/Readwise/Books/Working in Public]] - [[3. Resources/Readwise/Books/Building Brand Communities]] - [[3. Resources/Readwise/Books/The Business of Belonging]]