How would you explain the pros / cons of Open Source to cofounders?
I'm the CTO in a startup with 2 other entrepreneurs (finance & business backgrounds, not engineers), and ran into something revealing about my own bias: they don't immediately see the benefits of open-source.
I could come up with a great list of pros for open-sourcing code: sharing code amongst various ventures without licensing concerns (MIT license), others using the code in their own projects and therefore testing / finding bugs / contributing back to the original project, thus helping make the codebase more stable, etc.
I've been struggling to come up with a list of cons. The only one I could think of after a bit was something along the lines of "make sure not to accidentally release some critical IP to the business."
Since this seems like a less straightforward issue, I thought this would be a great inaugural post to Indie Hackers! What are your thoughts? What pros / cons did you use when evaluating this for your own companies?
Pros
Cons
The immediate "con" your cofounders are probably thinking of is it eliminates a part of your "economic moat." That is -- it makes it trivial for your competitors to replicate your software. So if your competitive advantage lies in SaaS and you don't have a unique advantage someone else couldn't also replicate, then open-sourcing your code doesn't necessarily make sense.
Now that said, open source can be a competitive advantage -- see Protonmail, Ubuntu, Elasticsearch, etc. But in order for that to materialize, you really need to invest in an active open-source community, and 99.99% of projects simply never develop one.
Hi Sam,
Having read some of the comments to your question, there seem to be two facets that are being tackled in this post. So let's first separate the two sides of "open source" and identify the values and risks of each strategy.
A. Using open-source libraries and frameworks to build your product.
Regardless of your product source is closed or open, your first decision is whether to use open-sourced tools, libraries and/or frameworks to build your product. The short answer here is that it is overwhelmingly in your favour to use open-sourced tools and libraries. Many "closed source" tools today would have leveraged open source libraries and components within them.
The value of using open source is as obvious as it sounds. You leverage community knowledge, stand on the shoulders of giants and reduce the cost of development.
The risk of using open source tools and libraries is that the roadmap, maintenance and security of the source is as good as the maintainers of the project. If you're building mission-critical products (finance, health, banking, etc) then you can still leverage open source with the help of tools such as repository gateways (you control and approve which packages that can be pulled in and making sure they don't suddenly disappear from public repositories. We all remember what happened with NPM
padLeft).B. Open-sourcing the product you're building (or parts of it).
The answer to this question is going to be more complex because it largely depends on the philosophy of your personal and organisation modus operandi. The short answer is that it depends on your product.
If you're building an IP-heavy product, one that relies on the source code to contain within itself core business logic, processes and domain knowledge, then avoid open-sourcing this. The risk of you and your team revealing IP into the public is too high and you will not receive any return on this risk because the community would not be able to contribute to a code base that they do not understand the goal/strategy/IP behind it.
If you're building a service-heavy product, one that relies on the people, network and area of expertise of your organisation/brand and the product you're building is just a tool to support the process, then there could be value in open-sourcing your code. The biggest value of this strategy is to leverage community engagement (not so much contribution). When you have a tool that has the ability to extend upon, such as plugins, etc. then an open-sourced community engagement can make all the difference.
The risk here is that a competitor that offers a similar service could use your product to give themselves a leg up, whereas, without your tooling, they would have had to invest into their own tooling or perpetually be one step behind you. To mitigate this risk, you could definitely decide to open source some parts of your product, particularly the parts that could boost your community engagement, for example, API SDK, integration libraries, etc.
Good luck on your venture and I hope this helps you to convince your co-founders.
Regards,
Tri.
If you are talking about open-sourcing your own code then the cons are:
It allows anyone to see your technology at the lowest level. For example, a B2B app may get pushback from a CTO after seeing concerning issues with the codebase. Thus, it must be really high quality which is a good thing.
Investors may not like that the secret sauce is out in the open. The benefits of open source code only work if you build a community around it. Otherwise, it is just revealing everything.
i've been doing "open source" for the last 3 years and now i'm closing down all my repos. you can engage in that communist utopian myth of open source and how you'll have a wonderful community of friends filing issues fixing bugs and loose 10% of your valuation or you can just do yourself and forget that madness called open source because nobody's really going to help you as much as you writing your own code
I understand the argument of not releasing critical IP as open-source, and I agree that if you open-source 99% of your company's proprietary code it will drive shareholder value down, but I'm asking from the standpoint of releasing non-unique features.
Take user management as an example. As long as your entire business is not built around your unique approach to user management, I wouldn't imagine releasing that code as open-source would cause your valuation to plummet.
I also believe if your primary reason for releasing something as open-source is to have others pitch into your project and fix problems for you, you're doing it for the wrong reason. There shouldn't be any expectation for others to help out, just that the code is out in the public for anyone to use if they would like. And then if they're using it and find a critical issue with it, the hope is they give back (understanding that doesn't happen all the time).
but who's going to use your code like somehow everybody thinks that you open source and suddenly there's this magical "thriving community" around it... i've made over 200 packages over the years do you think somebody uses them except for me? maybe 1-2 people might use a package but most downloads come from a node package around another software to work with images, and it's what people want not my packages. open source is a game where you need to visit boards etc talk about your stuff get people interested, like pure marketing it is but then why not market your product instead. what saved me a lot of nerves is accepting that i've never been doing coding for open source but for myself. it's just this myth they want to bring upon everyone like open source is the new jesus. if you're doing it for yourself and want to share then do it but don't do MIT go for AGPL. the reason why people choose mit is because it's so easy, you just throw your code out there and i guess it's fine but don't expect like people gonna come up to you and be super grateful like wow many thanks and start using it and you'll all be one happy family. maybe for others it's been better but i haven't made a single friend in open source. you can't even chat to people on github there's only issues. what the hell community are they talking about everywhere. what are you planning to open source anyway.
That's always tricky because sometimes to look the issues, reproducing bugs and review PRs can take some time and investors can think that OS is slowing their company. But when opening some library/framework to community you can have more eyes on code review and different thoughts on your codebase. People will help by asking questions and when thinking about the answers maybe some security issues/qa/docs will be addressed properly. And when you grow up a little bit it's cool to have some open source to show to candidates and prove that you are capable to write extensible and well written code.
From a business perspective, will Open Source help the business ? If yes and you can definitively prove that to the cofounders, then you should make your case. From a business perspective, no one cares whether you do Open Source or not unless it specifically helps the business. I say this as a founder who is also a developer and loves Open Source.
Startups don't have a lot of time to experiment with "nice to have" things. If Open Source is not the primary driver of revenue, scale and sustainability for the startup, I would forget about it for now. Perhaps once you are more matured as a company, you can then may be Open Source some smaller component to see if it gives you an additional benefit.