We like to think we are rational, and that we learn from our mistakes. However, research shows that this is not the case. Instead, we are good at creating neural pathways, and these can be good or bad. For example, if we can’t remember a word that is on the tip of our tongue, it’s likely that in the future we will not remember that same word again, based on the neural pathway that has been created.
Why is this important for software developers and IT teams? Because it explains a common pattern of behaviour around open source. More specifically, how we can move from proprietary software to open source to avoid lock-in, but then over time choose to lock ourselves back in again.
As a CIO, avoiding vendor lock-in is a key challenge.
The move to open source
It’s not an exaggeration to say that open source has become dominant in the software development sector. Though proprietary software vendors continue to build and release products, the majority of software today is open. Gartner estimates that more than 70% of database installations will be implemented on open source and 50% of existing projects based on closed source databases will move to open source equivalents by 2022.
Percona’s own research supports this — around 89% of respondents to the Open Source Data Management Software Survey were using more than one open source database in their applications. The most popular public cloud services make heavy use of open source in their cloud deployments, and host many open source implementations. The growth of software containers based on Docker is also increasing the consumption of open source.
A reliance on open source in enterprise: Necessary for digital transformation
However, the move from proprietary databases to open source is not always simple. The initial choice to move from closed products to open source is often successful. Yet, many teams find themselves moving back away from open source by implementing versions of the software that are effectively proprietary, either by adopting versions that include proprietary extensions or by choosing options that are run as effectively closed services on public cloud deployments.
The decision process is understandable — developers want help to deploy and run quickly, and they desire the flexibility that managed services or cloud can provide. They also want help in the event of something going wrong. However, the rush to get support can often lead to a missed opportunity to regain control.
Keeping an open mind
It is easy to slip back into a familiar pattern of working with IT providers. However, rather than just trading one proprietary service provider for another, it is worth spending time looking at how you
can keep control over important elements such as service and support. Instead of falling into old patterns, you can adopt a fresh mindset, take stock of all available options, and look at the advantages and restrictions that they present.
One approach is to look at the community that exists around an open source project and how they add to that core. A good example is PostgreSQL — this central database project has multiple open source tools for areas such as data management, backup, and security. However, making the most of these tools can be difficult if you don’t have the dedicated skills in place to manage them. To solve this, distributions of PostgreSQL exist that build in these open source tools as standard. Taking this approach can ensure you remain in control of your implementation, whilst filling any gaps that might exist in the main open source project.
For internal projects where you lack the necessary skills for a specific open source deployment, you could research managed services or cloud implementations. You needn’t solely look at the commercial offers from cloud providers, or for enterprise versions of the open source software — instead, third-party offerings can fill that gap. The availability of third-party services helps keep the wider market honest, as it presents multiple alternatives when running and supporting applications and infrastructure. This means that you do not have to be locked into a single approach.
Don’t put all your data in one basket — avoiding vendor lock-in with a multi-cloud strategy
How to avoid making the same mistakes
Evolution is inevitable in the IT industry: open source projects continue to grow and more people will benefit from these implementations.
It is important to avoid re-establishing the same processes and thought patterns that led to problems such as proprietary lock-in. The value that software can deliver is essential to today’s businesses, but we have to guard against the future impact of decisions made in haste.
By encouraging openness and competition in the software market, and avoiding following the patterns that led to problems in the past, we can make positive choices that benefit our business now and in the future.
