Rules for Standards-Makers  🔗 **Source:** [Rules for Standards-Makers](https://this.how/standards/) > [!note]+ Document Notes > tags: [standards, interop, open-formats, protocol-design, rss, xml-rpc, dave-winer, postels-law, spec-writing, open-web, governance, api-design] > title: Rules for standards-makers > author: Dave Winer > source: "this.how / Scripting News" > reference: https://this.how/standards/ > date created: 2026-09-04 11:05 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] Provenance and capture > > **The page is client-side rendered and both scrapers failed on it.** The pipeline's own fetch got 51 characters; Reader's scrape got 386. The full text (~6,800 chars) was recovered with a JS-rendering scrape and re-saved as a replacement Reader doc; the truncated original was archived. Quotations below come from the recovered render, not from either partial scrape. > > **This is a living document, not a 2017 artifact.** Posted 18 June 2017, derived from a 9 May 2017 Scripting News post, and last updated 4 August 2026 — the same day as the companion post. It is published from an outliner (an OPML version is linked), which is why it reads as nested bullets rather than prose. > > **Material self-interest, disclosed here because the page does not.** Winer created or co-created RSS, XML-RPC, OPML, and rssCloud. Several rules adjudicate disputes he was a party to (XML-RPC vs. SOAP, rssCloud vs. its alternative). That does not make the rules wrong; it does mean the examples are selected by a participant. > > # 🏷️ Title: Rules for standards-makers > <!-- 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) - [🧱 Refactor Appendix](#-refactor-appendix) - [🧰 Template Library](#-template-library) ### 🔗 References (in-page) - Source: https://this.how/standards/ (OPML: https://this.how/standards/?format=opml) - Original 2017 post: http://scripting.com/2017/05/09/rulesForStandardsmakers.html - 2026 addition: http://scripting.com/2026/08/04/124651.html - RSS 0.91 spec: http://backend.userland.com/rss091 · RSS 2.0: https://cyber.harvard.edu/rss/rss.html - XML-RPC: http://xmlrpc.com/ · Winer on SOAP: http://scripting.com/davenet/2001/04/04/aBusyDevelopersGuideToSoap.html - Postel's robustness principle: https://en.wikipedia.org/wiki/Robustness_principle - Slide-show version: http://scripting.com/manifesto/rulesforstandardsmakers.html - Feedback: https://github.com/scripting/Scripting-News/issues ## 📝 Summary **What this is.** About twenty rules for people making open formats and protocols, written by someone who has made several and fought to keep them unowned. It is deliberately not a spec-writing style guide; it is a claim about what a standard is *for*, with the rest derived from that. **The load-bearing claim.** Interop is the only reason open formats exist. Every other rule is downstream: fewer formats, fewer features, no breakage, freeze the spec, ship a toolkit, write in plain English. Once you accept that interop is the goal rather than expressiveness or elegance, most of the rules follow without further argument. **The chain of priority.** Users > software > formats. Format-first design produces good demos and dead standards. Software-first design produces standards because implementors have users to offer each other, and interop is how they trade access to those users. **Stakeholders.** Individual implementors and small teams — explicitly the intended audience. Standards bodies (W3C, IETF) appear only as a cautionary example. Users appear as the beneficiary and the justification: interop exists so they can leave. **Risks and tradeoffs.** Winer says so himself — some rules contradict each other and you have to strike a balance. The sharpest internal tension is "if practice deviates from the spec, change the spec" against "freeze the spec," and he resolves it historically rather than in principle: RSS 0.91 was adjusted to match practice, RSS 2.0 was frozen and no longer is. **Bottom line.** The strongest, most transferable idea is the reframing of interop as a *user-freedom* commitment rather than a technical nicety — competing on merit instead of lock-in, with the exit door left open on purpose. The weakest parts are the ones where a participant in old disputes is also the referee, and one example (Slack) that has aged badly enough to now argue against the point it was chosen to make. ## 📖 Main Content **Interop as an ethical position, not an engineering one.** The move that gives this document its force is the Hippocratic comparison. Winer does not defend interop on grounds of efficiency or elegance; he defends it on grounds of what it does for the person using the software — they can leave. That converts a format decision into a statement about the relationship between a vendor and a user, and it is why the document generalizes past formats to anything with an export button. **The priority chain is the actual method.** "Software matters more than formats" and "users matter even more than software" together specify a sequence: build the thing, get users, then standardize what already works. This is the opposite of the design-by-committee sequence, and it is the same argument the 2026 companion post makes about not taking RSS.chat to a standards body. The rule explains the failure mode precisely — format-first work produces demos, because a format with no implementations has nothing to interoperate *with*. **Simplicity as an anti-capture mechanism.** The XML-RPC/SOAP passage is the document's most pointed claim, and it is not about complexity as an aesthetic problem. It is an allegation about motive: that complexity was engineered to make full support infeasible, so a large company could claim openness without becoming interoperable. Whether or not that read of SOAP's history is right, the *test* it proposes is genuinely useful and checkable — can a competent developer fully support this in a bounded time? If not, ask who benefits. **"Perfection is a waste of time," and the worst-name discipline.** The deliberately-terrible-names anecdote is a procedural trick for killing bikeshedding: make the naming obviously arbitrary up front so nobody can relitigate it. The supporting argument is better than the joke — for a reader whose first language isn't English, element names are opaque symbols regardless, so the connotation being argued over doesn't exist for much of the audience. **"Mail lists don't rule."** The most quotable passage and the least evidenced. The observation — that a venue's participants overestimate their authority over a world that isn't listening — is sharp and recognizable. But it is asserted from experience, and it is asserted by someone with a long, well-documented history of conflict with exactly those venues. It reads as true and arrives with no evidence you could check. **Postel, cited by half.** "Fewer formats is better" closes by invoking the robustness principle as *"1/2 of Postel's robustness principle -- be conservative in what you send."* The framing is accurate and the omission is the interesting part: he takes the send-half, which is uncontroversial, and leaves the accept-half, which is the half under sustained attack (Rose's RFC 3117, Thomson's drafts, the 2018 Tor result). Winer's own rules — no breakage, freeze the spec, one way is better than two — are arguably *in tension* with liberal acceptance, since tolerating non-conforming input is precisely how a bug becomes a de facto part of the format. The document never works this through. ### 🗒️ Notes - **The Slack example has inverted since 2017.** Winer praises Slack for making interop easy and for signalling that users should be free to leave. Slack has since restricted API access, deprecated broad-scope tokens, and limited data export and third-party client capability. The example now illustrates a *different* rule the document doesn't state: interop friendliness is a phase of a company's lifecycle, not a property of it, and praise for a vendor's openness expires. This is the single most important update the page needs. - **"Freeze the spec" vs. "change the spec to match practice" is a real contradiction**, and Winer pre-authorizes it by saying rules contradict and you must balance. The historical resolution is that RSS 2.0's freeze ended the practice-tracking. What's missing is a criterion — *when* does a format graduate from tracking practice to freezing? - **Extension mechanisms are the pressure valve** that makes freezing survivable. Named once, in one clause, and doing enormous load-bearing work — the whole "freeze but don't stagnate" position depends on it. - **The document is itself an argument for its own format.** It's an outliner document with a linked OPML rendering and per-item permalinks (each bullet has a `#` anchor with a timestamp ID). Winer created OPML. The medium is a demonstration. - **Client-side rendering makes it invisible to naive scrapers** — a document arguing for durable open formats delivered in a way that two of three fetchers failed to read. Not hypocrisy exactly (the OPML is right there, and the anchors are stable), but a genuine irony worth noting, and a practical warning: "open format" and "accessible to a simple client" are different properties. - **Audience is explicitly individual developers**, and the document was written to be handed to future ones. That framing explains the absence of anything about governance structures, IP policy, patent commitments, or conformance testing — all of which a standards body would consider mandatory and none of which appear here. ## 📚 References Primary sources cited by the page, all verified present in the recovered render: - **RSS 0.91 spec** (userland.com) and **RSS 2.0 spec** (Harvard Berkman) — cited as the practice-tracking and the freeze respectively. - **XML-RPC** (xmlrpc.com) and **Winer's 2001 "Busy Developer's Guide to SOAP"** — the simplicity-as-anti-capture argument. Note the SOAP critique links to Winer's own contemporaneous piece, so the citation supports the claim with the claimant. - **Postel's robustness principle** (Wikipedia) — cited for the send-half only. - **Slack Web API docs** — the praise example. - **Hippocratic Oath** (Wikipedia) — the ethical analogy. - **Scripting News GitHub issues** — the feedback channel, in place of a mailing list, which is consistent with "mail lists don't rule." Not cited, and relevant: RFC 3117 (Rose, 2001) and Thomson's "The Harmful Consequences of the Robustness Principle" both bear directly on the Postel invocation. Neither appears. Also absent is any reference to the RSS 1.0 / RSS 2.0 fork, which is the most contested episode in the history the document draws its authority from. ## 🗣️ Paraphrase **What is this / Intro.** A 2017 Scripting News post, moved here so it can grow as the author learns more about how standards-making works. He has used many formats and protocols across a long career, created several, and fought with mixed success to keep them independent and unowned. These are the principles he will stick to on shared open-tech projects, gathered in one place to hand to future developers. **Rule #1 and its justification.** Interop is all that matters — the only reason open formats and protocols exist is so software can interoperate. Why interop? So users are free to move; so products compete on performance, features and price rather than lock-in. He calls this as basic as the Hippocratic Oath, and says it honors and respects users. **Balance.** There are few absolutes; some rules contradict others, so you have to think and strike a balance. **Priority chain.** Software matters much more than formats: designing the format first and conforming software to it yields good demos but rarely a standard. Users matter more still — people interop because it brings them new users, and with no users to offer there's little interest. **Reduction.** One way is better than two, because however much better the new way is you'll still support the old. Fewer formats is better: collapse two into one where you can do it without breakage or loss of interop; removing complexity is always good; think of it as code factoring at a larger scale — and this is half of Postel's principle, be conservative in what you send. Fewer features is better: before adding one, study the existing format and namespaces to check it hasn't already been done, and if it has, use the original. **Naming and prose.** Perfection wastes time. He once opened a standards discussion by requiring the worst possible name for every element, so that "I think foo is better" could be laughed off. Names don't matter; we can learn anything; and to non-native English speakers they're opaque symbols anyway. Specs should be plain English, written for educated people who like to think and care about interop — readers are not computers. **Process.** Post a quick RFC when adding to a format or a popular application, because prior art matters twice over: there may already be an interoperable way, and you'll live with the decision forever. Explain the curiosities — why things are as they are — but only after explaining how it works and giving an example. **Practice and stability.** If practice deviates from the spec, change the spec: writing RSS 0.91 he dropped earlier limits that developers were already ignoring, and no one complained. After RSS 2.0 the format was frozen, so no more practice-based adjustment. No breakage: version 2 should be backward compatible, so a version 1 file is a valid version 2 file; don't break the installed base, which you can't anyway — people still run XP. Freeze the spec once new ideas slow to a trickle and compatible software accumulates, but provide an extension mechanism as an outlet; developers need a fixed foundation. **Simplicity and adoption.** Beware open formats impossible to fully support. XML-RPC could be fully supported in days; SOAP never could, and he believes that's no accident — large companies crafted it to claim openness without interoperating with competitors. Developers are busy: with an open, documented format you're encouraging competitors to be compatible, so build a toolkit in a popular language, because working code fills the spec's gaps and some developers will never read the spec at all. **Venues and praise.** Mail lists don't rule — participants come to feel they're masters of the universe when they're just people on a list nobody, including each other, heeds; the same goes for conferences. Praise developers who make interop easy: he names Slack, which didn't have to make it that easy, and reads the choice as saying users should stay because the product is best, not because they're stuck. **Closing.** Comments go to the Scripting News GitHub issues; a slide-show version exists; thanks for making it this far. ## 📰 Newsletter **"Interop is all that matters" — and the WordPress version of that sentence** Dave Winer has been quietly maintaining [Rules for standards-makers](https://this.how/standards/) since 2017, and he updated it again in August. It's about twenty rules for anyone making an open format, and the whole thing hangs off one claim: the only reason open formats exist is so software can interoperate, and the only reason *that* matters is so users are free to leave. He compares it to the Hippocratic Oath, which sounds grand until you notice it's the same argument behind every export button that actually works. Products should compete on performance, features and price — not on how expensive it is to go. The rules worth stealing regardless of what you build: users > software > formats, in that order, because format-first design produces good demos and dead standards. One way is better than two, since you'll support the old way anyway. Freeze the spec once the ideas slow down, but ship an extension mechanism so there's somewhere for new ones to go. Write specs in plain English — "people reading specs are not computers." And ship a toolkit, because some developers will never read your spec at all. He includes himself in that group. Two things to read critically. He praises Slack for making interop easy — that was 2017, and Slack has spent the years since tightening API access, which quietly turns the example into evidence for a rule the page doesn't have: a vendor's openness is a phase, not a property. And he cites Postel's robustness principle, but only the send half. The receive half — be liberal in what you accept — is the half that's been under sustained attack for two decades, because tolerating broken input is exactly how a bug becomes part of your format forever. Worth the ten minutes, and worth arguing with. Which is presumably the point of a document its author keeps editing nine years on. ## ✅ Action Items **Courtney — personal:** - Read this against her own plugin work: Post Kinds, Outpost, and the Micropub/IndieWeb surface are all interop bets, and "users matter more than software matters more than formats" is a direct challenge to how IndieWeb specs are often argued. - The "ship a toolkit, not just a spec" rule is the actionable one for [[3. Resources/Permanent Notes/Agent-Readable Data Is Becoming the Default Plugin Integration Surface]] — a documented format without reference code doesn't get adopted. - Worth pairing with the Standard.site / AT Protocol publisher-pillar work: that audit found consumer-only implementation, and Winer's rule says the toolkit is what closes that gap. **Core / Core AI:** The "fully supportable in bounded time" test is a usable review criterion for any new WordPress-adjacent format or ability schema — if a competent implementer can't fully support it in days, ask who the complexity serves. **Plugins / Themes:** "No breakage — a version 1 file is a valid version 2 file" is the same contract as [[3. Resources/Permanent Notes/A Maintenance Release Earns Fast-Update Trust by Fixing Only Not Adding]], arriving from the format side rather than the release side. **Documentation:** "Write specs in plain English… readers are not computers" and "explain the curiosities, but only after showing how it works and giving an example" are both directly usable in the Diátaxis reference-vs-explanation split. **Openverse / Meta / Tide:** Prior-art-first ("post a quick RFC") is a cheap process addition where new fields get added to shared schemas. **Community / Training:** The document is a good teaching artifact for what a standard is *for*, ahead of any format mechanics. **Marketing / Support / Photos / TV / Polyglots / Mobile / Playground / CLI / Hosting / Core Performance / Core Program Team:** Not applicable to this source — no surface of theirs is touched. **Accessibility:** Not applicable directly, though the "names are opaque symbols to non-native speakers" argument is an internationalization point with an accessibility flavor. **The WPOCC:** Not applicable to this source — no governance or funding dimension raised. **FAIR:** Genuinely relevant — a federated repository is an interop bet, and "fewer formats is better" plus "ship a toolkit" bear on how FAIR defines and distributes its metadata format. ## 🧪 Hypotheses 1. **Format-first standards have lower implementation counts than software-first ones.** Testable by sampling formats by origin (committee-designed vs. extracted-from-working-software) and counting independent implementations at five years. 2. **The "fully supportable in bounded time" test predicts adoption** better than technical merit does. XML-RPC vs. SOAP is one data point offered by an interested party; JSON vs. XML, and Markdown vs. DocBook, are independent tests of the same claim. 3. **Vendor interop friendliness decays with market position.** The Slack example predicts this: measure API permissiveness and export fidelity against market share over time across several platforms. If it holds, praising a vendor for openness is always a time-stamped claim. 4. **Liberal acceptance produces de facto spec drift.** Formats whose parsers accept non-conforming input will show more implementation-specific behavior at ten years than strict ones. This is Thomson's claim, and it directly tests the half of Postel that Winer omits. 5. **Extension mechanisms determine whether a frozen spec survives.** Frozen formats with a namespace/extension outlet should show longer active life than frozen formats without one. 6. **Deliberately arbitrary naming reduces design-cycle time.** The worst-name discipline is a testable process intervention, not just a joke. ## 📊 Methodology **There is none, and that should be stated plainly.** This is distilled practitioner experience — assertion supported by selected anecdote. No data, no systematic comparison, no counterexamples sought. That is a defensible genre for a document whose stated purpose is to pass principles to future developers, but it has three specific consequences: - **Case selection is by a participant.** XML-RPC vs. SOAP and rssCloud vs. its alternative are episodes Winer was in, and he won the framing in both retellings. A survey that included formats he wasn't party to would be a different kind of evidence. - **Survivorship is unaddressed.** The formats cited as validating the rules are the ones that survived. Formats that followed every rule and died are not counted, and they are the ones that would test whether the rules are sufficient or merely present in successes. - **The strongest empirical claim is the least supported.** "Large companies crafted SOAP so they could say they were open without interoperating" is an assertion about intent, sourced to Winer's own 2001 essay. It may well be right; it is not demonstrated, and the citation is self-referential. The claims most worth testing empirically are the ones this document is best positioned to have gotten right and least able to prove: the priority chain, and the bounded-time supportability test. ## ❓ Questions 1. What is the criterion for graduating a format from "track practice" to "frozen"? The document names both states and the RSS history, but never the threshold. 2. Does Winer still endorse the Slack example in 2026, given the API restrictions since? The page was updated in August 2026 and the example was left standing. 3. Why cite only half of Postel? Is the accept-half rejected, assumed, or simply not the point being made — and how does liberal acceptance square with "no breakage" and "freeze the spec"? 4. What counts as "prior art" checking in practice, and who arbitrates when two formats already do the thing differently? 5. Do the rules apply to formats with real security surface, where liberal acceptance and extension mechanisms are attack surface rather than pressure valves? 6. Is "mail lists don't rule" a claim about mailing lists specifically, or about any venue that mistakes participation for authority — and does the GitHub issues channel escape it? 7. What would Winer count as a *counterexample* — a successful standard that came out of a body, designed format-first? ## 🔮 Future Research - **A systematic version of this document.** The rules are testable in aggregate: build a dataset of formats with origin (body vs. implementor), initial complexity, toolkit availability at launch, extension mechanism, and independent implementation count over time. That converts a manifesto into evidence, and would be genuinely novel. - **The decay curve of vendor openness.** The Slack inversion is the seed of a much more useful claim than the original praise. Measuring when and why platforms close is directly relevant to the WordPress ecosystem's dependence on third-party APIs. - **Postel's two halves, evaluated separately.** The literature treats the robustness principle as one rule; the send-half and accept-half have different track records and arguably opposite effects on long-run interop. Worth a note of its own. - **Where the rules break under security constraints.** Every rule here optimizes for adoption and longevity. A parallel set optimizing for safety would conflict at several points, and naming the conflicts precisely would be more useful than either list alone. - **IndieWeb as a test case.** A living ecosystem that explicitly follows the software-first, toolkit-shipping model. Whether its interop record supports Winer's chain is checkable. ## 💡 Implications **For practice.** The priority chain is the immediately usable thing: build software, get users, standardize what works. It inverts the instinct to specify first, and it explains a large fraction of dead specifications. **For policy.** If interop is a user-freedom commitment rather than a technical preference, then closing an API is a user-facing action requiring justification, not a routine product decision. That framing has teeth in platform-governance arguments and is underused. **For security.** The document's blind spot. Extension mechanisms, liberal acceptance, and never breaking the installed base are each in tension with a defensible security posture — the Tor result on Postel's principle is the sharpest published example. A standards-maker following these rules needs a second list. **For education.** Two rules are directly transferable to documentation practice: plain English over mathematical elegance, and examples before explanations of *why*. Both are Diátaxis-compatible and stated more memorably here than in most docs guidance. **For funding and sustainability.** "Ship a toolkit" is a resourcing claim disguised as a technical one. A format's adoption depends on someone maintaining reference code in a popular language, and that labor is exactly the kind that goes unfunded — the same gap named in [[3. Resources/Permanent Notes/Open Source Depends on Teaching Labor That Has No Formal Home]]. ## 🧠 Learning Styles Assessment - **Visual** — Poorly served in the page itself: no diagrams, no tables, no images beyond an OPML icon. Partly mitigated by the linked slide-show version, which is the visual rendering of the same content. - **Aural** — Not served. No audio or video. The material would carry well as a talk, and the slide-show implies it has been given as one. - **Verbal (read/write)** — Very well served, and this is the document's native mode. Short declarative rules, each a heading with supporting bullets; scannable and quotable. - **Kinesthetic** — Weakly served. There's nothing to do — no exercise, no worked example of applying the rules to a candidate format. The nearest thing is the implicit invitation to check your own format against the list. - **Logical** — Well served. Explicitly hierarchical: one root rule, everything derived, with the author flagging that some rules conflict and require judgment. The reader can reconstruct the derivation. - **Social** — Moderately served. A named feedback channel (GitHub issues) and a warm sign-off, but no discussion is visible on the page itself. - **Solitary** — Very well served. Self-contained, ~6,800 words of tight prose, densely linked to primary sources for independent follow-up. - **Naturalistic** — Not applicable to this source — no environmental or pattern-in-nature dimension. **Reading level:** roughly grade 9–11 in sentence construction — short, plain, conversational, contractions throughout. Conceptual load is much higher than the prose level suggests: full comprehension needs working familiarity with formats vs. protocols, namespaces, RPC, backward compatibility, and the specific history of RSS, SOAP and XML-RPC. A capable non-specialist will follow every sentence and miss half the argument. ## 📊 Accessibility Assessment Assessed against WCAG 2.2 AA, treating the published page as the artifact: 1. **1.1.1 Non-text Content (A).** Minimal exposure — the only image is the OPML/XML icon, which is a link. Whether it carries an accessible name could not be confirmed from the recovered render; worth checking, since it's the sole graphical control. 2. **1.3.1 Info and Relationships (A).** The outline nesting carries real semantic meaning (rule → supporting points). Whether it renders as nested lists and headings or as styled `div`s determines whether that structure reaches assistive technology at all. Client-side rendering makes this the page's biggest open question. 3. **1.4.3 Contrast (Minimum) (AA) / 1.4.4 Resize Text (AA).** Not assessable from a text render; the site is a plain, high-contrast layout by convention, but that is an assumption rather than a measurement, and it is exactly the kind of assumption worth not making. 4. **2.1.1 Keyboard (A).** Every interactive element in the recovered content is a link, which is keyboard-operable by default. Low risk. 5. **2.4.4 Link Purpose (In Context) (A).** A real weakness: each bullet carries a bare `#` permalink whose visible text is a single character. Dozens of adjacent links reading "#" give a screen-reader user's link list no way to distinguish them. This is the clearest defect the render exposes. 6. **3.1.1 Language of Page (A) / 3.1.2 Language of Parts.** Presumed `lang="en"`; not verifiable from the render. 7. **4.1.2 Name, Role, Value (A).** Depends entirely on whether the outliner emits semantic list markup or generic containers — the same open question as 1.3.1, and the reason a JS-rendered document is harder to assess than a static one. **Overall:** likely broadly usable — it is text and links — with one concrete named defect (the repeated bare `#` permalinks) and a cluster of unknowns created by client-side rendering. This connects directly to [[3. Resources/Permanent Notes/Detecting a Property Is Not Evaluating Whether It Serves Anyone]]: a scanner could confirm each `#` link has an accessible name and still miss that fifty of them are indistinguishable. ## 🌍 DEIB Assessment - **Cultural breadth.** One genuinely thoughtful moment: the argument that element names are opaque symbols to people whose first language isn't English, used to defuse naming debates. That is an internationalization consideration most standards writing omits. Otherwise the frame is Anglophone and US-centric, and the history recounted is that of the American web industry. - **Inclusive language.** Plain and non-exclusionary. No ableist idiom. The one edge is "I write for people who have brains, like to think, are educated" — warm in intent, but "educated" as an entry criterion sits oddly in a document about lowering barriers to implementation. - **Neurodiversity support.** Incidentally strong. Short, discrete, independently comprehensible rules with stable per-item anchors is a friendly structure for readers who don't process long argumentative prose linearly. Nothing suggests this was deliberate. - **Representation.** Sparse. The named actors are Winer, Postel, and Slack's API team; the history is told through a small circle. Nobody who disagreed is named or quoted, which matters in a document whose authority rests on contested episodes. - **Psychological safety.** High for the reader, mixed for absent parties. The tone is generous to developers ("developers are busy," "thanks for making it this far") and explicitly invites disagreement via a public channel. But "mail lists don't rule" characterizes unnamed people as self-appointed masters of the universe — fair comment on a dynamic, and not something the people described can answer here. ## ✅ Logical Validity **Strong reasoning:** - **A single stated root premise with visible derivation.** Interop is the goal; the rest follows. Whether or not you accept the premise, you can see exactly which rules depend on it, which is far more than most manifestos offer. - **Self-aware about conflict.** "Some rules even contradict others, so you have to think" is an honest disclosure that pre-empts the cheapest objection and correctly refuses to pretend the list is an algorithm. - **Concrete, checkable tests.** "Could a developer fully support this in a bounded time?" and "is a version 1 file a valid version 2 file?" are real criteria a reader can apply without the author. - **Scope honesty on Postel.** Saying "1/2 of Postel's robustness principle" rather than invoking the whole thing is precise, and precise in a way most citations of Postel are not. **Fallacies and weak points:** - **Appeal to motive / unfalsifiable intent claim** — the SOAP passage. "Large companies crafted SOAP so they could say they were open without interoperating with competitors" attributes coordinated intent, cites the author's own contemporaneous essay, and is constructed so that any evidence of SOAP's complexity confirms it. *Fix:* separate the checkable claim (SOAP could not be fully implemented in bounded time) from the intent claim, and support the second independently or drop it. - **Survivorship bias**, structural, running through the whole evidence base. Every validating example is a format that survived. *Fix:* name one format that followed the rules and failed; it would sharpen the claim from "these are present in successes" to "these cause successes." - **Hasty generalization** — "No one, not even the other people on the list, care what you think." Universal, unsupported, and self-undermining, since the document itself is a public statement of opinion hoping to be heeded. *Fix:* narrow to the specific failure (venue participants overestimate their authority over implementors) which is defensible as stated. - **Anecdotal evidence as proof of rule** — "So I left the limits out of 0.91 spec. No one complained." Absence of complaint is weak evidence, and the vault has a note saying exactly why ([[3. Resources/Permanent Notes/Absence of Complaint Is Resignation Not Satisfaction]]). *Fix:* cite adoption or implementation data rather than silence. - **Stale example presented as current** — Slack. Not a fallacy at time of writing; it becomes one when a document updated in 2026 still offers a 2017 vendor posture as evidence. *Fix:* date the example or replace it. **Tone of voice:** Plain-spoken, senior, generous to the reader and sharp toward institutions. Contractions throughout, first person, no marketing register and no false modesty. Confident to the edge of dismissive when the subject is standards bodies. It reads like someone who has had these arguments many times and has stopped expecting to persuade the people on the other side — which is both its energy and its blind spot. ## 🛡️ DARVO Analysis **Largely not applicable** — DARVO describes a defensive response to an accusation of harm, and no accusation is at issue here. Checking each element for completeness, one is partially present: - **Deny** — absent. Nothing is denied; the author concedes his rules conflict, that he lost some fights ("with varying degrees of success"), and that judgment is required. - **Attack** — present in a mild, non-DARVO form. Standards-body participants are characterized unflatteringly ("masters of the universe") and large companies are assigned bad motive over SOAP. This is polemic, not the attack limb of DARVO, because it isn't deployed to deflect a charge against the author. - **Reverse Victim and Offender** — the only limb with any real presence, and it is faint. The framing positions independent developers (the author's camp) as the party wronged by institutional standards work, in a domain where the author was an active and often aggressive combatant. Readers who know the RSS fork history will notice that the document's account is one-sided. This is ordinary partisan framing rather than DARVO proper, but it is the place where a reader should apply the most independent scrutiny. **Net:** a polemical document with a clear point of view, not a defensive one. Worth reading the institutional-conflict passages against an independent account of the same events. ## 🎯 Conclusion **Bottom line.** A maintained, nine-year-old, roughly twenty-rule distillation of what open formats are for, resting on one premise — interop, so users can leave — with the rest visibly derived from it. Its best contributions are the priority chain (users > software > formats), the bounded-time supportability test, and the reframing of interop as a user-freedom commitment rather than an engineering preference. Its weakest are a self-refereed evidence base, a structural survivorship problem, and one example that now argues against itself. **Next steps.** 1. Read alongside the 2026 companion post and the Postel page — the three form one argument, and the tension between them is where the useful thinking is. 2. Apply the bounded-time test to any format Courtney is implementing against, starting with the Standard.site / AT Protocol publisher surface. 3. Watch whether the Slack example gets updated; if it doesn't, that is itself a small data point about how living documents actually live. 4. Treat the Postel half-citation as the open thread — the accept-half is where the interesting modern disagreement sits. ## 🧱 Refactor Appendix ### Literature Split Pad **Proposed Literature Note:** `Rules for Standards-Makers (Winer)` - Bib capsule: Winer, Dave. "Rules for standards-makers." this.how/standards, posted 18 June 2017 from a 9 May 2017 Scripting News post; last updated 4 August 2026. - Adler Q1 (what is it about?) — what open formats are *for*, and what follows once you answer that with "interop." - Adler Q2 (what is said in detail?) — ~20 rules organized as one root premise plus derived guidance across reduction, naming, prose, process, stability, simplicity and adoption. - Key arguments (≤3): (1) interop is a user-freedom commitment, not a technical nicety; (2) the priority chain runs users > software > formats, which inverts the design-first instinct; (3) full supportability in bounded time is a test of whose interests a format serves. #### Claim atoms (H3 candidates) ### Interop exists so users can leave > [!quote] ID:rw_01m1pmxkg1qeznsj5yjm7yqqqn > We want interop so that our users are free to move. Where: "Why interop?", the second rule. Why it matters: relocates interop from engineering preference to a commitment about the vendor-user relationship, which is what makes it arguable in governance and product terms rather than only in technical ones. <!-- atomicity: 1 idea ✓ --> ### A format nobody can fully implement is closed in effect > [!quote] ID:rw_01m1pmxkg1qeznsj5yjm7yqqqn > XML-RPC could be fully supported in a few days. You could never fully support SOAP. I believe this is no accident. Where: "Keep it simple." Why it matters: supplies a bounded-time test that distinguishes nominal openness from usable openness, without needing to establish anyone's intent. <!-- atomicity: 1 idea ✓ --> ### Format-first design produces demos, not standards > [!quote] ID:rw_01m1pmxkg1qeznsj5yjm7yqqqn > Too often people try to design a format first, and then make software that conforms to the format. You might get some good demos. But not much chance of developing a standard that way. Where: "Software matters more than formats." Why it matters: names the sequencing error behind a large share of dead specifications, and is the rule the 2026 companion post applies to RSS.chat. <!-- atomicity: 1 idea ✓ --> ### A spec must be readable by people, not just parsers > [!quote] ID:rw_01m1pmxkg1qeznsj5yjm7yqqqn > I write for people who have brains, like to think, are educated, care about interop. I understand that people reading specs are not computers. Where: "Write specs in plain English." Why it matters: the documentation-practice half of the argument, and the one directly transferable to Courtney's technical-writing work. <!-- atomicity: 1 idea ✓ --> #### Permanent Note candidates 1. **"Interop Is a Commitment That Users Can Leave, Not a Technical Preference"** — atom 1 generalized. Highest resonance of the four; check against [[3. Resources/Permanent Notes/A Plugins Survival Requires Owning Distribution Beyond the Repo]] and the Standard.site audit material before creating. 2. **"A Format No One Can Fully Implement Is Closed Regardless of Its Licence"** — atom 2. Strong, checkable, and generalizes to ability schemas and agent protocols. Check against [[3. Resources/Permanent Notes/A Tool Earns Trust by Staying Small Enough to Be True]]. 3. **"Standardize What Already Works Rather Than Specifying What Should"** — atom 3. Check against existing product-instinct notes before creating; may already be covered from the product side. 4. **"A Vendor's Interop Friendliness Is a Lifecycle Phase, Not a Property"** — *not stated in the source*; it is what the Slack example demonstrates in hindsight. The most original candidate here and the one most worth writing, but it needs a second source before promotion. **Recommendation:** hold all four for a synthesis pass. Candidate 4 is the most novel and the least supported by this document alone — exactly the profile that should wait for corroboration rather than being created on one ironic example. ### Fleeting Queue - Postel's two halves have different track records; the send-half is uncontroversial and the accept-half is under attack. Possible standalone note once the Wikipedia page is processed. - "Freeze the spec" vs. "track practice" — what is the graduation criterion? Unanswered here; watch for an answer elsewhere. - A document arguing for durable open formats that two of three scrapers couldn't read. Irony, and a practical warning about conflating "open format" with "reachable by a simple client." - Dozens of adjacent bare `#` permalinks — a real, small, fixable a11y defect on a widely-read page. - Does the IndieWeb ecosystem's record support or undercut the users > software > formats chain? <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Rules for Standards-Makers.md|Rules for Standards-Makers by Dave Winer]] ## Highlights - We want interop so that our users are free to move. ([View Highlight](https://read.readwise.io/read/01m1pp7jehmspahfnphr9ty40y)) - Note: The root premise the whole document derives from. Relocates interop from engineering preference to a commitment about the vendor-user relationship — which is what makes it arguable in governance and product terms, not just technical ones. - Tags: atom/zettel/z1, atom/literature/h1 - Too often people try to design a format first, and then make software that conforms to the format. You might get some good demos. But not much chance of developing a standard that way. ([View Highlight](https://read.readwise.io/read/01m1pp7rtyh5x4m7hsrdrk3jhv)) - Note: The sequencing error behind a large share of dead specifications. This is the rule the 2026 companion post applies to RSS.chat — build first, standardize what already works. - Tags: atom/literature/h1 - I write for people who have brains, like to think, are educated, care about interop. I understand that people reading specs are not computers. ([View Highlight](https://read.readwise.io/read/01m1pp7zp9bvtzxx8ds0yat8st)) - Note: The documentation-practice half, and directly transferable to technical writing. Note the small tension: "educated" as an entry criterion sits oddly in a document about lowering barriers to implementation. - Tags: atom/literature/h2