Hacker News Reader

Comment by adam_arthur | Hacker News Reader

Government should just require open communication protocols/file formats, if a competitor is willing to host the same data at cost.

Client applications should compete on their individual merits, not coast on protocol lock-in.

Would WhatsApp or YouTube have as many users if others could build clients for the same data? (PII etc notwithstanding)

Protocols compete on the merits of the protocol, clients compete on the merits of the client.

I think this will be the reality/obvious a few decades down the line.

View on HN

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.

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

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.

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?

Ask customers

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

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

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.

"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

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.

> Government should just require open communication protocols/file formats, if a competitor is willing to host the same data at cost.

Well, that's what happened with the "Office Open XML" standard, which has been a catastrophe. Microsoft perfectly handled every country to have their ISO standard pass. Even though it was in violation of ISO requirements, which many countries voiced. Those complaints "somehow" disappeared. The fact that at ISO you're not allowed to divulge who is paid by which company might be related. Or maybe not. Either way, IMO, the conclusion is that you can't delegate democratic functions to a non-democratic organization.

But I wholeheartedly agree with you on the principle. Interoperability brings innovation and competition. Not lock-ins/walled gardens. And interoperability requires standards not ""technical specification"" which is the new slang for oligopoly.

>Would YouTube have as many users if others could build clients for the same data?

Would those YouTube clients offer a subscription service to pay for the data they download, or did you expect Alphabet to cover all the costs?

There are an astounding number of people who never stop for even a second to consider the nuts and bolts implications of the ideas they want to foist onto society.

You're talking about the employees of big tech firms, right?

Yes. As well as their detractors.

Pass regulations that might kill YouTube just to see how it works out. Maybe Google is more robust and cleverer than we expect. Worse case we just lost a bunch of pointless reaction videos and other crap.

They would likely employ advertising, just as YouTube does. Are you saying it's not profitable to run a video hosting service?

YouTube is evidence of that already.

A more straightforward way to accomplish this in areas where content size is large/expensive is to disallow coupling client creation with data hosting, and data vendors would license access to their data to client creators.

Bundling becomes anti-competitive at a certain network size, because there becomes no meaningful way to create a competitor network. The essence of what makes capitalism effective is competition driving costs lower, and in many areas in tech we have very little competition due to large network effects.

Keep in mind Capitalism != Free Market. A fully free market is a form of Capitalism that has no laws, and no impediment to monopoly formation. Competitive Capitalism with minimal laws to encourage competitive where large network effects or monopolies form is far more societally beneficial in the long run.

Decoupling client/data has already been done many times in the past in analogous situations, e.g. when movie producers were not allowed to own the theaters where the movies were played, giving a much more equal footing to smaller content producers.

They're asking who's going to cover YouTube's costs for providing their videos via API. Or is the expectation that if you use a 3rd party client you'll see youtube's ads to cover their costs, and then additional ads from the client?

Yes, there are many ways to do it, one of which I described above.

You can disallow bundling a video client with the video data provider, thus forcing the data provider to monetize by charging the clients to use the data. The clients make money either via subscriptions or ads, and selling new video data back to the provider.

e.g. Google would have to spin-off or re-org YouTube to split client/data and give same pricing terms to their client branch as to other third party clients

This is a lighter touch/market based solution, which I prefer to being overly prescriptive.

The government should move fast and break things in these sorts of cases. Especially in this case… video streaming isn’t very important, take action that might destroy their business model and see if we learn anything about how to regulate them in more meaningful markets.

We already have 3rd-party YouTube clients: SmartTube, ReVanced, etc. They work quite well, in fact, much better than YouTube's own client.

They don't need any money to cover their costs; they're FOSS. As for YouTube's costs, they don't show YouTube's ads, so basically Google is covering the cost there, though perhaps not willingly. But Google makes the YT API usable by these apps, and after all this time hasn't done too much to try to shut them down. We'll see how long that lasts, but there seem to be real technical limitations to how much Google can force ads, without resorting to recoding videos with ads in them which they surely really don't want to do.

> without resorting to recoding videos with ads in them which they surely really don't want to do.

There is an easy technical solution to this, just stream ads in the video feeds just like TV does. That downgrades the user experience compared to easier to separate ads, but if they can see you watch videos without the normal ads they can always do that.

But the main reason they don't is probably that they can't target such ads very well and it is more expensive to inject in a stream rather than send separate videos, so not sure if it is even worth it for them.

>There is an easy technical solution to this, just stream ads in the video feeds just like TV does.

You mean bake the ads into the stream? I don't think that's so easy to do in realtime. Even TV decades ago never did this AFAIK: they played the programming from one source, and then switched over to the commercial from another source (probably videotape) at the correct time.

Anyway, if you're talking about permanently encoding the ad into the video, that really doesn't make sense. The ad probably won't be relevant to many of the viewers. YouTube is global, so if someone from France watches a cat video uploaded by an American and it has ads in English for Applebees restaurant, 1) they probably won't even understand it unless they happen to speak English and 2) there's no Applebees in France. The same thing applies if it's an ad for a restaurant that only exists in, say, California: viewers in New York aren't going to care, and the restaurant doesn't want to pay to advertise to viewers outside their area. Even worse, ads normally run for limited times, so YouTube would have to constantly re-encode videos to change the embedded ads.

