Month: <span>March 2013</span>

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.)

RSS Web

Chuck Shotton: Google Reader’s Real Value (via Dave Winer)

“Google Reader was at best an average RSS reader. But it excelled at keeping all of my other 3rd party RSS reader apps in sync… When Google Reader shuts down, what is going to do that for me? The answer right now is ‘nothing.'”

Yep – this is a big hole. One that will hopefully be filled soon.

I wrote a bit last month about what Syncpocalypse would mean for bloggers, after the last brief outage.

RSS Web

From The Old Reader blog:

“Paid accounts will have some additional features, but the basic free accounts will still be 100% usable. We are not in this game to make money, but we want to give something special back to the people who are going to be supporting us…

“We reworked the plans according to the news today. Creating an API for mobile clients is the number one priority in our roadmap. We would love to collaborate with any developers who were making Google Reader clients. Please, spread the word about this if you can.”

This is the right move, in my opinion, however I do have two bits of unsolicited advice:

  1. Please clone the Google Reader API, even if you are going to create your own. By doing this you’d immediately make it possible for app developers to migrate their users from Reader to your service.
  2. Re-position your API as a more general service, not just targeted at Mobile. While there are many more mobile apps that depend on the Google Reader API, there are still desktop apps that use it too.

For now their web UI is under quite some strain. It took many seconds to load when I tried it just now (but it did load). They’re adding capacity as I write this, and I bet they’ll get it under control.

(Bonus link – Rob Fishman on BuzzFeed: Google’s Lost Social Network. “How Google accidentally built a truly beloved social network, only to steamroll it with Google+.” Amen, brotha.)

Blogging RSS Web