How Hyper-Personalized Software Challenges Open Source
AI makes it cheap to build software for exactly one person's workflow. The idea is twenty years old, but suddenly feasible. And it breaks an assumption at the heart of open source collaboration.
Modifying software is now easier than asking open source developers for changes. And technical and non-technical users are building bespoke note-taking, task management, and cooking recipe apps using AI. I think this is changing something important about how software will be built and distributed in the future.
Looking specifically at open source, it was always possible for users to run their own copy of a specific piece of software. But that copy was still someone else's design, with their own priorities and choices baked into the product. And adopting it either meant learning to live with their ideas or collaborating to find a middle ground.
AI changes this and makes it cheap to build bespoke software that fully matches one's own workflow. Existing applications can be forked and modified, or a completely new app can be created from scratch.
Evidence
One example of this is Glaze, a toolkit to build desktop apps from prompts. Applications can be shared with other users via a store, which also allows them to "remix" applications.
To be honest, most applications look pretty simple and, quite frankly, useless. But some are very creative, like the app Radical that reimagines the calendar as a circle. I wonder if this would've ever been built without AI.
Another platform I find interesting is Val Town, which makes it easy to run JavaScript snippets. And just like with Glaze, users can easily use AIs to create these snippets or remix other users' public projects.
History
The idea of hyper-personalized software isn't new and has been written about a long time ago. Clay Shirky, a professor at NYU, wrote an essay in 2004 titled Situated Software that contrasts web applications built for scale with software developed in and for special situations:
Allowing the user to customize the interface of a Web site might make it more useful, but it doesn't make it any more personal than the ATM putting your name on the screen while it spits out your money.
Situated software, by contrast, doesn't need to be personalized – it is personal from its inception.
Another example is Robin Sloan's 2020 post An app can be a home-cooked meal, which describes the development of a very simple messaging app for him and his family. It ends with an observation about ownership that I think expresses better than anything why hyper-personalized software has such an attraction:
This messaging app I built for, and with, my family, it won’t change unless we want it to change. There will be no sudden redesign, no flood of ads, no pivot to chase a userbase inscrutable to us.
And finally, the most recent example that I want to share: the essay Malleable Software by Ink & Switch, which explores how much current software can be customized and what a better world would look like.
We envision a new kind of computing ecosystem that gives users agency as co-creators. We call this idea malleable software—a software ecosystem where anyone can adapt their tools to their needs with minimal friction.
Questions
A lot of smart people have spent a lot of time thinking about hyper-personalized software, but there are many unanswered questions left. Especially around infrastructure, security, and maintenance. But looking at open source specifically, I am wondering what changes if we go from one mainline to many.
What would we even collaborate on?
In open source today, the artifact of collaboration is the source code. But in a world where non-technical users can create their own applications using AI, code becomes meaningless as an artifact. Most users won't be able to understand it, let alone reason about it in a pull request review. And if the applications are hyper-personalized, they won't have the same code anyway.
Right now, the level of granularity seems to be either the whole application (Glaze), very small snippets of code (Val Town), or a prompt that can be fed into an LLM (Attractor). None of these feels right, but we don't have something better yet.
Maybe specifications can fill the gap, making it possible to reason about functionality on different levels, and combining features from different apps by using a code-agnostic definition. But the tooling around specifications is still rudimentary and certainly not suited for a non-technical audience yet.
What infrastructure does this run on?
Every piece of infrastructure we run today assumes that one piece of software is distributed to many users, be that websites or mobile apps. A canonical version is deployed and shipped to every single user. With personalized software, we will move closer to a one-to-one mapping with some interesting consequences.
For one, we can run software much, much closer to the user. It lets us reconsider if a backend even is required, and avoid costly optimizations that are necessary to serve millions of users globally. But we need to make deployments transparent. Non-technical users do not care where their applications run. They just want to use them. Which means we don't make a distinction anymore between the infrastructure and application provider. Wherever you build your app will also be the platform where you run them.
For another, how do you discover applications to either collaborate on or to remix? Look at how many task management apps there already are. Now 100x that number. How are you ever going to find the one that's right for you? App stores have horrible discoverability as is, and the problem will only get worse.
Who do you trust?
The security story of open source revolves around many eyes seeing the same code. If every app becomes a unique snowflake, with code that is not even reviewed by the user, our current approaches to supply chain security fail. How can users trust the applications they run, fork, and remix?
Who maintains it, and who pays?
Software always requires change. I think that is a truth every developer eventually understands and accepts. No matter how perfect the code is we write today, the environment in which it operates changes and that requires us to change the code as well. That might be for technical (e.g. Apple switching its processor architecture to arm64) or compliance (e.g. GDPR) reasons.
But who updates a million divergent forks? And for open source specifically: If everyone forks and no one converges, who maintains the common foundation all those forks are cut from? The sustainability problem of open source will only get worse, since there will be fewer contributors but more consumers.
Collaboration
The question I keep coming back to is the one about collaboration. Open source had already been struggling, even before AI entered the scene. In three years working in open source full-time, I saw all the rough edges and felt the paper cuts.
I think we need to find a fundamentally new model of collaboration for the future. We won't be able to keep up with the amount of code being written, and maybe that isn't even the right level of abstraction going forward. And we need to find new ways to build community in a world where humans and agents interact, on projects that look the same from the outside but diverge wildly between users.
How do we share and build on hyper-personalized software when there is no mainline anymore? That's what I want to explore further.