Open source has taken the enterprise by storm. What was once seen as risky code, developed in suburban basements, has taken on new life. Major software companies employ teams of full-time workers to write and contribute code to open source projects. Even end user companies such as Netflix, Lyft, Capital One, etc., are contributing back to the ecosystem. The level of confidence and comfort is here, and it is now the enterprise norm.

According to Synopsys, in 2023, 76% of code in codebases was open source software. According to RedHat, in 2022, “The move from proprietary software toward open source solutions is accelerating,” with an expectation that enterprise leaders will increase the use of open source software from 29% to 34% along with an equivalent decrease in the use of proprietary software.

But the rules of this world are changing.

OSS Vendors Are Changing Licensing In More Ways Than One

Amid the growing adoption and participation from vendors and contributors, OSS vendors are changing the license policy for their open source software.

  1. Red Hat decided to change its license from fully open source software (FOSS) to more of a Frankenstein of closed and open source.
  2. HashiCorp updated licensing for most of its products to a Business Source License.
  3. MariaDB, MongoDB, and many others have changed licensing in different ways.
  4. Open source is not limited to software alone — silicon and hardware vendors are also joining the bandwagon.

Leading causes for these shifts include:

  1. Changing commercial and competitive situations. Cloud economics has changed the game for open source, placing pressure on vendors such as Mongo, Elastic, and HashiCorp to offer compelling reasons to pay them for their services. It also paves the way to address future competitive positions.
  2. Hyperscaler commercial offerings are based on OSS. Fully open source vendors have watched the major cloud players step in and offer their version of products that are based on and compete with their open source equivalents.
  3. Lack (or absence) of contribution by hyperscalers. Larger, better-funded competition represented by the cloud service providers are able to fork off the OSS platform and rebrand them as their own, often with minimal feedback of improvements to the main codebase.
  4. Instinctive response to survival concerns. Cloud service providers legally taking open source software platforms as their own is a threat to the OSS ecosystem.
    • OSS vendors with mature products are especially vulnerable, since the bulk of innovation is done.
    • Enterprises have developed close ties with the hyperscalers, and the CSP solutions are enticing to clients. CSPs drive consultative services, as well, driving revenue away from OSS vendors. OSS vendors find it hard to compete with this vertical integration.

What Red Hat and HashiCorp have done in terms of their code availability and licensing model appears to be a reaction to this encroachment on their position and value. Their approaches are not the only path to address the issue, and we expect to see more vendors experiment with ways to protect their intellectual property, viability, and market presence.

What It Means For Open Source Users

  1. Understand licensing. As always, understanding the licenses is imperative, as license infringement costs dearly. Developers often don’t pay attention to the legal details, but enterprises must!
  2. Assess the changes holistically. Your experience will depend greatly on your exposure to open source and frequency of usage. Typically, the changes are applicable to the newer versions/releases. Parts of your users/apps may not see much impact initially, especially if they do not update their products frequently and if there is limited or no external exposure. Others will see more drastic changes, with ecosystem partners altering their support plans or dropping out of the market.
  3. Review your vendors’ financial health. One of the big concerns with such events is the financial health of your OSS vendor. What if it goes under? The potential loss of the platform will necessitate a search for alternatives, including the potential support of an open source alternative. New open source alternatives based off forked, older source code will take time to develop and may not provide the same experience in terms of adoption, support, and feature upgrades that were experienced with the original.
  4. Aim at portability. You write your code for Linux and are free to choose the distribution that best serves your needs. The same is true for other open source products, as well. You choose a vendor to provide expertise and support service … OR just do it yourself. With restricted source licensing, it may not be that easy.
  5. Watch the market developments. As both the vendors and their clients test the waters with restricted source licensing schemes, other vendors are watching. Expect them to make similar announcements if the early signs of this model show success.