Open Forks of Boring Apps With Authority

If Bluesky, ATProto, and the broader Atmosphere want adoption outside of microblogging, the best path is not only to build better social apps. It’s to identify proven software categories where one authority figure can bring a whole user base with them.

A barbershop chooses a booking app, and all of its clients use that booking app. A festival chooses an event app, and thousands of attendees use that event app. The user does not create an account because they care about decentralized identity. They do it because they want a haircut, a schedule, a ticket, a map, a lineup, or whatever practical thing they were already trying to do.

That’s the idea.

I think the Atmosphere would gain a lot by getting much more precise about the kinds of applications it wants to prove out next. Not abstractly. Not “what are all the apps someone could build on ATProto?” More like: what are the software categories that already have proven utility, already have a buyer or authority figure, and already have a natural path where that authority tells other people to use the product?

Schedulicity is the example I know personally. It was a booking app for appointments that has since been bought by Mindbody, which is the bigger company in that space now. But the shape is the important part. A barbershop or provider chooses Schedulicity, and then their clients use Schedulicity because that is how they book the appointment.

In Bozeman, there’s one main barbershop that probably serves a quarter of the male population every month. Those people just want a haircut with the person they know. They do not care what the booking surface is. The barbershop gets to evaluate the software and then dictate it to their community.

My application, Open Music Event, is another version of this. Wicked Woods can tell 5,000 people to download an app because Wicked Woods owns the event. It’s their public surface. Attendees are not downloading it because of social identity. They are downloading it because they need the schedule, the map, the lineup, and the event context.

And then we can add identity and social features on top of that.

This is the type of adoption surface I think the Atmosphere should be looking for.

The important shape is:

There’s also a permissioned data piece here that deserves its own section. A lot of these applications need private or semi-private data because that is just how the business function works. Booking, membership, event access, staff tools, organizer controls, attendee state, appointment history, all of that. And we are starting to prove out the tools that make permissioned data possible in the Atmosphere.

That matters because these are not all microblogging-shaped problems. Some of the most useful software in the world is boring business software with authority and permission boundaries.

Users do not need to understand that they are joining the Atmosphere on day one. We still benefit even if they do not share an account at first, and they still benefit if the software is good. It should be easy to sign in with an account they already have, but if they accidentally create another one, that is not the end of the world. They are still using Atmosphere-backed software. They can discover the relationship later. We can build account merge and identity reconciliation tools around that.

These should become open forks or reference applications.

A company like Bluesky, or anyone with enough resources to prove this out, could build an open booking-shaped app that provides a reasonable minimal product experience for booking appointments on the Atmosphere. It does not need to win the entire market. The reference app does not have to become the final product.

It gives developers a serious foundation to fork from.

Someone with a weird idea about the next booking app should not have to start with OAuth, AppViews, records, permission models, identity, SDK design, and all of the product architecture at once. They should be able to fork a real, high-quality, Atmosphere-native application and start from a proven foundation.

And maybe we just win with the reference app. That’s fine too.

But either way, it does two useful things.

First, it creates real products that can get real adoption through existing authority relationships.

Second, it creates learning surfaces for developers. The best way to teach people how to build in the Atmosphere is not only documentation and toy examples. It is real applications, built at a high standard of quality, where we can show exactly how the product works and exactly how the tools underneath it work.

That is also how the SDKs get better. Not by designing them in the abstract, but by building well-understood applications like booking, events, membership, and local services, and forcing the SDKs to survive contact with real product surfaces.

So the strategy is pretty straightforward:

Find application categories where authority-driven adoption is already proven.

Build open, Atmosphere-native reference applications in those categories.

Use those applications to prove out the SDKs, permission models, AppViews, identity flows, and educational material.

The Atmosphere does not need to win only by convincing people to post somewhere new. It can win by becoming the foundation for software people already need to use because of real-world relationships.