The Default Always Wins

I got into a debate at work recently instigated by a meeting one of my colleagues wanted to take with a drone startup. I have no idea if they ever actually took the meeting—we're in growth mode so time is at a premium—but we weren't arguing over the merits of spending 30 minutes on the phone with someone. Rather, it was a totally tangential discussion over the speculative business model of the company in question. Probably not a good use of our time, but sometimes it's fun and healthy to sit back and have non-work conversations with work colleagues.

The technology, apparently a drone-in-a-box concept, is not particularly novel and was still a solid pipe dream when I was in the drone space 6 years ago. It's true computer vision technology and maturing data processors have pushed the space a long way since I left it; for all I know people may very well be using boxed drones for legitimate operations these days. Wind turbine, transmission line, and solar farm inspections were a big prize for the tech—the flight plans are (relatively) standard, they're often annoying to get to and you have to do them frequently. The drone-in-a-box saves you having to ship guys out there to do dull, dirty, and occasionally dangerous inspections unless something is actually wrong.

The use case the startup had mentioned involved using drones to augment construction security. Not a particularly novel idea; we speculated it was going to involve having a drone fly around the perimeter at regular intervals to supplement a guard or cameras. Perhaps it would be smart enough to respond to suspicious events or have some sort of mechanism to allow a monitor to take over to get a closer look. At night you could equip it with an IR camera and save having a guard at all; run a monitoring algorithm on it and you could have it call the cops for you if it saw someone breaking in.

Assume the technology worked flawlessly. Would you have taken the meeting?

Problems often don't need solving

There are two pieces of common business "wisdom" out there everyone repeats but in my experience fall apart under the slightest bit of scrutiny:

People will welcome new ways to solve their problems.

Companies must be efficient; inefficient ones get beat.

The second point is particularly common in the cringe-worthy "government must be run like a business" talking point, as though corporations are paragons of efficiency. Whenever I see that one I want to grab and shake the person who said it. Have you ever worked at a company of any size, let alone one with tens of thousands of employees? Efficient, they are not.

The first point is perhaps slightly less common in the general sphere, but is tantamount to gospel in tech and startup culture. Most of it comes from a place of good faith; even today with things going gaga for AI and grifts becoming more common the vast majority of people in the space enjoy coming up with clever solutions for real problems and inefficiencies they see in the world. People have problems, technologists have a dizzying array of hammers. Seems like a match made in heaven.

Thing is, a solution receiving widespread or even niche adoption is a rare event. For every library, app, platform, or product that gets picked up and used consistently there are dozens if not hundreds gathering dust on someone's hard drive. And that's not including the zillions of toy projects or one-off hacks put together by someone looking to fix something for themselves.

Some of them die from competition. Others die because their authors get bored, or don't want to devote the time and energy necessary to build out the infrastructure (be it technical, social, or financial) to support it. In those cases, the platonic ideal of the solution is viable, even if that particular implementation crumbles. Cars replaced horses. Facebook replaced MySpace. Google replaced AltaVista.

Most of these, however, die because they never find the people who need those problems solved. Not because they never find people who have those problems (though that happens too), but because they cannot convince those people to use their solution and solve their problem. The juice is not worth the squeeze.

Solving a problem is necessary for a new solution; it is not sufficient enough reason for people to adopt it.

It's a strange axiom, almost counterintuitive (especially for those of use who solve problems for a living). After all, if you can get rid of one of your headaches, why wouldn't you? You'd be silly not to.

Yet, time and time again, companies fail to turn products into sustainable solutions, even in situations where people are literally throwing money at their idea. Consider Damballa:

Howard and his fraud team...said, “If you can stop this kind of trust fraud, it can save eBay $40 million per year. How much will you sell it for?"

Merrick, who didn’t have an actual product yet, let alone a pricing plan, did what experienced entrepreneurs do—he made up a plausible number and said, “$150,000 per year or so, to start.” Howard jumped on it. His next question was

“How soon can you deliver?

eBay had a problem. Damballa had a way to solve it. The savings promised to be several orders of magnitude more than the cost of adoption. Yet eBay balked, and so did the rest of their market. Ten years and millions of investment dollars later, the company was parted out for $9 million. Everyone lost money.

Necessary but not sufficient.

Situational defaults > resolving pain points

We humans are very good at solving problems, but we're even better at cooking them up in the first place. Yet we still cling on to the fantasy that there will come a time when all our cares and worries are gone, that we will be blissfuly problem-free until the end of our days. It's a silly conceit. We all know it. And we keep on believing that if we can just solve this problem we're be happy forever.

Just one more turn...

There's plenty of research into why the "hedonic treadmill" is such a core part of our wiring; it's a fascinating topic in its own right. Suffice to say, short of reaching nirvana any human will have problems causing them some degree of pain. The fact that those same humans get on with their day regardless of their problems is an obvious but overlooked corollary. More importantly, we constantly ignore or suffer our issues even when we have the capability to solve them. Avoiding going for a run even when feeling stir-crazy; skipping lunch even though you're hungry to finish a project; not going out the night before a presentation because you don't want to miss your friends. All are relatable experiences where the power of the situation won out over solving the biggest issues the person was facing. Humans are spectacularly bad at acting like the utilitarian robots economic and logical models would have us believe, yet time and time again builders and founders are shocked when their elegant solutions to real problems are met with a resounding shrug.

