Open source is the most reliable engine of compounding innovation in software. I have bet on it, contributed to it, and built with it across my career, and the conviction has only sharpened with each new wave of technology. The headline lesson is not that open source is a license choice or a moral position. It is that openness is the single most effective design pattern for distributing good ideas at scale, and the teams and companies that internalize that pattern compound faster than the ones that do not.

I want to set down what I have learned from doing this work, because the AI era is restating the question of what “open” means, and the answer matters for anyone building products, leading teams, or investing in this space.

The Cofax bet

In 2000, my team at Knight Ridder Digital made a strategic decision that looked unusual at the time. We had built Cofax, a content management system that powered newspaper websites across the company. The conventional move would have been to keep it internal, treat it as proprietary infrastructure, and let competitive advantage accrue. We made the opposite decision. We open-sourced Cofax on SourceForge.

The bet paid back in ways the proprietary version could not have produced. Within a couple of years, newsrooms and publishers around the world had adopted it. Sun Microsystems featured Cofax on the Java homepage. Contributors I had never met were submitting bug fixes, writing documentation, and extending the platform into use cases we had not anticipated. The code went farther than my team could have carried it, and it came back stronger than we had sent it out.

The lesson was not that open source is generous. The lesson was that open source is leveraged. Every external contributor multiplied our internal effort. Every adoption validated decisions we had made on thin internal evidence. And every reuse strengthened the surrounding ecosystem of practice that the original code lived in. Closed innovation can only spread as far as the organization that owns it can carry it. Open innovation spreads anywhere, and what comes back is worth more than what went out.

That bet shaped the way I have made every similar decision since.

What separates projects that compound from ones that do not

Looking across the projects I have released and worked with over the years, the pattern that separates compounding projects from inert ones is consistent. It comes down to four properties, and they hold across eras.

First, the project solves a problem the author keeps having. Maintenance becomes a side effect of using the tool, not a separate burden. The author is the first user, and the user-feedback loop is internal.

Second, the documentation is good enough that a stranger can succeed without reading the source. This sounds obvious and is usually skipped. The projects that survive treat documentation as part of the product, not as an artifact produced after the fact.

Third, the scope is clearly defined and defended. Contributors can understand what is in and what is out without a meeting. Scope discipline is the single largest predictor of long-term project health.

Fourth, the community has governance from day one, even if the governance is one sentence about who decides. Projects that defer this question end up with fork wars, license disputes, and contributor drama. Projects that name the decision-maker early skip almost all of that.

License choice is the floor. Apache, BSD, MIT, and the Creative Commons variants matter at the margin. They do not determine whether anyone shows up. Everything that determines success sits above the license.

The community is the actual product

The thing experienced maintainers know, and that newcomers learn the hard way, is that the code is the smallest part of the work. The larger part is the community around it. Issue triage. Pull request review. Defending scope decisions. Saying no, often, with reasons. Keeping a tone in the issue tracker that contributors want to be part of.

This is leadership work. The maintainer’s job is not to write the most code. It is to set the conditions under which other people contribute their best work. That is the same job a senior technology executive does inside a company. Open source teaches it in a setting where you have no positional authority and have to earn every contribution. That is exactly the discipline I think the next generation of senior technology leaders needs to learn, and it is one of the reasons I keep building open-source projects alongside my operating roles.

The AI era restates the question

The dynamics I learned from Cofax and from the WordPress plugin work I did with Blogroll Links carry forward into the AI era, but the question of what “open” means has shifted in meaningful ways. Model weights are not just code. A model with open weights and closed training data is a different artifact than the Linux kernel. It is reproducible in deployment but not in creation. The debate over what counts as open AI is going to define a generation of infrastructure decisions.

The right frame is to stop asking whether AI is open source and start asking which layer of the stack is open at which company. Anthropic has been thoughtful about publishing research, building developer tools that work across providers, and articulating responsible scaling principles in public. Frameworks like LangChain replicate the pattern of community-built infrastructure on top of mostly proprietary models. The dynamics differ from the LAMP stack era, but the underlying lesson holds. Innovation moves faster when the pieces are inspectable, modifiable, and combinable.

I have been building Ragbot.AI as an open-source AI assistant that combines language models with retrieval-augmented generation. The project is the testbed for synthesis coding, the disciplined human-AI collaboration practice I have been articulating, and that the broader synthesis engineering framework sits inside. The same four properties I described above apply. Solve a problem you keep having. Document for strangers. Defend scope. Govern early. The AI era does not change the fundamentals. It raises the stakes.

Synthesis coding and the contribution question

Synthesis coding raises a real question about open-source contribution. If AI lowers the cost of producing code, does it raise or lower the value of contributing to projects you do not own? My answer is that it raises it substantially. The bottleneck on most open-source projects has always been maintainer time, not contributor code. AI helps potential contributors get a working pull request together faster. It also helps maintainers triage and review faster. Both ends of the funnel widen, and the projects that adopt synthesis coding practices are going to outpace the ones that do not.

The discipline matters. Synthesis coding treats AI as a collaborator whose output you take responsibility for, not a generator whose output you forward. The contribution is yours regardless of how it was produced. Maintainers who insist on this standard will keep their projects healthy. Maintainers who do not will drown in volume.

What I would tell a CEO or a board

The thread running through Cofax, Blogroll Links, Ragbot.AI, and whatever I release next is not really about software. It is about how innovation propagates. The closed version of any innovation can only spread as far as the organization that owns it can carry it. The open version spreads anywhere, gets adapted to contexts the originator never imagined, and comes back changed in ways that improve the original.

For a CEO making strategic technology decisions, the practical implication is that the question is not “should we open-source this?” but “which layers of our stack benefit from being open, and how do we structure the open layers so that contributions strengthen rather than dilute our position?” The companies that get this right in the AI era will compound faster than the ones that treat openness as a binary choice.

This is the work I have been doing for my entire career, and it is the work I expect to be doing for the rest of it. The principles are stable. The applications keep changing. That is what makes the field worth being in.