Do you know what the impact open-source will have on the tech you’re just about to inherit?
The answer to that question is far more nuanced than you expect, and contrary to popular belief, it isn’t all bad either. However, depending on the vendor and the changing market dynamics at play, there could be a considerable impact going forward. It is my belief, the changing market dynamics, more than anything else, poses the greatest threat to your tech stack post-acquisition. It is no wonder that Thoughtworks has even flagged this risk as a part of their quarterly tech radar.
This is a lengthy post, but I want to provide some context into this area as it feeds into one of the criteria I use while evaluating a target company’s tech stack. What follows is some background on open-source and the startups that have made it their business model. Then I highlight the various knobs available to them as they strive for profitability, and lastly the risks to your potential purchase post-acquisition as the various knobs are turned.
If any of this raises an eyebrow or two, don’t hesitate to drop me a line.
Background
Many moons ago, I cut my teeth at the end of the dot-com era with the start of Linux and the open-source movement beginning to take over the world. I grew up with it, and being the young liberal that I am, I was heavily steeped in the altruistic techno culture that was the free software movement. This didn’t stop after graduating college and remaining in academia for several years working in the high-performance computing space. Nor later with Sun Microsystems. I have also worked with several companies in the past where their main product was based on open-source technology and as a business model.
What they have in common was the culture of transparency, openness, and sharing to improve all. The open-source ideal wasn’t so much free as in beer, but free as in speech (to borrow the Free Software Foundation’s mantra). This ideal, more than anything else, helped with the explosive growth of Linux and the Internet in the 90s and through to the present. It provides the operating system that powers everything from cell phones to routers, and the core libraries and tooling used to power the world today by leveraging the world’s expertise to bring our dreams to reality.
Regardless of the draw towards the open-source ecosystem, it is the software’s license that enforces the intellectual property and promotes the sharing of knowledge regardless of use. Conversely, the license dictates the level of risk from a business perspective. For example, if you have a novel idea, how much of that idea that is built on top of the underlying open-source products will dictate who really owns it. Additionally, how do we really know the underlying components are really safe?
Open-Source Business Model
For those who want to make a living in open-source, the options are:
- Work in academia by creating and releasing software based on research projects
- Treat it as a hobby and rely on donations or spare-time
- Work for a company who is a strong believer in open-source (Sun Microsystems as an old example)
- Start a services/software maintenance company to support the open-source community such as RedHat
- Start a product company and open-source the core product
These options will dictate the type of projects that get worked on, where and when the attention is focused, and the financial motivations behind them. For example, the projects out of academia will be cutting edge, but are usually designed for a specific research project that, depending on funding and interest, may or may not be maintained going forward. From the academic standpoint, the project may have been initially funded through a research grant with an eye towards being freely available to anyone willing and able to use. As long as there is funding for the project, they’ll have the resources to maintain it, but profit isn’t the goal.
On the other end of the spectrum is the startups that are product companies such as Mulesoft and more recently Hashicorp. In these cases, they started out as a single product company looking to solve a specific problem. They open-sourced their core product for one of several reasons:
- Giving back to the community
- Increase awareness (contrarians to the big corporate software shops)
- Early adoption by potential customers
- Relying on volunteers to augment their own internal engineering team
However, one of the most difficult, and important, questions these startups must ask themselves is how do they generate revenue with their product? Especially since each knob at their disposal controls not only a different aspect of the revenue stream, but also can impact certain segments of their user base depending on how they consume the project. Note: an open-source project can drift between these options during its lifetime. As a result, when they need to show profitability to either survive or for their shareholders, then they start adjusting the knobs towards a less open and more profit-driven approach.
The knobs they can turn consists of the following:
- Altering the types of licenses between open-source and commercial versions of the product
- Building out different capabilities between a lite and full offering
- Expanding professional services and support on a pre-existing or much larger open-source project
- Limiting what they gift and volunteer to
Depending on how these knobs are turned will dictate the terms of how the software can be used. The biggest risk to any enterprise, regardless of where the acquisition is in the M&A journey, is the company turning these knobs. So what are they?
Altering License Types
Given the numerous types of open-source licenses, some are more permissive to commercial activity than others. For example, there is the AGPL (Affero General Public License) which requires the project’s source code (the true intellectual property of any business) to be released if it is hosted on the public internet (think of all web-apps you interact with every day and their crown jewels being published as a result of this license). On the other end of the spectrum is the more permissive licenses that you’d find with the Apache or BSD licenses. Depending on the stage of the vendor, the type of adoption they are hoping for, and their financial situation, will dictate the type of license they use from the open-source perspective.
When the vendor’s funds begin to get tight or other competitors take advantage of their permissive offerings, the knob will be turned towards a more restrictive license to force more people to use their paid offering. This has the detrimental effect of reducing adoption going forward, or losing current users who may be dependent upon the free offering and are unwilling to pay for it resulting in the community “forking” the core product. The most recent example of this is when Hashicorp changed the licensing model used by their core product: Terraform. Redis is another example of a company that did this with more to follow in the near future.
Different Capabilities
This is perhaps the most common knob, and the most sensitive for the user base. One of the biggest advantages of the open-source business model borrows from the shareware model of the 90s in that it allows the prospective customer to “try before you buy.” There is a lite version that can be used with the core functionality of the vendor’s product. However, if you want the full feature set, then you are encouraged to buy their next tier. The two companies that come to mind is Hazelcast (for SSL support) and Kong (for the plethora of additional plugins such as OAuth2/OpenID Connect support). The components that are a part of the commercial offering are the ones usually locked under a different license and provide the unique IP for the vendor.
If the vendor needed to increase sales or prevent competitors from using their product, they would tighten this knob to either cripple the lite or core version so that it is very difficult to use without buying the full product, or provide the source code for the core product in a form that cannot be easily used. The best example of this is RedHat ceasing the publishing of their source packages.
Professional Services & Support
The last of the for-profit models is offering professional services and support it allows the company to sell their expertise with a popular open-source project such as Kubernetes or FreeBSD. They provide a point of contact and support when there isn’t a large vendor backing a critical component while also providing the customizations businesses rely on each day. Normally these customizations are created as one-off components that may be open-sourced or owned fully by the organization, but would still need proper care just like any other custom software developed in-house. The risk in this case has less to do with the vendor, but instead lack of in-house expertise.
The knob in this case is very much specific to the levels of support they offer as well as the custom solutions and the on-going maintenance required for their continued maintenance.
Gifting and Volunteering
This last knob isn’t so much of a business model taken by an open-source vendor save for what they release as a by-product of their normal course of business. However, this also reflects all of the other open-source projects that are in use and maintained by a small group of dedicated maintainers. The motivation is more altruistic, but as a result, means the support and maintenance is on an as-needed basis.
Since profit is not a motivator, it is time for individuals to dedicate to the project, the risks are different. The most notable example recently is the log4j security issue. In this scenario, it is maintained by a small group of developers, but has had global importance as being used by most java projects in the world. There have been other cases of programs in use where the sole author has withdrawn it from the public Internet due to their politics clashing with those who were using it.
Concluding Remarks
There is a quote attributed to Issac Newton where “if I am able to see further, it is by standing on the shoulder of giants.” That is where I see open-source these days. The combined works of a lot of engineers over the years to advance the state of technology to the next place. However, there is a difference between work done for the sake of advancing the state of the art, and commissioning work to advance a business goal. There is a balance that must be maintained. Just like in everything, this balance has risks and trade-offs, and that is what must be evaluated as a part of your due-diligence process. Were the right trade-offs made? Does it account for the constantly changing state of the industry? From the company being acquired, did they keep that in account with the vendors they partnered with or the software they incorporated into their intellectual property?
This is why the impact is… it depends.