Introduction

A couple of months ago, I had an insightful conversation with my former manager, the Cloud Director of a major European telecom company. In that moment, I metaphorically swapped my “employee” hat for my “strategic consultant” hat, the same one I wear when I first engage with clients to discuss their open source strategy.

I explained to him the various ways a company might approach open source, especially if it decides to partner with a vendor. This is a conversation I often have with customers in the early stages to help clarify their strategic direction. In my experience, the decision to engage with open source isn’t always driven by the technology itself; it’s typically a business decision. And that’s why I want to share the advice I give to clients and discuss how these conversations are vital in determining the best approach for engaging with open source vendors.

Open source has come a long way. In the late 1990s, it was primarily driven by passionate individuals who wrote code in their spare time. Today, it’s a full-fledged industry, with dedicated engineering teams pushing open-source projects forward. Although passionate contributors are still the heart of it, open source is now a key player in shaping how software is developed, marking a fundamental shift in the tech world.

One of the most profound impacts of open source is how it democratises access to technology. It’s enabled individuals and small companies to thrive without the burden of costly licenses or subscriptions. This is a stark contrast to the traditional proprietary models, which often come with hefty price tags and restrictive terms.

That said, many companies still struggle with how best to engage with open source, especially if a vendor is involved. Should they passively consume a packaged solution, or take a more active role by contributing and collaborating with the community? Based on my 25+ years of experience, I’ve witnessed the different ways businesses navigate these decisions and the outcomes that follow.

In this article, I aim to explore two key models that companies use when engaging with open source and its vendors, the Proxy Model and the Cooperative Model, and share my recommendations. Whether you’re a small business or a large enterprise, choosing the right model can unlock both short-term and long-term value from open source.

Proxy (Passive Consumption) vs. Cooperative (Active Participation)

Over the years of working with open source software, I’ve seen two predominant ways companies typically engage with open source vendors: the Proxy Model and the Cooperative Model. Before we dive into these, a quick note: what I’m about to describe applies specifically to companies that choose to embrace an open source vendor, rather than going fully open source themselves, usually for reasons like peace of mind, compliance, or insurance needs.

Now, these terms (Proxy Model and Cooperative Model) aren’t official terms from the broader open source community. They’re just ways I’ve come to describe the two main approaches businesses often take when interacting with both open source vendors and the open source community. And while these models primarily apply to companies working with open source vendors, there are elements of the Cooperative Model that still hold true if a company decides to embrace an upstream open source project without vendor support.

Proxy Model

Let’s start with the Proxy Model. In this approach, companies consume open source software in a “black-box” fashion, much like they would a proprietary solution. The name Proxy originates from the concept that the vendor serves as a middleman, or a proxy, between the company and the open source community. Companies interact with the vendor in much the same way they would with a traditional software vendor: buying licenses, opening support tickets, and relying on the vendor to handle all the heavy lifting.

In other words, the company benefits from the functionality and power of open source software, but they don’t actively participate in the development or direction of the project. Instead, they let the vendor take care of everything (updates, patches, and fixes) while the vendor, in turn, works with the open source community to make those changes or release new versions of the software. It’s like using a product that you trust, but with little to no direct influence over how it evolves.

Cooperative Model

On the flip side, the Cooperative Model is all about active engagement with open source projects. In this model, companies don’t just consume the software, rather they become part of the broader ecosystem, collaborating directly with vendors and the open source community. It’s almost like a triangle, with the customer, vendor, and open source project all connected in a mesh of collaboration.

Here, companies typically have more control over the software’s development. They might contribute code, report bugs, or offer feedback to improve the project. For instance, if a company is experiencing an issue in production, they can fix it themselves, submit a pull request to the project, and work with the vendor’s support team to review the fix before it’s merged into the project’s upstream. This leads to a deeper, more collaborative relationship with the software, and gives the company a voice in shaping its future.

Comparing the Two Models

Before diving into the details, the first thing I tell companies is that the investment required for both the Proxy and Cooperative models is often very similar in terms of budget. The difference lies in where that money goes. In the Proxy Model, most of the budget goes toward products and services (usually with external resources). Meanwhile, in the Cooperative Model, the focus is on investing in skills and retaining knowledge and control within the company.

When comparing the Proxy Model and the Cooperative Model, the key differences come down to control, commitment, and engagement with the open-source community. Let’s break it down.

Control and Influence

In the Proxy Model, companies essentially give up control over the software. Since they’re not actively involved in its development, they have no say in the project’s roadmap or new features. If the vendor decides to make changes or discontinues support, the company could find itself stuck. They might have to follow the vendor’s upgrade path, or worse, switch to a different vendor altogether.

Contrast that with the Cooperative Model, where companies have much more control. By engaging directly with the open source project and its community, they can influence the software’s direction without relying on a specific vendor. This model allows businesses to customise solutions, contribute improvements, and collaborate with other users and contributors, ultimately leading to a more tailored and sustainable solution in the long run.

Vendor Lock-In

The Proxy Model can often lead to vendor lock-in, even with open source software. By depending on a third-party vendor for support and updates, companies may become reliant on that vendor’s ecosystem. If the vendor raises prices or changes direction, the company could find itself scrambling to adapt, or worse, switch providers, which can be a costly and time-consuming process.

A good example of this is when a well-known open source vendor discontinued its initial virtualisation offering, pushing companies to adopt a more complex solution like Kubernetes with KubeVirt. Technically, the latter is a great product, but it requires a significant additional investment in terms of both time and resources.

On the other hand, the Cooperative Model reduces the risk of lock-in. By working directly with the open source project and adhering only to “upstream” features, companies aren’t tied to a specific vendor’s version of the software. They have the freedom to switch between vendors or take control of the solution themselves.

