Skip to Content

Prepare your business to leverage the potential of open source

5 Aug 2022

What comes into your mind if you think about open – source software (OSS)?

Depending on your history in the IT industry, the answer might be very different – ranging from “I won’t trust my business to fuzzy stuff that people plug together in their free time” to “paid software is overpriced stuff, I only trust OSS.”

Now, you might be upset by the fact that I mixed OSS and paid vs. free software in one sentence. And you are totally right – OSS is about licensing and your access to the source code or even “freedom,” and not about a pricing model. In fact, in my opinion there are very good reasons to pay for OSS.

In this post I will share my experience of over 15 years in software development and software architecture using OSS.

What is open source?

According to Gartner, “Open source describes software that comes with permission to use, copy and distribute, either as is or with modifications, and that may be offered either free or with a charge. The source code must be made available. Open-source software may be developed in a collaborative public manner.”

Important for OSS are several direct and indirect characteristics:

  • Community
    • Open-source solutions geared toward the enterprise often have thriving communities around them, bound by a common drive to support and improve a solution that both the enterprise and the community benefit from (and believe in).
  • Transparency
    • Open-source code means that all have full visibility into the code base, as well as all discussions about how the community develops features and addresses bugs.
  • Fast patching
    • As there are “more eyes on it,” the bugs are identified and fixed quickly. You can even do it yourself.
  • Trust
    • As it is open and can easily be vetted by the community trust will be high
  • Avoid vendor lock-in
    • OSS gives you the freedom of choice. You may use and adopt products independently of any vendor.

Your IT is running on open source

Linux is probably one of the most famous OSS projects. On top of that, some of the most discussed topics in the IT industry are data, AI, and cloud. If you have a look at the technologies that drive these topics, you will find out that many are famous OSS projects, like Spark, Cassandra or Kafka for data, TensorFlow for AI, and a myriad of OSS technologies for cloud, with Kubernetes being one of the most famous of these. If you look further, you might stumble upon the Cloud Native Computing Foundation, which lists over 120 open-source projects and has over 800 members. So, you can clearly see that your business is already “running on open source” or will be in the near future.

Why open source?

Open source became a huge topic in recent years in the enterprise IT industry. Many traditional “closed source companies” invested in OSS, for example Microsoft, which bought for USD 7.5 billion in stock. Much of the world’s software infrastructure is now based on open-source software. Applications and software engineering leaders should use this hype cycle to track innovations that facilitate the use of, or are powered by, open-source software. According to a Gartner survey from 2021, 75% of successful digital businesses used cloud-native OSS stacks and OSS-powered cloud services to build their digital platforms. In 2020, 60 million new OSS repositories were created on GitHub by 56 million developers on the platform. The COVID-19 pandemic has driven renewed interest in OSS, primarily in search of cost-cutting strategies. While OSS reduces licensing fees, it doesn’t always reduce total cost of ownership because support subscriptions are often comparable in price to license subscriptions. Organizations that opt out of support subscriptions must bear the risks and costs of self-support. Strategic planning assumptions from Gartner predict that through 2025 more than 70% of enterprises will increase their IT spending on open-source software, compared with their current IT spending. According to Gartner, additionally, software as a service will become the preferred consumption model for OSS due to its ability to deliver better operational simplicity, security, and scalability Capgemini itself also invested in OSS, for example with its own OSS project devonfw and through its contributions to Drupal. In the next sections, I will expand on some reasons why OSS is so well known and important.


During my career in the IT industry, I worked a lot with closed- and open-source products and vendors. And working with vendors of OSS products often felt much easier compared to those focusing on closed source products. Maybe it is the culture of openness, sharing, and trust which drives the way of working of open-source companies which I like better.

