Manifesto: Rules for standards-makers

Seventeen rules for creating standards that actually work, prioritising interoperability and real-world implementation over theoretical perfection.

  1. Interop is all that matters

    The only measure of a standard’s success is whether different implementations can work together.

  2. There are tradeoffs in standards

    Every decision involves compromise. Accept this rather than seeking impossible perfection.

  3. Software matters more than formats (much)

    Working software that people use trumps elegant specifications that remain unimplemented.

  4. Users matter even more than software

    Ultimately, standards exist to serve people. Keep their needs at the centre of decisions.

  5. One way is better than two

    Multiple ways to do the same thing create confusion and interop problems. Pick one.

  6. Fewer formats is better

    Every new format fragments the ecosystem. Use existing formats when possible.

  7. Fewer format features is better

    Each feature is a potential incompatibility. Include only what’s genuinely necessary.

  8. Perfection is a waste of time

    Good enough and shipping beats perfect and theoretical. Standards improve through use.

  9. Write specs in plain English

    If developers can’t understand the spec, they can’t implement it correctly.

  10. Explain the curiosities

    Document the weird bits and why they exist. Future implementers will thank you.

  11. If practice deviates from the spec, change the spec

    Reality wins. When implementations consistently differ from the spec, the spec is wrong.

  12. No breakage

    New versions must not break existing implementations. Backwards compatibility is sacred.

  13. Freeze the spec

    At some point, stop changing it. Stability enables confident implementation.

  14. Keep it simple

    Complexity is the enemy of interoperability. Resist feature creep.

  15. Developers are busy

    They won’t read long specs or attend endless meetings. Respect their time.

  16. Mail lists don't rule

    The loudest voices on mailing lists don’t represent all implementers. Seek broader input.

  17. Praise developers who make it easy to interop

    Celebrate those who prioritise compatibility. Their work benefits everyone.