The Benefits of Open Source and the Risks of Open Core

Chapter 4. Distinguishing Open Core from Other Trends

We have made some claims fraught with controversy in the previous chapters. We have pointed out that the meaning of the term open core is unclear and that both vendors and customers can misinterpret what they are getting. In this chapter, we distinguish open core from corporate or community practices that might seem confusingly similar.

Red Hat

Red Hat is the most financially successful company based on open source, having been acquired by IBM for $34 billion in 2019. Many people deny that Red Hat is truly an open source company. We argue that it has always been and remains one.

Red Hat’s flagship product, Red Hat Enterprise Linux (RHEL), remains 100% open source. Conveniences such as easy installation or integration of tools into a dashboard do not impinge on that status, in our opinion. When you run RHEL, you are running a distribution of GNU/Linux, plain and simple.

One of the authors of this report (Andy) does freelance work for Red Hat and can testify to the enormous contributions that developers there are making to “upstream” open source projects. Other companies, of course, make big contributions too, but Red Hat’s strategy does not involve extending the projects with proprietary software. They are very up front about basing their cloud services on open source components.

As a case study, Red Hat is unique. That’s because they focus on the operating system, a very complex and fussy piece of software with many compiler and hardware interactions and external dependencies. Customers have been willing to pay Red Hat to install and maintain GNU/Linux, whereas one might not find customers willing to pay for similar services in other kinds of software. Red Hat’s original Linux strategy has become diluted as it moved “up the stack,” making major investments in Java, the cloud, and other areas. But the strategy seems to continue to work for the company, judging from recent reports of a 17% increase in earnings.

MySQL

This is the most popular open source database engine, the critical M in the historic LAMP stack mentioned earlier. Before the company MySQL AB was taken over by Oracle as part of their larger acquisition of Sun Microsystems, it pursued a complex strategy, but one that fit firmly within the open source tradition.

True, MySQL encouraged customers to pay for individual features, and even sometimes allowed a customer to use a feature in a special, proprietary version for a few months. But every feature was soon incorporated into the open source version. The Business Source License (BSL), created by the founders of MySQL, formalizes a delay in the release of software as open source.

MySQL also employed dual licensing. If you ran the database as a separate program next to your web server or other software, you could use the open source license. If you wanted to embed the database into a proprietary offering, you needed to license the database under a separate, proprietary license for which you had paid.

The dual licensing strategy seems particularly apt for databases because many customers would like to embed them in other software. As evidence for this claim, another company known for dual licensing was Sleepycat Software, which licensed a database product called Berkeley DB. (Sleepycat invented dual licensing and got it approved by the Free Software Foundation.)

MySQL has become open core since the Oracle purchase. However, there is still a strong open source offering. The creator of MySQL, Monty Widenius, left Oracle and forked MySQL to create MariaDB, a variant that gained a lot of users. The last we heard, Oracle and MariaDB cooperate on sharing open source code.

Corporate Funding

Most software projects depend on funding from large institutions, whether private or public. The funding does not diminish their open source status. If the license is open source, the software is too.

It’s also common practice to take donations from particular customers to fund particular features, and this is totally compatible with open source. As we mentioned in the section about MySQL, we would not deny open source status to a project that does a very limited bit of open core by allowing a company exclusive access to a feature for a short period of time. We think that a project enters a danger zone when it sets up a long-term open core component.

Closed Core

This is an extremely popular practice whereby a company contributes to open source projects that are not central to its business. For instance, major cloud-based companies such as Google create or work on a lot of tools for administration, analysis, and so forth. Kubernetes is a prime example. The term closed core was first assigned to this practice in a 2011 blog post by Andy, one of the authors of this report.

Closed core is different from open core because a company is not trying to make money directly from its contributions in closed core and does not layer proprietary features on the open source component. Closed core is one of the actual models covered by the Open Core Summit mentioned in Chapter 3.

Dual Licensing

Dual licensing was mentioned earlier in the section on MySQL. This practice is not a mix of open and closed features, like open core. Dual licensing means that the same software can be licensed (and charged for) in different ways defined by the vendor. The practice is pretty common in software as well as other industries. Depending on the needs of the customer, a vendor can offer the same products under different pricing schemes.

InnerSource

InnerSource is not a licensing model, but an organizational practice inspired by open source. Large companies are using InnerSource to develop internal or proprietary software. The managers and developers study the communications and other methods used by open source communities, described in Chapter 1, and mimic them on internal projects. Sometimes companies employ people who are familiar with open source practices to work on InnerSource projects, in order to benefit from their expertise. But the results are not open source (unless the company decides to open the software later).

Source Available

Many proprietary companies offer their source code to customers willing to pay for the privilege. Unix is a famous example; many people treated it as free software (before that term was invented) and wrote books about how to change and recompile Unix source code. A book published in 1977, A Commentary on the Sixth Edition UNIX Operating System by John Lions, drew extensively on the source code, became a runaway success, and remains a computing classic. But Unix was definitively not free software, as academics altering the software discovered when its owner, AT&T, sued them in the early 1990s and when the Linux developers were similarly sued by AT&T’s successors.

Making the source available is a convenience to customers who want to check for bugs and perhaps even make local enhancements to their version of the product. But the customers are not allowed to share the original code or their changes outside the organization. The original vendor maintains full control.

Open Hardware Cores

We mention this hardware project simply because the name is similar to the software practice in this paper. OpenCores has nothing to do with this report’s topic. It is an open hardware project that collaboratively develops hardware chips and boards and places the designs under open licenses. The open hardware movement complements open source software and is inspired by many of the same principles but is a distinct issue.