A much better framework is a one based on situational defaults. It is the idea that, more often than not, people do what they feel the moment requires of them—even if it causes them pain. I first came across this idea in an excellent CommonCog article about product-market fit , which I strongly recommend. It's part of a series of essays about The Heart of Innovation (written by the former founders of Damballa), which has a pithy razor the authors sum up as "not nots:"

Authentic demand exists for a solution when someone is put in a situation and they cannot not buy (or use) the solution.

In other words, most decisions are made not because someone is actively seeking to do XYZ thing. Most decisions are made because the person making it cannot not make that decision. It is the default choice in the moment.

I get a bonus at work. I invest it in index funds over gambling on individual stocks.

We are going to a show downtown. We take the train so we don't have to pay for parking.

My neighbor gets stuck in transit and asks me to bring in her mail. I do so and give it to her when she returns.

These situations aren't determinative of individual behavior. You aren't (usually) forced to mindlessly act in a default manner—maybe you really want to drive your new car or you hate your neighbor. It's in the aggregate where the framework shines through: most people will do the same thing in the same situation becaues doing otherwise requires them to go against the grain, sometimes in unconscious ways.

The framework has additional predictive power for cases where doing something is of neutral benefit, or someone opts to do something for pleasure (as opposed to eliminating pain). Think of the government bureau forcing you to fax documents for a permit because they haven't upgraded their systems yet. In doing so they create demand for online PDF-to-fax converters because they create a situation that requires them to exist. More pleasurable pursuits follow the same path. I want an Aston Martin DB9, but even if I could scrape the cash together there are plenty of other desires to fulfill before I get a fancy car.

Similarly, I argued against taking the drone meeting at the top of the article because I couldn't see a compelling reason people would adopt it. A secure site might want the drone; they might think it's neat and could solve a problem they have in particular situations. But most site managers are perfectly happy with some cameras and a security company. Break-ins and losses aren't desirable; the spectre of theft and arson causes headaches. But they are not such a problem, and the benefits are not so massive that a site manager can't not have a drone.

Which raises an interesting point: you can change the situation to create a demand for the solution. From CommonCog:

...if you make statistical software, and you get the US Food and Drug Administration (FDA) to mandate that all new drug applications must be submitted in a proprietary file format produced by your statistical software, then guess what: you may not have solved a pain or satisfied a desire...but you have created everlasting demand.

If construction insurers started mandating drone-in-a-box solutions or had some sort of "continuous, responsive coverage" clause in their policy contracts, the math would change rapidly. You'd be foolish NOT to take a meeting with a firm in the space. But as the situation stands in the industry today, I voted to take a pass.

ATProto is not the default...

Technological change drives social change, but to do so it has to thrive in the marketplace. For consumer software, the way to do that is as a startup. Further, great products drive protocol usage. – Tessa Brown

I like the AT Protocol . I think it has found an ideal compromise between hyper-federalized systems like ActivityPub vs the walled gardens run by today's tech giants. Data ownership by the user over the service is core to the design philosophy and something we desperately need if we are to keep the web from descending into utter enshittification.

What I am not convinced of is whether or not the advocates of decentralized protocols fully understand the demands of the situation. All of the fediverse markets their protocol as a benefit to the users of apps that run it. "You own your data. You can leave if the company becomes the enemy." It's a compelling case! I don't mean to downplay it. On the AT Protocol, the very existence and success of Blacksky and Northsky as alternatives to Bluesky prove the user argument has the juice.

But a protocol is fundamentally a technical solution and needs to meet the needs of the builders and entrepreneurs. Most users don't really care about the advantages the model provides. People are generally uncomfortable about how their data is used and managed today, but for most it's just a sense of unease to be lived with, not a problem demanding a solution. You are not going to win over users based on the fact they own their data if they can't do anything useful with it in the first place.

The end result is that apps running on the Fediverse are built solely by the early adopters, the people interested in and excited about the situation. Most of the users don't care about the underlying technology, nor do they care enough about data portability right now to choose a protocol app over something else. Most Bluesky users joined the site to flee Twitter and with Musk's changes to the API most of that data has remained there. It is the closest thing to a "killer app" the protocol has. But adoption of Bluesky as a Twitter alternative should not be confused with a user endorsement of the AT Protocol. To most people, it is an interesting quirk bundled up with joining "liberal Twitter”; it changes nothing about how they interact with the internet.

AT Protocol cannot win until the wider tech community feels it can't not implement it in their products—as a first-class alternative if not the core identity system outright. It needs to be the first choice not just of the builders excited about it, but the developers and entrepreneurs who don't care one way or another.

