Why Theo Browne Thinks AI Could Strengthen Open-Source Businesses

I have been losing trust in closed software that I cannot change when it stops meeting my needs. AI makes the business case for openness complicated: competitors can copy, customers can self-host, and attackers can inspect code more easily. Yet I think the ability to customize may make open products more competitive, not less.

The risks are real. Open code can help competitors reproduce features, let customers avoid a hosted subscription, and expose vulnerabilities for investigation or exploitation. I have heard of open projects dealing with a high volume of security reports and attempted attacks; the balance depends on the product and its operations.

We have not open-sourced T3 Chat. Our small team would have to handle the security and engineering burden of exposing a hosted service whose failure could be costly. T3 Code runs on the user's machine with their own subscription, which changes our risk assessment. I want the benefits of openness, but I cannot ignore the cost of supporting it.

To explain the business case, consider established platforms such as Salesforce, AWS and Retool. Their scale comes partly from serving a broad range of customer needs. My example uses fictional numbers to illustrate the pattern, not actual Salesforce usage data.

Imagine a product with 1,000 features where each customer uses 50. Perhaps 25 are common to most customers, while the other 25 differ from one customer to the next. A new competitor can build the common core quickly, but a customer may refuse to migrate because one obscure feature is missing.

At large scale, a feature used by 1% of customers can still serve many organizations; for a small competitor, the same feature may serve only one. Incumbents accumulate this long tail over time. The resulting breadth makes them difficult to displace even when customers use only a small slice of the whole product.

Plugins are one answer, but I have found plugin architecture difficult to design and support. Extension points cannot anticipate every request, and compatibility becomes a commitment of its own. Plugins can work, yet they do not eliminate the cost of deciding what is extensible or maintaining that interface.

Another route is to serve a common use case particularly well. I use Vercel as an example: developers can deploy web applications without assembling every infrastructure component themselves. The important point is that the hosted application remains code the customer can connect to other services.

A developer might use Cloudflare for a firewall, Supabase for a database or Convex for backend queries. Instead of waiting for the hosting provider to supply every feature, the developer composes services in code. This modularity predates AI; AI may reduce the effort needed to use it.

My proposal for application businesses is to let customers build their own unusual requirements on top of a useful core. That is harder than applying the same idea to infrastructure, especially when customers already have systems to integrate. It calls for building blocks and a way to modify them.

T3 Code is our open-source graphical interface for coding agents. At the time of the video it required users to bring their own provider subscription or API access and had no direct monetization. I cite it here because its users have started experimenting with the code in ways our team did not plan.

I report roughly 42,000 distinct installation identifiers that opened the app, about 16,000 weekly users, nearly 9,000 GitHub stars and around 1,500 forks at that time. Fork counts are not the same as unique active users or proof that each fork contains a customization; they show interest in experimenting with the repository, not a measured 10% customization rate.

One user, Emanuele, forked T3 Code into DP Code and added features including multiple terminal panes, split conversations, a queue and a handoff workflow. I would like to bring some ideas back into the main project, although making a feature reliable for a broad audience takes additional work.

Open-source customization is not new. My argument is that AI agents may lower the cost of modifying an existing codebase, letting more people attempt a tailored version. That does not remove the need to review, test, secure and maintain the result, especially for people who do not understand every change.

Imagine a customer who likes PostHog's hosted backend but needs a visualization the product does not offer. I have waited on requests for specific charts and considered leaving when they were unavailable. I do not want to operate the entire analytics infrastructure myself; I would like to customize the part my team uses while retaining the managed service.

Mitchell Hashimoto, creator of Terraform and Ghostty, describes a related building-block economy. Theo cites his account that Ghostty reached around a million daily users over 18 months, while libghostty spread into other products much faster. These are figures reported in the discussion and concern different products and periods.

Hashimoto's point is that a building block can be a library, a framework or even an application that others adapt. Agents can assemble documented components quickly, and projects such as Ghostty are seeing customized forks. I see this as an expansion of the modular software practices developers already used.

I cite an experiment in which a coding agent often selected particular modular tools, including Zustand and Vercel in the tested circumstances. Those choices depend on the prompts, model and sample; they do not prove that all agents always prefer open-source tools or any particular vendor.

The T3 Stack was an earlier attempt to help developers choose components that work together. People experienced decision fatigue even when good tools existed. Agents can help assemble and explain combinations, though they still make mistakes and need human judgment about suitability and dependencies.

Hashimoto acknowledges security vulnerabilities, instability and limited understanding of important systems as risks of rapidly produced software. Smaller custom tools may ship with a narrower scope than a mainstream product, while maintainers can learn from working forks and decide which ideas belong upstream. A private fork's lower initial bar does not make maintenance disappear.

Maintainers may find it easier to decline a feature request when users have a practical way to make the change themselves. Forks can also provide prototypes for research and development. Hashimoto still expects many users to choose polished, supported mainstream applications; building blocks can complement those products rather than replace them universally.

Commercialization remains the hard question. Hashimoto says he does not yet have a concrete answer, and I appreciate that distinction. Claims that agents favor free or open options need evidence for specific models and tasks; a business still has to find a service that customers will pay to keep using.

I built Lawn as an alternative to a video-review product I was frustrated with. Getting a version running internally was easier than packaging hosting and pricing for other customers. People have forked Lawn for their own video workflows without paying us, and I think their success is good; figuring out a sustainable business is the next challenge.

Those users still had to solve storage, authentication, database management and possibly payments. What if we operated the video infrastructure and backend for a fee while customers owned and customized their frontend? A hosted service could remain valuable even when users control the code they interact with.

A customer could run a fork on a custom domain, ask an agent to add a missing feature, and keep using the provider's backend. I call that potentially sticky because customization becomes part of the product relationship. It is a proposed business model, not evidence that customers will actually pay or that updates will be easy.

My next proposal is a file called patch.md. It would record, in plain language, the intent behind custom changes as well as changing the code itself. The idea builds on tools such as patch-package, but addresses a familiar problem: a patch may stop applying when upstream code moves or changes.

Imagine a Customize button that creates a local fork of T3 Code and lets an agent modify it. Later, when the upstream project changes, an update process would first try to apply the existing changes. If that fails, an agent could attempt a merge or recreate the described features against the new version.

The user would then inspect the result and decide whether to migrate. I call this idea patch-in-place: keep customization accessible while helping users stay current. It is a proposal rather than a working feature, and a written description or an agent-assisted merge cannot guarantee correctness or security.

The hard questions are obvious: how do many customer forks receive security fixes, remain supported, and integrate with the rest of the system? I have spent time thinking about the idea but have not built it. It needs experimentation, tests and a way to handle failures rather than an assumption that every conflict will heal itself.

My broader prediction is that malleable platforms become more valuable as more people can ask agents to implement their needs. Pi is one example I associate with a minimal, customizable agent. I do not know the timeline or whether this will work in every category, but I am investing in the possibility.

The case for an open business is that users can explore niche needs, share prototypes and form a community around a useful core, while a company sells something such as hosting or support. The risks and economics still have to be worked out. My invitation is to build useful open alternatives and see what people make with them.