Moving towards open source
Journey of a SaaS company
Like all companies, we at integrationmadeeasy.com, use a lot of open source. These are languages (JavaScript, Ruby, Java), frameworks (React, Spring, Camel) and lots of libraries. We are definitely not the only one. Open source software is driving most cloud companies.
On the shoulders of giants
The power of open source is that you build on top of each other's work. When creating a new project, it’s almost 100% that you will use multiple other open source projects. You are standing on the shoulders of giants.
As a startup, there is no other way than to use open source to build a product.
Our company uses open source, but the product we build is not open source. This is both logical and illogical.
It’s logical, because open source is not a business model. It can only be part of a business model. For example, Red Hat made it the core of its business. However, that model is not easily replicated. Red Hat started from the beginning as an open source company and has now the trust and reputation to put it into profit.
As integrationmadeeasy.com uses a subscription based model, it was not directly obvious to do anything with open source. So we didn’t have any strategy on open source at all.
On the other hand, this was illogical. We use tons of open source in our product. And open source only works when developers build on each other's work. You can’t only take, without giving.
Since we are now moving from a startup to a scale-up, we decide that this a good time to start giving and develop an open source strategy. We strongly believe that in the long run, open source and collaboration is the way to build a solid business.
An open source strategy is however more than just to put a bunch of code online. Firstly it needs to be an enhancement of the business model, not working against it, secondly everyone in management needs to agree with it, and lastly we need to have a plan. In this blog, I want to share our experience so far and how we implement the strategy step-by-step.
Our 7-step plan
1. Alignment
Before you start to do anything, first everyone needs to agree that a strategy is needed and agree on the follow-up steps. From the developer perspective, working with open source libraries and frameworks, is more obvious than from other parts of the company.
They had questions like how does it impact the business model, how does it influence intellectual property and how does it affect security. It’s good to go through the advantages and disadvantages of open source and agree on the steps to take. After two or three discussions, we were ready to take the next step.
2. Dependencies
The very first thing we did was a scan on all the libraries and software that we were using. We knew that most of it already was open source, but we still had some libraries that were not. For example, we moved from the proprietary jsPlump to React flow. In our latest release, all libraries, frameworks, and software (like databases) are open source.
3. License
The next step was to think under which license we want to open source our own code. There are various options like BSD, GPL and Apache you can choose. We decided at the end to go with the Apache License.
Why did we stick with Apache? Most of the frameworks we are using, like Apache Camel and Apache ActiveMQ are already licensed under the Apache License. The license is also good compatible with other open-source licenses, making it easier to combine and integrate Apache-licensed software with projects under different licenses. Another reason is that it is a permissive license that allows users to use, modify, and distribute the software for any purpose, whether it’s for personal, commercial, or non-commercial use. Developer and business friendly thus.
4. Organization
To not scatter the different repositories all over the place or that they are part of some developer's personal GitHub account, we created a new organization on GitHub and a special label to put all our open source efforts on. This was placed under the name Assimbly (from to assemble and A-self-service-integration-module).
Assimbly has its own webpage and own GitHub that are not related and independent of the company. This makes it in our view easier for other individuals or companies to take part in the project. We already have contributors that are outside the company. In the future, we may establish a separate board (or when it’s really got big) join the Apache Foundation.
5. Open source repositories
I already had several open source projects on my personal GitHub. The company had all repositories in a private GitHub. We moved around 14 repositories to the new organization and started working from that moment publicly on GitHub. There is no shadow repository, this is also the code we run in production.
6. Collaboration and contribute
Another step that we largely simultaneously implemented is to collaborate and contribute to the open source software that we are using. It doesn’t mean immediately that we are code committers on all those projects, but at least we try to help the key projects with documentation, report bugs, help others, write blogs and so on.
For some developers this was already what they were doing, for others it was a bit more scary to join open source communities. This is still an issue that needs to grow, but I do think that it has been fruitful. I must honestly say that communities like Apache Camel, ActiveMQ, JHipster, and Spring has been very kind and helpful so far.
7. Building a community
The dream we have is that eventually a community is building around the code we open-sourced. This last step may well be the most difficult thing of going open source. Other developers and companies firstly need to find the project. Secondly, they need to find it useful. And thirdly, they need to trust the project and feeling comfortable to contribute to it. This is an area where we need to learn and grow over the coming years.
Some last thoughts
We surely feel we are good under way, but we continue to evaluate the open source strategy and decide what will be our next step. This may also mean that something in a step will not be fully open source. For example, we want to move to Kubernetes, which is of course open source, but we need to evaluate the way to get there.
Going open source is thus not always so straightforward or can be even scary sometimes, but I hope that the insight in our strategy may help others or at least understand our choices. If you have any tips or want to share your experience, please leave a comment.
