There’s only one regulation of Big Tech that has no downside for the rest of us: Break up these companies, and require interoperability, to create the conditions that make genuine competition possible.
@dangillmor I’m fully in favor of breaking them up, but as a developer who has taken multiple runs at non-profit and public interest software startups: Don’t mandate interoperability. You will destroy all competition that way.
The big guys can afford to implement n^n connections to each other’s platforms. Startups can’t. The idea might be that it would lead to the creation of common protocols, but that locks people in to a single implementation.
It would take a government more capable than what most of us currently have to come up with a regime for mandatory interoperability that doesn’t suck, but at the same time it’s hard to imagine them bungling it so badly that there’d be any harm to mastodon.social in the attempt.
@kbal @dangillmor How would you go about mandating interoperability? As in, in non legal language, how might you frame the law?
Sure, I’ll take a stab at it. Everyone with more than ten million users implement activitypub and rss, or whatever future protocols are designated by the ietf to replace them. Arbitrary blocking of bad actors is okay so long as you don’t go crazy with it (for a reasonably generous definition of crazy) or are below that size threshold.
(I’m thinking of “social media” of course. Some other “big tech” type things would obviously require different protocols.)
@kbal @dangillmor So you caught the first issue in your final line.
> I’m thinking of “social media” of course. Other[s…] would require different protocols.
How would you define the set that are required to implement RSS? The set required to implement ActivityPub?
That’s an amazingly uninteresting question. In “non legal language” the answer is blatantly obvious, and in legal terms you could look at various recently-drafted legislation around the world which, for all its manifold flaws and dubious aims, does generally manage to do not too bad a job of identifying what counts as social media.
@kbal @dangillmor I’m sorry it’s uninteresting, but it’s the crux of the matter. Mapping services to protocols is the hard part. And it’s not just social media. If we’re talking about mandating interoperability among big tech, we’re talking about all tech.
Social media is most at the forefront of people’s minds, but search and email are just as problematic. Email’s already built on an interoperable protocol and it’s *still* monopolized to where big tech dictates who gets to participate.
There are other parts of the “tech” world I’d apply similar principles to, but they are not search and email which have somewhat different problems. I see no reason not to address these things one at a time.
Some problems are better addressed by the “break them up” part of the proposal we started with, which though it might be less efficacious given the extreme concentration of market power we’re starting with seems also even less likely to involve “downsides for the rest of us.”
@kbal @dangillmor And then on top of that, when you lock certain service types into certain protocols, you cut off evolution.
Imagine if we’d legislated email interoperability by declaring that all “services that implement messaging must implement email”.
You’ve now seriously hampered the evolution of IRC, AIM Chat, MSN Messenger, the various social media messaging services, Slack, Discord, and even localized chats like Stackoverflow’s chat.
@dangillmor While I lean in favor of what you suggest, I fear that “interoperability” will be difficult. This is because, as we discovered over the years with IETF defined protocols, that many groups implement only the minimal core of a protocol or standard, and often do so in ways that are not particularly robust in their response to interactions with slightly different implementations or when network conditions become something less than the perfect, noiseless conditions found on developer networks.
And one need look no further than the awful state of e-mail interoperability today.
My business is building tools to allow implementers the means to test their implementations in less-than-optimal conditions. It is surprising how often even long-deployed code wobbles or fails.
