The Biggest Myth About Open Source
I used to think open source meant giving away your ideas.
That probably sounds strange coming from someone who now keeps a GitHub repository for his website and has spent the last several months building software with AI, but it was genuinely how I saw the world. If I spent weeks building something useful, why would I make it public? The code represented my time, my effort, and maybe even a future business. Keeping it private felt like the obvious choice.
That question came up again recently after I started building several small applications with Claude Code. None of them are trying to become the next billion-dollar startup. They're simply tools that solve problems I ran into in everyday life.
One of those tools came out of a conversation with my nephew, who works in financial services. His team spends thousands of dollars every year buying lead lists that convert at roughly one percent. As we talked through the problem, I started wondering if AI could help identify better prospects by combining publicly available data from multiple sources. A few hours later, I had a working prototype.
Whether it ultimately succeeds isn't really the point. The point is that, for the first time in my life, I was building software that solved a real business problem.
Then I pushed the code to GitHub and immediately found myself wondering whether it should stay private.
That simple question turned into one of the more interesting conversations I've had in a long time.
Your Code Isn't the Advantage
William Collins made an observation that forced me to rethink my assumptions. Most people believe their code is their competitive advantage. Open source communities have been demonstrating for decades that this often isn't true.
Take Terraform as an example. HashiCorp didn't become successful because nobody could see the source code. Anyone could download it. Anyone could contribute to it. Anyone could even fork it. Yet Terraform became the standard because the value wasn't just the code. It was the ecosystem that grew around it.
Providers were built for nearly every major platform. Documentation improved. Modules appeared. A community formed around best practices. Vendors invested in supporting it because customers were already using it. The software became valuable because of everything surrounding it, not because the implementation was hidden.
That distinction feels more important today than it did even a few years ago.
Where the Value Moves
Artificial intelligence has dramatically lowered the barrier to creating software. People who would never have considered themselves developers are now building useful applications. Network engineers are writing automation. Product managers are creating internal tools. Entrepreneurs are validating ideas over a weekend instead of hiring a development team.
As the cost of building software continues to fall, it raises an interesting question.
If more people can build software, where does the value move?
I think William's answer is right.
It moves to execution.
The hard part isn't writing code anymore. The hard part is understanding customers well enough to solve problems they genuinely have. It's validating an idea before investing months into it. It's continuously improving a product after it's released. It's earning trust, supporting users, and building a community that wants your project to succeed.
Those things are considerably harder to copy than a GitHub repository.
That doesn't mean every project should be open source. There are perfectly legitimate reasons to keep code private. If your application contains proprietary algorithms, customer data, or represents intellectual property that gives your business a genuine advantage, keeping it private may be exactly the right decision.
But that's a business decision, not an emotional one.
Code Can Be Copied. Context Can't.
I realized during our conversation that my instinct wasn't really about protecting intellectual property. It was about protecting the time I'd invested. I equated someone copying my code with someone taking something I'd worked hard to create.
Those aren't necessarily the same thing.
Even if someone copied every line of code from one of my projects tomorrow, they wouldn't have the conversations that led to the idea. They wouldn't understand the customer problem that motivated it. They wouldn't know why certain design decisions were made or how the application evolved through feedback.
Code can be copied.
Context usually can't.
That's the biggest shift AI has forced me to make.
A year ago I would have argued that software was the product.
Today I think software is becoming one piece of the product. The surrounding knowledge, relationships, execution, and community increasingly matter more than the implementation itself.
Ironically, AI may end up making the human side of building software even more valuable.
The episode started with a simple question about GitHub repositories.
It ended with a much bigger one.
If AI makes software creation accessible to almost everyone, what will truly differentiate the people who build the next generation of products?
I'm starting to think it won't be the code.
It will be the people who know which problems are worth solving in the first place.
This grew out of a conversation with William Collins on The Art of Network Engineering. Listen to the full episode.