4 ms·

>> 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 t

by zepto 5y ago

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

AnthonyMouse 5y ago
> 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.
- zepto 5y ago
  > 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.

by zepto 5y ago

AnthonyMouse 5y ago

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

zepto 5y ago
> 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.