Why I Open Source My Code
Part 1: The Business Case
I have been fortunate enough to have the freedom to open source my work for most of my life as a developer. It is not something to be taken for granted. I’ve had to think about why it matters quite a bit, more often than not to justify the risk to people who don’t have the personal investment in free software that I do.
I will break this up into two parts: first, the practical business case, then the personal reasons.
Part 1: The Business Case
I believe that open source should always be part of an integrated strategy. If your goal is to have a successful business, you need to have value coming back for any value you put out. Your source code is valuable, but probably not as valuable as a million users or a really vibrant and active development community. This is not a something for nothing deal. You need to have an end-to-end strategy to capitalize.
It’s hard to compete with a free product
“What keeps them from just copying our codebase and competing with us?”
If you’re a business looking to invest a lot of time, money and resources into a product, trying to sell something that is already free is a really risky idea. There is no race to the bottom— you’re starting there and working backwards to other revenue streams. Open source acts like a double edged sword in this way. Sure, anyone can jack your code and sell it. On the other hand, they are starting off with an entrenched competitor who knows the market and can build the software much better and cheaper than they can.
If your code is close enough to what they want anyways, they are more likely to become a contributor or sponsor. If you give them a path to contribute, sponsor and demonstrate to their own stakeholders some kind of deeper partnership or ownership than what others have, it’s just as valuable to their business without the risk and cost of supporting the entire project themselves.
There is a spectrum to this risk. The more complex your software is, the harder it is for other companies to extract one-sided value out of via consuming or forking. A small package that solves a useful problem will get a lot wider integration and use, while there is a lot more incentive to work together on more complex applications.
Community is your marketing engine
People hate being marketed to. On the other hand, people love telling people about things they believe in. If we make things worth building and give people products worth believing in then they will help us to market our product in countless, unseen ways.
When people are invested in you and your work they will market it for you because they want you to succeed. They will tell their friends, respond to your tweets, give your app a good rating on the app store. The network effects of altruism and goodwill add up to a powerful grassroots force.
A sense of ownership in something is a powerful and motivating feeling, and this is a force that needs to be carefully managed and respected. To enjoy the network effects you need to let your community take ownership. You need to be respectful and receptive to feedback. You need to make time for your community and talk to them.
Also, do merch. If you are making something that people love, even if it’s just like a tiny framework that does one thing— make t-shirts, stickers, coffee mugs. You can get it all done made-to-order and drop shipped directly. People love that stuff, and other people get to see how much they love it.
Developers are picky
Unless you’re working on futuristic deep tech I’ve never heard of, you probably have competitors. If your goal is to get developers using your product, you need to speak to their values and understand what they value.
Developers usually have very practical fears. What happens if you go out of business? What happens if I need something fixed? Are you going to maintain this forever? Is there an on-prem version for my one super paranoid client?
In the end, developers will make a decision based on feelings and values. Right language and frameworks? Check. Open source? Check. In the vast majority of cases whatever got implemented first stays that way as long as it works, and your service business is safe.
You do probably need a service business, though. For a large project, that usually means making some dividing line in your features that go into the open source project and the features that go into the cloud.
The ideal division is to charge for the things users would have to pay for anyways. Offering a hosted version of your product with everything set to just-work speaks to developer’s main pain points of getting up and running and also getting deployed to production. Paywalling off useful features creates an us vs them mentality that is unsustainable in community projects.
True believers are the best developers
Sometimes your users join your team.
Some people love what they are working on, and it shows. I don’t know whether “10x engineers” is a real thing, but I do know love when I see it. People who take responsibility and care about the outcome are priceless and rare, and tend to go deeper and deliver exponentially more value.
Finding someone who loves your project as you do is very hard. Paying them a lot of money is usually not enough. If you want other people to build something with you and love it as you do, they have to share your dream. And you have to be willing to share your dream with them.
Mindshare is the golden goose
You’re deciding to get some information about something. A year ago, your option was to search Google.
Today, your options are: ask ChatGPT, search Google, search Bing, in that order.
OpenAI (and Microsoft by extension) have clearly taken mindshare from Google. The practical effect of that is seen every time you make a small decision on where to get information and which brand to reach for first. Changing entrenched consumer behavior is really hard, and if you’re making something disruptive you are going to need all the grease you can get to make it easy and frictionless for people to adopt.
The fastest growing product wins. As long as the product can continue to grow, growth should be the number one focus. It is much, much easier to capitalize on growth later than to focus on pre-growth capitalization.
A good example right now is the Alpaca/Llama language models. Even though they are significantly worse than OpenAI’s current offerings they are the only models today making any headway in mindshare against GPT-4. Why? Because they are free, open source, you can fine tune them and run them at home.
Open source protects the founders
If you are willing to accept that other people might fork your work, open source guarantees that, no matter what, you will be able to continue to use it.
When the code is open source, it decouples the codebase from the fate of the company or organization. If the company dies, the code can be reborn into something else. If you made the work (code, design, etc) then you know what is there and how to get value from it, and if you find yourself in the middle of a bad split or pivot to something else, you can always fork and do your own thing.
This is obviously a double edged sword— while a company might perceive this as a risk, it also keeps the org honest to the original mission. Some orgs, like Ethereum and the Ethereum Foundation, have this built in, and have experienced forks in the past due to community alignment issues.
Splitting off or forking is usually a violent slowdown in development pace. There is very little incentive to leave unless something is really going wrong or people are misaligned. In Ethereum’s case, the end result was multiple Ethereum forks that spoke to the values of those forking communities, and less internal conflict in the original community. Vitalik talks at length about this here.
Altruism sells
People want to be good. They want to spend their time here doing the right things, helping themselves and others when possible and leaving this reality at the end of their lives with no regrets.
When you build something for reasons more than profit, it shows. When you make things that allow others to participate in that reason, you add purpose to their lives.
You will have competition for your product based on what people want. But you can carve a really strong position if you can build a product that reinforces an ideal people believe in.
To be continued…
While I’ve most often had to justify the business case, that’s not really why I’m here. Part II will be the other side of the coin— why I really believe in the free software movement on a personal level.
You can follow me on Github and see what projects I’m working on here