An Argument for Open Source

22 Feb, 2026

There has been a war waging for the soul of software development for decades now: open source vs proprietary, closed source software.

Linux vs. Microsoft PostgreSQL vs. Oracle Llama vs. ChatGPT

I recently open sourced a project that implements Tom Keelin’s Metalog distribution in JAX. This was something I had worked on roughly five years ago, culminating in the release of pymetalog to the open source community.

metalog-jax was mostly an exercise in exploring the capabilities AI coding assistants like claude-code can provide. I feel deeply sheltered at work from these advanced capabilities and was looking for an avenue to explore their use. Translating metalog into JAX code felt like the perfect fit! Upon release to the open source community, I had three PhDs reach out within the first week. Responses ranged from “this looks great” to “I have an idea for further research” to “have you seen this new paper?”. This type of reaction is exactly why I love open source software.

Expanding the response surface of your product through open source opens up many more opportunities for follow on experimentation in ways closed source cannot.

Within a span of a week, I was pointed towards research that I may not have ever found. Genuine curiosity and shared interest in betterment of the product I had built was at the core of this, not maximizing shareholder value. This doesn’t happen without being vulnerable and putting something out there for people to play with. If I had developed this product within the confines of my company, we would have been constrained by the collective imagination of the research group. The numbers are just not in your favor when there are millions of people who can review what you’ve released on a public GitHub repo compared to tens or hundreds of people in a private company repo.

In my experience, developing closed source software opens up your product to the world of “compliance”, “ownership”, “risk management”, and quarrels over priorities. These concerns are understandable in an organization who makes metal contraptions that humans strap themselves in and fly. There needs to be sign off when human life is at stake. These concerns don’t make a lot of sense for frontier research. Control and governance kill vibes man.

There is fundamental tension between development speed and consideration of all stakeholders priorities. If I’ve learned one thing doing this for 10 years now, it’s that the election of a “steering committee” to provide oversight is the fastest way to kill a fledgling product. Development team’s focus shifts away from maximizing utility for the masses to pleasing the steering committee. The steering committee may not know what the hell the product even does.

I will admit that in many instances there exists a gap between the best open source offering and the best closed source offering of software products. Oftentimes this gap is never really closed. If I had to pick a database to store realtime vehicle diagnostics during an F1 race, I would most certainly choose Oracle over Postgres. However, I think the most interesting experimentation is done in the open source space. Even a juggernaut like Anthropic who only employs the best of the best of the best cherry picks the best open source developments to integrate into Claude: Opus 4.6 is likely just Opus 4.5 with recursive language model and agentic swarms wired in. These are significant new features that both have roots in the open source community. Clawdbot, now the most stared open source project ever, is another prime example of creation of an entirely new product that stands on the shoulders of open source work.