Open source licence series - Instaclustr: Is open core a rotten deal?

Open idealism

The driving promise of open source licensing is allowing for technology that can extend far beyond the limitations of what any single entity’s proprietary solutions can offer. 

Ideally, open source software should be, well, free and open. 

It should bring prosperity to a robust community of organisations large and small – who then contribute back to the project in proportion to their capabilities. 

Unfortunately, the reality now too often falls short of these ideals.

I’d argue that more than ever before, anyone committing to using an open source technology needs to first do a thorough risk assessment that carefully vets the licensing terms, in addition to assessing the strength of the community and the business motivations of commercial entities involved with the project. Those that require vendors or managed service providers (disclosure: what we are and what we do) to implement open source technologies effectively, must do their due diligence to understands those businesses’ interests.

Is open core a rotten deal?

We also need to consider ‘open core’ solutions offered by companies that build on top of OSS projects by adding proprietary features in order to create commercialised versions that they control.

While open core providers will often market these features as enterprise-grade improvements, in my view the reality is that the business model that ‘open core’ companies utilize invariably includes deep conflicts of interest.

Before all the pitchforks come out: let me also say that yes, open core providers do meaningfully contribute to the open source projects at the heart of their solutions (and doing so invariably also helps improve their own product). However, when the best interests of open core providers are at odds with those of their open source project’s community and contributors, it is not uncommon for those with an open core business model to leverage their influence and steer a project in a more self-serving direction (sometimes to the detriment of the project’s userbase).

For example, take a scenario where the community around an open source project plans to introduce features that would effectively offer an open core provider’s ‘enterprise features’ for free. While these new bells and whistles may be universally beneficial to the rest of the community, an open core provider would almost certainly wield its influence to oppose them as fiercely as they could – because their business motivations conflict with users’ needs. 

These incentives just conflict to much with the spirit of open source.

Incentivised betrayal of trust

Businesses also risk direct negative impacts of their own when they become reliant on open core offerings. They often require the expertise of external providers to navigate OSS complexity; unfortunately, open core support teams can be incentivised to betray this trust, and may press customers to utilise proprietary features instead of free alternative – even when the result is a sub-optimal deployment. 

In the worst scenarios, open core code may not be portable, leading to vendor and technical lock-in that makes it extremely challenging for businesses to change providers or wrest away control of their own solutions. 

I’d also add a last word of caution around the trend of managed services for complex solutions delivered by major cloud providers – for example, AWS’ recently-announced Apache Cassandra Service (MCS) – because these businesses are motivated to add users to their cloud platforms, not necessarily to deliver exceptional or expert service. As a result, cloud providers can fail to drive innovation or contribute proportionally to open source projects.