Ease of Use vs. Resource Commitment

The Proxy Model is, in theory, the easier and quicker option. Since the company isn’t involved in the development or maintenance, it’s essentially a plug-and-play solution. The vendor handles everything, allowing the company to focus on its core business operations without worrying about the technical stuff.

However, much like with traditional proprietary software, the company might eventually need to rely on the vendor or certified third parties for further customisation to fit its unique processes. This can complicate the deployment, essentially leading the company down the same path as customising something like SAP.

In contrast, the Cooperative Model requires more effort. Companies need to be committed to contributing back to the open-source community, whether that’s through code, bug fixes, or providing feedback. It can be resource-intensive and may require specialised internal expertise.

Here’s a quick note: doing software customisation as a fork or private patch might seem like a quick and easy solution, but it’s a slippery slope. It can lock you into a specific version, making future upgrades a nightmare. The best approach is to provide a temporary internal fix while also working on a long-term solution that’s contributed upstream, where it can be maintained and improved by the community. This approach might take more effort initially, but trust me, it’ll save you a ton of headaches down the road when you’re able to upgrade seamlessly.

Long-Term Sustainability

In the Proxy Model, the long-term viability of the solution is in the hands of the vendor. If the vendor pulls the plug or shifts focus, the company may face disruption. But in the Cooperative Model, companies can help ensure the long-term sustainability of the software. By being involved in the open-source community, they contribute to the software’s growth and future-proof it by making it less dependent on any single vendor.

Remember, open source and open protocols can be slow to start, but they’re often the best long-term choice. The initial investment in time and resources pays off when the software is flexible, sustainable, and able to evolve with your business needs.

My Experience on Choosing the Right Model

Before we dive in, I should be upfront: I’m personally biased toward the Cooperative Model, and I strongly believe in investing in skills and people. However, that being said, what I’ve shared with my manager and other companies I’ve worked with is that there’s no clear-cut right or wrong between the two models.

Over the years, I’ve seen companies thrive using both the Proxy and Cooperative models. The right choice depends largely on your company’s specific needs and long-term goals.

If your company is looking for a quick, reliable solution with minimal internal resources spent on maintenance, the Proxy Model can be a great fit. For example, if the open source technology isn’t central to your competitive advantage and you just need something that works out of the box, the Proxy Model provides the simplicity and peace of mind you’re after, allowing you to focus on execution without worrying about the software’s evolution.

On the flip side, if open source technology (and software in general) is a crucial part of your company’s strategic goals, then the Cooperative Model is the better choice. This model requires a commitment, both to the software and to the open source community, but the long-term benefits can be huge. Engaging directly with the open source project allows you to influence its development, ensuring the software evolves in a way that fits your company’s needs. Plus, it helps reduce the risk of vendor lock-in and enables you to build deeper expertise in the technology, a huge competitive advantage in itself.

For larger companies adopting the Cooperative Model, establishing an Open Source Program Office (OSPO) can be incredibly beneficial. An OSPO helps centralise and manage open source efforts across the organisation, ensuring that contributions, governance, and compliance are well coordinated. It can be a powerful way to streamline open source initiatives, keep everyone aligned, and maintain control over how the company engages with the open source community.

In my experience, companies that choose the Cooperative Model tend to develop a stronger sense of ownership and innovation. They often end up with unique, customised solutions that set them apart in the market. But I’ve also seen businesses do really well with the Proxy Model, especially when their priorities lean more toward speed and simplicity rather than shaping the future of the software.

It’s also worth noting that it’s not all or nothing. You can choose the Proxy Model for non-strategic projects, like internal traditional IT infrastructure, and reserve the Cooperative Model for strategic products or services that you’re offering to customers. This way, you can play to the strengths of both models depending on your needs.

And even though my reasoning here is geared toward larger companies that can invest in skills and people, smaller and medium-sized companies can absolutely engage in the Cooperative Model, too. In fact, for smaller companies, it might be crucial to work with local consulting firms, what I call “boutique consulting”. These are firms that truly understand open source and can act as trusted advisors, helping companies navigate the world of open source software and get the most out of their engagement.

Closing Thoughts

Throughout my career, I’ve always approached each engagement with one thing in mind: the best interests of my clients. Sometimes, that means guiding them away from what seems like an easy path. It’s not always about taking on every project or saying “yes” to every opportunity.

There have been instances where I’ve had to decline an engagement because a customer initially asked for a Cooperative Model, but after discussing their needs in detail, I convinced them that, despite my personal belief in its benefits, the Proxy Model was actually a better fit for their specific situation. It’s about being honest with them, stepping back, and suggesting what truly makes the most sense for their long-term success, even if that means walking away from a project that might otherwise seem like a good fit. My goal is always to guide my customers toward what will help them thrive, not to push a solution that may not deliver the results they’re looking for.

While I respect each company’s decision, there’s always a part of me that feels a little sad when I see a customer opt for the Proxy Model, not because it’s inherently wrong, but because it often comes down to comfort or political factors. I believe that some companies can unlock their full potential with a more courageous, Cooperative Model approach. It takes more time and effort, but the payoff is worth it. Open source is a long-term game, and while proprietary solutions might deliver short-term gains, they can’t compete with the flexibility and innovation open source offers over time.

That said, I’m here to support businesses in any way I can. With over 25 years of experience building private infrastructures and private clouds utilising technologies such as OpenStack, Ceph, and Kubernetes, I bring the expertise to help you navigate the complexities of your open source journey. Whether you’re considering a new solution or looking to optimise your existing one, I’m always ready to help.