Software Should Be Allowed to Be Weird

A fairly large amount of the software I write would probably die in a corporate planning meeting.

There would be questions about the target audience, the business case, the monetisation strategy, the expected return, the number of potential users and whether there is already another product doing roughly the same thing. Quite a few of my projects would get as far as the sentence describing what they are before somebody reasonably asked why anyone should spend time on them.

That is probably why I like making them.

A deliberately strange programming language. An importer which takes years of listening history and turns it into AT Protocol records. Alternative clients for services which already have functioning official clients. An AT Protocol SDK written in C23 and C++23. A Personal Data Server written in C. Games built around mechanics which sound mildly deranged when explained out loud.

None of those started because I had found an exciting new market opportunity. Most of them started because I had an idea, thought it would be interesting to see if it worked, and then opened an editor.

I think software should be allowed to exist for that reason.

Not everything needs to become a product

There is a tendency, particularly around software, to treat anything somebody makes as though it is an early-stage company waiting to happen.

If a project gets users, people ask how it will be monetised. If it becomes popular, people ask how it will scale. If it is open source, people ask what the business model is. If it solves a particularly niche problem, people ask whether that problem is large enough to justify solving.

Sometimes the answer is that I wanted the thing to exist.

That really can be the whole justification.

Numlang is a programming language built around numbers. It is not going to replace C, Python or Rust. I am not expecting people to migrate their production infrastructure to it. I made it because the idea amused me and because building a compiler is an interesting way to learn how programming languages actually work.

Malachite came from a different kind of curiosity. I had years of listening history spread across services such as Last.fm and Spotify, and I wanted that history represented as AT Protocol records which I could actually control. The result is now tens of thousands of records on my own repository describing something as mundane as the music I happened to listen to on a particular day.

That is not going to change the world. It is still useful to me, and building it taught me a lot about ATProto in the process.

A lot of my projects work like this. Inkwell exists because I wanted a native client for long-form content on the ATmosphere. Wolfram exists partly because I wanted a lower-level AT Protocol SDK in C and C++. MetalBear pushes that further into the slightly ridiculous territory of implementing a PDS in C.

Some of these projects become genuinely useful. Some stay as experiments. Some will probably sit in my GitHub account indefinitely after I lose interest in them. That is fine. A repository does not need to justify its existence by becoming a product.

Weird software is useful precisely because it goes off the path

There is also a practical reason I keep ending up with these projects.

Normal software tends to exercise normal parts of a system. Strange software has a habit of finding the corners.

If you build another conventional client, you mostly follow the paths that other people have already followed. If you try to use a protocol for something it was not obviously designed around, you start finding assumptions. Libraries reveal where they are overly coupled to one particular application. Documentation reveals where it is describing the common case rather than the actual protocol. APIs which felt nicely general suddenly turn out to have opinions.

That is where a lot of interesting development work happens.

It is one of the reasons I like AT Protocol as much as I do. Bluesky proves that ATProto can support a very large social network, and that is obviously important, but the protocol becomes much more interesting to me when people stop asking how to build another Bluesky.

The ATmosphere needs more weird shit

AT Protocol is still discussed as though it is primarily a technology for making Twitter alternatives.

That is understandable. Most people encounter it through Bluesky, and most of the records they see belong to the app.bsky.* namespace. The obvious thing to build on top of that is another client for the same network, perhaps with a different design or a slightly different set of features.

There is nothing wrong with that, but I would be disappointed if that was where the ecosystem stopped.

If an open protocol eventually produces twenty applications which all show more or less the same feed of short posts, then we have not done very much with the fact that it is an open protocol.

The interesting part begins when people use it for things which do not look like Bluesky at all.

Music is one example. My own PDS contains a stupid amount of listening history because Malachite imported it into records. Those records have nothing to do with microblogging, and they do not need to.

Long-form publishing is another. This blog is represented through site.standard.* records. Leaflet treats ATProto as publishing infrastructure rather than a social feed. Other projects are experimenting with code, events, forums, games and identity.

That is the bit I want to see more of.

I want people to use ATProto for applications where explaining the project requires somebody to stop and think for a second. I want software where the connection to Bluesky is incidental rather than central. I want things which make use of the fact that an identity and its data can exist independently of one particular application.

