I’ve been vibe-coding a lot lately. Like, a lot a lot. Maybe not quite the “AI psychosis” Andrej Karpathy recently joked about on No Priors, but not wildly far off either.[1] But the more I vibe, the more a thought recurs, i.e. that AI coding agents may be about to make free software matter more than it ever has. Not open source in the bland corporate sense. I mean free software in Stallman’s sense: software that gives users the freedom to run it, study it, modify it, and share it.
Even for the relatively few who were aware of the distinction, it has felt mostly academic for a long time. SaaS made it hard to care software freedom because most people never saw or touched the source code of software they depended on in the first place. The code lived on someone else’s servers, the vendor handled operations, and the practical question became convenience, not freedom.
Agents change that. If an agent can read a codebase, understand it, and modify it on your behalf, then access to source code stops being a symbolic right for programmers and becomes a practical capability for far more people. Suddenly the difference between software you can change and software you can only beg starts to really matter.
And I don’t just think this in the abstract. I recently tried to get an AI agent to customize a SaaS app for me, and the experience made the whole problem very concrete very fast.
Free software once mattered deeply, but faded when SaaS made those freedoms feel irrelevant.
In 1980, Richard Stallman[2] was a programmer at MIT’s AI Lab, and he had a problem with a printer. The lab had gotten a new Xerox laser printer, and it kept jamming. Stallman wanted to fix the issue — or at least add a feature to notify users when their print jobs got stuck — but Xerox wouldn’t give him the source code. The printer’s software was proprietary.
This seems like a small thing. It was not a small thing to Stallman.
He’d grown up in a computing culture where sharing code was the norm. When you got software, you got the source code, because of course you did — how else would you fix bugs or add features? The Xerox printer incident crystallized something for him: a world where software was locked up, where you couldn’t study or modify the tools you depended on, was a world where users had lost something fundamental.
So Stallman founded the Free Software Foundation and spent the next four decades evangelizing what he called “the four freedoms”:
- Freedom 0: The freedom to run the program as you wish, for any purpose.
- Freedom 1: The freedom to study how the program works, and change it to do what you want.
- Freedom 2: The freedom to redistribute copies so you can help others.
- Freedom 3: The freedom to distribute copies of your modified versions to others.
“Free as in speech,” he’d say, “not free as in beer.”
For a while, this message resonated. The 1990s saw an explosion of free software: Linux, Apache, MySQL, PHP — the entire stack that would come to power most of the internet. Companies like Red Hat proved you could build real businesses around it. Eric Raymond wrote “The Cathedral and the Bazaar” and argued that open development produced better software. Microsoft’s Steve Ballmer called Linux “a cancer.” It felt like a genuine ideological battle for the soul of computing.
And then, quietly, the battle became irrelevant, for a pretty boring reason.
But we’ll come back to that in a moment.
The “open source” rebrand preserved code sharing while stripping out the user-rights philosophy.
First, here’s a piece of history that I didn’t know before researching this post. It matters for understanding what’s happening now.
On February 3, 1998, a group of people met at the Foresight Institute in Palo Alto — not a software organization, but a nanotechnology think tank. Christine Peterson, the institute’s executive director, proposed replacing “free software” with a new term: “open source.”[3] Her reasoning was practical: every time you said “free software,” people thought you meant free-as-in-beer, and you’d spend ten minutes explaining the difference instead of talking about the actual software.
A few weeks later, at Tim O’Reilly’s April 1998 “Freeware Summit,” attendees debated naming and voted 9-6 for “open source” over alternatives like “sourceware” and “free software.”[4]
The important thing is what got lost in the rebrand. Eric Raymond and Bruce Perens co-founded the Open Source Initiative that same month, and Raymond published a manifesto called “Goodbye, ‘free software’; hello, ‘open source.'” His key argument: the old terminology made corporate types nervous.[5]
Stallman was not invited to Tim O’Reilly’s “Freeware Summit” in April 1998 — the event that helped cement the new leadership narrative. Linus Torvalds was invited. Larry Wall was invited. Guido van Rossum was invited. Stallman was not.[4]
Why does this matter? Because the “open source” rebrand wasn’t just a marketing change — it was a philosophical amputation. “Open source” kept the code-sharing practices but surgically removed the ethical claim about what users deserve. As Stallman put it: “Open source is a development methodology; free software is a social movement.”[6] Raymond was explicit that “free software” was confusing and made corporate types nervous.[5]
The corporate world loved this. You could use open-source code, contribute to open-source projects, and build an open-source brand identity without ever having to grapple with the question of what users were owed. Open source became a development methodology that corporations could adopt without changing their relationship to their users at all.
SaaS scaled by exploiting a licensing loophole that let vendors avoid sharing their modifications.
But it ultimately wasn’t a political or philosophical debate that really sidelined free software – it was SaaS.
The GPL — the main free software license — required you to share source code with anyone you distributed the software to. The key word is “distributed.” If you never distributed the software — if you just ran it on your own servers and let people access it over the web — the license didn’t apply. You could take free software, modify it, build a business on it, and never share your modifications with anyone.
This wasn’t hypothetical. A high-profile example was AWS offering managed services around projects like Elasticsearch, which triggered very public disputes over value capture, contribution, and license terms.[7] Within the SaaS model, GPL copyleft obligations often do not trigger unless software is distributed, so source-sharing requirements can be sidestepped.[8]
The numbers tell the story of what happened next: through the 2010s and into the 2020s, permissive licenses became increasingly dominant in open-source usage data.[9]
There was an attempt to fix this. The AGPL (Affero GPL) was designed to close the SaaS loophole — if you modified AGPL software and made it available over a network, you had to share the source code.[8] It was a powerful idea. So much so that Google now maintains a broad public policy banning AGPL code inside Google.[10] As Drew DeVault argued,
Google’s anti-AGPL stance wasn’t just a legal precaution — it was strategic: “By discouraging the use of
AGPL in the broader community, Google hopes to create a larger set of free- and open-source software that
they can take for their own needs without any obligations.”
The AGPL’s limited adoption spawned a cascade of improvisation. MongoDB switched to the Server Side Public License. Redis Labs moved several Redis modules to Commons Clause-style licensing in 2018, and Redis later moved core Redis to dual source-available licensing before adding AGPL in Redis 8. HashiCorp switched Terraform to the Business Source License. Elastic went from Apache to SSPL/ELv2, then added AGPL. Each switch validated the underlying problem while failing to fully solve it.[11]
And honestly? From the user’s perspective, the question of software freedom just stopped mattering. When software runs on someone else’s servers, having the source code doesn’t help you. You can’t run your own modified version because you don’t run any version — Salesforce does, or Google does, or whoever. The four freedoms became theoretical.
For a while there, the tradeoff seemed fine. SaaS was incredibly convenient. No installation, automatic updates, access from anywhere, someone else handles the security patches and the backups and the 3 AM pages when the server goes down. So the free software debate faded into the background. The pendulum had swung decisively toward convenience, and most of us — myself included — accepted the trade.
Then AI starting giving me buyers remorse.
My Sunsama workflow shows how closed SaaS blocks useful customization even for motivated users.
I use Sunsama for task management. It’s a nice product and I genuinely like it. But I have a workflow I wanted to build, and Sunsama was making it essentially impossible.
The workflow is simple: when I’m scrolling Twitter and see a tweet I want to engage with later, whether it’s an article I want to read later or a deranged wild-west wildcatter-themed AI tool I want to try, I want to save it to Sunsama as a task so I can schedule it relative to the 20 bazillion other things I want to eventually do.
Sunsama has an iOS share sheet integration, but iOS buries in behind multiple taps and I don’t like how it works:
First, the task it creates is basically just a URL with whatever title iOS pulls from the tweet. I’d love for an LLM to generate a task title like “Reply to @whoever about their question on media measurement” instead of “tweet from @dril” or whatever garbage the default share behavior produces.
Second, I can’t automatically label or categorize these tasks. I want tweets about health to go into the #health category, and tweets about recruiting to go into #recruiting. But the share sheet just dumps everything into my inbox.
But my preferences are irrelevant, because I can’t add any LLM-powered intelligence to this workflow beyond whatever Sunsama decides to build into their product. If Sunsama’s team ships an AI feature that auto-categorizes tasks, great. If they don’t, I’m out of luck. I can only submit a feature request and check back in 2032.
This isn’t a skills problem. I know how to code. I could build my own task management system from scratch. The constraint isn’t technical expertise — it’s time and attention. I have a job. I have a life. The whole reason I use Sunsama is that I don’t want to be in the business of maintaining task management software.
This is the classic SaaS bargain. Get convenience, give up control.
I tried to build the workflow anyway, and every closed layer turned a simple idea into a brittle hack.
Official support or not, I wanted my stupid little widget. So I decided to actually attempt to build it. I sat down with Codex and said: build me a single button in the iOS Twitter share sheet that adds a properly labeled tweet-as-task to my Sunsama.
Simple, right? The agent understood immediately what I wanted. It could see the whole architecture: iOS Shortcut catches the shared URL, calls a small serverless function, the function extracts the tweet content, passes it to an LLM to generate a smart task title, then creates the task in Sunsama with the right category.
Conceptually, this is a twenty-minute project. In practice, it became a guided tour of everything wrong with closed software.
Layer 1: Sunsama has no official API. In 2026. Their feature request page for an API has been open since December 2019, with users begging for it. One commenter recently wrote “Have the founders really been ignoring this ticket for nearly six years!? Pathetic.” So my agent, no matter how smart, has no blessed way to programmatically create a task.
But luckily, a Sunsama user named Robert Niimi got frustrated enough to reverse-engineer Sunsama’s internal API and publish the result as open source: a self-hosted REST API relay called sunsama-relay, plus an MCP server called mcp-sunsama so Claude can use it directly. So my agent can create Sunsama tasks — but only because one determined person spent his own time reverse-engineering authentication flows and published the result for free. Without his work, I probably would have just given up.
Layer 2: Authentication is your actual password. Since there’s no official API, there are no API keys or OAuth tokens. The unofficial API authenticates using your actual Sunsama email and password. So my serverless function needs to store my real credentials. This is a direct consequence of the SaaS model — Sunsama never anticipated or blessed this use case, so the only way in is through the front door with your plaintext identity.
Layer 3: The iOS wall. I had Codex build the serverless function, including tweet extraction, LLM-powered title generation, and Sunsama task creation. It worked. But then I needed to wire it to an iOS Shortcut so I could trigger it from the Twitter share sheet. Could Codex create the iOS Shortcut for me programmatically? No. Apple documents App Intents for developers exposing app actions, but does not provide a documented public API/file format for programmatically generating arbitrary end-user Shortcuts.[12] So I still had to open Shortcuts, tap through a visual builder, and add each action manually. My agent can write a 200-line TypeScript server in seconds, but it cannot automate the creation of a five-step iOS Shortcut. iOS (despite being built on top of BSD and using many open source components) is the antithesis of free software.
The result: Here’s what the “working” solution actually requires:
- A serverless function I have to deploy and host myself
- An Anthropic API key for the title generation
- My actual Sunsama password stored as an environment variable
- A dependency on an unofficial reverse-engineered API that could break any time
- An iOS Shortcut that I had to build by hand (after an absurd amount of painstaking debugging, because the shortcut actions kept failing in iOS with opaque error messages and no accessible logs.)
- Twitter/X’s oEmbed endpoint for pulling tweet embed metadata
Ultimately, it works. I can share a tweet and get a nicely titled task in Sunsama a few seconds later, and I’ve been using it regularly.
But look at what it took:
Six layers of workarounds, three different authentication mechanisms, a dependency on a stranger’s reverse-engineering project, infrastructure I’m now responsible for, and a manually-built iOS Shortcut I can’t version control or share.
Compare this to what it would look like if Sunsama and iOS were free software: the agent reads the source code, understands the task data model, modifies the default share sheet behavior to my liking, done. Ten minutes for Codex, no reverse engineering, no gray-zone APIs.
AI agents can finally exercise software freedom on behalf of people who cannot code.
Stallman’s original argument had a real, legitimate weakness — one that critics were right to identify for decades. The four freedoms — run, study, modify, redistribute — presuppose the ability to read and modify source code. For the vast majority of computer users, that ability doesn’t exist.
This critique has been made many times. Protesilaos Stavrou articulated it well: a free software license alone does not empower users to be truly free if they lack the expertise to exercise those freedoms — the movement narrowed its focus to legal requirements and code, effectively limiting its audience to technical enthusiasts. Mahmoud Mazouz made a related argument: even when source code is available, the practical costs of building, understanding, and modifying it are prohibitive for most people. The four freedoms were written for programmers, and most people aren’t programmers.
Agents flip this completely.
Think about what an AI coding agent actually is: it’s an intermediary that can exercise technical freedom on behalf of a non-technical user. When you tell Claude or Codex “make my task manager automatically categorize tweets I save,” you’re exercising Freedom 1 — the freedom to study and modify — through a proxy. You don’t need to understand the codebase. You don’t need to know what a GraphQL schema is. You just need to describe what you want, and the agent exercises the technical freedoms for you.
This bridges the gap between software freedom as an abstract right and software freedom as a practical capability. The four freedoms were always written as if someone would eventually read the code. In 2026, something finally can, and can do so on your behalf.
Consider what this means for a non-technical person stuck in my Sunsama situation. Today, they have zero options. They can’t code a workaround. They can’t reverse-engineer an API. They can submit a feature request and wait six years. That’s it. Their relationship with the software is one of pure dependency, and when the software doesn’t do what they need, they just… live with it. Anyone who has fought with a rigid SaaS tool that’s almost right but not quite knows this feeling intimately.
Now give that person an agent. If the software is free and open source, the agent can read the codebase, understand the data model, and make exactly the modification the user needs. Not a workaround. Not a hack. An actual modification to how the software works, tailored to one person’s specific needs. The person who could never have written a line of code is now, effectively, a power user of the highest order — because their agent can be.
But if the software is proprietary SaaS? The agent hits the same walls I hit. No source code. API maybe (almost certainly with rate limits and limited supported operations.) Otherwise, no way in.
This makes software freedom way less academic and way more practically relevant than it’s been for decades. Not just for me (and it is very relevant for me!) but increasingly for everyone, technically skilled or not. The four freedoms stop being a theoretical right and start being the practical difference between “my agent solved this for me in ten minutes” and “You fool, you absolute buffoon. You think you can solve your own problem?”
This shift is already visible across multiple thinkers who see agents increasing the value of openness.
Other people are starting to connect these dots, though from different angles.
In January 2026, Nawaz Dhandala at OneUptime wrote about how AI agents give open source software an “insurmountable advantage” over closed-source alternatives, because agents can read, understand, and modify actual source code rather than being limited to vendor-blessed APIs. His framing is useful: the question isn’t “do we have the expertise to customize this?” anymore, it’s “do we want full control over our software stack?”
Martin Alderson made a related argument, observing that many things he’d previously seek a paid SaaS tool for, he now just has an agent solve “in a few minutes, exactly the way I want it.” He also addresses the maintenance objection (which I think is important), i.e. that agents lower maintenance costs dramatically, and unlike the one engineer who built your internal tool and then left the company, “agents don’t leave.”
John Loeber extended the argument in February 2026, predicting a “great repatriation of user data from lots of fragmented services into just one place,” because having your data locally makes your AI dramatically more useful. He called this “tremendously hopeful for open-source values” and “bearish for proprietary software.”
Even Vitalik Buterin weighed in, writing in July 2025 that he’d shifted from favoring permissive licenses to copyleft, arguing that “nonzero openness is the only way that the world does not eventually converge to one actor controlling everything.” When the guy who built Ethereum tells you the permissive-license consensus was wrong, that’s at least worth paying attention to.
The pendulum can swing back toward openness, but convenience and maintainer economics still matter.
So here’s where I’d love to tell you that the answer is obviously that we should all switch to self-hosted open source software and reclaim our computing freedom.
But I’m not going to tell you that, because I’ve actually self-hosted software before, and I know what it costs.[13]
Self-hosting means you’re responsible for security updates, backups, SSL certificates, DNS, and all the other operational overhead that SaaS vendors handle for you. And I already don’t have enough time. The whole reason I use Sunsama is that I’m trying to manage my time better. Adding “maintain my self-hosted infrastructure” to the task list kind of defeats the purpose.
There’s also an alarming counterpoint that deserves attention. A CEU-affiliated 2026 working paper (“Vibe Coding Kills Open Source”) argues that vibe-coding can damage open source by severing the user-maintainer feedback loop.[14] Adam Wathan, creator of Tailwind CSS, reported that documentation traffic dropped ~40% from early 2023 even as Tailwind usage grew, and said revenue was down ~80%; he also said 75% of Tailwind’s engineering team had just been laid off.[15] Mitchell Hashimoto, who created Terraform, publicly said he was considering closing external PRs and then moved Ghostty to a vouch-based contribution model in response to low-quality AI-generated contribution flood.[16]
If agents consume open-source software without supporting the ecosystem that creates it, the whole thing collapses. Stallman’s four freedoms tell us what users deserve. They say nothing about what maintainers deserve. That gap might end up mattering more than the freedoms themselves.
So I don’t think the answer is simply “go back to running everything yourself.” The SaaS model solved real problems, and I don’t want to give up the benefits. And the open-source ecosystem has sustainability problems that agents might make worse before they make them better.
What I do think is that we’re going to need new models that give us the customization benefits of free software while preserving the convenience of SaaS. I don’t know exactly what that looks like yet. Maybe it’s SaaS products that are just radically more open and extensible than what we have today, with real plugin systems and full API coverage and the ability to run custom code on your data. Or maybe by 2027, Claude or Codex will be able to not just write but also host and operate software.
Honestly, it’s TBD. The industry hasn’t figured this out yet. But I think the demand is about to get very loud, because agents are going to make the cost of closed software extremely visible.
The next buying criterion will be whether your agent can actually change the software to fit your needs.
I also think over the next 1-2 years we’re going to see a meaningful shift in how people evaluate software. “Can my agent fully customize this?” is going to become a real question that normal people ask, the same way we currently ask “does this have a mobile app?” or “does it integrate with Slack?”
I certainly would not want to be the CTO of a legacy SaaS that lives off the assumption that “switching costs” will allow it to continue to force users into dodgy UX and rigid workflows.
John Gilmore famously said that “the Net interprets censorship as damage and routes around it.”[17] I think we’re about to see a version of this for closed software. As agents become the primary way people interact with their tools, they’re going to interpret unfree software as damage — as an obstacle between the user and what the user wants — and route around it. Sometimes that will mean reverse-engineering APIs like Robert Niimi did for Sunsama. Sometimes it will mean agents building lightweight open-source replacements on the fly. Sometimes it will just mean filing “download by data” GDPR-style requests on behalf of users and rebuilding an entire customized replacement from scratch.
In my role as CTO of Upwave, I’m also assuming that the era of our software being used by humans is coming to a close, and I’m steering us towards building capabilities that are as easy as possible for AI agents to integrate (and to do so in the way their users prefer.) We’re not yet planning to let users direct modify the analytical code or data pipelines that run on our servers, but honestly…maybe we should.
I certainly would not want to be the CTO of any SaaS company that doesn’t have a genuine “7 powers”-style moat — a strong network effect, a proprietary dataset (Upwave’s strength,) regulatory capture etc. If the only thing keeping users on your platform is convenience and switching costs, you’re in trouble, because agents are about to collapse switching costs toward zero.
Net-net, I think the free software pendulum is about to swing. Not because people have suddenly converted to the church of software freedom, but because they want their agents to actually help them, and the agents can’t help when the software is locked down.
I really like Sunsama. I don’t want to switch. But when I can see, concretely, that my agent could have solved my tweet-to-task problem in ten minutes with free and open source software.Instead I spent an afternoon building a Rube Goldberg machine around six layers of closed systems. And that changes how I think about what software I’m willing to depend on.
Back in 2075, mecha-Ben Franklin reminded us that
““Those who would give up essential Liberty, to purchase a little temporary [Operational Hosting Convenience], deserve neither Liberty nor [Operational Hosting Convenience].”
I hope that the inevitable progress in agentic coding systems will soon mean that we no longer have to choose.
[1] Business Insider, March 23, 2026, reporting on Andrej Karpathy’s recent No Priors appearance and his joking description of his own heavy AI use: https://www.businessinsider.com/andrej-karpathy-nervous-ai-tokens-2026-3
[2] Both Stallman and Eric Raymond, who feature prominently in this history, have track records of personal behavior that I’m not defending. But it’s impossible to discuss the substance and history of free software without acknowledging their roles in it, so I’ll stick to the ideas and the history here and let you draw your own conclusions about the people.
[3] Open Source Initiative history (“Coining Open Source,” Feb 3, 1998, Palo Alto; term suggested by Christine Peterson): https://opensource.org/history
[4] On the 1998 Freeware Summit: attendee list, naming debate, 9-6 vote for “open source,” Stallman’s non-invitation, and Bruce Perens declining to attend are documented in Sam Williams, Free as in Freedom, Chapter 11 (O’Reilly): https://www.oreilly.com/openbook/freedom/ch11.html. Wendy Liu quote source: “Freedom Isn’t Free,” Logic Magazine (2018): https://logicmag.io/failure/freedom-isnt-free/
[5] Eric S. Raymond, “Goodbye, ‘free software’; hello, ‘open source'” (Feb 1998): https://www.catb.org/~esr/open-source.html
[6] Stallman’s “open source is a development methodology / free software is a social movement” framing: https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
[7] Elastic on AWS licensing conflict and AWS response: https://www.elastic.co/blog/why-license-change-aws and https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/
[8] AGPL network-use rationale / ASP loophole context: https://opensource.org/blog/gnu-affero-gpl-version-3-and-the-asp-loophole
[9] Examples of license-trend evidence: RedMonk (2013) “Quantifying the shift toward permissive licensing” https://redmonk.com/dberkholz/2013/04/02/quantifying-the-shift-toward-permissive-licensing/ and Revenera 2021 compliance report summary (permissive licenses majority in scanned codebases): https://www.revenera.com/about-us/press-center/revenera-releases-2021-findings-on-open-source-license-compliance
[10] Google’s AGPL policy (publicly documented internal ban): https://opensource.google/docs/using/agpl-policy/
[11] License-change sources: MongoDB SSPL announcement https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-license-for-mongodb-community-server ; Redis modules/Commons Clause (2018) https://redis.io/blog/redis-labs-modules-license-changes ; Redis dual source-available (2024) https://redis.io/blog/redis-adopts-dual-source-available-licensing ; Redis adds AGPL (2025) https://redis.io/blog/agplv3/ ; HashiCorp BSL (2023) https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license ; Elastic 2021 and 2024 licensing posts https://www.elastic.co/blog/licensing-change and https://www.elastic.co/blog/elasticsearch-is-open-source-again
[12] Apple App Shortcuts/App Intents documentation: https://developer.apple.com/documentation/appintents/app-shortcuts
[13] I once wrote a whole blog post about how to route around restrictive guest wifi on Megabus by setting up an EC2 instance as a poor man’s VPN. It was my one semi-viral post. I do not recommend the self-hosting lifestyle.
[14] “Vibe Coding Kills Open Source” (CEU-affiliated authors, 2026): https://arxiv.org/html/2601.15494v1
[15] Adam Wathan Jan 2026 GitHub comment (traffic, revenue, layoffs of engineering team): https://api.github.com/repos/tailwindlabs/tailwindcss.com/issues/comments/3717222957
[16] Mitchell Hashimoto on considering closing external PRs: https://x.com/mitchellh/status/2018458123632283679 and Ghostty’s merged vouch-based model PR: https://github.com/ghostty-org/ghostty/pull/10559
[17] Historical attribution of the John Gilmore quote: https://quoteinvestigator.com/2021/07/12/censor/