# A Project Is the Community, Not the Code The durable asset of an open source project is its **community** — the people, trust, accountability, and shared context — not the source code. Code is the artifact the community produces; it is not the project. Libby Clark draws the line cleanly: *"Successful and sustainable open source projects have always been more than code. The people who show up and contribute turn code on the Internet into a community that supports and grows the codebase, makes it useable, and sometimes even starts technology trends that move markets"* (Source: [[3. Resources/Readwise/Articles/Why Open Source Foundations are the IDEs for People and Communities|Why Open Source Foundations are the IDEs for People and Communities]]). The negative case is the sharper statement of the same claim: *"Without a community, it is just free code on the Internet."* Forked, license-stripped, AI-reproduced code with no people around it isn't a project — it's a file. This becomes newly urgent because **AI makes the code cheap, which raises the relative value of the community layer.** When a coding agent can generate a plausible implementation of almost anything, the scarce and valuable thing is no longer the code — it's the relationships that turn code into something sustained. Clark: *"Coding assistants may be good at generating code, but no IDE is going to create the relationships that build successful open source projects."* This is the open-source instance of a more general law: when an input becomes abundant, value migrates to whatever remains scarce and complementary — here, the human community. (The exact structural parallel is [[3. Resources/Permanent Notes/When Answers Are Cheap Understanding Becomes the Scarce Good]]: cheap answers raise the premium on understanding; cheap code raises the premium on community.) The claim reframes what *infrastructure* means for open source. Clark's metaphor is that foundations are "IDEs for people" — *"Established foundations have reached the point now where they can supercharge a project community – much like how AI-enabled IDEs empower developers"* — with the Valkey fork spinning up "in a matter of weeks" at the Linux Foundation after Redis changed its license as the worked example. The point isn't that foundations write code; it's that they provide the governance, trust, and coordination structures that let a community form fast and hold together. If the project *is* the community, then the highest-leverage investment is in the conditions for community, not in more code. <!-- atomicity: 1 idea ✓ --> ## Why This Matters For **open source governance**, this is a load-bearing premise that reorganizes the others. [[3. Resources/Permanent Notes/Maintainer Attention Is the Scarce Resource in Open Source]] follows directly — if the community is the asset, the maintainers' attention that sustains it is the binding constraint. [[3. Resources/Permanent Notes/Permissive Licenses Define a Floor But Don't Constitute a Community]] is the same claim from the legal side: a license governs the code; it cannot manufacture the community. And [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] sharpens *which* people count — the claim is about the contributing, accountable community, not raw user headcount. For **the WordPress moment specifically**, this is why governance fights are existential rather than cosmetic: a dispute that fractures trust damages the actual asset (the community), even when the code is untouched. It connects to [[3. Resources/Permanent Notes/Open Source Project Market Share Tracks Founder Trust]] — market share follows trust, because trust is the community's binding agent. For **AI strategy**, it predicts where defensibility moves. If anyone can regenerate your code, your moat is the community you can't regenerate — which is an argument for investing in [[3. Resources/Permanent Notes/Stewardship Invests in Contributor Capacity Not Just Cash]] precisely as AI commoditizes the code layer. ## Counterpoints to Hold - **Code quality still gates community.** A project with a thriving community but unusably bad code doesn't survive either; the claim is that community is *necessary and the scarce input*, not that code is irrelevant. The two aren't substitutes. - **Some hugely consequential code has ~no community.** A single-author library (or an AI-generated one) can power enormous downstream value as pure dependency. "Just free code on the Internet" can still matter a lot — the claim is about *sustainable projects*, not about whether code-without-community is worthless. - **"Community" can be romanticized.** Communities also produce toxicity, bikeshedding, and capture; more community is not strictly better. The asset is a *healthy, accountable* community, which is harder to build than the slogan implies. - **Foundations aren't the only community-infrastructure.** Clark (writing from a foundation vantage) frames foundations as the answer; companies, BDFLs, and informal norms also produce community. The "IDE for people" metaphor is suggestive, not exhaustive — and foundations bring their own governance failure modes. ## Links - [[Open Source Projects Are Not Communities by Default]] — extends: code and users become a project community only when relationships, shared practice, and accountable participation are intentionally formed. - [[3. Resources/Literature Notes/We'll Take Community Seriously When It's Embedded Into the Product Experience]] — applies-in: embedding member interaction in the product treats community experience as part of the offering itself. - [[WordPress.org Contribution Consideration if it is just Matt Mullenweg's Website]] — applies-in: the note separates GPL-covered core work from labor contributed to privately controlled community infrastructure, showing why code ownership alone doesn't settle project legitimacy. - [[Soft Skills for Community Managers]] — evidence-for; communication, conflict resolution, empathy, and coordination are the day-to-day labor that makes a community more than a code repository - [[3. Resources/Permanent Notes/When Answers Are Cheap Understanding Becomes the Scarce Good]] — the exact structural twin: abundance in one layer (answers / code) raises the premium on the scarce complementary layer (understanding / community) - [[3. Resources/Permanent Notes/Maintainer Attention Is the Scarce Resource in Open Source]] — if community is the asset, maintainer attention is the binding constraint that sustains it - [[3. Resources/Permanent Notes/Permissive Licenses Define a Floor But Don't Constitute a Community]] — the legal-side version: a license governs code, it can't manufacture community - [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] — which people count: the contributing/accountable community, not raw user headcount - [[3. Resources/Permanent Notes/Stewardship Invests in Contributor Capacity Not Just Cash]] — the investment thesis that follows: fund the community layer, especially as code commoditizes - [[3. Resources/Permanent Notes/Open Source Project Market Share Tracks Founder Trust]] — trust as the community's binding agent; why governance fights are existential - [[3. Resources/Literature Notes/The Drupal Open Web Manifesto - Advancing the Principles of the Open Web]] — evidence-for; Drupal's manifesto defines the project through collaboration, shared principles, and an inclusive community rather than code alone. - [[3. Resources/Permanent Notes/Trademarking a Commons's Descriptive Terms Converts a Steward Into a Gatekeeper]] — applies-in: control over the shared name controls who may gather and act as the project community, not merely who may copy its code. ## Open Questions - If community is the asset, what's the *measure*? Contributor retention, decision-participation, trust — not stars or installs. Which metric actually tracks the asset? - Does AI-cheap code strengthen communities (frees humans for the relational work) or erode them (floods projects with low-context AI contributions that burn maintainer attention)? Both are plausible; which dominates? - Is the "foundation as IDE-for-people" metaphor durable, or does it overclaim — do foundations *supercharge* community or merely *administer* it, and when does foundation governance become its own capture risk? ## Source - [[3. Resources/Readwise/Articles/Why Open Source Foundations are the IDEs for People and Communities|Why Open Source Foundations are the IDEs for People and Communities — Libby Clark]] — "without a community, it is just free code on the Internet"; "no IDE is going to create the relationships that build successful open source projects"; foundations as community accelerators (Valkey fork in weeks at the Linux Foundation) - See also: [[Open Source Governance MOC]] and [[Commons & Community Governance MOC]] - [[3. Resources/Readwise/Articles/Proposal Restructure the Community Team Handbooks]] — shows documentation structure functioning as governance infrastructure for contributors. - [[3. Resources/Readwise/Articles/Automattic Releases Code for the People, a Documentary Short Arguing the Open Web Is Under Siege and Needs Defending]] — frames the open web as a community worth defending, not only a codebase.