Otherwise, ATProto risks becoming culturally much narrower than it is technically.

A protocol should be boring underneath interesting software

The successful version of this does not involve everybody learning what a DID is.

Most people should never need to know how a repository works, what an XRPC endpoint is or why somebody is arguing about lexicons.

I care about those things because I am the sort of person who voluntarily writes protocol libraries in C. That is not a reasonable expectation to place on everyone else.

What I actually want is for somebody to open an application which does something completely different, sign in using the identity they already have and continue from there.

Maybe it is a music application. Maybe it is a blogging platform. Maybe it is a game. Maybe it is some tiny specialised tool built for a group of twenty people. Maybe it is something nobody has put a name to yet.

The important part is that the underlying identity does not suddenly stop existing because the user moved between applications.

That is when ATProto starts becoming infrastructure rather than merely "the thing Bluesky uses".

The protocol itself can stay boring. The software built on top of it should not have to be.

I probably do have too many projects

I am aware that I have too many repositories.

This is not exactly new information.

There is probably a more disciplined version of my development life where I maintain two or three projects, keep immaculate roadmaps, plan my time properly and avoid starting something new until the previous thing is finished.

I know myself well enough to know that this is not going to happen.

More importantly, I am not entirely convinced it would make me a better developer.

The projects bleed into each other constantly. Something I learn while writing a C library changes the way I think about a Swift application. Working around an awkward protocol behaviour in one client makes me notice that the SDK underneath it needs changing. Importing tens of thousands of music records turns an abstract belief about owning personal data into an actual engineering problem.

Even the projects which go nowhere usually give something back.

Sometimes the useful result of a project is the project itself. Sometimes the useful result is discovering that the idea was bad. Sometimes it is a tiny piece of code or an architectural lesson which turns up months later somewhere completely unrelated.

That kind of development would be very hard to justify if every hour had to be attached to a roadmap or a financial return.

Luckily, mine does not.

Open ecosystems need room for bad ideas

There is a point where every software ecosystem starts becoming more organised.

Libraries mature. Conventions emerge. People work out which designs are sensible. Documentation improves. Everybody gradually develops an idea of what a "normal" application looks like.

A lot of that is necessary. I do not want every ATProto project inventing its own completely incompatible authentication system in the name of creativity.

The problem starts when convention becomes expectation, and expectation becomes an unofficial boundary.

If every tutorial begins by teaching somebody how to create a feed, every SDK treats app.bsky.* as the centre of the universe and every new project is measured according to how effectively it replicates some part of Bluesky, then the protocol remains open while the surrounding culture quietly stops being so.

Open ecosystems need enough space for people to make bad ideas.

They need projects which are over-engineered, under-engineered, too niche, too strange or simply unnecessary. They need somebody to use a feature in a way nobody intended and discover that it is actually useful. They need experiments which fail badly enough that somebody else learns not to repeat them.

Some of the weird shit will be pointless.

That is part of the deal.

You cannot have genuine experimentation while demanding that every experiment prove its usefulness beforehand.

Build things because you want them to exist

There are limits to all of this.

Once other people start relying on your software, you have responsibilities which did not exist when it was just an experiment on your laptop. Security matters. Accessibility matters. Data loss matters. Compatibility matters. "I made this for fun" does not magically make negligence harmless.

I have felt that transition myself. Several things I originally made because I wanted them now have users, issues, compatibility expectations and maintenance work attached to them.

That has not convinced me that I should stop making strange things.

It has mostly convinced me that the strange phase is worth protecting.

You are allowed to build something even if somebody else already built a more sensible version.

You are allowed to use an unfashionable language because you want to learn it.

You are allowed to make a protocol do something its original designers probably did not have in mind.

You are allowed to spend several evenings on an idea and eventually decide that it was terrible.

You are allowed to make software because you would personally like it to exist, even if the eventual audience consists of yourself and six other people.

There is already more than enough software designed by committee, built to satisfy a market analysis and sanded down until nobody can object to it.

The ATmosphere has plenty of feeds.

It could do with more weird shit.