As much as I think big tech sometimes abuses their power and leverage unfair advantages we shouldn’t stifle innovation by requiring everything to be totally open from the get go. If there’s zero switching costs to go to a competitor then what’s the incentives for companies to spent a lot of money and time building a product? It’d be very risky (especially for small players actually) and they’ll have to do “safe” incremental functionality until they have a larger user base and can afford to invest in R&D because it’s less likely many of their users will leave all at once. It’s the same reason why we have patents for things - to incentivise the investment in R&D. Maybe there could be a threshold for time+revenue+users that trigger the need for openness? Same should be true for social networks and when we can/should set a higher bar for holding them responsible for abuse on their platform I feel.

The problem is open protocols can just as easily be consolidated down to network monopolies at the application layer.

Look at what happened to SMS (Apple's malicious implementation pushing everyone onto propriety networks like WhatsApp). Or email, where Outlook and Gmail have a bulletproof duopoly, leading to decades of stagnation. Outlook still renders emails with the 2006-era Microsoft Word html engine (Gmail is almost as behind on this), hence why email still doesn't support a lot of modern (>10 years old) accessibility features.

Things like ownership over domain names in the email protocol still create monopolies -- since Google owns gmail.com, it's literally like them owning your telephone number/mailbox. If you're like 99.9% of consumers without their own domain name for email, you cannot switch. Gmail owns you.

> Government should just require open communication protocols/file formats

They did, Microsoft made Office support some open XML thing, and what changed?

People realized that actually it requires a lot of investment to produce an office suite.

It's not really open, nor is it really the MS Office documents format.

And yet, a few competing alternatives appeared anyway.

What changed? It's now trivial to write exporters for Office formats for specific use case. Save a sample of what you want to have exported, and then just template the XML, generate it based on source data and zip it.

Most of the time you don't even need to read the specification.

Compare that with the times of eg. closed binary XLS format.

We did get Libre office and Apache OpenOffice due to that? I think they both should become obsolete in an ideal world where folks converse in fluent markdown to achieve everything they want in a document.

No, LibreOffice (and Apache OpenOffice, but Apache OpenOffice is pretty much dead and nobody should use it) are descended from Sun's OpenOffice.org, which is descended from their acquisition of StarOffice. See https://en.wikipedia.org/wiki/LibreOffice

LibreOffice uses the OpenDocument standard. https://en.wikipedia.org/wiki/OpenDocument

Microsoft's "open" standard, "Office Open XML" was created in response: https://en.wikipedia.org/wiki/Office_Open_XML The standardization process was incredibly irregular (see Wikipedia and LWN from that time period.) I'm sure the naming was not intended to sow confusion at all.

I've observed that the quality of third-party SDKs for Microsoft office formats improved substantially. The .xls format was notoriously fickle to process or produce from outside of Excel. As of .xlsx, the open source community produced myriad SDKs in various languages, and the ones I have experience with worked quite well. The format becoming less arcane and better documented was important to enable this.

I would replace government with people: people should collectively demand what you have described.

This ultimately is a function of education, which will get better as technical knowledge becomes more widely and freely available.

As you say, it's only a matter of time before the walled gardens start to crumble.

> I would replace government with people

This is... The entire point of a government. Yes, they're flawed, but they're meant to exercise the will of the people, especially in terms of regulating entities that have outsized power vs. an individual citizen (corporations, wealthy magnates, etc).

Government has by far and wide the most "outsized power" v. a corporation or wealthy citizen... It does not "exercise the will of the people", it forcefully imposes that of their rulers.

https://rintintin.colorado.edu/~vancecd/phil215/Nozick.pdf

Perhaps, but you're missing my point. Governments are out of touch with what people need and even if they're trying to help, they'll get things very wrong (for example, those annoying cookie popups we've all had forced upon us).

People know what they want, and will vote with their wallets. As long as options are allowed to exist, you can trust a well informed public to gravitate towards the most optimal solution over time.

> People know what they want, and will vote with their wallets.

Sure, but in this case there's stacked incentives against people being able to vote with their wallets in the first place with ecosystem lock-in. The companies are incentivized to prevent people from being able to easily switch to a competitor, which is exactly why most people don't, and by and large the general populace isn't going to be savvy enough to recognize that's what's happening.

Like you said, the way you combat that is having a "well informed" public, but who's going to be responsible for informing the government? That's the entire point of the US FTC, is representing the interests of US consumers and paying attention to related issues.

> Governments are out of touch with what people need

Yes, governments are going to be slow and conservative w.r.t. what current public opinion is, because organizing large groups and institutions is difficult.

> This ultimately is a function of education, which will get better as technical knowledge becomes more widely and freely available.

Unfortunately, the level of technical knowledge of the population is going down. People do not care or treat tech as a magic. On a higher level of education, Microsoft can rely on a cohort using Windows at school/home/university/work.

> As you say, it's only a matter of time before the walled gardens start to crumble.

Watch what Microsoft and others are doing in the acquisition space. Microsoft is buying into businesses that use their products. What are the chances of those businesses witching away from Microsoft software stack?

I've never used Team but Google Docs/Sheets/Presentation has a chat function

https://support.google.com/docs/answer/2494891

Is that required to use an open protocol?

You're not required to use an open chat protocol, you're required to make any chat protocol you use open. (With some exceptions)

Communication protocols and file formats IMHO.

but.. file systems

This is just going to create a perverse incentive to create really fat clients.

Reply on news.ycombinator.com