Open Source Is a Cost-Allocation System  🔗 **Source:** [Open Source Is a Cost-Allocation System](https://dri.es/open-source-is-a-cost-allocation-system) > [!note]+ Document Notes > > [!info] Provenance > > **Analysis generated:** 2026-08-27 by Claude (Opus 5) via the `readwise-deep-read` pipeline. > > **Source:** dri.es — https://dri.es/open-source-is-a-cost-allocation-system > > **Published:** 2026-08-27 · **Length:** 856 words · article > > **Author:** **Dries Buytaert** — `[STATED]` self-identified in the closing bio, *"I'm the creator of Drupal and co-founder of Acquia."* Reader's `author` field is the bare domain. > > **Disclosed interest:** `[EVIDENCE]` The Acquia affiliation is stated on the page. `[INFERENCE]` Acquia is a commercial Drupal vendor and therefore a large consumer of the infrastructure discussed. Noted for calibration — the position is also long-held: all three "keep reading" links are his own prior posts developing the same argument. > > **Register key:** `[STATED]` author-stated · `[EVIDENCE]` demonstrated · `[INFERENCE]` reviewer inference · `[RECOMMEND]` reviewer recommendation. > > **Coverage:** Full article read (856 words, 4 links, 1 image, 1 `<h2>` — all enumerated). > > **Verification performed:** The WordPress comparison below was **checked against WordPress 7.0.2 source** (`~/.wp-tests/wordpress/wp-includes/update.php`), not inferred. The internal arithmetic of his traffic estimate was also worked through. > # 🏷️ Title: Open Source is a cost-allocation system > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Drupal Core's release history](https://updates.drupal.org/release-history/drupal/current) — the ~0.5 MB file at the centre of the example > - [License-only versus Stewarded Open Source](https://dri.es/license-only-versus-stewarded-open-source) > - [Balancing Makers and Takers](https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source) > - [Open Source infrastructure deserves a business model](https://dri.es/open-source-infrastructure-deserves-a-business-model) > ## 📝 Summary > **The reframe.** `[STATED]` *"Open Source is usually described as a licensing model, a development model, or a production model. All three descriptions are useful, but they leave something out. **Every Open Source ecosystem is also a cost-allocation system.**"* > **The mechanism, in two moves.** `[STATED]` Open Source *"breaks the link between access and payment"* — but *"separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users."* And the consequence that matters: `[STATED]` *"Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund."* > **The claim worth keeping.** `[STATED]` *"Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later."* > `[INFERENCE]` **Architecture is cost allocation.** That is the portable finding, and it is stronger than the funding argument it sits inside. > **The worked example.** Drupal sites poll `updates.drupal.org` daily, sending **one request for core plus one per contributed project** — `[STATED]` *"A site with 100 contributed projects therefore makes 101 requests each time."* The design was sound at the time: static files, no per-request rebuild. Today the service handles `[STATED]` *"nearly a billion requests a month"*, core's release-history file is `[STATED]` *"roughly half a megabyte"*, and he estimates `[STATED]` *"roughly 50 to 75 TB of data transfer each month"* for core checks alone. > `[STATED]` *"No one chose to make updates.drupal.org transfer tens of terabytes of release data each month."* > **The governance structure, and this is the real analysis:** site owners **benefit**, the Drupal Association **pays**, and Core committers **decide** — `[STATED]` *"The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own."* > **Bottom line.** `[INFERENCE]` A genuine reframe with an excellent worked example and one careful restraint most people in this argument abandon. Two things it leaves out: **the fix has a name**, and **WordPress already made the opposite architectural choice** — verified in source below. > ## 📖 Main Content > ### The unnamed antipattern, and why naming it matters > `[EVIDENCE]` 101 requests for 100 projects is the **N+1 problem**, moved from the database to HTTP. The article describes it precisely and never names it. > `[INFERENCE]` Naming it matters because **the fix is well understood and cheap to state**: batch the request — one call carrying a manifest of installed projects, one response. `[INFERENCE]` And that sharpens rather than weakens his argument. If the remedy were obscure, the persistence of the problem would be a *technical* story. **Because the remedy is a solved pattern any engineer would recognise, the persistence is evidence for exactly his thesis** — the obstacle is that decision authority and cost-bearing sit in different places. > `[RECOMMEND]` `[INFERENCE]` **The second lever is larger than batching and goes unmentioned: the half-megabyte file.** Core has two decades of release history, and a site checking for updates needs to know one thing — *is there anything newer than what I have.* Truncating to recent releases, or serving a delta from a supplied current version, would cut the payload far more than deduplicating requests would. > ### The question his own numbers raise > `[INFERENCE]` Working the arithmetic through, because it is checkable and he invites it: > - 50–75 TB ÷ 0.5 MB ≈ **100–150 million core requests/month** > - Against *"nearly a billion requests a month"* total → **core is roughly 10–15% of requests** > - So contributed-project requests are ~6–9× core requests, implying an **ecosystem average of roughly 6–9 contributed projects per site** > `[INFERENCE]` That is internally consistent, and it is **an order of magnitude below the "100 contributed projects" site in his illustration.** The illustration is explicitly hypothetical and the aggregate cost stands either way — but the typical case is much lighter than the example implies, which is worth knowing before reasoning about where the traffic actually comes from. > `[INFERENCE]` **The more important unanswered question is whether this traffic is cache misses.** A static file served over a CDN should support `ETag` / `If-Modified-Since`, and release histories change rarely. If the 50–75 TB reflects **full-file transfers on every check**, the client is not sending conditional headers — and the fix is a client-side HTTP header, not an architectural change. `[INFERENCE]` **That distinction decides how big the governance ask actually is:** adding conditional-request support is a far smaller thing to ask of Core committers than redesigning the update protocol. The article's framing assumes the larger ask without establishing that the smaller one has been tried. > ### WordPress made the opposite choice — verified in source > `[EVIDENCE]` I checked WordPress 7.0.2 rather than assuming. `wp_update_plugins()` in `wp-includes/update.php` makes **one** `wp_remote_post()` to `http://api.wordpress.org/plugins/update-check/1.1/`, with the entire plugin list in the request body: > ```php > 'body' => array( > 'plugins' => wp_json_encode( $to_send ), > 'translations' => wp_json_encode( $translations ), > … > ``` > `[EVIDENCE]` The timeout even scales with the payload — `$timeout = 3 + (int) ( count( $plugins ) / 10 )` — which is only meaningful for a single request carrying many items. Themes follo Because the right to use the software is not tied to payment, the license does not connect the people who benefit, the people who decide, and the people who bear the costs. Projects have to build those connections deliberately through governance. AUG 27, 2026 View from under a sturdy stone bridge toward a fragile wooden bridge in the distance, with two people standing on it. Open Source is usually described as a licensing model, a development model, or a production model. All three descriptions are useful, but they leave something out. Every Open Source ecosystem is also a *cost-allocation system*. Keeping software relevant and dependable requires people to write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations. Someone always bears those costs. A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases. Open Source breaks the link between access and payment. Anyone can redistribute the software at any price, including zero. Payment is therefore not a condition of using or redistributing it, and those rights do not themselves provide a durable mechanism for funding production and maintenance. But separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users. A maintainer may volunteer their time. An employer may pay a developer to contribute. A foundation may operate infrastructure. Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund. Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later. Drupal's update service recently gave me a good example. Drupal sites periodically contact `updates.drupal.org` to ask whether new versions of Drupal or any installed add-ons are available. Drupal calls these add-ons "contributed projects", such as modules and themes maintained by members of the community. The current design sends one request for Drupal itself and one for every contributed project installed on the site. A site with 100 contributed projects therefore makes 101 requests each time it checks for updates, by default, once a day. There were good reasons for that design. Each project's release history could be stored as a static file and served repeatedly without rebuilding it for every request. The design was straightforward, and it worked. But Drupal grew. Today, `updates.drupal.org` serves nearly a billion requests a month. The file containing [Drupal Core's release history](https://updates.drupal.org/release-history/drupal/current) is roughly half a megabyte by itself. Based on the number of requests for that file, I estimate that Drupal Core update checks alone may account for roughly 50 to 75 TB of data transfer each month. Traffic for contributed projects comes on top of that. No one chose to make `updates.drupal.org` transfer tens of terabytes of release data each month. That scale emerged gradually as Drupal grew, from a design that had been reasonable when the ecosystem was smaller. Part of the challenge is that, in Open Source, the people who benefit, the people who decide, and the people who bear the costs are often different and may have no formal obligations to one another. Site owners benefit from reliable update notifications, usually without paying the Drupal Association for them. Drupal Association staff operate the update service, while the Association bears its traffic and infrastructure costs. But the code that determines how sites make those requests lives in Drupal Core, where changes require the involvement of Core committers. The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own. In practice, Drupal Association staff and Core committers collaborate closely. That collaboration matters because decision-making authority and cost-bearing sit with different groups. The people bearing material costs need a way to make those costs visible and influence the decision, even if they do not control it. This example shows why every Open Source architecture is also a cost-allocation system. Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable. Understanding an Open Source system therefore requires more than understanding its code or license. We also need to understand who benefits, who decides, and who bears the costs as the system grows. Once those relationships are visible, a community can decide whether the allocation is sustainable or whether the architecture should change. #### Keep reading * [License-only versus Stewarded Open Source](https://dri.es/license-only-versus-stewarded-open-source)Some Open Source is simply shared. Some is maintained as infrastructure. Naming the difference changes the conversation. * [Balancing Makers and Takers to scale and sustain Open Source](https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source)To scale and sustain Open Source ecosystems in a more efficient and fair manner, Open Source projects need to embrace new governance, coordination and incentive models. * [Open Source infrastructure deserves a business model](https://dri.es/open-source-infrastructure-deserves-a-business-model)Open Source infrastructure is essential, invisible, and chronically underfunded. A more sustainable approach may be to connect the cost of running that infrastructure to the organizations that rely on it most. Join 5,000+ readers. I'm the creator of Drupal and co-founder of Acquia. I write about Open Source, AI, and the future of the web, with a focus on building, scaling, and thinking long-term., Open Source Is a Cost-Allocation System, Dries Buytaert, 01m12nkdb6022bw2hx47hm08p5.