On croyait globalement jusqu’ici que Google avait fermé Reader pour un problème de coûts. En gros, laisser tourner Reader coûtait trop à Google, sans que l’entreprise ne trouve de moyen de rentabiliser l’affaire, et donc, comme d’autres services, il fallait fermer le service.

Un billet de Marco Arment est venu complètement chambouler cette potentielle version, avec une idée, une hypothèse encore plus moche, mais bien plus crédible à mes yeux.

Il commence en expliquant pourquoi l’hypothèse des coûts trop élevés n’est pas recevable. En gros, Reader ne coûtait quasiment rien en hommes, et pas grand chose en machines.

The most common assumption I’ve seen others cite is that “Google couldn’t figure out how to monetize Reader,” or other variants about direct profitability. I don’t believe this, either. Google Reader’s operational costs likely paled in comparison to many of their other projects that don’t bring in major revenue, and I’ve heard from multiple sources that it effectively had a staff of zero for years. It was just running, quietly serving a vital role for a lot of people.

Puis il explique le plus gros problème de Reader aux yeux des dirigeants de Google : son interopérabilité.

RSS grew up in a boom time for consumer web services and truly open APIs, but it especially spread like wildfire in the blogging world. Personal blogs and RSS represented true vendor independence: you could host your site anywhere, with any software. You could change those whenever anything started to suck, because there were many similar choices and your readers could always find your site at the domain name you owned.

Hors, l’interopérabilité a céssé d’être un pré-requis pour faire un « grand » service. Facebook en est l’exemple le plus concret, comme l’explique Jeremy Keith :

Once Facebook had proven that it was possible to be the one-stop-shop for your user’s every need, that became the model to emulate. Startups stopped seeing themselves as just one part of a bigger web. Now they wanted to be the only service that their users would ever need… just like Facebook.

Seen from that perspective, the open flow of information via APIs — allowing data to flow porously between services — no longer seemed like such a good idea.

Puis il explique le fond du problème : les grands du web n’ont pas réellement envie que leurs services soient interopérables. Ils veulent que les utilisateurs restent chez eux !

The bigger problem is that they’ve abandoned interoperability. RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).

Google resisted this trend admirably for a long time and was very geek- and standards-friendly, but not since Facebook got huge enough to effectively redefine the internet and refocus Google’s plans to be all-Google+, all the time.4 The escalating three-way war between Google, Facebook, and Twitter — by far the three most important web players today — is accumulating new casualties every day at our expense.

Bon, et à part ces mauvaises nouvelles ?

…

A part ça, Marco Arment propose une belle conclusion, à laquelle je souscris plutôt :

That world formed the web’s foundations — without that world to build on, Google, Facebook, and Twitter couldn’t exist. But they’ve now grown so large that everything from that web-native world is now a threat to them, and they want to shut it down. “Sunset” it. “Clean it up.” “Retire” it. Get it out of the way so they can get even bigger and build even bigger proprietary barriers to anyone trying to claim their territory.

Well, fuck them, and fuck that.

We need to keep pushing forward without them, and do what we’ve always done before: route around the obstructions and maintain what’s great about the web. Keep building and supporting new tools, technologies, and platforms to empower independence, interoperability, and web property ownership.