10

Commercialization of Open Source

In Chapter 1, The Whats and Whys of Open Source, we talked about how open source was the realm of hackers and counter-culture movements and considered by many as the antithesis of commercial software. This is the case due to the actions of some prominent commercial software vendors in response to open source. Microsoft was known to be a primary opponent to open source back in the 1990s and early 2000s with the internal stance of “embrace and extend,” which was a tactic used with other competitive software vendors to gain dominance over a market. Using that same strategy with open source generally isn’t successful, as with its “scratch-your-own-itch” model, open source projects cover spaces that might not be profitable for a commercial product to exist in. Or many times, it’s the ability to view and modify the source code itself that is valuable, and that’s something commercial software generally can’t provide.

I will say that corporate involvement in open source has come a long way, with these organizations taking a much more responsible and respective approach as they work with open source projects and communities. In my days maintaining the PHP Windows Installer, Microsoft approached me, asking me to fix a few issues to make the installer work better with Windows Server 2003 (yes, I’m dating myself). Microsoft set me up with a copy of Windows Server 2003 for testing and development, and as a token of gratitude not only recognized me publically for my contributions but also sent me a Microsoft Zune as a gift. This is something they surely didn’t need to do, but they wanted to show goodwill for the work I did.

While open source software is free to use in compliance with the license it is released under, a successful project will see commercial usage. In this chapter, we will explore how a project could be used commercially, and how a project can be best set up for commercial use. We’ll cover the following topics:

• The importance and value of an open source project being used commercially
• Commercialization models for open source
• Setting your project up for commercial usage

Let’s start by addressing the concerns many in the open source community have when their project is brought into commercial software or delivered commercially.

The importance and value of an open source project being used commercially

As you may recall from both Chapter 1, and Chapter 3 there have been generally two approaches to software licensing: permissive (meaning one that has minimal restrictions on reuse of the code) and copyleft (meaning that the code license has specific restrictions to ensure any derivative works also stay under the same open source license). Copyleft licenses are generally used by projects where taking the project and reselling it commercially is a large concern.

There are some use cases where that is a valid concern, namely in the area of open source software. which is more end user focused, such as a desktop application such as LibreOffice, Inkscape, GIMP, or Firefox. However, that doesn’t mean the software can’t be used commercially as over time, we’ve seen creative ways around this. Examples include offering services and support around the software itself, “open-core” models where commercial add-ons are licensed separately, or “Tivoization,” where source code is made available but significant proprietary hardware and other software is required to leverage the source code modifications. We will dig more into those mechanisms of commercialization in the next few sections.

Is commercial usage ok?

In the introduction to this chapter, I talked about how open source was considered the “antithesis” of commercial software in its early days. Open source software is often lumped together with free and libre software under the term FLOSS, which stands for Free Libre and Open Source Software. If you are familiar with the term libre, you’ll know it is an Italian word for free. There’s a saying in the open source community that open source is “free as in freedom, not free as in beer,” which ties to the root of the word libre being used more to describe freedom versus something of no cost.

If you create an open source project, you are effectively providing the software for no monetary cost (although in the early days of open source before the internet was prevalent, charging a nominal fee for a CD or disk with the software was acceptable; in fact, the GNU Public License specifically addresses and provides permission for this). Even though it is free, the license the code is under provides the terms and guidance to the user of the project on how to use it. While you cannot be discriminatory toward a particular class of users (that is, provide different terms for commercial versus personal usage), the maintainer can choose the degree of responsibilities the user of the project must adhere to. More on these license models was covered in Chapter 3, Open Source License and IP Management.

As shown in Figure 10.1, the sustainability of a project is dependent on its usage and market acceptance. Commercial usage is just like any usage, and whether a company is using it internally or making it part of a product, this validates the project’s value on the market.

I often see sensitivities when companies use the project commercially without giving back in some form, whether this is by adding developers, funding, or other investments. Companies are looked upon as “taking advantage of open source” and “using projects as free labor for commercial gain,” which you will find occurs in open source. While some companies might be predatory in this way, in my experience, many have good intentions and either are new to open source or have trouble knowing how to engage. We will dig more into this topic in the Setting up your project for commercial usage section.

In this section, we saw that commercial usage is OK, and just like any other usage of a project. Commercial usage, like any usage, contributes to a sustainable model for an open source project to exist in. Let’s look at the sustainability cycle in more detail.

The sustainability cycle

There’s a diagram I often use to illustrate how sustainability works in open source projects, which you can see in Figure 10.1:

