Open source licence series – Delphix: Rent vs buy, which fits your licencing cost model?
Open source grew, it proliferated… and it became something that many previously proprietary-only software vendors embraced as a key means of development… but the issue of how open source software is licenced is still the stuff of some debate.
The Computer Weekly Open Source Insider team now features a series of guest posts examing in the ups & downs and ins & out of open source software licencing.
Colin Rand, Delphix’s VP cloud products writes from this point forward.
Choosing an open source licensing model can feel a lot like a first-time home buying experience. It’s a big commitment, and deciding whether to “rent” versus “buy” a software license can have a lasting effect on the entire lifecycle of a product. You first need to decide where your software is going to run before you even decide what to do with it. That decision comes down to whether you’re running on-prem or in the cloud.
Everything stems from that first choice, and suddenly you’re faced with difficult technical selection criteria at every step of the open-source journey. At the heart of it all is licensing – or in layman’s terms: who’s running the operation.
Of course, if you’ve got a greenfield, it’s much easier to make these decisions. But more often than not, you’re tasked with modernising a main application that’s been around for 10 or even 15 years – that’s when it gets especially hard. You could be stuck with a proprietary database on-prem, and for whatever reason, the cloud provider can’t offer an equivalent licensing cost model. Several recent examples with both open source (e.g., Elastic and MongoDB) and proprietary (e.g. Oracle) have shown database vendors changing licensing terms to combat competition with public cloud providers. In other words, the developer-friendly OSS companies are turning into customer pain points!
Let’s take a look at two different scenarios when approaching your cost-models and how they’re affected by who ultimately operates the platform the application runs on.
“Renting” aka the managed approach
When an application follows a rented (or managed) approach, you’ll often see a selection process for new components as follows:
1) Use the built-in component provided by a public cloud
2) Use a service provided by a trusted third party
3) Use an off-the-shelf library component
4) Write custom code
If you use this model, you’re inherently selecting productivity for developers and ease of operational scale over cost optimisation. At each step of the way, the component could be open source or proprietary, but the big benefit here is reducing the effort to run or operate the component versus a license granting permission. Cost modeling in this situation is therefore based on usage as the primary driver. While capital is cheap, enterprises can benefit greatly from the short-term flexibility this type of approach provides.
“Buying” aka the owned approach
The other option is to go the owned route. When an application follows an owned model, the selection process follows a different pattern:
1) Compatibility with the ecosystem
2) Compliant with policies
3) Vendor support
In this scenario, the dominant benefit is enterprise control as opposed to developer productivity. Costs here are often negotiated upfront and renewed on a multi-year basis, leading to models with better long-term visibility. After the big cloud hype cycle of the last decade, I believe we’ll see a return trend in which long-term cost management frequently wins over short-term productivity for the enterprise.
Two is not always better than one
Depending on the context of the application, both of the above models can prove to be effective for a business. The real challenge comes in when these two models are mixed, such as when a component or service with the short-term benefit of flexibility is added to a platform that is optimised for long-term control. This tension will complicate any cost strategy, often leading to a situation in which the “worst of both worlds” results in long-term dependency on a cost structure that’s extremely difficult to control.
Ultimately, when developers make selections for components, open source is often their go-to choice, offering benefits that accrue to productivity goals. However, the cost strategy must always take into account the full picture, including vendor lock-in and operations. Once you’ve made the initial, crucial decision for where your software will run – cloud or on-prem – the cost implications of that decision will have an impact on the entire life cycle of the application. If you carefully consider that ripple effect in the first decision-making stage, you’ll be far better prepared for what’s to come.