Cover of Working in Public

Working in Public

Nadia Eghbal

6 ideas

  1. Four Types of Open Source Communities

    Open source projects can be classified along two axes — high or low contributor growth, and high or low user growth — yielding federations, clubs, stadiums, and toys. Stadiums (one or few creators, massive user base) are increasingly common and behave differently from the collaborative federations people imagine when they think of open source.

  2. Attention Is the Scarce Resource, Not Code

    Making code freely available is cheap and abundant, but a maintainer's attention to review contributions, answer questions, and triage issues is finite and non-scalable. The real cost of open source is not writing software but the ongoing human labor of maintenance, which does not scale with the number of users.

  3. Contributions Can Be Net-Negative

    A new contribution is not automatically valuable; reviewing, merging, and maintaining it imposes a permanent cost on the maintainer that can exceed the benefit. This inverts the assumption that more participation is always good — sometimes the most valuable act a maintainer performs is saying no.

  4. Creators as Solo Producers, Not Collaborators

    Modern open source increasingly resembles individual creators with audiences rather than communities of equal collaborators, mirroring platforms like YouTube or Twitch. Viewing maintainers as creators reframes their challenges as those of audience management and personal sustainability rather than coordination among peers.

  5. Excludable vs Rivalrous Goods Distinction

    Open source code is non-excludable and non-rivalrous — anyone can use it and one person's use doesn't deplete it — but the maintainer's attention is rivalrous. The funding problem arises because people try to monetize the abundant non-rivalrous good (code) when the actual scarcity lies in the rivalrous good (human attention).

  6. Funding Should Target People, Not Projects

    Because value in open source flows from specific individuals' sustained attention and judgment rather than from the code artifact itself, sustainable funding should support maintainers as people rather than financing discrete projects or features. The goal is to retain the person's continued engagement, since their replacement is costly and often impossible.

Save and mark ideas in the app