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 > <!-- deep-read:sections start --> ## 🧭 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 follow the same shape at `themes/update-check/1.1/`. `[EVIDENCE]` WordPress additionally throttles *frequency*, varying the check interval from immediate through 12 hours depending on context. `[INFERENCE]` **So the two largest PHP CMS ecosystems made opposite architectural calls on the identical problem: Drupal N+1 GETs of static files, WordPress one batched POST.** Same benefit to site owners, order-of-magnitude different cost to the infrastructure operator. `[INFERENCE]` **And this strengthens Dries's thesis rather than undercutting it.** The difference is not competence — Drupal's design was reasonable when made, as he says. It is that **two projects made a cost-allocation decision at different moments under different scale assumptions, and neither treated it as a cost-allocation decision at the time.** That is his argument, with a controlled comparison he does not have. `[RECOMMEND]` Worth noting the mirror-image risk: WordPress's batched POST cannot be served from a static CDN edge and must be computed per request. **WordPress traded bandwidth for compute.** That is still an allocation, just a different one — and the same "revisit when it becomes unsustainable" discipline applies. ### The three-way separation is the article's best analysis `[STATED]` *"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."* `[INFERENCE]` **Benefit, cost, and decision authority in three different places, with no formal obligation between them.** Stated that plainly it is obviously a governance problem; the reason it is not obvious in practice is precisely his point — **the diffusion is what makes it invisible.** `[EVIDENCE]` And the restraint is the thing to credit: `[STATED]` *"The people bearing material costs need a way to make those costs **visible and influence** the decision, **even if they do not control it**."* `[INFERENCE]` **He explicitly declines the obvious move** — *whoever pays should decide* — which is the argument that leads directly to vendor capture. Given that he co-founded the commercial vendor with the largest stake here, declining it is a meaningful choice rather than a rhetorical flourish. `[INFERENCE]` **Visibility plus influence, without control, is the harder and more defensible position**, and it is the sentence to quote from this piece. ### The counter-argument the article never engages `[INFERENCE]` There is a real case against the framing and it appears nowhere: **the cost diffusion is a feature, not a defect.** The reason anyone can redistribute at zero price is the reason the ecosystem grew large enough to generate a billion requests a month. Tightening the link between benefit and cost reintroduces exactly the friction the licence exists to remove. `[EVIDENCE]` He gets close — *"separating payment from access does not make the costs disappear"* — and then treats the diffusion purely as a problem to be managed. `[INFERENCE]` **The honest version is a trade-off with two sides:** diffusion buys adoption and costs sustainability, and the governance question is where to sit on that curve, not how to undo it. His actual prescription is compatible with this; the framing is not. ## 🗒️ Notes - **The opening enumeration is the piece's structural move**, and it is well made: licensing model, development model, production model — `[STATED]` *"All three descriptions are useful, but they leave something out."* `[INFERENCE]` Adding a lens rather than replacing one is why the argument is hard to dismiss. - **The cost inventory is concrete and complete**, which matters because it is usually left vague: `[STATED]` *"write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations."* `[INFERENCE]` Note that **only the first is what most people picture when they think about open-source labour**, and the other seven are where the cost concentrates. - **The proprietary contrast is stated fairly, not as a strawman:** `[STATED]` *"A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases."* `[INFERENCE]` No claim that this is better or worse — only that it is a *mechanism*, and that open source lacks it. - **"Individually reasonable" is doing important work.** `[STATED]` The allocation *"can emerge slowly from decisions that were individually reasonable and become visible only years later."* `[INFERENCE]` This forecloses blame as an explanation, which is what makes the piece a governance argument rather than a complaint — and it is the same shape as the WP Rocket post-mortem in this batch, where every individual triage step was performed correctly and the outcome was still bad. - **The image is a metaphor and its alt text is genuinely good:** `[EVIDENCE]` *"View from under a sturdy stone bridge toward a fragile wooden bridge in the distance, with two people standing on it."* `[INFERENCE]` Descriptive, complete, and it conveys the contrast the image is making — better alt text than most of this batch managed. - **Three prior posts on the same theme are linked**, which establishes this as a developed position rather than a reaction. `[INFERENCE]` *License-only versus Stewarded Open Source* in particular sounds like the taxonomy this piece assumes. - **The prescription is process, not policy:** `[STATED]` *"Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable."* `[INFERENCE]` Three verbs — consider, monitor, revisit — and the middle one is the one nobody does, because monitoring requires someone to own the metric. ## 📚 References `[EVIDENCE]` **Four links, three of them to his own prior posts**, plus one to the actual release-history file — which is the right link to include, since it lets a reader verify the half-megabyte claim directly. `[INFERENCE]` **No external source is cited**: no data on the request volume beyond his own estimate, no reference to other projects facing the same problem, no prior work on open-source cost allocation. `[INFERENCE]` For a short opinion piece from a project founder writing about his own project's infrastructure, primary knowledge is the appropriate basis and self-linking is legitimate continuity. **The gap that costs something is the absence of any comparison** — the argument would be materially stronger with one other ecosystem's numbers beside Drupal's, and one was available. ## 🗣️ Paraphrase We usually describe open source as a licensing model, a development model, or a production model. Those are all useful and they miss something: every open-source ecosystem is also a way of deciding who pays. Keeping software dependable takes real work — code, review, releases, security reports, infrastructure, documentation, support, migrations. Someone bears that. A proprietary vendor can tie access to payment, so every subscription funds some of it. Open source deliberately severs that link: anyone can redistribute at any price, including nothing. Severing it doesn't remove the costs, it scatters them — across maintainers, employers, foundations, sponsors, users. And because they're scattered rather than collected in one transaction, they're harder to see, and harder to fund. Technical decisions often determine where they land, usually without anyone intending it. Drupal's update service is an example. Every site asks updates.drupal.org whether there are new versions — one request for Drupal itself, one for each installed add-on. A site with a hundred add-ons makes a hundred and one requests a day. That was a sensible design: each project's release history could be a static file, served without recomputation. Then Drupal grew. The service now handles close to a billion requests a month. Drupal Core's release-history file alone is about half a megabyte, and Dries estimates core update checks account for 50 to 75 terabytes of transfer monthly, with add-ons on top. Nobody decided that. The structural problem is that the people who benefit, decide, and pay are three different groups. Site owners get the notifications, usually without paying. The Drupal Association runs the service and pays for the traffic. But the polling behaviour lives in Drupal Core, and Core committers don't report to the Association — so the Association can't change it alone. In practice they collaborate closely, which matters precisely because authority and cost sit apart. People bearing real costs need a way to make those costs visible and to influence the decision, even without controlling it. Good governance thinks about that allocation up front, watches it, and revisits it when it stops working. ## 📰 Newsletter **Dries Buytaert has the cleanest frame I've read on open-source sustainability, and it isn't about money.** *"Every Open Source ecosystem is also a cost-allocation system."* Open source breaks the link between access and payment — but *"separating payment from access does not make the costs disappear."* It scatters them across maintainers, employers, foundations and users. **And because they're scattered rather than collected in one transaction, they're harder to see, and harder to fund.** **The line to keep is about architecture, not funding:** *"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."* **The example is excellent.** Drupal sites poll for updates once a day — one request for core, one for each add-on. A site with 100 add-ons makes **101 requests**. Perfectly reasonable when built, because each release history could be a static file. Today `updates.drupal.org` handles **nearly a billion requests a month**, core's history file is **half a megabyte**, and he estimates **50–75 TB/month** for core checks alone. *"No one chose to make updates.drupal.org transfer tens of terabytes of release data each month."* **The governance shape is the actual finding: site owners benefit, the Drupal Association pays, Core committers decide** — and *"the Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own."* Three parties, no formal obligation between them. **Two things he leaves out, and one is a gift to WordPress people.** First, 101-for-100 is the **N+1 problem** in HTTP clothing, and the fix is a solved pattern — which *strengthens* his argument, because it means the obstacle isn't technical. Second: **WordPress made the opposite call, and I checked the source.** `wp_update_plugins()` sends **one** POST to `api.wordpress.org` with the whole plugin list in the body, and even scales its timeout by plugin count. Same problem, opposite architecture, order-of-magnitude different infrastructure cost. **That's not a Drupal-competence story** — it's two projects making a cost-allocation decision at different moments under different scale assumptions, neither treating it as one at the time. Which is exactly his thesis, with a controlled comparison he doesn't have. (WordPress traded bandwidth for compute: a batched POST can't be served from a static CDN edge. Still an allocation, just a different one.) **And the sentence to quote:** people bearing costs need to *"make those costs visible and influence the decision, **even if they do not control it**."* Coming from the co-founder of the largest commercial Drupal vendor, declining *whoever pays should decide* is a real restraint. ## ✅ Action Items #### DevRel - **Developer advocacy:** `[RECOMMEND]` **"Every architecture decision is a cost-allocation decision"** is a talk, and the Drupal/WordPress update-check pair is the demo — same problem, opposite choices, verifiable in both codebases. - **Education:** `[RECOMMEND]` Teach the **three-question audit** — who benefits, who decides, who pays — as a design review step, not a governance afterthought. - **Developer experience:** `[INFERENCE]` The reusable heuristic: **any client behaviour that scales with the number of installed extensions is a cost-allocation choice**, and the party bearing it is rarely in the room when it is made. - **Developer marketing / Community management / Cross-project:** Not applicable to this source. #### OSPO - **Policy & Governance:** `[RECOMMEND]` **Adopt the three-question audit at design time.** `[INFERENCE]` And note the middle verb in his prescription — *consider, **monitor**, revisit* — is the one that fails, because monitoring needs an owner and a metric, and neither is assigned by default. - **Software Inventory:** `[INFERENCE]` Infrastructure cost per ecosystem service is an inventory item almost nobody tracks, and it is what makes "revisit when unsustainable" actionable rather than aspirational. - **Community Engagement:** `[RECOMMEND]` The **visibility-plus-influence-without-control** formulation is the model for funder relationships. It is more defensible than either "funders decide" or "funders have no say." - **Security Management:** `[INFERENCE]` Update-check infrastructure is a security dependency, not just a convenience — an operator that cannot afford to serve it is a supply-chain risk. Not raised in the article. - **License Compliance / Developer Support / Strategic Alignment:** Not applicable to this source. #### Community - **Maintainers:** `[RECOMMEND]` Before shipping a client behaviour, ask what it costs at 100× current scale **and who pays that**. `[INFERENCE]` The Drupal design was correct at the scale it was designed for; nothing about it was wrong except that nobody re-asked. - **Sponsors:** `[INFERENCE]` The fundable thing is whatever the architecture has made invisible. `[INFERENCE]` This generalises the OCN finding in this batch — *"the machine gets unlimited code generation, the maintainer gets unlimited homework"* — to a rule: **fund the side of the asymmetry that architecture pushed cost onto.** - **Contributors / Ecosystem:** Not applicable to this source. #### WordPress - **Core:** `[RECOMMEND]` `[EVIDENCE]` WordPress already batches (`wp_update_plugins()`, one POST, timeout scaled by plugin count) — **that is a cost-allocation win worth knowing about and documenting as a deliberate property**, not an accident. `[INFERENCE]` The open question is the reverse allocation: a batched POST cannot be CDN-cached, so it costs compute rather than bandwidth. Is that monitored? - **Meta:** `[RECOMMEND]` The three-way separation applies exactly to WordPress. `[INFERENCE]` Site owners benefit from api.wordpress.org, the .org infrastructure bears the cost, and Core committers decide the client behaviour — **the same structure Dries describes, with the same absence of formal obligation.** This batch already contains the incident where that mattered: ~300,000 sites auto-updating prematurely during the 7.1 release. - **Hosting:** `[INFERENCE]` Hosts are the largest beneficiaries of update-check infrastructure and bear none of its cost — the clearest instance of the asymmetry in the WordPress ecosystem. - **Plugins / Themes:** `[INFERENCE]` Every additional plugin adds to the payload of a batched check rather than adding a request. Worth knowing which architecture you are adding load to. - **Core Performance:** `[INFERENCE]` The compute cost of serving batched update checks is a performance-team-shaped question that lives outside any site's own metrics. - **All other WordPress teams:** Not applicable to this source. #### The WPOCC - **Programs:** `[RECOMMEND]` **This is the clearest articulation in the batch of what a funding body is actually for.** `[INFERENCE]` Costs that are diffuse are invisible, and invisible costs are unfunded — so **the fundable target is whatever the architecture made invisible.** That is a sharper selection criterion than "support maintainers." - **Funding experiments:** `[INFERENCE]` *Visibility before funding* is a programme in itself: measuring and publishing who bears which ecosystem costs is cheap, and it is the precondition for anyone deciding to fund them. - **Projects:** Not applicable to this source. ### FAIR `[RECOMMEND]` `[INFERENCE]` **The most directly relevant source in this batch to FAIR, and it supplies a frame FAIR is rarely discussed in.** - **A distribution layer is a cost-allocation decision.** Whoever serves the packages bears the traffic. FAIR's federation model **changes who bears that cost** — and that is arguably among its most consequential properties, discussed almost entirely in terms of independence and resilience instead. - **The three-question audit applies directly:** in a federated distribution model, who benefits, who decides, and who pays — and are they the same parties as today, or different ones? - `[INFERENCE]` **And it pairs with the Graze/Flipboard finding in this batch, one layer down.** There: *an open protocol defends data portability and does not defend against economic re-centralisation.* Here: **an open licence defends access and does not allocate cost.** Both are "the open thing guarantees X and is structurally silent on Y" — and in both cases the silence is where the sustainability question lives. ## 🧪 Hypotheses 1. **H1 — The traffic is cache misses, not necessary transfer.** A material share of the 50–75 TB is full-file responses that conditional requests (`ETag` / `If-Modified-Since`) would eliminate, meaning the fix is a client header rather than a protocol change. 2. **H2 — Batched update checks cost operators an order of magnitude less bandwidth.** Per active install, ecosystems using batched update checks transfer substantially less than those using per-extension requests. 3. **H3 — Cost-allocation decisions are made without being recognised as such.** In design discussions for client-side ecosystem services, infrastructure cost to the operator is raised in a small minority of cases. 4. **H4 — Separation predicts persistence.** Ecosystem-cost problems persist longer where decision authority and cost-bearing sit in different organisations than where they sit in one. 5. **H5 — The average install is far lighter than the illustrative case.** Drupal's ecosystem-average contributed-project count is roughly 6–9, an order of magnitude below the 100-project site used as illustration. 6. **H6 — Batching trades bandwidth for compute.** WordPress's per-request compute cost for update checks is materially higher than a static-file model would be, making its allocation different rather than strictly better. ## 📊 Methodology - **H1 — the cheapest and most decisive, and it changes the size of the governance ask.** Inspect the Drupal client's request headers and the server's response headers on `updates.drupal.org`; measure the 304 rate. **Fully observable from outside**, requires no cooperation, and takes an afternoon. `[INFERENCE]` **If the 304 rate is low, the remedy is a client-side header and the article has framed a small ask as a large one.** - **H2:** Compare Drupal's and WordPress's published or measured update-check traffic normalised per active install. **Confound:** check frequency differs (WordPress varies its interval from immediate to 12 hours; Drupal defaults to daily), so **frequency must be held constant or the comparison measures throttling rather than batching.** - **H3:** Content-analyse design discussions — RFCs, core issues, ADRs — for whether operator cost is raised. **Confound:** cost may be discussed in venues that leave no public record, so a low rate is a lower bound on consideration, not proof of neglect. - **H4:** Case comparison across ecosystems, coding governance structure against time-to-resolution for known infrastructure-cost issues. **Weak design** — small n, and structure correlates with age, size and funding. `[INFERENCE]` Listed because the question matters, not because the study is strong. - **H5 — already computable from figures in the article.** 50–75 TB ÷ 0.5 MB ≈ 100–150M core requests; against ~1B total, contrib is ~6–9× core. **Confirmable directly from the operator's logs**, and worth doing because it changes where you would look for the traffic. - **H6:** Measure origin compute for batched update-check endpoints against static-file serving at equivalent volume. `[INFERENCE]` **The one that tests whether WordPress's choice is actually better or merely different** — which is the honest framing, and the article's own logic demands asking it. ## ❓ Questions - **Does the Drupal client send conditional request headers?** `[INFERENCE]` The single most consequential unanswered question, because it determines whether this is a protocol problem or a header problem. - Why hasn't batching been proposed? `[INFERENCE]` The article implies governance friction and never says whether it has been raised, discussed, or rejected. - **Could the 0.5 MB file simply be truncated?** Most clients need recent releases only, and payload reduction likely beats request deduplication. - `[EVIDENCE]` What is contributed-project traffic in TB? *"Comes on top of that"* is the entire quantification of what is 85–90% of the requests. - `[INFERENCE]` What does WordPress's batched endpoint cost in compute? Its allocation is different and it is not obviously cheaper overall. - **What would "monitoring" actually look like?** He names it as the middle step and nobody owns a metric for it. ## 🔮 Future Research - **Comparative infrastructure economics across package ecosystems** — npm, Packagist, PyPI, wp.org, updates.drupal.org — normalised per install. `[INFERENCE]` Nobody appears to have published this, and it would make "who bears the cost" arguable with numbers instead of anecdotes. - **Whether cost-allocation is considered at design time**, and what makes projects that do so different. - **Governance structures and the persistence of cost problems.** `[INFERENCE]` His central claim, currently supported by one case from his own project. - **The trade-off curve he does not draw:** how much adoption is bought by cost diffusion, and at what point sustainability costs more than the adoption is worth. ## 💡 Implications - **Practice.** `[RECOMMEND]` Ask **who benefits, who decides, who pays** at design time — and ask again at 10× and 100× current scale. `[INFERENCE]` The Drupal design failed no test that existed when it was made. - **Policy.** `[INFERENCE]` **Visibility plus influence, without control** is the transferable governance formulation, and it is the one that resists vendor capture while still giving cost-bearers standing. - **Security.** `[INFERENCE]` Update infrastructure is a security dependency. An operator who cannot afford to serve it becomes an availability risk for everyone who relies on it — unraised here and arguably the strongest argument for funding it. - **Education.** `[EVIDENCE]` The piece's method is worth teaching independently of its content: **name a lens the field already has three of, then demonstrate it on one concrete system with real numbers.** That is why an 856-word post lands harder than most long-form sustainability writing. - **Funding models.** `[INFERENCE]` **The sharpest implication and the one he does not quite state: diffuse costs are invisible, and invisible costs are unfunded — so making a cost visible is itself the intervention**, prior to and cheaper than funding it. ## 🧠 Learning Styles Assessment **Reading level estimate.** `[INFERENCE]` **Flesch–Kincaid grade 11–12** — moderate sentences, plain vocabulary, low subordination. Hand estimate on 856 words, ±1.5 grades. `[EVIDENCE]` **Unusually well glossed for a founder writing about his own project:** *"Drupal calls these add-ons 'contributed projects', such as modules and themes maintained by members of the community"* defines the one term a non-Drupal reader would stumble on. #### 👀 Visual learners - **Present:** `[EVIDENCE]` One image — a sturdy stone bridge in the foreground, a fragile wooden one beyond — carrying the argument metaphorically, with full descriptive alt text. - **Improve:** `[INFERENCE]` **The three-way benefit/cost/decision separation is a diagram delivered as a paragraph**, and it is the piece's central analytical content. Three boxes and the absent arrows between them would make it immediate. #### 🔊 Aural learners - **Present:** Nothing. - **Improve:** `[INFERENCE]` Low value — an 856-word argumentative post is read, not listened to. Saying so is more useful than a reflexive audio recommendation. #### 🗣️ Verbal learners - **Present:** `[EVIDENCE]` **The strongest dimension.** *"Every Open Source ecosystem is also a cost-allocation system."* *"No one chose to make updates.drupal.org transfer tens of terabytes."* *"Visible and influence the decision, even if they do not control it."* `[INFERENCE]` Each compresses a full argument, and the last is precisely hedged. - **Improve:** Nothing substantive. #### 🧩 Kinesthetic learners - **Present:** `[EVIDENCE]` The release-history file is **linked**, so a reader can check the half-megabyte claim in one click. `[INFERENCE]` A small thing that most posts making a size claim omit. - **Improve:** `[INFERENCE]` No audit checklist. The three questions are the reusable artifact and are embedded in prose rather than offered as a tool. #### 🧠 Logical learners - **Present:** `[EVIDENCE]` Clean structure — general claim, mechanism, worked example, governance analysis, prescription — with each step supported before the next. The numbers are given, and given as an estimate rather than asserted. - **Improve:** `[EVIDENCE]` **The counter-argument is absent** — cost diffusion as the thing that bought the adoption — and the arithmetic implies an ecosystem average an order of magnitude below the illustrative case, which invites a question the piece does not answer. #### 🧑‍🤝‍🧑 Social learners - **Present:** `[EVIDENCE]` The account of Association/committer collaboration is generous and specific: *"In practice, Drupal Association staff and Core committers collaborate closely."* - **Improve:** `[INFERENCE]` No one else is quoted — no committer, no Association staffer, no site owner. For a piece about relationships between three groups, only one voice describes all three. #### 🧘‍♀️ Solitary learners - **Present:** Self-contained, with the primary artifact linked. - **Improve:** `[INFERENCE]` Three of four links are self-referential, so following the citations deepens the same argument rather than testing it. #### 🌿 Naturalistic learners - **Present:** `[EVIDENCE]` The bridge image, and *"emerge slowly"* / *"grew"* framing throughout. - **Improve:** `[INFERENCE]` The genuinely apt frame is available and unused: **this is a commons problem** — diffuse costs, concentrated benefit, no mechanism to price the externality. The vocabulary exists and would connect the argument to a large literature. ## 📊 Accessibility Assessment Assessed against **WCAG 2.2 AA**, from the captured markup only. `[INFERENCE]` **Scope limit:** content structure and text as retrieved. Focus, keyboard operation, live contrast, and reflow require the rendered page and are **not assessed**; absence of a finding is not a pass. #### Screen reader semantics - **Present:** `[EVIDENCE]` **The best alt text in this batch.** *"View from under a sturdy stone bridge toward a fragile wooden bridge in the distance, with two people standing on it."* — descriptive, complete, and it conveys the contrast the image exists to make. `[INFERENCE]` Compare the eight `alt=""` images on the nomad.blog post and the credit-line-as-alt on the GraphRAG article. - **Improve:** `[EVIDENCE]` **Only one `<h2>` in the document, and it is "Keep reading"** — the article body has no headings across 856 words and five distinct movements (thesis, mechanism, example, governance analysis, prescription). **WCAG 2.4.6 Headings and Labels (AA).** `[INFERENCE]` Fifth source in this batch to fail this criterion, and the structure exists in the prose — it is simply unmarked. #### Keyboard navigation - **Not testable from the captured markup.** #### Contrast and readability - **Not testable** — no CSS captured. #### Text resizing and reflow - **Not testable from the captured markup.** No wide content (tables, code blocks) that would create the usual hazard. #### Media and captions - **Not applicable** — no audio or video. #### Forms and interactions - **Not applicable.** #### Standards reference - **1.1.1 Non-text Content (A)** — **satisfied, and notably well.** - **2.4.6 Headings and Labels (AA)** — **failure.** No headings in the article body. - **2.4.4 Link Purpose (A)** — satisfied; all four links have descriptive text. ## 🌍 DEIB Assessment #### Cultural breadth - **Present:** Subject is a global ecosystem; no region-locked framing. - **Improve:** `[INFERENCE]` One substantive omission: **cost diffusion falls unevenly by geography and economics.** A volunteer maintainer in a low-income country and an employer-funded contributor at a large vendor both appear in his list of cost-bearers as equivalent line items. `[INFERENCE]` **The distribution of who can afford to absorb diffuse costs is itself a finding**, and treating the bearers as a flat list obscures it. #### Inclusive language - **Present:** Neutral and precise throughout; roles named by function rather than status. - **Improve:** Nothing substantive. #### Neurodiversity support - **Present:** `[EVIDENCE]` Short paragraphs, one idea each, strictly linear argument, no digressions. - **Improve:** `[EVIDENCE]` **No headings and no summary** across 856 words. `[INFERENCE]` The structure is genuinely clear and entirely unmarked, so a reader who needs signposting has to hold the whole thread. #### Representation - **Present:** `[EVIDENCE]` Three constituencies are named and their positions described fairly — site owners, Association staff, Core committers. `[INFERENCE]` Notably, **none is blamed**, and the committers are explicitly described as collaborating well. - **Improve:** `[EVIDENCE]` **No one else speaks.** `[INFERENCE]` The people bearing the costs are described by the person arguing on their behalf, and the group with the least power in the arrangement — volunteer maintainers, named in the cost list — appears only as a category. #### Psychological safety - **Present:** `[EVIDENCE]` **Handled well, and deliberately.** *"decisions that were individually reasonable"* and *"No one chose"* remove blame as an explanation, which is what makes this readable by the people who made those decisions. `[INFERENCE]` A piece about an infrastructure bill running to tens of terabytes that names no culprit is doing something harder than it looks. - **Improve:** Nothing substantive. ## ✅ Logical Validity #### Strong reasoning - **The additive reframe is the piece's structural strength.** Naming three existing lenses, granting each is useful, and adding a fourth is much harder to resist than replacing them — and it is honest about what it is doing. - **The example is causally complete.** Design rationale → growth → emergent scale → measured consequence, with each step given and the numbers marked as an estimate. - **The governance analysis identifies the actual constraint**, not the symptom: `[STATED]` *"The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own."* `[INFERENCE]` That single sentence explains the persistence better than any amount of discussion about funding would. - **The prescription is precisely hedged.** *"Visible and influence the decision, even if they do not control it"* — and coming from the co-founder of the ecosystem's largest commercial vendor, **declining the stronger claim is argument against interest.** - **Blame is foreclosed deliberately.** *"Individually reasonable"* converts what could be a complaint into a structural analysis. #### Fallacies - **Suppressed counter-argument.** Cost diffusion is treated purely as a problem, never as the trade that produced the adoption. **Weakness:** the honest framing is a curve with two costs, and the piece presents one side. **Fix:** one paragraph acknowledging what diffusion buys. - **Generalisation from a single case.** *"Every Open Source architecture is also a cost-allocation system"* is supported by one example from the author's own project. **Mitigation:** the claim is close to definitional, and one worked example is appropriate for an 856-word post — but *every* is doing more work than one case licenses. - **Unexamined alternative explanation.** `[INFERENCE]` The traffic may be a caching failure rather than an architectural one. **Weakness:** if so, the governance framing is applied to a problem with a much smaller remedy, and the piece never establishes that the cheaper fix was tried. - **Asymmetric quantification.** Core traffic is estimated; contributed-project traffic — 85–90% of requests by his own numbers — gets *"comes on top of that."* #### Tone of voice `[EVIDENCE]` Measured, unhurried, and conspicuously free of grievance — remarkable for a piece whose subject is an unfunded infrastructure bill. `[INFERENCE]` The register is **analytical rather than advocacy**, and that is what makes the argument portable: nothing in it depends on the reader sharing a position about Drupal. `[EVIDENCE]` Confidence is calibrated. *"I estimate"*, *"may account for"*, *"roughly"* attach to the numbers; the structural claims are stated firmly. `[INFERENCE]` **The hedging appears exactly where the evidence is weakest**, which is the pattern this batch has repeatedly found absent elsewhere — and it is the reason the estimate is credible despite being unaudited. ## 🛡️ DARVO Analysis **No DARVO pattern present.** `[EVIDENCE]` DARVO — Deny, Attack, Reverse Victim and Offender — describes a response to accusation. This is an analytical essay with no accusation, no accused party, and no adversarial dimension. Checking each element explicitly rather than omitting the section: - **Deny:** None. `[EVIDENCE]` The piece affirms a costly problem in the author's own project and quantifies it rather than minimising it. - **Attack:** `[EVIDENCE]` **Conspicuously absent, and the material is abundant.** A founder writing about an ecosystem service consuming tens of terabytes a month could easily blame the original designers, the Core committers who have not changed it, or the site owners who benefit without paying. `[STATED]` Instead: *"There were good reasons for that design,"* *"decisions that were individually reasonable,"* and the committers *"collaborate closely."* `[INFERENCE]` **The absence of a culprit is the piece's defining rhetorical choice.** - **Reverse victim/offender:** `[EVIDENCE]` Absent. The Drupal Association bears an unchosen cost and is described as a party needing **visibility and influence**, not as a wronged one. `[INFERENCE]` The available move — *the people paying are being taken advantage of* — is declined. `[INFERENCE]` One adjacent observation, recorded separately because it is **not** DARVO: the author co-founded the largest commercial vendor in this ecosystem, and an argument that cost-bearers deserve influence over decisions is, structurally, an argument that benefits well-resourced organisations. **He disclosed the affiliation and explicitly limited the claim to influence rather than control**, which is what keeps it a position rather than a manoeuvre. Already logged under Logical Validity. ## 🎯 Conclusion **Bottom line.** `[INFERENCE]` The clearest frame in this batch for open-source sustainability, and its most portable claim is about architecture rather than money. 1. **"Every Open Source ecosystem is also a cost-allocation system."** `[INFERENCE]` The mechanism is that severing payment from access **scatters** costs rather than removing them — and *"because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund."* **Diffusion makes cost invisible, and invisible costs go unfunded.** 2. **Architecture is cost allocation, usually without anyone deciding it.** `[STATED]` *"That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later."* `[EVIDENCE]` Drupal: 101 requests for 100 add-ons, ~1B requests/month, a 0.5 MB core file, an estimated **50–75 TB/month for core checks alone.** *"No one chose"* it. 3. **The three-way separation is the real finding.** Site owners benefit, the Association pays, Core committers decide — *"the Core committers do not report to the Drupal Association."* `[INFERENCE]` Three parties, no formal obligation, and **the diffusion is exactly what keeps it invisible.** **Two things I'd add, one of them verified.** `[EVIDENCE]` **WordPress made the opposite architectural call, and I checked the source rather than assuming.** `wp_update_plugins()` sends **one** POST to `api.wordpress.org` carrying the whole plugin list, and scales its timeout by plugin count. `[INFERENCE]` **Same problem, opposite architecture, order-of-magnitude different infrastructure cost — and that strengthens his thesis rather than embarrassing Drupal.** Neither project treated the choice as a cost-allocation decision at the time; they simply made it at different moments under different scale assumptions. It is his argument with a controlled comparison he does not have. (WordPress traded bandwidth for compute — a batched POST cannot be CDN-cached. Still an allocation.) `[INFERENCE]` **And the question his numbers raise and do not answer: is this traffic cache misses?** Release histories change rarely and a static file should support `ETag` / `If-Modified-Since`. If the 50–75 TB is full-file transfers on every check, **the remedy is a client-side header, not a protocol redesign** — which makes the ask of Core committers far smaller than the framing implies. **Observable from outside in an afternoon**, and it decides whether governance is really the binding constraint here. **The sentence to keep**, and it is argument against interest from the co-founder of the ecosystem's largest commercial vendor: cost-bearers need *"a way to make those costs **visible and influence** the decision, **even if they do not control it**."* `[INFERENCE]` He declines *whoever pays should decide* — the move that leads straight to vendor capture — and the harder position is the defensible one. **Where this lands for your work.** `[INFERENCE]` **For FAIR, this is the most directly relevant piece in the batch and supplies a frame it is rarely discussed in: a distribution layer is a cost-allocation decision, and federation changes who bears the traffic.** That pairs with the Graze finding one layer up — *an open protocol defends portability and not livelihood; an open licence defends access and not cost.* **For WPOCC**, it sharpens the selection criterion from "support maintainers" to **fund whatever the architecture made invisible.** **Practical next steps.** 1. Run the **three-question audit** — who benefits, who decides, who pays — at design time, and again at 10× scale. 2. `[RECOMMEND]` Check whether the Drupal client sends conditional request headers before accepting the protocol framing. It is the cheapest decisive test available. 3. Note that WordPress's batching is a **deliberate property worth documenting**, and that its reverse allocation (compute, not bandwidth) is unmonitored as far as I can tell. 4. `[INFERENCE]` Watch the middle verb in his prescription — *consider, **monitor**, revisit.* Monitoring is the one that fails, because it needs an owner and a metric and neither is assigned by default. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Open Source Is a Cost-Allocation System.md|Open Source Is a Cost-Allocation System by Dries Buytaert]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01m12ny4045mj13rtew7a9sj01)) - Note: ARCHITECTURE IS COST ALLOCATION — the portable finding, and stronger than the funding argument it sits inside. Paired with the line just before it ("because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund"), the mechanism is complete: SEVERING PAYMENT FROM ACCESS SCATTERS COSTS RATHER THAN REMOVING THEM, AND DIFFUSION MAKES THEM INVISIBLE, AND INVISIBLE COSTS GO UNFUNDED. "INDIVIDUALLY REASONABLE" IS DOING THE HEAVY LIFTING. It forecloses blame as an explanation, which is what makes this a governance argument rather than a complaint — and it's the same shape as the WP Rocket post-mortem this batch, where every individual triage step was performed correctly and the outcome was still bad. VERIFIED CROSS-PROJECT CONTRAST HE DOESN'T HAVE: WordPress made the OPPOSITE architectural call on the identical problem. wp_update_plugins() sends ONE POST to api.wordpress.org with the entire plugin list in the body ('plugins' => wp_json_encode($to_send)), and even scales its timeout by plugin count (3 + count/10). Drupal does N+1 GETs of static files. Checked in WP 7.0.2 source, not inferred. SAME BENEFIT TO SITE OWNERS, ORDER-OF-MAGNITUDE DIFFERENT COST TO THE OPERATOR. And this STRENGTHENS his thesis: the difference isn't competence, it's two projects making a cost-allocation decision at different moments under different scale assumptions, NEITHER TREATING IT AS ONE AT THE TIME. Note WordPress's reverse allocation though — a batched POST can't be served from a static CDN edge, so it traded bandwidth for compute. Still an allocation, just a different one, and as far as I can tell unmonitored. #atom/zettel/z1 #action/h1 - 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. ([View Highlight](https://read.readwise.io/read/01m12nz06z2wm3dfhdjrjqj67b)) - Note: THE QUESTION HIS OWN NUMBERS RAISE AND DON'T ANSWER — AND IT DECIDES HOW BIG THE GOVERNANCE ASK ACTUALLY IS. Release histories change rarely and a static file served over a CDN should support ETag / If-Modified-Since. IF THE 50–75 TB IS FULL-FILE TRANSFERS ON EVERY CHECK, THE CLIENT ISN'T SENDING CONDITIONAL HEADERS — AND THE FIX IS A CLIENT-SIDE HEADER, NOT A PROTOCOL REDESIGN. Asking Core committers to add conditional-request support is a far smaller thing than asking them to redesign the update protocol, and the article assumes the larger ask without establishing the smaller one was tried. OBSERVABLE FROM OUTSIDE IN AN AFTERNOON: inspect the client's request headers and the server's response headers, measure the 304 rate. No cooperation needed. TWO OTHER LEVERS HE DOESN'T NAME: (1) 101-for-100 is THE N+1 PROBLEM in HTTP clothing — the fix is a solved pattern, which STRENGTHENS his argument, because it means the obstacle is governance rather than engineering. (2) THE 0.5 MB FILE IS PROBABLY THE BIGGER LEVER THAN BATCHING — core has two decades of release history and a client needs to know one thing: is there anything newer than what I have. Truncation or a delta-from-current-version cuts payload far more than deduplicating requests. ARITHMETIC WORTH KNOWING: 50–75 TB ÷ 0.5 MB ≈ 100–150M core requests/month against ~1B total, so core is 10–15% of requests and contrib is 6–9× core — implying an ECOSYSTEM AVERAGE OF ~6–9 CONTRIBUTED PROJECTS PER SITE, an order of magnitude below the 100-project site in his illustration. Aggregate cost stands; the typical case is much lighter than the example implies. #atom/zettel/z3 #action/h2 - 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. ([View Highlight](https://read.readwise.io/read/01m12nyhznef8fm168a26mw9kp)) - Note: THE THREE-WAY SEPARATION IS THE REAL ANALYSIS — BENEFIT, COST, AND DECISION AUTHORITY IN THREE DIFFERENT PLACES WITH NO FORMAL OBLIGATION BETWEEN THEM. Stated this plainly it's obviously a governance problem; the reason it isn't obvious in practice is exactly his point — THE DIFFUSION IS WHAT MAKES IT INVISIBLE. That last sentence explains the persistence better than any amount of discussion about funding would: the party who can see the cost cannot change the behaviour, and the party who can change it doesn't see the bill. THE SAME STRUCTURE APPLIES EXACTLY TO WORDPRESS: site owners benefit from api.wordpress.org, the .org infrastructure bears the cost, Core committers decide the client behaviour. And this batch already contains the incident where that mattered — ~300,000 sites auto-updating prematurely during the 7.1 release, per Anne McCarthy's decision log. HOSTS ARE THE CLEAREST ASYMMETRY IN THE WORDPRESS CASE: largest beneficiaries of update-check infrastructure, bearing none of its cost. THE SENTENCE TO QUOTE IS THE PRESCRIPTION, AND IT'S ARGUMENT AGAINST INTEREST: cost-bearers need "a way to make those costs VISIBLE AND INFLUENCE the decision, EVEN IF THEY DO NOT CONTROL IT." Coming from the co-founder of the ecosystem's largest commercial vendor, DECLINING "whoever pays should decide" — the move that leads straight to vendor capture — is a real restraint. Visibility plus influence WITHOUT control is the harder and more defensible position. #atom/zettel/z2