Why You Should Go Open-Source

In this article, I would like to analyze ideas and misconceptions floating around when it comes to open-source software and provide arguments on why an open-source strategy can be a success story.

So, if you are a developer trying to convince your manager or you are the one who is currently exploring and deciding on the open-source strategy, this article is for you. It is based on the experience we had with our open-source project iceoryx, which led to the founding of our open-source company exkide.

Discuss the article on Reddit

What Is iceoryx

iceoryx is a zero-copy inter-process communication framework written in C++/Rust. With ekxide, we founded a company that backs up the open-source project, provides commercial support and products around it, and supports the community with new features, bug fixes, and tooling.

Let's Ask The Business Team To Open-Source Our Software

But What About Our Unique Selling Point?

One counterargument often used is, "When we open-source our product, we give away one unique selling point!". When you encounter this statement, it is worth digging deeper and understanding what unique thing the business people are trying to sell.

In our case, it is not zero-copy inter-process communication by itself. This is necessary for most users in our domain, and there are already multiple custom closed-source solutions. If you would like to develop software for a car, a robot, or a medical device, you most likely require fast inter-process communication to deploy a robust and efficient system.

What makes our product unique is the upcoming support for zero-copy communication on GPUs or across hypervisor partitions. So, a strategy could be to open-source the core functionality, design and architecture that supports closed-source extensions, and promote them. This is not a new idea! It is the Open-core model.

But Wouldn't It Help Our Competitors?

When a company open-sources software, other competitors can get inspired by it, use it, or fork and extend it. So they save time, create their product faster, and save money at the same time. But this is only partially true. If you develop the product, you have the expertise and the innovation on your side. Couple this with a well-defined Open-Core business strategy, and you will be ahead. The underlying issue may be something else. Question yourself, Do you rather want to succeed, or do you want your competitors to fail? If you want to succeed, what is the problem when your competitors also succeed?

If your software is well received and others start using it, you may even save money since there is a common interest in solving bugs and introducing new improvements and features. This may lead to cooperation between you and the community or they start contributing and you get new features for free. This is how iceoryx got FreeRTOS platform support - thank you, NXP Semiconductors, for the contribution.

However, the most significant benefits are that you can define the ecosystem around your open-source software, grow horizontally, and gain customers in domains you have never thought of. When you invest time in the community, you also have access to a talent pool that may support you with bug fixes and features where you lack some expertise. Big thanks goes to our community for helping with the bazel support in iceoryx where we still have some knowledge gaps.

But Wouldn't It Slow Down Development?

This argument comes more from the developer's side. The misconception is that the maintenance overhead with additional testing, documentation, and a clean code base is not worth the effort. It is required for the community to consider your project, but it is also vital for yourself. The proof-of-concept phase may be a bit slower, but as soon as this goes into production, documentation, clean code base, and test concept are not optional. Leaving out documentation, tests and code clean-ups will produce faster results only in a brief period. After that, every additional feature will be more expensive and time-consuming just because of technical debt.

With poor tests, how are you sure the new features work and do not break existing ones? With poor documentation, how can other developers (including your future self) use the software as intended and continue developing it further?

Isn't it something we all strive for as developers? Create something that is used also in the future and continues evolving. To create something that matters and persists. If you are confident that your problem is a problem worth solving, others may think the same. When the solution is closed-source, they will develop their custom solution, and your code may end up lost in some big mono-repo.

I believe the benefits you gain from open-sourcing outweigh the extra effort of additional documentation and community work. Not only does the community benefit from it, but so do you too - when others will later continue the work and ideas you have started or stumble across all the edge cases you never thought of.

But How To Sell This To Our Investors?

If you are working in a startup, your investors expect you to increase the value of your startup. How can this be achieved when providing software as open-source? So the question is: why offer software as open source? Let's explore this in more detail.

Why Offer Software As Open Source

Set The Standard

Let's go back to the unique selling point. When your software is the only open-source software that solves a particular problem, you can set the standard. When others provide proprietary solutions, they have to compete with you, and they need to offer more advanced features worth the extra costs one has to pay for their product - depending on your open-source license and business model. Furthermore, with your solution, you can steer the ecosystem and define the architecture and how your business will evolve around it.

When your project succeeds and reaches a critical mass, companies will require their supplier to be compatible with your solution to simplify their software stack. By offering an open-source solution, your product eliminates the need for a closed-source solution, and you have the advantage of knowing your solution in great detail.

Horizontal Growth

When your project flourishes, it will be used by users from different domains with use cases you never thought of in the first place. We were surprised when we noticed that fintech libraries, desktop applications, or computer-aided medical procedures are using iceoryx, which was initially developed for the embedded safety-certified automotive market.

These new use cases also moved the frontier of what we strive for with iceoryx. Support for new operating systems was requested, and they wanted to communicate via low-latency network protocols or become much more dynamic than the typical static safety-critical automotive use case. Now, we will work on language bindings for C#, Lua, Python, or Java, all things you usually do not encounter in a car but on a desktop machine. So, after some time, we gained users we didn't even think of when we started the project.

When starting a new project with a proof-of-concept phase, developers began to use our software. Since it is open source with a permissive license (Apache 2.0), they did not have to ask their manager for an evaluation license but could just use it.

When their product matured enough, they required our advanced features. But sometimes some pieces were missing, and who do you call when you have problems with the software you are using - the company behind it! In this case exkide.

Our core use case benefits from this as well. We also use those new tools and features in our workday life. Windows is not running in cars, but it is nice to have the freedom to develop on any machine you want - from Windows, macOS, Linux to FreeBSD - thanks to the platform support community members like ecal requested.

Increase Your Talentpool

Getting talented developers is a challenge many companies are facing, especially when your particular field requires detailed domain knowledge. The onboarding of new hires can be time-consuming, and the lack of experience in a specialized field may slow down the development process.

When building up a community that is welcoming and fun to interact with, you create a talent pool at your fingertips. You observe who is shining with their contributions, and you have the advantage that they do not need the entire onboarding process since they already know the product. We also received applications just because people wanted to work with us on our iceoryx project.

Even when employees leave the company, they stick around the project and are often supportive when you are in need. A good community has your back when it comes to an urgent bug fix or support in a feature where you lack the expertise.

Special Thanks

I want to conclude the article by saying thank you to the company that gave us a cozy place to start our development of iceoryx and supported us when we open-sourced our project, Robert Bosch GmbH.

In the last 3 years, Apex.AI has been our home. The atmosphere there did let us thrive and brought more features into iceoryx.

Without them, iceoryx wouldn't have been the success story it is today.

The primary goal of our new company ekxide is to focus now entirely on iceoryx, boost feature development further, and provide commercial support, training, and custom feature development for our community, users, and customers.