When to Open Source as a Startup
Open source has become the supercharger of the software industry. Startups with modest budgets are today changing the world because they can build on the solid fundament created by Apache, Linux, Elasticsearch, and the likes. As much as using Open Source has become a no-brainer, closed-source startups still struggle when to contribute to the community.
At Collaborne, we have been giving to open source from day one. Our contributions range from bug reports and fixes, up to plugins and stand-alone open source projects.
Why we contribute to open source
So why do we — as a closed-source startup — contribute to open source? Idealistic reasons aside (aka “sense of fairness”), we have been reaping very tangible benefits:
- Improve code quality: Like it or not, developing in a pressure cooker environment leads to shortcuts: “Do we really need to document this method? Test this corner case? Fully comply with this standard?” Often the answer is: “He, we are just a couple of developers who know all our tweaks.” Well, guess what happens whenever a new developer joins.
Open sourcing forces us to look to the code like there were 100s of developers. Compared to our proprietary code, we see better separation of concerns, more tests, better documentation, stricter compliance with standards, and more stable APIs. Call it a mental trick — yet it works. - De-risk dependency on third parties: Just having access to the source code won’t help much if a project becomes dormant. Hence, we have every motivation to promote and strengthen the project to increase its prospect to flourish.
As a side effect, writing fixes and plugins prepares us for the worst-case scenario: at least we would know how to maintain the code on our own. Finally, contributing earns us karma points, which give access to the behind-the-scene decision making. - Help recruit developers: Our open source contributions come up frequently during recruitment interviews. Many candidates got convinced by our contributions that we have amazing developers from whom they could learn how to write great code.
In short, open sourcing makes a lot of sense to us. This brings us to the question when to develop open source and when to develop closed source.
How we decide what to contribute
At Collaborne, we open source by default. Meaning, we open source our code as long as there is no reason speaking against it.
In concrete terms, we ask ourselves these four questions whenever we develop a new module:
- Is there an existing open source project that does what we need?
- If not: Is there an existing open source project to which we could contribute to make it do what we need?
- If not: Is the problem non-strategic or the solution approach commoditized, so that we can open source the code?
- If not: Can we split out our secret sauce into a proprietary part, and open source the rest?
Did you spot the one question that we don’t ask ourselves: Will other developers use — or even contribute to — our open source project? Our egos obviously love if developers adopt our stuff. And we love even more if other guys fix our bugs. Still, we don’t focus on adoption because we simply can’t effort to build & maintain code that can be applied to use cases far beyond our own needs.
Yet, this means in no way that we stop others from doing so. If somebody provides a pull request, we generally accept it. If another developer volunteers to push the project to general purpose, we are equally happy to hand over the code. If somebody uses our code as inspiration to build their own thing: That’s cool too.
Summary
Contributing parts of the code base to open source generates significant benefits also to closed-source startups. The very act of open sourcing pushes towards a better code base, de-risks the dependency on third parties, and helps recruiting developers.
Our key to success has been open sourcing by default combined with a clear understanding of what’s really part of our secret sauce.
Photo: Sweet Chili Arts
