RSS Sync: Please, No Standards Bodies

love-rss-icon-sm.jpg: Seen on Brent Simmons’ new RSS-Sync mailing list:

On Sun, Mar 17, 2013 at 10:13 PM, Will wrote:
“It seems like W3 Community groups are designed to structure the development of this sort of web standard… it seems like integrating with their process would help add credibility to the protocol this group settles on…”

I think this is the wrong approach.

We already have a de-facto standard in Google Reader’s API. Tens, if not hundreds of mobile and desktop apps are built to speak this API, and don’t currently have an alternative.

Involving a standards body, with all the negotiating, politics, and gnashing of teeth that comes along with that, could take years and might still not result in a useful protocol.

Given that there’s a matter of months before Reader is turned off and hundreds of apps break, slowing down now is not an option.

A couple of examples

De facto standards count, especially when they’re widely adopted.

Here are a couple of examples where there was a large push to get the standard supported by a standards body, which haven’t panned out so well:

ATOM
The Atom format was an IETF standard that arrived after RSS was already established. It took at least 18 months to be published as an IETF proposal.

Atom has never been as widely adopted as RSS, and the RDF-based RSS 1.0 has even less footprint than Atom does today.

SOAP
I worked for months on SOAP 1.1 interoperability while at UserLand in the early 2000’s. SOAP was a W3C standard.

Getting everyone to agree on what it should be was enormously time-consuming, and arguably yielded a spec that as of v1.1 when my involvement ended, still had many ambiguities, and favored some programming languages over others.

Today JSON prevails, and SOAP is limited mostly to apps that need to interop with legacy services, and large enterprise service-oriented architectures.

(JSON was an informal standard for years before it was published as an IETF standard.)

Why this matters

Users shouldn’t have to care
Users don’t know, and couldn’t care less what protocol or wire format is used for this stuff.

They want their feeds to stay in sync across all of their devices. And they want their favorite apps to keep working after Google turns off the lights.

Users couldn’t care less whether the way this works has a stamp of approval from a standards body, and they’ll never glimpse the blood, sweat and tears that developers will invest in the systems they rely on.

They just want their stuff to work.

Developers shouldn’t have to care either
A new standard means that the tens or hundreds of apps that are already in the ecosystem, would have to have one of their most important components rewritten. And that’s assuming that whatever the new standard were, it would even be compatible with those apps without a major rewrite in other areas.

Apps by developers who can’t (or won’t) make the investment to move to the new standard would die, and that would be nothing but bad for users, bad for competition and diversity, and bad for RSS.

And when those apps die, who will the majority of users blame?

(Hint: It’s not Google.)

Be First to Comment

Post a comment