The intersection between open source projects and businesses has long been a fascination of mine. In many ways they’re opposing concepts which simply should not function. One is an entirely socialist idea driven by community, the other an entirely capitalist idea driven by competition.
Yet, somehow, they come together to form an incredibly powerful coalition with a vast reach.
Traditionally there are two accepted models. You’re either a business with an open source project, or you’re an open source project with a business.
Github, Twitter and Stripe are all great examples of massive businesses who have adopted the former model. Their core focus is on growth and revenue, but they’ve also had great success in sharing components they use with the open source community.
Conversely: Docker, WordPress and Ember.js are all good examples of open source projects, which happen to also have a business. The primary focus is on creating free, open software — and the revenue generation is secondary/separate.
All operate differently in terms of how they’re structured, but most generally fall into one of these two buckets.
What’s interesting to me in particular is the difference in approach both to business as well as to open source depending on which bucket you’re in.
Businesses with an open source project are run by the business. They focus their development efforts are first-and-foremost on their own use-case. They build the product which they want to use, and then they share it freely. The sacrifice is the reach of the open source code. If it’s only built for one use-case, it probably won’t build up a large community or attract many maintainers.
Open source projects with a business are run by the community. They focus their development efforts first-and-foremost on a wide array of use cases so that the project will spread as far and wide as possible. Then, separately, figure out a way to use the project to run a business. The sacrifice is the extreme complexity of building the business. It becomes far harder to focus and iterate on one use-case when the development team is committed to building many.
These two models are both largely very effective, but they’re not without faults. When there is a business-first focus at the expense of transparency and integrity, it frequently creates very real friction in the open source community. But, an open-source-first focus at the expense of being able to create a sustainable business also frequently ends up in software which slowly dies off or is suddenly sold without warning.
Ghost is in a really interesting position, because it doesn’t quite fit into either of those buckets. We’re trying to carve out a brand new one.
We have a viable business which is a non-profit organisation, and the company’s sole purpose is to fund the open source project. Neither one survive unless the other exists, and so their fates are irrevocably bound. In the above examples the interests of the business and project are in a constant state of conflict — whereas in our model they turn out to be in continuous alignment.
When we want to work on something purely to benefit the open source community, we can; there are no complaints from shareholders about our commitment to their investment. When we want to work on something that purely benefits the business, we can, because all of the money from the business comes back to the open source project and helps the community in turn.
So, we are neither a business with an open source project, nor an open source project with a business.
We’re an open source business.