[jad]

Companies can iterate on their products much faster if they're not required to publish all of their functionality as public APIs. Once the APIs have been published, it's much harder for them to be changed.

Doing this also puts them at the mercy of whether or not client applications are willing to support their new functionality. Maybe YouTube wants clients to adopt some feature, but a powerful client application doesn't like that feature and so won't support it.

The protocol/platform lock-in is a problem, but preserving companies' ability to iterate quickly on features is also very important.

[adam_arthur]

The company doesn't need to expose custom APIs on their data. If they implement a chat protocol, they must allow other clients to interface with it.

For the data side, likely any requirements wouldn't go into effect until a dataset is deemed sufficiently large/societally important, and there could be a period of exclusivity similarly to the patent system to encourage innovation. This system works very well for new drug creation, with competitors free to copy the drug for pennies on the dollar after patent expiry, so I very much doubt it would stifle innovation in tech, especially given the lower capital requirements to innovate.

I'm not suggesting at all the government mandates private companies implement a public write api into their own datacenter. I'm suggesting the privately hosted data must be replicatable and thus hostable by competitors. Likely the practical way to do this, technically, is to support a public kafka/persistent eventing system such that anybody can firehose all historical and new data. Ideally with funding help.

Hosting data is cheaper than ever, and continues to deflate in cost. The companies in this line of fire are already quasi-monopoly behemoths, so I don't buy into the cost-prohibitive/stifling innovation perspective.

[9dev]

> The company doesn't need to expose custom APIs on their data. If they implement a chat protocol, they must allow other clients to interface with it.

And how would that work without a way to talk to the company’s chat server, and document the way to do that, and commit to keeping that way of communicating reasonably stable? In other words, an API?

Which implies sort of a commitment to the way that chat protocol works, maybe even before the company knows how that looks like. Modern development methodology, that is, working in sprints and iterating towards a local maximum, doesn’t really go well with an API that’s required to work pretty much stable from day one. So when would the point in time be where you’d be required to open up to other clients?

[adam_arthur]

The comment you're replying to already answers this, so I'll refer you to that

[9dev]

not really. An API doesn’t necessarily have to be a HTTP interface. A data schema is also an API, if the documents are made available. The endpoints where that data is available is. And you still need heaps of documentation that someone needs to maintain. Not every system has simple to, from, and content fields.

I just doubt you really thought this through.

[Waterluvian]

It’s going to be hard to actually draw a line on what ought to be public.

If I make a multiplayer video game and it has a chat feature, do I have to expose that?

Opinions and feelings won’t cut it: what’s the prescriptive rule to know?

[bionhoward]

Ask customers

[BoredPositron]

Some guy at Google who worked on like 14 chat apps over the last two decades might just welcome it...

[hinkley]

Most of the APIs that do get published or standardized are so large and complex that they form a kind of regulatory capture. Almost nobody but the biggest boys can afford to make them. Add a few laws that increase overhead, and Bob's yer Uncle.

[kmeisthax]

"Public API" doesn't mean you can't change the API, nor does it limit how quickly extensions or new versions can be added to that API. It just means you have to actually inform people of what you're changing and when.

If a client application refuses to implement functionality, that's on them, not the original developer. If I want the new feature, I'll switch.

These days however, new features nowadays are usually things I don't want. Not strictly outright anti-features, but usually completely pointless "Bob needs a bonus[0]" changes that lets a middle manager put something good in their promo packet. The whole reason why people want compatible file formats and third-party clients is specifically so we can dictate to the originator of those formats and protocols how and how fast they can iterate on their products and limit how bad they can deliberately make them to increase profits.

[0] https://youtu.be/ssob-7sGVWs?t=2748