Figure 10.1 – Projects, Products, and Profits cycle of open source sustainability (https://www.linuxfoundation.jp/blog/2017/09/new-initiatives-to-create-sustainable-open-source-projects-at-the-linux-foundation/) – CC by 3.0

This diagram illustrates the continuous loop an open source project operates in concerning market viability. Let’s look at each piece.

Projects

Projects are simply a collection of software code and also the community itself. Open source communities, as we’ve seen across this entire book, are successful when a strong, collaborative, and diverse group comes together to build technology that they all see as important to them and the work they do. This community can be a combination of corporate employees working on their employer’s behalf, and/or simply individuals that have an interest and a passion for this space.

Products

As a project becomes more and more useful and valuable to the market, the project itself will become productized. Productization could mean several things, from taking the project and selling it as a commercial product, incorporating pieces of the project into a larger commercial product, or offering service and support. These are common areas where a software vendor sees an opportunity to use the project to aid in selling their software.

But another angle of productization is usage, meaning someone takes the project and uses it in one way or another. Perhaps this is a developer that leverages an open source library in something they are building. Or maybe it’s a company using an open source project internally for doing reporting or integration. The very nature of the project being used by others is, in effect, productization, as the project is being consumed just like any other product would be.

Profits

Commercial software vendors release new software all the time to address what they see as the needs of a market. Sometimes, it ends up quite lucrative, where the software catches on and the vendor continues to support and update it over time. Sometimes, it ends up being a flop, and the vendor decides to no longer develop or support the software because it doesn’t make economic sense to them. And over time, markets change and software that today is popular becomes less so due to economic, technological, or other conditions. All of these decisions are driven by economic value or profit.

For this sustainability cycle, profit is the key part that validates the productization of the open source project itself. That economic value can manifest itself in several different ways, such as these:

• Lower cost of research and software development, by not having to write and maintain code that an open source project could provide instead
• Larger addressable market, by adding features and functionality to a project that the current development team doesn’t have the time or expertise for
• Faster time to market, where the development team can leverage one or more open source projects as building blocks for their commercial product rather than having to build them all out themselves

Each of these factors generates an economic value for the commercial software vendor. The same holds for a user of an open source project; the fact that they don’t have to write the same code that exists in an open source project saves them time and money. Looking back on my example of the PiSCSI project in Chapter 1, The Whats and Whys of Open Source, (https://github.com/PiSCSI/piscsi), the existence of that project for me as I was restoring my Macintosh IIsi meant that I didn’t need to track down expensive, slow, and hard-to-find SCSI hard drives and network cards, and instead could use an off-the-shelf Raspberry Pi Zero with an extra header board to emulate both. The savings to me was both time and money, with an additional value of the flexibility provided, all of which created economic value and represented profit.

What’s important to complete the cycle is investing that profit back into the project. This could mean simply community participation and providing feedback. It could also be adding development support to the project by a company assigning developers to work on the project, sponsoring infrastructure, or marketing support, or in the case of an individual, that person helping maintain the project. It could also mean direct financial support to the project, a topic we will dig into as we discuss setting up your project for commercial usage. Either way, investing back into a project that has created economic value means it can continue to grow and function over time.

There are several ways for projects to be commercialized; let’s look at those now.

Commercialization models for open source

As open source projects can have many forms, from code snippets to fully featured applications, the models of commercialization are different. Additionally, the license you choose impacts commercialization, as leveraging code under more copyleft licenses adds more complexities than code under permissive licenses.

The commercial model of open source has evolved over the years, but we generally see one of three models. Let’s look at them now.

Dependency or component of a larger commercial software package

The first model involves using open source software as a dependency or component of a larger commercial software package. This is probably the most common example of open source software in commercial usage, and often the one most people don’t see. Figure 10.2 illustrates what the typical application stack looks like concerning open source:

Figure 10.2 – Breakdown of a typical application and where open source is used

Modern applications tend to be built on a framework of some sort, such as the Linux, Apache, PHP, MySQL (LAMP) stack, Bootstrap.js, or some other tool or development platform. The majority of these applications are built in open source, even ones developed by commercial vendors, as this aids in being able to handle broader use cases. At the top level, you see open source used in solving common problems, whether that would be using a SAML library to support authentication or perhaps a base theme for a WordPress or Jekyll website. If you look at the total lines of code, you generally see anywhere from 80-90% of the code base being open source, which most people don’t realize. This especially comes to light when there are large security vulnerabilities in these base components, as companies are assessing how they are affected and how to upgrade those components to secure versions.

One consideration when a dependency or component is used as part of a larger commercial software package is to ensure that the proper attributions are kept in place in the open source code. This includes both license file headers in the source code, but also a more formal software bill of materials (also known as SBOM) that details the components and the licenses used in the product. If your commercial product uses a common tool for managing third-party dependencies such as PyPi for Python, this is usually easy to track down. If not, it can be a bit more manual. Further, using Software Package Data Exchange® (SPDX®) short-form license identifiers makes tools such as FOSSology that do license scanning produce more accurate results – learn more about this at https://spdx.org.

Let’s look at the next example of how an open source project is commercialized: through service and support.

Service and support

Service and support was one of the earliest models in open source commercialization, popularized by Red Hat with its Red Hat Linux Enterprise support programs. The recognition was that open source software was essentially free to use, but as with all software, end users run into problems or have issues and need someone that can help. For companies, having problems with the software that their business relies on can be a huge problem, and having the proverbial “throat to choke” gives them a bit of peace of mind in using the software.

Service and support can mean a few different things:

• A traditional call center or support center where people can talk to someone about a problem they are having, get help on how to solve it, or a workaround
• Help with installing or implementing the open source software itself, such as setting up the server or building customizations
• Training and education, whether instructor-led or virtual training, or perhaps a book publisher such as Packt having a book on using a particular open source project

The biggest challenge in this model is also its greatest appeal – a low barrier to entry. This has been a space where many companies have set up businesses around supporting open source software. While this is often done with the best intentions, it also creates a bit of confusion. Think of this like when you might need a plumber to fix a drain or sink in your house; you can go through online resources to find several ones nearby, or perhaps chat with friends and family, but outside of rating systems, it’s often hard to differentiate. For open source projects, you see the same model, where someone sets up a business saying “Provides commercial support for project X,” but what that looks like can vary. The challenge here is that by using the brand of the project, it can provide a negative view of the project itself if that vendor isn’t a good one, even though that vendor is likely not part of the project. We will talk about the use of vendor and conformance programs in the next section, where we will look at strategies to help.

Open Core

We talked about the Open Core model in Chapter 2, What Makes a Good Open Source Project?, along with the challenges of using this model. Nonetheless, it is still a common and valid commercialization strategy. I won’t spend too much time on the model here as it was covered previously.

A somewhat analogous model to open core is where the open source might be a base framework, and there are several commercial extensions available that can connect or integrate with it. We’ve seen this in Linux with many specialty device drivers kept under a commercial license, but designed to work with Linux. We’ve also seen it in ecosystems such as Hadoop, where vendors would build integrations from data visualization tools to Hadoop to leverage data stored in those data lakes.

With an understanding of the various business models possible, let’s look at how to best set up your project for commercial usage.

Setting your project up for commercial usage

Creating a way for commercial vendors to use and leverage your project invites more usage, often in ways you might not have imagined before. It also opens up the possibility of new contributors and maintainers to help support and drive your project, helping improve how things work and the quality of the code base itself.

There are some things we should consider for a project to ensure that commercial usage adds value versus creates confusion. Let’s look at them now, starting with branding and IP management.

Branding and IP management

As we illustrated at the start of Chapter 3, Open Source License and IP Management, having solid management of your project’s brand and IP is crucial. If you talk with a lawyer that specializes in intellectual property, they will likely stress how ensuring your project’s brand is being used as intended is quite crucial to helping users understand the project.

We covered branding and IP management extensively in Chapter 3, Open Source License and IP Management, and encourage you to reference that chapter for more specific information on that topic. As it relates to commercial usage, there are two considerations to keep in mind:

• If you have a popular project, vendors will want to reference the name and/or brand of the project as part of their product name. This is an area where a project has to be careful, as it’s very important to separate any commercial products from the project itself. I highly suggest building branding guidelines for your project to help describe the right and wrong way to reference the project or its brand in a commercial product; some examples are as follows:
  • Open Mainframe Project Brand Guidelines (https://www.openmainframeproject.org/branding-guidelines)
  • HyperLedger Branding Guidelines (https://www.hyperledger.org/wp-content/uploads/2017/03/hyperledger_trademark_usage_guidelines_031417.pdf)
  • Eclipse Branding guidelines (https://www.eclipse.org/legal/documents/eclipse_foundation_branding_guidelines.pdf)
• Depending on the license used, it’s important that vendors properly attribute the use of the project to their product. This can be a hard one to police, but providing guidance on how to best do this usually will mean the vendor will comply.

Often, vendors are quite appreciative of the project community and want to work with them. Just like in Chapter 6, Making Your Project Feel Welcoming, creating ways to make your project welcoming and appreciative of vendors shows goodwill toward them too. Let’s look at some ideas for this.

Recognition and conformance programs

Recognizing vendors being users of the project not only shows goodwill towards them but also shows validation of the open source project itself. If you have experience in commercial software product marketing, you know that one of the biggest sales aids for your product is the logo of a company or testimonial of a user that has used your software. Open source is no different, and many projects will leverage this to help them grow.

That being said, it’s important to have mechanisms to make it easy for commercial users to both be recognized for using the project, as well as using the project in line with the way the maintainers and the larger community would expect. There are different ways to best do this, depending on how the project is intended to be used.

If the open source project is primarily meant to be consumed and used, a simple user recognition program is a great way to call out users of the project. This can take several different forms:

• The simplest way is for the project to have an ADOPTERS file in its code repository. Maintainers can add users of the project to this file (with their permission, of course), or better yet, end users can add themselves to the ADOPTERS file. The latter method is preferred, as the user doing a pull request to add themselves ensures explicit permission has been granted to reference the user.
• If you have users that are not only willing to state they are a user but are willing to provide an endorsement, then consider a user testimonial or case study program. If you are from a product marketing background, this might feel daunting or like overkill, but in reality, a good case study is pretty simple in form: what problem did the user have, why did they choose the project, how has the project solved their problem, and what plans do they have in the future? And if it’s just a testimonial, it’s a simple quote from the given user. If you use GitHub or GitLab for your project management, you can set up a pull request template or issue template to collect them, and again leverage an ADOPTERS file or something similar. If your project has a formal web page, then add them there.

If the project is designed to be a framework where users could build on the project or something that could be integrated into a larger software application to provide interoperability, then one possibility is to use a conformance program. We talked about the usage of conformance programs in Chapter 1 and Chapter 3, but building on those chapters, conformance programs are simply a way for a project to create a neutral mechanism for recognizing vendor solutions related to an open source project.

Establishing a conformance program often takes the form of a legal contract between the project and the specific vendor. Here are the general steps for establishing such a program:

1. First, determine what conformance looks like. Often, this is API compatibility between different implementations, but could also be applications that integrate into a particular endpoint or part of the project in a standard way. Support and service vendors could also have a conformance program, where the project might want to determine if a vendor has the competence to properly support users of the project.
2. Once you have determined what conformance looks like, you can start to formally define the requirements. These should be driven by the project community itself openly and transparently, as conformance programs intend to be vendor-neutral. There are generally two parts to the requirements:
   • One is the technical part, where the community can define what the implementation or application needs to do to be conformant, or in the case of support or service conformance, what the vendor’s capabilities must be. It’s best to make these requirements both objective (meaning you can easily determine if it is fulfilled, and not left up to an opinion or personal preference) and preferably with some sort of battery of tests that can be run against the software. If there aren’t tests, a simple checklist can suffice.
   • Second is the business requirements, which usually means some sort of funding for the project and obligations of the vendor to maintain the technical requirements for a given period.
3. Finally, a project needs to set up how to operationally process conformance applications. A project needs to be careful here, as competitors to the vendor submitting conformance might be part of the project leadership. Here, having an independent third-party (such as a project staff member) process applications is preferred, and these applications can be reviewed confidentially to avoid any concerns of vendor influence over accepting conformance applications. The project will also need to set up a place to list conformance applications and implementations, as well as logos and branding marks for the vendor to use to showcase their conformance.

Conformance programs are great ways to generate funding for the project, as we all know running an open source project has some costs involved with it. As we chatted about in Chapter 5, Governance and Hosting Models, using a conformance program is a great way to drive financial support for your open source project. This is because it ties back the support to a tangible value for the company, that being brand and market recognition for the application or implementation in line with the project itself. This makes it easier for companies to find the budget for funding from product marketing versus development, as the former tends to have more flexibility and be tied to profit centers in the business, whereas development costs are tied to cost centers.

Summary

In this chapter, we looked at how the commercialization of open source projects works while building on the concepts started in Chapter 3, as well as Chapter 5. We saw how sustainability in open source is tied to productization, whether that be by individual users or corporations/vendors. We then saw common models of commercialization for open source projects. Finally, we looked at some ways to best set your project up for commercial usage.

Commercialization of open source is still quite controversial, as it is sometimes viewed that companies take advantage of open source projects and open source developers for corporate gain. But I can first-hand say that this is an exception rather than the norm; look back to the story I led off with in this chapter in my work with Microsoft around the PHP Windows Installer. The work I did ended up being an opportunity for me to grow my career as an open source developer. While I didn’t get a job at Microsoft, it did open up other opportunities for me. In the next chapter, I’ll talk about my story more, and share some ideas on how open source can jumpstart your career as well.