RSS is the most forked format in this hub, and at the same time the most durable one. Those aren’t contradictory facts — they’re the same fact, viewed from two directions. A specification nobody has the standing to change doesn’t stay put. It survives, structurally frozen, while everyone who needs something it doesn’t offer builds around it, on top of it, or instead of it. That isn’t a story about RSS being badly designed. It’s a story about what happens to any standard — a file format, a wire protocol, an internal API schema — the moment its governance answers “who decides?” with silence.
The general claim is this: a standard that cannot be amended forks. RSS is the case study, not because its history is unusual but because the mechanism is unusually well documented. You can point to the exact clause that froze it, the exact license that let it be forked a second time, and the exact standards-body process that answered the freeze from outside. The full story of who actually built RSS, and how it split into two incompatible branches by 2000, is its own article. This one stays on a narrower question: once a spec exists, who is allowed to change it — and what happens when the honest answer is nobody?
Freezing a Spec Looks Like Stability, Until Something Needs to Change
In its own words, the RSS 2.0 specification states plainly: “The RSS spec is, for all practical purposes, frozen at version 2.0.1. We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the purpose of clarifying the specification, not for adding new features to the format.”
Read charitably, that’s a reasonable engineering decision. Implementers hate a moving target — a parser you wrote in 2003 should still work in 2026, and freezing the core is how you promise that. Plenty of stable infrastructure works exactly this way on purpose.
The trap is what freezing doesn’t answer: what happens the first time someone genuinely needs the format to do something new? A freeze without a body empowered to evaluate the next question doesn’t prevent that question from being asked — it just guarantees the question gets answered somewhere else, by whoever needs it badly enough to build without anyone’s blessing. RSS 2.0 has taken on no new required elements since that freeze. The world built podcasting, full-text feeds, and a second XML syndication standard around it instead.
Transferring the Document Isn’t the Same as Owning the Format
On 15 July 2003, UserLand transferred the RSS 2.0 specification to the Berkman Center for Internet & Society at Harvard Law School. That sounds like the moment RSS got a steward. It wasn’t — the transfer announcement says so directly: UserLand “specifically disclaimed ownership of the format that the specification describes, so no transfer took place on the format itself.”
Sit with the distinction, because it’s the whole mechanism. A specification document is a copyrightable text — you can hand custody of it to a university. A format is a set of rules other people implement. You can transfer the first while declaring the second unowned, and that’s what happened. The practical effect: nobody had standing to approve or reject a change to what RSS actually was — not UserLand, which had disclaimed it, and not Harvard, which held a document but not the thing it described. It’s the standards equivalent of a codebase with no one holding merge rights — the source is public, but no pull request can ever be accepted.
An Open License Doesn’t Prevent a Fork — It Pre-Authorizes One
Harvard published the RSS 2.0 document under a Creative Commons Attribution/Share-Alike license. That license is generous by design: anyone can copy, redistribute, and build on the text, provided they credit the source and share alike in turn.
It’s also exactly the mechanism that let RSS’s governance problem repeat at the document level. The RSS Advisory Board — a small group formed at the 2003 transfer, explicitly not describing itself as a standards body — later published its own “RSS 2.0 Specification, version 2.0.11,” dated 30 March 2009, self-described as “a derivative work of an original document titled RSS 2.0 published by the Berkman [Center] for Internet & Society authored by Dave Winer.” Harvard’s own copy carries a footer stamp of 29 April 2007 and was never updated to match. The result: two maintained, legally valid texts of one “frozen” specification, held by two institutions, neither with authority over the other.
The Board itself is worth being precise about: founded with Dave Winer, Jon Udell, and Brent Simmons; Winer resigned in June 2004; current membership recorded as Rogers Cadenhead, Adam Curry, and Steve Zellers — an odd-numbered group deciding by majority vote, whose own page states it is “not” a standards body. It can write technical notes and make minor clarifying edits per a roadmap. It cannot, and does not claim to, settle who owns RSS.
The lesson generalizes past XML: an open license without a governing body doesn’t prevent forking — it legally pre-authorizes it. Permissive terms are usually framed as a purely good thing for openness. They’re also the mechanism by which “one canonical text” quietly becomes two.
Atom: What a Standards Body Actually Buys You
While RSS sat frozen and disputed, the IETF chartered a working group to build something else. Its charter is candid about the relationship: the group “will use experience gained with RSS … as the basis for a standards-track document,” aiming to “produce a single feed format and a single editing protocol.” The outputs were RFC 4287, “The Atom Syndication Format” (December 2005), edited by Mark Nottingham and Robert Sayre, and RFC 5023, “The Atom Publishing Protocol” (October 2007), edited by J. Gregorio and B. de hOra — both Standards Track. Atom is not “RSS 3.” RFC 4287’s abstract stays deliberately neutral about the format it followed, and the working group is recorded as concluded, having shipped what it was chartered to ship and then closing down.
What governance bought here: one canonical, citable text with a permanent RFC number instead of a page two institutions maintain competing copies of; a formal decision process — working-group consensus, then IESG approval — instead of a three-person majority vote; and a defined errata path that requires no one to disclaim ownership of anything.
What it didn’t buy was displacement. Checked today, Apple’s current podcast requirements still specify a feed opening with rss version="2.0" — not Atom. Atom won the argument about how a spec should be governed and lost the argument about what people would actually run.
Extension by Namespace: The Escape Valve for a Core That Can’t Move
If the core can’t move, the pressure has to go somewhere, and RSS’s answer is the XML namespace — a way to attach new, optional elements to a feed without touching or renegotiating the frozen document underneath. Apple’s own required podcast-feed template is the clearest illustration: it declares both xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" and, tellingly, xmlns:content="http://purl.org/rss/1.0/modules/content/" — a module namespace belonging to RSS 1.0, the RDF-based branch, reused inside an RSS 2.0 document. The modern podcast feed is, structurally, a hybrid of both branches of the 1999–2002 split. Nobody had to resolve the fork to build on top of it.
The escape valve is still active work. The Podcast Namespace project adds tags like <podcast:transcript>, <podcast:chapters>, <podcast:person>, and <podcast:liveItem> through a phased, community-run process requiring, in the project’s own words, “commitment to adoption by at least 1 host and 1 app” before a tag graduates — shown, in its documentation, side by side with the older iTunes namespace rather than replacing it. That’s a real, if lightweight, governance process, operating entirely outside the document nobody has standing to amend: the freeze working as designed.
What It Costs to Be Able to Change Your Mind
It’s worth comparing this honestly to standards that do have a working amendment process, because governance isn’t free — it has a real cost.
HTML is maintained by WHATWG as a Living Standard: no version numbers, continuously updated, changes proposed by opening a GitHub issue the editor weighs against browser-vendor and developer feedback. WHATWG says plainly that the earlier alternative — treating HTML as “complete” after HTML4 — produced years of stagnation. But that model has its own fork history: for years, W3C and WHATWG independently published different specifications both called “HTML5,” a split with real structural similarity to RSS’s two-canonical-texts problem. It took a signed memorandum of understanding in 2019 to end it — WHATWG became the sole publisher, and W3C agreed to stop maintaining a competing version. Fixing that fork required two funded organizations to negotiate a treaty; nothing about the web forced it to resolve alone. And WHATWG’s own copyright line names who’s in the room: Apple, Google, Mozilla, and Microsoft — genuinely governed, by the same companies shipping the browsers that implement it.
HTTP shows the other cost. RFC 9110, “HTTP Semantics” (June 2022), formally obsoletes a stack of earlier RFCs — 2818, 7230 through 7235, 7538, 7615, 7694 — consolidating them into one current Internet Standard held by the IETF Trust. That’s the opposite of RSS’s problem: one citable version at a time, with a real process for retiring the old one. The cost is speed and access — working-group consensus takes sustained participation over years, and the organizations with budget to show up to every meeting, again largely browser and server vendors, carry outsized weight.
The honest trade: governance buys the ability to fix your own mistakes and one canonical text instead of a disputed one. It costs time, and it doesn’t happen without someone funding people to sit in the room — its own kind of ownership question, just quieter than “who holds the commit rights.”
The Work Never Stopped
This is where the RSS story stops looking like decline and starts looking like infrastructure. Standards work on syndication kept shipping long after the “RSS is dead” narrative set in. WebSub became a full W3C Recommendation on 23 January 2018 — and was revised as a Recommendation on 2 June 2026, adding cross-site-scripting mitigations. A specification still being amended in 2026 is not a relic. JSON Feed — a pragmatic, JSON alternative “like RSS and Atom” — was announced by Brent Simmons and Manton Reece on 17 May 2017 and updated to version 1.1 on 7 August 2020. The Podcast Namespace, described above, is still adding tags through its phased process today.
None of that was required. Nobody forces a maintenance team to keep publishing Recommendations and version updates for a format that’s genuinely dying. A format nobody uses does not keep acquiring standards. The frozen core stayed frozen; the ecosystem around it kept working exactly the way a namespace-based escape valve is supposed to let it.
The General Lesson, for Anyone Freezing a Spec
None of this is unique to XML syndication. It applies to any file format, wire protocol, or internal schema a team decides to lock down.
Decide who has standing to say yes before you need someone to say yes. “Frozen” isn’t a governance model; it’s the absence of one, and the absence gets filled by whoever’s willing to build without permission. Ship the extension point before you ship the freeze — namespaces are why RSS absorbed podcasting, iTunes metadata, and transcripts without ever reopening its own document. A permissive license doesn’t protect you from forking; without an owning body behind it, it’s the mechanism that enables one, as the Advisory Board’s own derivative specification shows. And don’t assume the better-governed alternative wins by default — Atom is tighter and more correctly processed, and it never displaced the format Apple still requires by name. Most tooling just accepts both; interop is usually cheaper than winning the argument.
❓ Frequently Asked Questions
Is Atom “RSS 3.0”? No. Atom is a separate IETF Standards Track format — RFC 4287 (December 2005) and RFC 5023 (October 2007) — built by a different organization with a different process. Its own abstract describes it neutrally, without treating RSS as a predecessor to be numbered after.
Who governs RSS today? No single body. Harvard’s Berkman Center holds one copy of the RSS 2.0 specification document; the RSS Advisory Board maintains a separate, CC-licensed derivative version; and the Board states on its own page that it is not a standards body. The format, as distinct from any document describing it, was disclaimed by UserLand in 2003 and has had no owner since.
If Atom is better governed, why didn’t it replace RSS? Governance and adoption are different contests. Apple built its podcast ecosystem on RSS 2.0 and has never required Atom; that one deployment decision, repeated across an enormous base of publishers and apps, outweighed Atom’s cleaner process. Most feed readers and parsers simply support both rather than picking a winner.
Is RSS still receiving updates? The core 2.0 specification is not — frozen at 2.0.1 since 2003 by design. But the ecosystem keeps shipping: XML namespaces, the Podcast Namespace’s phased tag process, WebSub as a W3C Recommendation revised as recently as June 2026, and JSON Feed as a related-but-separate format updated as recently as 2020.
Does this pattern show up outside RSS? Constantly. Any spec declared “stable” without a funded process for evaluating changes tends to sprout unofficial extensions, vendor forks, or a competing standard built by whoever needed the missing feature. RSS is simply an unusually well-documented example of an ordinary failure mode.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the primary documents, because on a governance argument they’re the actual evidence, not background reading. Every load-bearing claim in this article traces to a document you can read for free right now: Harvard’s RSS 2.0 specification and its version history, the RSS Advisory Board’s derivative “v2.0.11” text, the IETF’s atompub working-group charter, RFC 4287 and RFC 5023 themselves, the W3C’s WebSub Recommendation, WHATWG’s own FAQ on why HTML has no version numbers, and Apple’s current podcast feed requirements. None of them are paywalled, and a governance dispute is best understood by reading the actual clauses that caused it.
The book below earns its place where a print treatment goes deeper than a spec page can.
RSS and Atom in Action: Web 2.0 Building Blocks
Dave Johnson · Manning, 2006 · Paperback
⚠️ Note on the shelf itself: no post-2006 book on the RSS/Atom formats exists — this is the best of a closed, dated set, useful specifically for readers who want the format mechanics (elements, namespaces, the actual XML) that this article’s governance argument sits on top of. It won’t teach you the governance history — the free specification pages do that better and are current. It’s the right next step if the technical shape of a feed, rather than the politics of who could change one, is what you want to go deeper on.
One level up the stack: if the part of this article that stuck with you is less “how RSS’s spec got frozen” and more “who gets to write the rules an open system runs on,” that’s a bigger question than syndication formats. Custodians of the Internet: Platforms, Content Moderation, and the Hidden Decisions That Shape Social Media by Tarleton Gillespie (Yale University Press, 2018) examines the same underlying question — who has standing to decide the rules of a system nobody quite owns — one layer up, at the platform level rather than the file-format level. It is not about RSS and does not claim to be; it is offered as the adjacent argument for a reader who wants to keep pulling on this thread.