There are also some practical reasons why working with OSS is often more efficient in IT projects. Using an OSS product during development often reduces hassle with procurement and license management. Closed source vendors sometimes offer demo versions, but often you must make a request first, giving your contact details, and get constantly contacted afterwards. Just hitting the download button for a full featured version and full access to the documentation is much more convenient. When it comes to a problem with a product, having the source code available is a great help in many situations, whether you are hunting for a bug or something just doesn’t work as expected. Just to be able to see (e.g., in a debugger) what is really going on helped me more than once in the recent years. For sure sometimes it is more efficient to contact the vendor (or some other expert) for a problem with a product, but that is also possible for OSS. So, with OSS you get more options to help yourself.


The availability of the source code allows OSS to be ported to many different hardware platforms. In some cases, there is a very passionate community which ports OSS to many different hardware platforms. Even if it is not very “enterprise,” the success of “Doom ports” shows this very impressively. After the computer game “Doom” was made open source, many groups of people tried to run it on each and every hardware platform they could find. Today, “Doom” even runs on TI-84 calculators. For sure I don’t expect too many advantages for enterprise environments from that, but it clearly demonstrates the concept. From an enterprise point of view, portability is also very relevant. Open source allows you to port required tools, libraries, and other products to specialized hardware platforms and leverage their benefits. Being able to use (battery) optimized IoT hardware and not having to develop the software from scratch but having it built on well-proven OSS could be a huge advantage. Linux is probably the most famous example for portable OSS. I think a huge driver of its success is its availability on so many platforms.


Often, clients argue that they need to have support for a product and use this as an argument against open source. For sure for many important OSS products support is available. And from my experience, this support is often very high-quality. The reason might be that support is often key for the business models of open-source companies and they are often really good at it. On the other hand, there are OSS products with no dedicated support available. I would not say that you need dedicated support for each and every product; for example, when it comes to small developer-oriented libraries the support could be covered by the vendor of the OSS solution or by yourself. But for major building blocks, such as OSS databases, you probably will need support. So, if you want support, you can get it in a good quality!

Attracting talents

For sure there is a war for talents in the IT market. Especially when it comes to young professionals, they are used to working with open source. They often used these products during their education or even in private projects. So, those people know OSS products already and love to use them in their early professional lives. When it comes to recruiting, I often noticed that it is a very convincing point to tell candidates that they will work with open source in the company.

Digital sovereignty

“Digital sovereignty” is a term that is mostly used in the public sector, but I think the idea behind it is very relevant for other sectors, too. This refers an organization’s “ability to act independently in the digital world” (see the European Parliament’s “Digital sovereignty for Europe”). You could also call this “avoiding vendor lock-in 2.0.” There are many discussions around what this means on a political dimension, for example for Europe. Looked at in a broader scope in other sectors, it means that you should take measures and develop a strategy to keep control over your data and digital products. OSS could really help you in this area. This strategy is also compatible with cloud native development. You could for instance prefer cloud services that are based on an open-source product to foster sovereignty or store your data in a standardized format or to at least assure that a cloud service provides means to move the data to another service (or vendor) if required.


If you think about OSS, cost is always a big topic. Even if many OSS products are free, you should not overlook that there are many very good open-source products available that are not free, and I heavily recommend to have a close look at these products and pay for them if they meet your requirements. But there is a difference in what you pay for. Closed source products often depend on the usage (e.g., number of CPUs, installed memory, number of installations) and this is very often different for OSS! Often enough you do not pay for the product itself but for support, services, or enterprise features. You have more control over what you pay for and what not; for example licensing the enterprise edition for production and selected testing environments (with support) and using a free version in development and most testing environments. This gives you lower costs and more flexibility. Flexibility is key here since you might create additional testing environments without having to deal with licensing.

How about security?

If you read about open source and security, you will find many people arguing that open source is more secure than closed source. But this is not generally true. One major argument is that open source is more secure because people could look into the source code and find security issues. But this is only true if people really do look into the source code and are capable of evaluating the quality or identifying potential security issues. Often this is not the case. The recent log4shell security disaster is a very good example of this.

