Bluesky’s Atmosphere Protocol has the chance to become the base for a whole generation of applications. But it’s developing in surprising and disappointing ways.
I spent part of last week at the Local First Conference in Berlin. I was not surprised to find that AI coding was on everyone’s minds. Less expected was how pervasive ATProto was.
I’ve been considering trying to build on ATProto for a few months, so this was a great chance to ask a bunch of questions from both people building on it, and the people actually building it (multiple key Bluesky people were there).
I want ATProto to be the answer for me. I want to again live in a world where application developers use public, community driven standards to create interoperable applications with common data standards. I think it can be. But unfortunately I think it’s not on track to be that right now.
In this post I’m going to describe what I have been wanting to build, and how ATProto’s current and proposed designs do and don’t work with that. And I’ll also throw in some comments about what’s been surprising to me.
I’m probably trying to do too much here. But my main goal is to provide feedback on the proposed design, and it’s hard to do so without being clear about what I want to build and why.
Start With Reviews
The smallest version of what I want to build is a suite of applications for recording reviews. In an ideal world, these applications would supplant Yelp, GoodReads, Letterboxd, and a bunch of similar applications for just about anything you might consider reviewing. (Yes, I know there are already people building versions of these on ATProto; I’d want to collaborate with them.)
I want to replace these applications not because of their function, but because of their business models. Neither my wife nor I will use them the way they’re intended, and I think most people are like one or the other of us.
Local First Data
For me, I don’t want these companies to own my data. We have more than a thousand bookmarks in Yelp, but… they’re stuck in Yelp. I can’t do anything else useful with them: I can’t publish them, I can’t share them, I can’t write scripts across them, I can’t version control them. They belong to Yelp, not me. And, frankly, the experience they provide for managing lists of bookmarks kinda sucks.
This is a classic local first use case. I could adopt one tool that was great for writing reviews, another that used the same data but was better at publishing best-of lists for my friends, and another that made it easy to share “best business books” lists on my web site. No single app is going to do all of these, but a shared, public data model allows everyone to have what they want.
I’ve lost the willingness to give big corporations a permanent right to control how I use my own data. (That’s why I’m writing this in plain text and publishing via Hugo.) The apps only get worse over time. And if I’m going to invest that much time in recording my opinions, I want to control its use, not let Yelp do it.
Public and Private
As to my wife, she will just never publish anything online. Never. If I want her to review books or restaurants or recipes, it has to be in a place where I – and maybe the rest of our family – will see it, but no one else.
Personally, I am willing to publish public reviews. And sometimes I specifically want to, like sharing books I found useful as a founder. But doing so is complicated. The information I would record about a restaurant for myself is quite different from what I would want the wider world to know. Yet… most apps don’t allow you to draw this distinction. Reviews are public. Your opinion affects the subject’s reputation, even if you didn’t want it to. (I’m vegetarian and autistic, so a place working for me is not necessarily relevant for other people.)
Fundamentally, most of these applications are built to enable influencers: People who want to build a following online for their reviews. “Oh man, she has the best book recommendations!” “If he likes the restaurant, I know I will too!”
But most of us don’t want to become influencers. If anything, we’ve generally learned the lesson that it sucks to be followed by a bunch of people online. I want to keep my stuff private. I don’t want my opinions to matter to anyone else.
I mean sure, when someone comes to town I want to be able to give them a list of restaurants they should visit and activities they should do. But I want to send it to them, not the rest of the world.
We can split the world into three kinds of people:
Those who would only record a review if other people will read it. These are the influencer-wannabes
People like me, who would provide a mix of public and private reviews, depending on the circumstance
People like my wife who will only ever record reviews if they can be confident it will be private to just their friend group, or even just to themselves
The current crop of applications works fine for the first group. But it leaves the latter two out in the cold.
And I bet anything that those other two groups are much larger.
So, what we need is a system that allows application developers to easily let their users choose how public or private they want to be – entirely public, entirely private, or sharing piecemeal with individual groups.
What does this have to do with ATProto?
Let’s start with what’s great about ATProto: It seems to be the first protocol designed to solve identity at scale, enabling any application to build ATProto identities into their application for authentication, tracking followers and following, and the other related features that basically every application needs.
Its identity system not perfect (I wish it were more human readable, especially). But it seems to be close enough today that nearly every speaker at Local First this year mentioned it. No more does every app developer have to create their own social graph, their own identity and authentication systems, their own means of finding friends.
Unfortunately, at least for now, the rest of the protocol is of limited use for my goals.
Today, ATProto is public-only: It assumes that everything you do will be published online for the whole world to see. That design decision is baked into everything from the storage systems to the structure of the publishing services.
The community is currently designing what they call “permissioned data”. (I think this is a silly name, and it should just be called “private data”, which is better both because “private” is actually a word, and also because it describes user behavior instead of technical implementation, which is a far better naming practice).
Unfortunately, while most of the assumptions driving the design seem reasonable, the resulting design looks very hard to build on. A lot of where I think it goes wrong is captured perfectly in the above linked post:
Before we get into it, the through-line on all of this is that public broadcast data is substantially different from permissioned data.
Private and public data are basically identical. A restaurant review is a restaurant review whether I am the only one who ever sees it or it gets shouted to the rooftops. A book review I share with my book club is identical to a book review I share with my wife or publish on my web site.
Data I publish to the world is just a special case: The permission is world-read. Just like data I never publish is a special case: It has no readers other than me.
Unfortunately ATProto is already used out in the wild for Bluesky, and it is designed and built as a public-only protocol. It would be hard to change it to support access control, limited distribution, and the other features you need with private data.
So, instead, the community has, from what I can tell, just… designed a completely independent system for private data.
Permissioned Data relies on the existing identity system and lexicons (for defining data types). But adds entirely new data structures, plus new methods for managing and validating that data. (Note that the link above is to one in a series of posts on the design; you can get to all of them from there.)
So, as an app developer, you have to essentially write two applications: One for public data, and one for private. But, your users don’t think of it as two apps. “These are restaurant reviews. All the restaurant reviews should go together.” So your job, as the developer, is to support these two data systems, and two protocols, but never let the user see that they’re totally different.
That gets messy real fast. You’ve got a private post you want to make public? You’re not modifying it – you’re deleting the old one and making a new one in the public subsystem. Does it keep its likes? Its reposts? Links to it? 🤷♂️ No idea, but… probably not.
It’s actually worse than that. ATProto’s storage subsystem, the “Personal Data Server”, provides direct access to your data. In other words, you should expect more than one application to want to read and write your data. So now, anyone who is interested in this data has to write two versions, but lie to their users and hide any differences.
Because, again, there aren’t actual differences. The actual data being stored is the same. The way the user thinks about it is the same.
To me this is a sign that the current proposal is flawed.
I don’t know how to fix it. I’m nowhere near close enough to conversation to think I can propose solutions yet. But hopefully I can help people see problems, at least.
One last local-first note
I only had a high-level understanding of ATProto went I went to Local First, so I learned a lot while I was there. One thing I was definitely wrong about was how the PDS worked.
I naively assumed it worked a lot like a git repository. The ATProto community regularly says that I own my own data. I tend to assume that means that I have a copy of it, and that when I make changes, I am operating against my copy then distributing it. This is exactly how git works: I clone a repository, make my changes, then push them back up to the server for distribution. I have a hard time imagining “owning” my data without always having a copy of it.
But no, that’s not at all how ATProto works. The PDS is “your” server, but… it’s actually a server. You do not push data up and pull it down; you speak a protocol to it. You only “own” your data because it and the protocols for accessing it are public, and you can change where it is stored.
It does use cryptography-based data integrity guarantees like git does, which is one more reason I assumed I could easily manage the data like git does. But those guarantees are only used on the server, not in the protocols you use to provide new data.
ATProto meets about half of the design principles in the Local First essay linked above. But it clearly misses on the data being at your fingertips or the network being optional, and also misses out on a lot of implied abilities because you’re always talking to a remote server.
If you want to record a review while you’re offline… best practice is to essentially store those reviews in a temporary area, then push them to the server when you’re back online. In other words, you have to build your own custom storage and sync system if you want offline support. Obviously not impossible, but also obviously not local-first.
If you then cross this with the current design for Permissioned Data, I’ve got a bit of a mess:
Custom local storage for offline data
Custom sync system for emptying offline data
Sync system must use different protocols for public and private data
Online app usage must also use separate read and write systems for private and public data, and is likely different from the system used for offline support
As an application developer committed to both local first principles and letting the user choose between public and private, ATProto is working at least as much against me as with me. Am I really better off building on this, versus designing my own system? That question is doubly scary when you recognize that the protocol designer and I are so far apart philosophically.
If I believe public and private data are fundamentally the same, just with different access rights, but the community believes they are and should be different… I am fighting the protocol, storage system, and community every step of the way. I’ve done this before, and it sucks.
Conclusion
I’m still excited about ATProto. And thankfully, the Permissioned Data design is early enough that it can still be improved. And I’m not the only person out there pushing back on the existing design and its goals.
Even if the proposed design goes through, I can build at least somewhat on ATProto, maybe using its identity and lexicon systems.
But I came up in the 90s, when the entire internet was built on standardized protocols that were internet-scale, resilient, maintained by the community and a standards group, and built to empower its users rather than enrich whoever could build the biggest moat. I want that world again.
I think ATProto has the opportunity to be the first new protocol of this type in decades. I hope they go for it, and build something every application developer (but especially me!) wants to build on.
I decided to finally give vibe coding a try. I’ve barely written any code since I hired developers at Puppet in like 2009. And I’ve been a staunch AI/LLM skeptic. But I figured I should at least be an educated skeptic.
After a false start, and a couple of months of periodic usage, I’ve come to some conclusions about it. The first one is the most important:
You should treat AI like an untrustworthy consultant.
Think of this scenario: You need help with your company’s core product. You have to bring in an outside expert, either just as another body, or more likely, because they have knowledge your team doesn’t. What do you do?
Give them commit access and let them work unsupervised? Of course not.
At the least, you have someone sit by their side, checking every line.
More likely, you don’t even let them touch the keyboard. After all, you want more than the help – you want your team trained up so they don’t need that help next time. The only way you’ll get that is if your team does the work, even if someone else is telling them what to do.
That’s how I consulted at Puppet: I show up, I walk you through all the work, and when I leave you have more than a functioning system; you actually know how to use it. Sure, it was faster and easier to do all the work myself. But no one ever learned anything then.
All the coding I’ve done with AI help is in Swift, using SwiftUI, to build iOS apps. I’ve never worked with anything like any of that – I’ve not used any of the specific tech (other than an iPhone as a user). I’ve never used a UI framework. I’ve never worked in statically typed languages. And I’ve barely ever worked in compiled languages. So, it seemed like a solid use case for getting some fast help.
My first try used Cursor, and let it edit everything.
After a few iterations, I had a bare-bones application. But… I felt like I was pushing around a bag full of bolts. There was definitely stuff in there. But I didn’t even know how to think about the changes I needed, because I didn’t understand enough.
So on the second iteration, I decided I would do all the typing: The AI does not get to touch the keyboard. When I started it was all gibberish, because I didn’t understand anything. But after only a session or two, I have a pretty good sense of how both the language and framework work. That’s about when I realized the second big thing:
AIs are crappy architects.
It kept giving me stupid advice. For instance, every time it encountered an error, it would just catch it and print some logs. Uhhh… that’s bad. It would encounter a small problem, and design a big stupid solution instead of doing a small rearchitecture. Because it can’t think, it couldn’t realize when it hit a design wall that needed rethinking.
After a while, I concluded that it wasn’t very good at the back end code – I have a lot of experience with modeling and data flow, and I kept finding dumb things it did. But I never found those dumb things in the area I have no experience: the UI.
But… then I thought for a bit. And I realized, duh, that’s probably just because I’m not good enough yet to recognize the dumb stuff it’s doing.
Coincidentally, I am now hitting a repetitive wall with Swift’s type checking. I keep having to break a view into smaller and smaller files so that it can compile fast enough. Turns out that’s the AI’s only trick for fixing this problem. But a small amount of research shows there are other options. In particular, I can instrument the compile and see what’s actually taking all the time, and focus on just rewriting that code to be more compiler-friendly. This is the kind of stuff an experienced programmer does without thinking, but a crappy consultant whose entire experience is based on trawling Stack Overflow probably never figures it out.
I did find one area where LLMs absolutely excel, and I’d never want to be without them:
AIs can find your syntax error 100x faster than you can.
They’ve been a useful tool in multiple areas, to my surprise. But this is the one space where they’ve been an honestly huge help: I know I’ve made a mistake somewhere and I just can’t track it down. I can spend ten minutes staring at my files and pulling my hair out, or get an answer back in thirty seconds.
There are whole categories of coding problems that look like this, and LLMs are damn good at nearly all of them. Where did I fail to log correctly? Where am I not handling an error appropriately? If I am updating this method name, which files do I have to change?
I’ve had about five to ten sessions of using Claude – just on the command line, no fancy tools, and no editing allowed. I have about enough experience with Swift and SwiftUI that the terms of the relationship have changed. I feel more like the senior engineer, and it is the junior developer I have working on a short term contract. I can pass it the stupid grunt work (rename this method through the whole system, fill out this boilerplate for a new view, figure out how this new library works).
But I absolutely can’t trust it to make any big decisions. And I have to check all of its work. (Even better, it won’t be offended when I do.)
After a few more sessions, I’ll probably start letting it edit files directly. But only for that kind of large scale, small change work. Once I build the error management framework, it can probably push it through the system (especially since I’ve sprinkled my code with comments when the error management was missing). But I’ll still walk through all the changes to ensure it actually makes sense.
There is a new movement around tools for managing your calendar. My favorite is Reclaim, but there are many others. They provide help running meetings, rearranging them, and avoiding them.
It’s great that these tools exist. The calendar is the least improved area in the average office worker’s life in the last few decades. My particular bugaboo is that calendar apps don’t know that you exist as a physical person, so they are perfectly willing to let you schedule two in-person events five minutes and 3000 miles apart. Any other kind of application would see that as a catastrophically brain-dead bug, but somehow the tools we use to arrange our lives don’t.
But… Something always struck me as off about these new tools. I didn’t want to use any of them. I’m a tool junkie, so this is pretty weird. Even Reclaim took me a while to understand and fit into my life. It was obvious these tools weren’t for me, but why not? Who were they for?
They’re for front-line workers: Developers, accountants, SREs. I used to be one of those. I’ve certainly been yelled at enough by them for putting meetings on their calendars.
But I’m not one today. I haven’t been in at least a decade.
My employees at Puppet used to say they hated meetings (I’m sure they still do, they just don’t work for me any more). I would tell them: Replace “meeting” with “collaborating with my team-mates” and say that again, eh?
So yeah, I have a different perspective on meetings.
Not that I think they’re all awesome. But for me — and most other leaders and managers — meetings are how we do our job. The life of a manager is built around communication. Much of it can be unscheduled, and ideally asynchronous. But a lot of it needs to be direct, synchronous, interactive.
That interactive time is much less efficient than, say, email, which means managers have to schedule their time carefully to ensure they get everything done. And of course, employees hate it when a manager shows up at their desk unannounced and asks for time. They want that meeting scheduled, too.
So a manager’s day is built around meetings, and there is a new crop of tools to help with them. What’s not to love?
Well. The tools are built by and for people who hate meetings, and often who aren’t very good at them. Instead, I want tools for people whose job is built around meetings, and who know they must be excellent at them.
Managers do need help. Not nearly enough of them are actually good at the mechanical parts of their jobs, including managing meetings. But these tools are mostly about avoiding or constraining them. They’re for the people asked to join, not for the ones calling them or running them.
I hope these tools do well. I want there to be a mature market of great tools in this space.
But even more so, I hope to see a parallel mature market for tools to help make better meetings. The average employee suffers from all the meetings they have. If managers were better, there would be fewer meetings, and the ones remaining would be better.
Seeking a round of funding is about the most miserable thing I’ve ever done. Truly. Fundraising was less pleasant and more demeaning than anything else I did at Puppet. But Clickety’s final (abandoned) round was uncomfortable in a new way.
Two different investors asked me the same question:
Why are you fundraising if you hate investors?
The question caught me flat-footed. Mostly because it’s such a stupid one.
I don’t love working with real estate agents. I feel like I’m being scammed. Even if I like my own agent, I usually don’t like the other one. I’m uncomfortable the whole time.
But in the US, it’s way harder to buy or sell a house if you don’t use an agent. And even if I went without, the other side of the party probably would hire one. So, I use a real estate agent. And I work with the agent on the other side at the same time. You want the house, you use the system.
And when I buy that house? I ask my banker for a loan. It’s not because I love bankers. It’s because I need help buying the house, and he’s in the business of helping people buy houses. Seems pretty straightforward. It has nothing to do with whether I like bankers, banks, or the mortgage financing system.
The legal system is similar. I actually do like a lot of lawyers. But… god, not all. And the way lawyers often work is stupid. I don’t actually think lawyers designed modern legal documents as a form of job security, but it sure looks like it sometimes.
But when I need to work with complex contracts, I hire a lawyer. It doesn’t matter whether I like lawyers or the US contract system; I have a job that demands legal help, so I go get it.
There’s a huge difference between all of them and venture capitalists, though: Bankers, real estate agents, and lawyers don’t demand that I act like I like and respect their industry. But VCs don’t just want me to start a great company. They want me to like and respect them for trying to make money off the work of me and my team.
Why was I fundraising from VCs?
To paraphrase Willie Sutton (maybe?), because they’re the ones with the money. If I want funding for my company, I need venture capitalists. What does it matter how I feel about the venture industry?
If you’re an entrepreneur today, there is no other source of capital. You can either bootstrap, or raise money from VCs. There are a few firms experimenting at the edges, like Calm, but they have a minuscule amount of money compared to the venture capital industry.
Yes, I could bootstrap. I’ve done it before. But it took four and a half years. I’m not as patient today as I was when I was 29. I also thought it made sense to start this company as a CEO and product manager first, rather than as a programmer. (In retrospect that was a mistake.) That made it impossible to bootstrap. I needed a team.
This question is just offensive, though. Its implication is “you should not raise money from investors unless you are willing to show respect and appreciation for the money they give you”.
Why? The world famously hates bankers and lawyers, yet continues to work with them. Why does this field get to demand our respect, when others don’t? Finance, especially, is just here for the money, and everyone – them included! – knows it. We just have to convince them we’ll help.
VCs are gatekeepers
Investors display their power by demanding your respect. They don’t invest in people who don’t show fealty to their image of themselves.
It’s how banking used to work: Some people got money, and some people didn’t. Fundamentals had nothing to do with it. You had to be in the right network, have the right skin color, the right class. Eventually bankers realized they made less money when they only loaned it to their friends. (And the US government forced them to back off their discrimination a bit.)
Most investors today will tell you to just “play the game”. This is what they mean: Participate in our discriminatory process, and show us proper respect. This is why you usually need a warm introduction to even be allowed to pitch them.
But I raised money within it, many times, because that’s where the money is.
Hate the Game, not the Player
No, I don’t hate investors.
But I do hate the world of venture capital. It is fundamentally flawed. It incentivizes behavior I can’t stand, and quashes behavior I find respectable and moral.
For what it’s worth, I also hate the larger finance industry. It’s not like venture is some rare target for my ire. There’s a reason I’ve never considered working in finance. (Well. There are several.)
Venture is an amazing engine for creation and invention. But it mostly invents stuff I wish didn’t exist. And it does not seem to be able to solve the problems that matter most to me or the larger world.
People appear to hear my dislike for their industry and think I hate them, personally. I can’t do much about that. I respect and like some investors. I dislike some others. But I generally have no particular feelings about a given individual.
That being said…
I don’t tend to respect investors.
Being a venture capitalist doesn’t automatically disqualify you from garnering respect. But it also does not automatically deserve it.
In the 1980s, finance was at its peak. People made ungodly amounts of money ruining the lives of thousands and thousands of people. And they were held up as heroes of business. We’ve largely learned that stripping financial assets is maybe not something we should be proud of. These people still get rich, but we have learned not to lionize them.
Is the modern venture investor as heartless and shameless as a PE investor from 40 years ago? Generally, no. (Although there are definitely exceptions.) But like those 80s wolves of Wall Street, VCs have found a money-making edge, and they’re ruthlessly exploiting it.
I’m just not that impressed.
I can see why someone would read that disregard and disrespect as hate. Especially given the power dynamic: I’m asking them for money, yet I’m not showing “proper respect”.
My banker didn’t demand I “play the game” when I applied for a mortgage. He just needed evidence that I could afford the house I was buying, and that it was worth what I was paying.
Being autistic means I’ll never be able to “play the game”. It’s literally constructed so only the in-crowd can join. I can mask for a while. But it takes hundreds of meetings to raise a round. Most people in the meetings look the same, dress the same, went to the same schools, and ask the same questions, yet think they’re special geniuses. And most of them give the same answer (“no”). It becomes hard to hold a facade.
It’s not a choice, or a lack of skill. It’s a hardwired neurological limitation. You might as well ask me to be taller, or have a lower voice.
For better or worse, I’m not sure it matters now. My personal limitations are likely to prevent me from trying to raise money again. But I hit those walls in large part because of how harrowing fundraising is.
Will I do it again?
My experience at Clickety tells me I’m unlikely to run another venture backed startup.
It looks like I’m already a bit of a pariah, which might explain part of why it was so hard to raise. (Not that I don’t deserve some of that reputation.) It’s not about to become easier for me. The older I get, the less I can handle gatekeepers. And I was already crap at tolerating them when I was younger.
My health — both physical and mental — would need to significantly improve. Running a company is stressful enough. Raising money was too much.
I won’t rule it out. I know my future is going to look different from my past. I have a lot of healing to do.
But I still believe in the power of software to make people’s lives better. And venture capital is a fantastic source of acceleration. I hope to continue to work with founders, and intrinsically that means working with investors, too, sometimes.
I also love solving problems. I hope to help others do it. But I won’t rule out trying to solve some problems on my own.
And maybe one of those solutions will be so good they can’t ignore me.
Most industries are dominated by monopolies. How we enforce antitrust law explains far more than you might think.Photo courtesy of BP Miller.
My first monopoly was AT&T.
I lived on a commune until I was eight. We didn’t have toilets, but we did have phones. We didn’t own them. It was a commune, after all. But they were in our house and we got to use them.
When we reentered “normal” civilization, we still didn’t own our phones. AT&T did. This was 1984, the same year Congress broke them up. I was more confused than injured by their power. Capitalism was new to me. Every single thing in our house was ours, for the first time, except that one. We had to lease it from Ma Bell. Even weirder, the lines in our house were apparently not ours. (I mean. We were renters. But you get the idea.) We had to pay to attach other objects to ports in our own house.
This confounded me. “Some… outside company I’ve never heard of makes rules about what we have in our house?” Yes indeed.
Thankfully, it didn’t last. With five siblings, we needed but could not have paid for those extra phones.
My second monopoly was Microsoft.
They had complete dominance of desktop operating systems and software (the Office suite, plus Outlook/Exchange for email). I went to Reed College, so I exited school as a Mac user, in the middle of their dark days. In hopes of avoiding Windows I tried everything else: BeOS, Linux, Solaris, you name it. No matter how fast I ran, I was often stuck on Windows at work because, well, everyone was.
Microsoft abused its monopoly heavily and freely until being taken to court. Microsoft’s abusive behavior is usually discussed in terms of its effect on the web. But I’ll never forgive them for Outlook. It taught multiple generations of people to do email incorrectly. To this day, the average business user is incapable of having sophisticated discussions over email because Outlook trained them not to.
Ironically, Microsoft itself likely only exists because of Congressional antitrust action against IBM. The government eventually withdrew its case against Big Blue, but not before convincing it of the importance of leaving room for others.
The Paradox of Antitrust Choice
Kids coming up today are lucky. They have so many monopolies to choose from.
Of course, I don’t actually mean “choose”. You pretty much have to use all of them. Google for search, Facebook for social, Amazon for e-commerce and cloud infrastructure, and Apple for hardware and apps worth paying for.
Tech is absolutely rife with monopolies. (And monopolists.) But the industry itself is largely in denial about that. “We’re different!”
The last month has highlighted this. Congress has dragged the richest, most powerful tech founders and CEOs in to testify. More importantly, a Judiciary subcommittee has produced a huge report on concentration in the tech industry.
I’m going to focus on that last link, from Ben Thompson. He makes a throwaway comment:
consumer harm, which is the de facto standard for antitrust in the United States
The article itself is interesting and informative, as most of Ben’s writing is. But this small line shows that Ben is in a box that limits how he thinks about antitrust. And if he can’t see out, few others are likely to.
I think he should. I think you should. I think everyone should.
Abuse of monopolies affects all of us. It’s not just about tech. We’ve allowed most of our industries to become highly concentrated: Agriculture , pharma, internet access, and many more. Heck, even eyeglasses.
America doesn’t have a tech monopoly problem. We have a plain old monopoly problem.
Ben works hard to explain that the tech monopolies are natural because of what he calls Aggregation Theory. He implies this makes their monopolies more acceptable, even inevitable. He accepts there is abuse, but a very narrow definition of it. Even if his theory is sound (which I am not convinced of), it doesn’t explain the rest of the monopolies that plague us.
Something else does.
The “consumer welfare” standard is not the law
Ben is right that US antitrust law focuses on consumer welfare. That’s pretty much the work of one person: Robert Bork. His book, The Antitrust Paradox, successfully rewrote the history of American antitrust enforcement. Gone were concerns about competitive markets, or any discussions of the downsides of market power. Nope. If prices are low, it’s good. That’s it.
He didn’t get any new laws passed. He just convinced our country to enforce them differently.
Yes, consumer welfare is an important input in the laws themselves. But there’s far more to it, including a healthy focus on market power. Yet Bork managed to gut everything else with one book. (To be fair, there were a lot of rich and powerful people set who became even more so once he won.)
To be clear: The laws themselves have not changed. Only how we enforce them, within the government and the courts.
It is impossible to understand antitrust enforcement in our country without accepting this fact: We have strong antitrust laws and are choosing not to enforce them. They have been gutted by an extreme interpretation, and fifty years later, nearly every industry demonstrates the ruinous consequences.
Revisiting Consumer Welfare
Bork successfully reframed the downsides of market power, with a lot of help from the Chicago School of Law. But there have always been people fighting back.
Lena Khan produced the seminal work in this category, Amazon’s Antitrust Paradox. She lays bare how powerful Amazon is, and how useless consumer welfare is as a means of assessing monopoly abuse. Its impact has allowed her to carry the flag even further.
In particular, she was part of the team that ran that Judiciary subcommittee hearing, and produced the related report.
Yes, her argument - and thus at least partly, the argument made by Congress - is that Amazon and its peers have too much power, and they are abusing it to gain even more.
But more importantly, she’s arguing that you cannot have a conversation about market power without also talking about standards other than consumer welfare.
That’s what Ben Thompson (and Ben Evans) and all the other tech commentators need to understand.
The argument is not really whether one of these companies is a monopoly. It’s what standard we should use to assess their behavior.
Do we let Bork decide, and use a light hand and generally tolerate heavy concentration of power?
Or should we follow the original intent of the laws, focusing more on encouraging a competitive landscape and a market free from companies that are too big and too powerful?
The Tech Monopoly Minefield
Every tech founder I know builds their business around the reality of these monopolies. If you’re in e-commerce, your business is defined by the space Amazon leaves you. You don’t necessarily have to be on Amazon, but prepare to be attacked if you’re not. If you’re in social, you have to ensure Facebook doesn’t want your business. If you make apps, you can only make or sell them the way Apple lets you.
I expect most founders and investors don’t even realize how much we’ve given up on doing because of these monopolies (and all the smaller industry heavyweights, like Salesforce). We talk big about agile startups outwitting the big players, but… that only works if they can’t choke off your suppliers, outbid you for engineers, or take hundreds of millions in losses to destroy your company.
What could we build if we didn’t have to fear so many big players?
Conclusion
I’m still haunted by that AT&T phone we didn’t own.
I could not be happier that the government is finally revisiting our antitrust standards. And honestly, I’d rather they make mistakes in regulating the huge players than not regulate them all. We’ve seen what five decades of almost no action results in.
Like everyone, I love fast cheap shipping. But it’s not worth destroying independent retailers over. Honestly, I can’t stand using any of Facebook’s products, but maybe I could if they were stand-alone instead of part of a soulless corporation bent on domination.
I believe in the free market. But none of the markets I’m interested in are. They’re all dominated by players so large, so powerful, that our only choice is to work with or around them.
It’s long past time to get rid of the consumer welfare standard, and bring back to true antitrust enforcement.
I’m a tech founder and recovering SysAdmin. I helped found DevOps and grew up in open source. These days I am convalescing from a decade of physical and mental neglect while running Puppet.
Read more