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 > ## 🧭 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 docu *Rules for standards-makers* by Dave Winer. Originally a Scripting News blog post, May 2017; maintained since at this.how/standards. Last update: Tuesday August 4, 2026, 9:10 AM EDT. Posted: Sunday June 18, 2017. #### Intro I've used all kinds of formats and protocols in a long career as a software developer. I also have created a few, and have had to fight to keep them independent and unowned, with varying degrees of success. This set of rules represents what I've learned. If we work together on a project based on open tech, these are the principles I will try to stick to. I wanted to put all this in one place, so I can pass it along to future software developers. #### Rule #1: Interop is all that matters The only reason we have open formats and protocols is so our software can interoperate. #### Why interop? We want interop so that our users are free to move. So our products compete on the basis of performance, features and price, and not lock-in. This is as basic as the Hippocratic Oath that doctors take. It honors and respects the users of our products. #### There are tradeoffs in standards There are few absolutes in standards work, some rules even contradict others, so you have to think, and strike a balance. #### Software matters more than formats (much) 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. #### Users matter even more than software People choose to interop because it helps them find new users. If you have no users to offer, there won't be much interest in interop. #### One way is better than two No matter how much better the new way is, you'll still have to support the old way. #### Fewer formats is better If you can replace two formats with one, without breakage or loss of interop, then I say go for it. Removing complexity from the world is always good. Think of this like code factoring, but on a larger scale. This is 1/2 of Postel's robustness principle -- be conservative in what you send. #### Fewer format features is better If you want to add a feature to a format, first carefully study the existing format and namespaces to be sure what you're doing hasn't already been done. If it has, use the original version. This is how you maximize interop. #### Perfection is a waste of time I've witnessed long debates over which name is better than another. I once led a standards discussion beginning with this rule: We always had to come up with the worst possible name for every element. That way when someone said "I think foo is better" (and they did) we could all laugh and say that's exactly why we won't use it. It totally doesn't matter what we call it. We can learn to use anything. There are more important things to spend time on. Think of people whose first language isn't English. To them the names we choose are symbols, they don't connote anything. #### Write specs in plain English I write for people who have brains, like to think, are educated, care about interop. I understand that people reading specs are not computers. #### When to post an RFC When adding something to a format, or even a popular application, you should post a quick RFC. This is because prior art is so important, from two points of view. We always have to consider whether there's already a way to do it so we can interop. We're going to have to live with whatever we do forever, so it's worth thinking a bit. #### Explain the curiosities I also try to explain why things are as they are because people seem to be interested. But only after explaining how it works and providing an example. #### If practice deviates from the spec, change the spec In writing the spec for RSS 0.91, I found that a lot of the limits imposed by the earlier spec were being ignored by developers. So I left the limits out of 0.91 spec. No one complained. After RSS 2.0, the format was frozen, so no more adjustments based on practice. #### No breakage Version 2 of your format should be backward compatible. This means that a version 1 file is a valid version 2 file. Don't break the installed base. (Not that you can. There are still lots of people running XP even though Microsoft said it was over. And that's a commercial product, not a standard.) #### Freeze the spec At some point, when the new ideas have slowed to a trickle, and as a base of compatible software develops, freeze the spec, but provide an extension mechanism so new ideas have an outlet. Developers need a foundation to build on, one that is fixed and isn't moving. #### Keep it simple Beware of open formats that are impossible to fully support. XML-RPC could be fully supported in a few days. You could never fully support SOAP. I believe this is no accident. Large companies crafted SOAP so they could say they were open without interoperating with competitors. The goal of XML-RPC was to make it easy to interop. #### Developers are busy Now you've got a popular product and your data formats are open and documented, you are encouraging your competitors to be compatible. Next thing to do is to create a toolkit in at least one popular language that shows how to support the format. Real working code can help fill in the blanks for the spec. Some developers will use the sample code without ever looking at the spec. I know I do. #### Mail lists don't rule There's a weird bit of psychology that seems to happen on mail lists set up to discuss interop. The people there feel like they can make decisions that the world will then obey. You can hear it how people talk. They seem to believe they have arrived at the top of the pyramid and now they are masters of the universe. Actually, they're just people on a mail list. No one, not even the other people on the list, care what you think. Same is true for real world conferences. #### Praise developers who make it easy to interop I'm thinking of Slack. They didn't have to make it so easy, but they did anyway. It's the web way, it's the strong way. They're saying they want their users to be free to leave at any time. That they should stay with Slack because their product is the best, not because they have to stay. #### Updates August 4, 2026: How to create a standard, 2026 addition (scripting.com/2026/08/04/124651.html)., Rules for Standards-Makers, Dave Winer, 01m1pmxkg1qeznsj5yjm7yqqqn.