The user experience is important. Even if a user can't tell you the first thing about the protocol, they will notice when they can see their friend's posts in their stream.place chat. They will notice when their photos are available to share through Germ DM even though their laptop fell in the lake. They will absolutely notice when making a connection just requires swapping handles, not today's awkward social media handshake: "Are you on LinkedIn/Discord/Facebook...?" As ubiquity grows, so does demand. Such is the power of network effects.

But to achieve ubiquity you need the ecosystem. To establish the ecosystem, you need good, solid apps that stand on their own merits. You don't need the next Facebook or Tiktok; when the goal is not to pull everyone into a different garden but to disseminate a standard, a big killer app is actually detrimental to the cause. Bluesky is the current hegemon on the protocol, which means everything that touches AT Protocol gets tainted (rightly or wrongly) by the butterfly brand. You want to build an app on the protocol, you'd better be okay with telling users to create a Bluesky account (even if that's not what's happening); people who don't know or don't care about the protocol will know about Bluesky.

What you need are as many developers as possible building useful things on the protocol. Which means a) you need it to be as easy as possible to get started and scale up, and b) developers need a reason to do it—or at least need for it to be no more painful than the alternatives. If someone tells you about their cool new startup and you say "hey you should build it on the AT Proto," telling them they'll be able to give users ownership over their data is not going to be enough. For large chunks of the tech sector, that argument could actually be a reason not to do it. Telling a budding entrepreneur the developer experience is just as good as Next.js, that it'll save them the headache of worrying about identity management and put the cost of blob storage on the user, that integrating with Graze or Leaflet comes out of the box—these are reasons to integrate with the protocol or even build something protocol-first.

The big, hairy, audacious goal is to make it inconceivable that you would do anything other than build a protocol-first application. In that world, managing user data is as strange an idea as riding a horse from Chicago to St. Louis: you can do it, but it's definitely not the default option. The AT Protocol wins when developers think rolling your own auth or supporting centralized SSO providers is the weird choice—why do all that when you can make it a PDS provider's problem? And why take the business risk of pissing off the people who don't want to make yet another account?

...but it could be

Things aren't there yet of course. There are several core features for the protocol still to be built (private data leaps to mind) and developers are only just starting to explore the theoretical benefits of the PDS data model. No one is starting a project and saying "I'd better implement AT Protocol;" projects are getting going because someone says " wow this is cool, I wonder what I can build ."

The reality is that most of these protocol-first projects will die, or exist as curiousities without much traction. Others will gain success in niche communities, creating digital islands for underwater basket weaving or play-by-post RPGs. They may even dominate those spaces, but a few hundred or thousand people with the same hobby do not define a global ecosystem. But those projects are on the AT Protocol, which means the users are now on the protocol.

It's a virtuous cycle. A few people make apps on the protocol. More users experience its benefits. Other developers notice users like it and so start to implement it. Users start to feel friction using apps that don't implement it. Legacy players start to notice their customers leaving and feel forced to retrofit things to the protocol, bringing more users onto the protocol.

This is the AT Protocol's biggest advantage. You do not have to sell users on the benefits of the protocol to get their buy-in. They don't have to know a single thing about the fediverse, or give a moment's thought to the concept of data ownership. All they have to do is sign up for your hiking buddies app, and then realize that in doing so they are able to use that data in my diet app by clicking exactly one button.

"Log in with Google" is showing your passport to check in at the front desk of a hotel; "Log in with ATProto" is an RV with all your stuff in it that fits in your pocket. – Eli Mallon

Most fediverse debates seem to miss this point. The arguments are all about the advantages of your preferred protocol in doing all the good things that decentralization promise. None of them talk about the path to get there. Even the AT Protocol fanatics tend to gloss over the protocol's growth potential when hyping it up. Conversations are more about app interoperability, the ability to leave hostile service providers when they turn on you, and the starry-eyed ideals of digital self-determination.

The implicit assumption is that everyone will eventually adopt their favorite federation scheme. How could they not?

Proponents forget that most people don't know or don't care. Right now, the AT Protocol is the size it is because of Bluesky's success, not because of any particular benefits being protocol-first. It is not a given people will leave their walled gardens, even if it's "better" for them.

But people do care that they aren't losing their photos because MetaFlickr suddenly declared bankruptcy. They do care that their fitness apps sync together and they can track their health. They care that they can show their friends in FortBattleNight the sweet sword they earned in EldenCraft. Never mind that Epic owns the former and the latter was made by three sisters working out of their brother's garage.

The fediverse fights among itself, forgetting that these are the users you actually have to win over. You don't need to win over the GNU zealot running FreeBSD out of his spare bedroom. You need to win over your friend's mom who can't figure out why she can't open the doc link you sent her. The AT Protocol is not competing with Nostr or ActivityPub. It's competing with AppleID and Google Accounts.

Getting there is a long road to walk. There are plenty of pitfalls and ways things can go wrong. But a world where AT Protocol (or a spiritual successor) is the standard for our digital lives is a viable one, perhaps even a plausible one.

That's an exciting place to be.