Here at commercetools, we not only use open-source software in many of our projects, but we also build and maintain our own open-source repositories. At the same time, in the complicated world of SaaS, it’s not always clear whether building such software can be beneficial for the business. In this blog post, I outline some of the things I consider when making decisions about whether something we develop should be made/kept open-source or not.
What is open source?
There are a few theories of how the term “open-source” first appeared. My favorite one proposes that the term was coined during World War II by the Foreign Broadcast Information Service (which was a part of the CIA). They were calling the public data that they were collecting and analyzing by the name of “open-source intelligence.” A great example of their work was using the prices of oranges in Paris as an indicator of whether railroad bridges had been bombed successfully amid war times.
Now, fast-forward to the 21st century. Let’s take a look at the modern definition of the term “open-source” in the domain of software development. According to opensource.org, the official website of the Open Source Initiative, software can be called open-source only if it complies with the following criteria:
1. Free redistribution
2. (Disclosed) source code
3. (Allowing) derived works
4. Integrity of the author’s source code
5. No discrimination against persons or groups
6. No discrimination against fields of endeavor
7. (Automatic) distribution of license
8. License must not be specific to a product
9. License must not restrict other software
10. License must be technology-neutral
There are many companies that are trying to follow the above-mentioned rules and develop their own open-source solutions. Here are a few things to help you decide whether open-sourcing your SaaS code would be a good idea or not.
Why you should open-source your codebase
1. Help from the open-source community
Let’s start with the most obvious benefit. External developers can introduce new changes, help to identify bugs in your codebase and improve the functionality of open-source software. It can be surprising for some people, but many developers voluntarily contribute to open-source projects. There could be various reasons for this: Introducing the feature that they’re missing, helping the project to grow, and even learning how to code by going through the review process and getting different insights from the community that is taking care of the project.
2. Direct feedback
Open-source product development is driven by community requests. It happens way too often that product teams, especially in large companies, don't have direct access to the users of the software that they are developing. There is no such problem when it comes to open-source software. Many teams leverage features like Issues and Discussion, available in such hosting services as GitHub. It’s easy to collect and analyze feedback collected through these tools.
3. Channel customers through your open-source solution
The open-source repository can serve as an extra touchpoint for buyer groups with a technical background. It allows displaying the technical stack, know-how and commitment of the engineering teams. On top of that, it can show the transparency of the company and its readiness to receive and work with feedback.
4. A powerful distribution channel
The open-source community lives in many discussion boards, subreddits, forums and repositories. Developers who are contributing to the open-source write blogs combine lists of best libraries and “awesome” solutions. This can help to increase your online presence and build a reputation as a technically strong and open company.
5. Hiring and promoting the company among engineers
There are multiple ways engineers can find out about a tech company. Learning about it through a great open-source project is one of the best ways, from my point of view. It can give an honest overview of the software that the company is building, how they’re doing it and who are the people that are working there. Many companies try to make sure they have a link to a list of open positions in their main projects.
Why you shouldn’t open-source your codebase
One of the biggest issues that people have with posting their code online is a security concern, especially when it comes to enterprise software. The code that is available for the public shouldn’t include any private information, whether it is external or internal. Moreover, exposing the code means exposing the bad parts, as well as the good parts of the software. The publisher should be aware that the potential security flaws might be exploited, harming the well-being of the product and the reputation of the company.
2. When warranties matter
Open-source licenses are typically designed in a way that the team/owner of the repository provides the software “as is,” without a warranty of any kind. This can be a blocker for some of the potential customers who require all solutions they use to be covered by specific contractual agreements.
3. Your source code and roadmap are visible to competitors
By design, open source means that anyone, including your competition, can see parts of your product strategy and use this to their advantage. They will be able to see what you build and release, and how exactly you’re doing it. Licensing questions often start to arise here as well. For instance, it happens sometimes that companies fork existing open-source projects and build their own SaaS or PaaS offerings around them.
4. Product development is highly influenced by the community
Listening to the community is a big part of being open-source. At the same time, it’s not necessarily what you need to do in some cases. In the complex world of business, there are various stakeholders whose opinions could be more important at times. On the other hand, disregarding the requests of the community can play a negative role when it comes to open-source software and the reputation of the company which maintains it.
5. No way back
It is generally assumed that the most used open-source licenses like MIT or Apache 2.0 are irrevocable. Hence, it can be quite challenging to make software that was once open-sourced proprietary. Although there are plenty of examples of making a profit from open-source software, GitLab being one of the most famous ones, the license of the software always remains untouched in such cases.
What we do at commercetools
commercetools is a very active organization when it comes to building open-source software and participating in the open-source community. We always try to find a balance between proprietary and freely available software. Our engineers build open-source solutions, as well as contribute to external open-source projects.
Hence, going to our GitHub repository, one can find plenty of projects. Here are a few:
UI Kit — a component library for building applications following commercetools branding and UX guidelines that I am proudly working on.
commercetools-adyen-integration that provides an integration between the commercetools and Adyen payment service provider based on the concept of Adyen Web Components.
Enzyme extensions cover enzyme extensions to test shallowly rendered enzyme wrappers.
So you ask yourself, to open-source or not to open-source? Our answer to this question is yes. In a composable SaaS solution, there should be a place for both approaches. It makes sense when some parts of the product have to be kept internal for security, legal and competitive reasons. Whereas other parts, on the contrary, will only benefit from being exposed to the community of engineers who are motivated to provide honest feedback and further improve the solution. At the end of the day, this should be a conscious decision that has to be driven by the insights and vision for a certain product (or part of the product) in order to make a real contribution.
Does this sound interesting? Learn more about commerce possibilities for IT and see for yourself how open-source can be an integral part of a modern SaaS offering in the eCommerce domain.