So, what to do? First, don’t feel safe because you are using open source. You should for sure take the right measures for your context to improve your security, whether it is for OSS or closed source products. Since this blog post is about OSS and not about security, I would like to highlight here that I’m going to focus on a relatively new approach with OSS regarding security.

In typical software development projects based on open source, there are dozens of different libraries and other products included. So, it is a very good idea to introduce a vulnerability scan into your DevOps pipeline to be aware of these potential issues and take the appropriate measures. Closely coupled to this, I’d like to bring your attention to the so-called software bill of materials (SBOM). SBOMs are becoming more and more popular these days. They are a very good measure to cope with security incidents like log4shell. OWASP provides a standard CycloneDX for SBOMs together with some nice tooling. This standard allows you to list all dependencies of your product, whether it be software libraries or other products, and even SaaS dependencies are supported. The mentioned standard is independent of any programming language. With the standard in place, it becomes feasible to create a central inventory of all of the software components you use. If you were involved in the log4shell incident, you might already guess the huge benefit of this. One of the core problems with this incident was that this library is mostly used under the hood in many products, and finding out which products were affected and which were not was one of the hardest parts.

There are already many tools available around this standard. These tools automatically cover generation for the SBOMs as part of DevOps pipelines and analysis and management of vulnerabilities. Many of those tools are OSS themselves, for example DefectDojo from OWASP.

How to select open source?

Above, I wrote about the benefits of the ease of access to OSS. This ease of access, as in just downloading it, can be dangerous when it is not well managed. Without a product selection strategy or management, there is a high risk of your solutions being built on an uncountable number of components with quality issues, driven by a single developers in their spare time, and including incompatible licenses and other legal pitfalls. Therefore, I suggest to set up a lightweight selection process. The goal of this process is not to fully evaluate (complex) products but to assure a minimum quality for each and every product you use. At least the following criteria should be considered:

Documentation: Is there documentation available for the product? Is the documentation detailed enough? Is it up-to-date?

Availability of support: What support is available? This covers commercial and community support, e.g., discussion groups. How active are these groups and how many companies offer support at what costs?

Licensing: There are a couple of OSS licenses with different rights and obligations. A special thing are so-called copy-left or viral licenses, e.g. GPL. These licenses force you to put “derived” works under the same license as the original work. Together with other obligations, this might force you to put your product under the same open-source license as the component you use. Key here is the judgement on whether you produced a derived work or not. In my experience, solutions running on top of Linux (which is GPL), for example, are not a derived work. But prepacking a specially modified Linux together with your solution has high chances to be counted as derived work. You also must be aware that because of this some OSS licenses are not compatible; products with these licenses must not be combined. Luckily, there are OSS tools available that automatically detect these kinds of licensing issues and give you transparency.

Future-proofness: What is the expected lifecycle of the component? Is it already end-of-life? There often is no clear answer to that. But there are indicators that allow you to make a qualitative assumption. How many contributions from how many contributors does the project have? How many releases were there in the last couple of months? How active is the community around the products, and how big is this community? How large and stable is the user base?


There are many very innovative and battle-proven OSS products available that will be beneficial for your business. But do not mix up open source with for free. There are many very good companies in OSS which offer great services that are really worth paying for. While OSS has many inherent advantages, like openness, attractiveness for young talents, etc. there are also a few things to bear in mind. So, create an open-source strategy for your business and select OSS products carefully. This strategy should include at least the following safeguards against possible pitfalls with open source:

  • A suitable selection process for OSS products, which prevents selecting OSS with less quality and less future-proofness
  • A license management which prevents unwanted obligations from OSS licenses
  • Security, since open source does not guarantee more or less security compared to closed source.

About author

Simon Spielmann

Solutioning Head Cloud Custom Applications, Capgemini
Simon has nearly 20 years of experience in the software development industry, and he is mainly focusing on the design of the software architecture for large software systems in a security-critical environment. He is developing an innovative solution concepts, advise on the selection of suitable products and support architecture management. He also manages Capgemini agile development teams in the role of an architect.