If an API existed yesterday, and it does the same thing it did yesterday, you're fine. If you don't like how it works, add a new one and use that. You just can't take the old one out, or change how it works, without providing significant advance notice.
> What if you want to make a change to the system that isn’t compatible with maintaining the old api?
> How about if the old api can’t scale as the user base grows?
Tough luck?
What if Amtrak wanted to make trains twice as wide?
What if EDF Energy would rather supply 160V AC power?
What if it'd be easier if there were a few orders of magnitude more IP addresses?
Once you build something, especially if it becomes part of the infrastructure, you have to support it, often for a longer time than you'd like. When you get to a certain scale and level of societal/economic importance, the support required of you as a company should be enforced by society.
Scale brings many benefits but also should come with certain expectations and commitments. We are very bad at making tech companies play their part in this.
>> How about if the old api can’t scale as the user base grows?
> Tough luck?
Tough luck for whom? It seems like nobody wins in that scenario. What do you think would happen?
> Once you build something, especially if it becomes part of the infrastructure…
This is a circular argument. The proposal is that all services be forced to be treated as infrastructure, even if they aren’t. As I say, this is clearly unworkable.
No thanks. It’s fairly obvious that the current crop of giants will not retain their power forever.
I’d rather not have them declared infrastructure and become a permanent fixture.
AC voltage and Railway gauges were standardized in the 1880s.
The idea that Facebook should be established by law as infrastructure for the next 130 years is a level of dystopian thinking I hadn’t previously considered.
> Tough luck for whom? It seems like nobody wins in that scenario. What do you think would happen?
They would immediately announce that the old API is deprecated and will be removed in two years and then have high server bills for two years.
Also, you can provide the new API in parallel and publish good documentation for it so that other implementations use the new one immediately instead of waiting the two years and then only some small minority of clients will continue using the old one.
> I’d rather not have them declared infrastructure and become a permanent fixture.
Requiring Facebook et al to have a stable API would cause them to be less permanent, because it makes switching easier.
Right now you can create an alternative messaging app all you like but nobody will use it unless other people are using it. It has to be a lot better to dethrone Facebook.
If anyone could make one that could still be used to talk to people on Facebook, it would only have to be a little bit better for people to switch to it. And once you have a messaging app that can use twelve different services, the ones people were only using because of the network effect lose that advantage and die out.
Also, how are two years and "permanent" in any way equivalent? It's two years to give interoperable implementations enough time to be switched to the new API before the old one is discontinued, nothing more. The problem right now is that the first party service will discontinue the existing API and roll out a new client using the new API on the same day, intentionally breaking all alternative implementations until they scramble to reverse engineer and implement the new one, and then do that repeatedly on purpose until all other implementations are dead.
> Tough luck for whom? It seems like nobody wins in that scenario. What do you think would happen?
> They would immediately announce that the old API is deprecated and will be removed in two years and then have high server bills for two years.
What if they are a startup who can’t afford that?
More importantly, what if they can’t realistically operate both simultaneously because there is an impedance mismatch between the implementations?
> Also, you can provide the new API in parallel and publish good documentation for it so that other implementations use the new one immediately instead of waiting the two years and then only some small minority of clients will continue using the old one.
What if the service is operated by a startup, and the clients are the incumbents like Facebook, or competitors, who don’t have any incentive to switching to the new api immediately or even quickly?
> Also, how are two years and "permanent" in any way equivalent?
Because it’s far easier for a company with billions in revenue to afford the costs of keeping many parallel APIs running, and crippling for a startup which needs to iterate fast. Forcing this expense on services would be the best thing to happen to the incumbents.
> It's two years to give interoperable implementations enough time to be switched to the new API before the old one is discontinued, nothing more.
You might like it to be that, but that’s not what it is. You seem to think this would hurt Facebook, when really it just creates a giant impediment to newcomers that Facebook never had to deal with as it was growing.
> The problem right now is that the first party service will discontinue the existing API and roll out a new client using the new API on the same day
Yes, which is exactly how an evolving new service must operate in order to be competitive.
> Right now you can create an alternative messaging app all you like but nobody will use it unless other people are using it. It has to be a lot better to dethrone Facebook.
We deserve a lot better than Facebook. There is no point in dethroning it with something that is only slightly better.
If an API existed yesterday, and it does the same thing it did yesterday, you're fine. If you don't like how it works, add a new one and use that. You just can't take the old one out, or change how it works, without providing significant advance notice.