The future is already here — it's just not evenly distributed yet. — Arthur C. Clarke
When I first encountered an open-source AI agent built by Nous Research, something caught my attention that had nothing to do with benchmarks, model parameters, or training pipelines. The builders were understandably proud of what they'd created — a persistent, self-improving agent that remembers across sessions. They framed it as a tool for developers and power users. And it is.
But they were looking through the wrong end of the telescope.
The more interesting question isn't what an AI agent can do for people who already write code. It's what it does for people who don't — the vast majority of the population for whom open source software might as well be locked behind a vault door.
This article is my attempt to name what I think is happening, before it becomes obvious in hindsight. I'm grateful to Teknium and the team at Nous Research for building the tool that sparked this thinking. The agent is marvellous. What follows isn't about the tool itself, but about what it represents for a much larger shift that nobody is talking about yet.
The Paradox of Free
Open source has always carried a paradox at its core. The code is free. The access cost is enormous.
Consider what happens when someone — not a developer, just someone who needs software — tries to use an open-source project for the first time. They find a project on GitHub. They click through to the README. And then:
The README is written by a developer, for other developers. It assumes you know what a terminal is, what a package manager does, what environment variables are, why dependencies conflict. It assumes you have git installed. It assumes you're comfortable with the concept of "building from source." The documentation gap isn't an accident — it's a cultural artifact. Open source communities optimize for contributor onboarding, not user onboarding.
So the software is free, but the knowledge tax to use it is paid in hours of frustration, Stack Overflow searches, and eventually, giving up.
I've watched this happen repeatedly. Someone finds a project that would solve their problem perfectly — a self-hosted photo backup, a private wiki, a VPN, a price tracker. They're excited. They open the installation instructions. They close the tab fifteen minutes later. Not because the software is bad, but because the distance between "I want this" and "this is running on my machine" is measured in a learning curve they don't have time to climb.
This isn't a small problem. This is the structural barrier that has kept open source from reaching the majority of people who could benefit from it. The software exists. The desire exists. The barrier is the distance between them.
What Changes When You Insert an Agent
Now consider what happens when an AI agent sits between the person and the entire toolchain.
A user says: "Set up a photo backup service on my server."
The agent reads the documentation. It installs the dependencies — resolving version conflicts silently. It writes the configuration files. It sets up the reverse proxy. It generates SSL certificates. When something breaks, it reads the logs, diagnoses the error, and fixes it. When it's done, the software runs.
The gap between "I want this" and "this is running" collapses from a multi-day learning curve into a conversation. That's not incremental improvement. That's a category change.
Consider what this looks like in practice — not hypothetically, but in patterns I've observed:
- "Set up my own cloud storage." The agent installs Nextcloud, configures the database, sets up the web server, generates SSL certificates, and has it running. The user never touches a config file.
- "I want my own email server." The agent parses DNS requirements, configures MX records, sets up SPF, DKIM, and DMARC. The user pastes their domain provider's instructions and the agent handles the rest.
- "Can you build a price tracker for this website?" The agent installs the necessary packages, resolves dependency conflicts that would have taken hours of troubleshooting, and deploys a working application.
- "Update the home server software." The agent SSHes in, checks running containers, updates them, and troubleshoots connectivity issues — all from a messaging app.
In every case, the request is simple. The execution is complex. The agent absorbs the complexity. That gap — between the simplicity of the request and the complexity of the execution — is the thesis.
The Wrong Revolution
Here's where the discourse went sideways.
The AI agent conversation has been dominated by coding agents — tools that help developers write code faster. They live in IDEs. They're evaluated by benchmark performance on coding tasks. They're marketed to people who already know what a function is.
This makes sense as a business. Developers have money, influence, and a clear use case. But it has created a blind spot that distorts the entire conversation.
The agent revolution was framed around creation: AI helps you write code faster. But the bigger transformation is access: AI helps you use software that already exists.
These are different problems requiring different categories of tool. Coding agents are excellent at what they do. They win benchmarks, they have strong out-of-the-box performance, and users who write code daily benefit from them genuinely. The fact that a coding agent can't install Nextcloud doesn't make it bad — it makes it specialized.
But for the thesis — opening the entire open-source corpus to the majority of the population — coding agents are the wrong category of tool. They live in terminals and IDEs. They require you to already have a development environment. They assume you know what a repository is. For a non-developer, they're a dead end at the entry point. No IDE, no terminal, no git — you can't even get to first base.
What's needed is a general-purpose agent runtime — a tool that is a superset of a coding agent. It can write code. But it can also install software, configure services, deploy infrastructure, maintain systems over time, and — critically — meet the user where they already are: on messaging platforms like Telegram, WhatsApp, or Discord, not in a terminal window.
The distinction matters because of where the attention has gone. The market is over-indexed on coding agents. They get the funding, the media coverage, the conference keynotes. General-purpose agent runtimes get a fraction of the attention, despite serving a dramatically larger population and unlocking a dramatically larger transformation.
This attention imbalance is momentum, not logic. Coding agents are easier to understand (you can see the code output immediately), easier to evaluate (benchmarks exist), and easier to sell to (developers have budget). General-purpose agents are harder to demonstrate because their value is in infrastructure work that's invisible — the SSH session that fixed the Docker container, the DNS record that was configured via API, the dependency conflict that was resolved before the user even knew it existed.
The imbalance should be reversed. The bigger prize isn't helping developers write code faster. It's helping everyone else use the software that already exists.
The Agent as Package Manager
Here's a framing that helped me think about this clearly.
The history of software distribution is a history of collapsing barriers:
- Compile from source — you needed a compiler, build tools, and the knowledge to resolve build errors
-
Package managers (
apt,brew,npm) — someone else handled compilation and dependencies; you just needed to know the package name - App stores — you didn't even need to know the package name; you searched, clicked, and it worked
Each step removed a layer of required knowledge. Each step expanded the population who could use the software.
The AI agent is the next step in this lineage. It's the package manager of the natural language era. You don't need to know the package name. You don't need to know the platform. You describe what you want — "I want to back up my photos privately" — and the agent figures out which open-source project fits, installs it, configures it, and maintains it.
But here's where it goes further than app stores: app stores gave you closed, curated, commercial software. The agent gives you the entire open-source corpus — millions of projects, built by communities, free to use, that have been sitting behind a knowledge wall for decades.
The software was always free. The agent removes the toll booth.
Where the Agent Ends and Judgment Begins
I want to be precise about one thing. The agent can install and configure, but it can't decide for you.
It can set up nginx, but it can't tell you whether your security posture is appropriate for your threat model. It can install a self-hosted photo service, but it can't tell you whether self-hosting is the right choice versus a commercial alternative given your specific constraints. It can deploy a VPN, but it can't assess whether the privacy tradeoffs align with your needs.
There's a layer above mechanical installation that requires judgment — and that's still human. What the agent does is remove the mechanical barrier so the human can focus on the judgment barrier. The person still decides what to install, why, and whether the tradeoffs are right. The agent handles the how.
This is actually a healthier division of labor than what we have today, where the mechanical barrier is so high that people never even get to the judgment stage. They give up before they can evaluate whether the software is right for them, because the installation process itself is the filter.
The Grief and the Reward
Every subculture faces a moment when the thing that made it special becomes accessible to everyone. There's a grief that accompanies the progress. The Linux community saw it when Ubuntu made Linux usable. The crypto community saw it when exchanges made buying simple. Open source will see it too.
Some contributors will feel it. Their identity is partly built on being among the few who could cross the barrier. When the barrier drops, the exclusivity drops with it. That's a real human response, and it deserves empathy rather than accusation.
But here's the deeper pattern: most creators want their software to be used.
A maintainer who sees their download count go from 500 to 50,000 because agents are installing it for people — that's not grief. That's the reward. That's the entire reason they built it. The dopamine of impact. Software that changes lives is more satisfying than software that sits in a repository admired by a handful of people who could figure out how to compile it.
The agent doesn't just democratize access. It democratizes audience for the creators.
Consumption First, Participation Later
There's an honest tension worth naming. The agent democratizes consumption of open source — using the software. It doesn't immediately democratize participation — contributing to the projects. A person who says "install Nextcloud" becomes a user, not a contributor. The contribution pipeline, the thing that keeps open source alive, still runs through people who write code.
But consumption comes first. And participation follows through two mechanisms:
Learning by proximity. When you interact with software through an agent, you start to understand it. You see what the agent does. You develop opinions about configuration choices. Over time, some users will want to contribute — not because they learned to code from scratch, but because they've been close to the software long enough to have something to say about it.
Agents contributing back. As general-purpose agents become more capable, they can generate bug reports, submit patches, and fix issues upstream. This isn't hypothetical — it's already beginning to happen in early forms. The agent that installs the software is also positioned to notice when it breaks, diagnose the cause, and potentially contribute the fix.
The pipeline doesn't break. It widens.
What Needs to Happen
I'm not prescribing a roadmap. The power of naming a thesis is in letting people find their own role in it. But I'll suggest a few directions, not as prescriptions, just as signposts:
For agent builders: The access transformation requires agents that are easy to install, that meet users on messaging platforms, and that can handle the full scope of infrastructure work — not just code. Optimize for the non-developer, not the power user. The power user is already served.
For open-source maintainers: The agent is coming for your software. Not to replace it — to install it for thousands of people who couldn't before. Consider whether your project is agent-friendly: clear installation paths, minimal dependency conflicts, robustness against partial failures. The agents will find the rough edges. Smooth them.
For the community: The attention imbalance needs correcting. The conversation about AI agents is dominated by coding tools solving the creation problem. The access problem — the larger transformation, the one that serves the majority — deserves at least equal attention, equal funding, equal discourse.
The Future Is Already Here
Arthur C. Clarke said the future is already here, it's just not evenly distributed. This is that moment.
Right now, today, people are using general-purpose AI agents to install, configure, and maintain open-source software — through conversations, from messaging apps, without touching a terminal. It's happening. It's just not happening at scale, and it's not being talked about.
The open-source corpus already exists. The agent technology already exists. The barrier between them — the knowledge tax, the ecosystem fluency, the interface familiarity — is the thing that's dissolving.
The future is already here. It's just not evenly distributed yet.
Let's distribute it.
This article was written in collaboration with an AI agent — the same kind of general-purpose agent runtime described here. The ideas are human. The agent helped shape them. If that's the future of writing, it's the future of software access too.
Follow me on X for more on AI agents and open source.
Top comments (0)