# The Maker-Taker Frame Confuses Two Different Scarcities Buytaert's Maker-Taker model identifies a real tension in open source: companies that profit from a project without investing in its maintenance create an asymmetric burden on those who do. But the model conflates two different kinds of scarcity, and that conflation leads to governance proposals that miss the actual problem. The software itself is anti-rivalrous. More users increase its value through bug reports, edge cases, documentation, and network effects. As Toderash emphasizes, "I am not only not harmed when you share an anti-rival good: I benefit." The traditional free-rider problem doesn't apply to the code. But Buytaert's real insight is that the customer is rivalrous: "For end users, Open Source projects are public goods; the shared resource is the software. But for Open Source companies, Open Source projects are common goods; the shared resource is the (potential) customer." When an end user becomes a customer of Company A, that same user won't become a customer of Company B. Here's the problem. The Maker-Taker frame treats these two scarcities as one thing, then proposes governance for the bundle. Contribution credit systems, marketplace visibility requirements, and social shaming campaigns all target the code-contribution side. But the actual rivalry is on the customer side. A company could contribute heavily to the codebase and still capture customers that other contributors feel entitled to. The Drupal credit system partially solves this by tying marketplace visibility to contributions -- but that's a commercial incentive dressed as community governance. It rewards code contributions with customer access, which conflates the two scarcities rather than addressing them separately. Toderash's critique sharpens the point further. The Maker-Taker model requires that maker and taker compete directly for a limited customer pool. When those conditions aren't met -- when a "taker" brings new users to the ecosystem, when the customer pool is growing, when the products don't directly compete -- the "taker" label becomes a tool for asserting entitlement rather than identifying harm. ## Why This Matters If you're designing open source sustainability models, separate the two problems. Fund maintainer attention directly (the actual scarce resource). Compete for customers through product quality, not through contribution-shaming. Governance proposals that conflate anti-rivalrous code with rivalrous customers will produce credit systems that feel coercive and miss the point. <!-- atomicity: 1 idea ✓ --> ## Links - [[3. Resources/Permanent Notes/Standards Governance Benefits From Categorical Precision Over Comprehensive Definition]] — evidence-for: separating code abundance from maintainer scarcity shows how a precise category can clarify governance better than a totalizing label - [[3. Resources/Permanent Notes/Stewardship Invests in Contributor Capacity Not Just Cash]] — applies-in: capacity investment targets scarce maintainer attention, while a cash-only maker-taker frame can leave that bottleneck unchanged - [[3. Resources/Permanent Notes/The Inverse Commons]] — evidence-for: code abundance paired with scarce maintainer attention is the inversion the maker-taker label collapses - [[3. Resources/Permanent Notes/The Stadium Is the Dominant Open Source Pattern]] — applies-in: a large user audience and tiny contributor core make the two scarcities visible in participation data - [[3. Resources/Permanent Notes/Coerced Contribution Kills the Commons]] — constrains: treating every user as a delinquent maker turns a scarcity diagnosis into pressure that damages voluntary contribution - [[3. Resources/Permanent Notes/Ostrom-Theology Crossover - Commons Governance in Faith and Code]] — extends: commons governance allocates scarce attention through rules and boundaries instead of relying on a moralized maker-taker binary - [[3. Resources/Permanent Notes/Matt Mullenweg WCUS 2024 Keynote - WP Engine]] — evidence-for: the keynote's moral comparison between firms treats code contribution and scarce maintainer capacity as one contribution ledger - [[3. Resources/Permanent Notes/Permissive Licenses Define a Floor But Don't Constitute a Community]] — extends: the license permits taking code, while the social layer must address the rivalrous attention and customer resources the frame conflates - [[3. Resources/Permanent Notes/Public Credit Mechanisms Are the Visible Skeleton of Open Source Social Contracts]] — applies-in: visible credit can recognize scarce maintenance work without treating anti-rivalrous code use as theft - [[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/Full Document Contents/Articles/Balancing Makers and Takers to Scale and Sustain Open Source]] - [[3. Resources/Readwise/Full Document Contents/Articles/Reframing the Maker-Taker Problem]] - [[3. Resources/Readwise/Articles/Solving the Maker-Taker Problem]] - [[3. Resources/Readwise/Books/Working in Public|Working in Public]]