Why Contensis isn’t open source

"Why isn't Contensis open source?" Every year, someone asks me this question. Sometimes it comes from a developer who lives in the Drupal ecosystem and genuinely can’t understand why you’d build a CMS any other way. Sometimes it’s a procurement team at a university or a council doing their due diligence, working through a checklist and trying to understand what they’re committing to. Occasionally it’s more direct. Why are you charging us for something we could get for free?

It’s a fair question. And it deserves a straight answer, because our decision not to open source Contensis is a deliberate one, and the reasoning behind it is more considered than 'we want to charge for it’.

Open source software has produced some of the most important infrastructure on the internet. The community model drives genuine innovation, the transparency builds trust, and the absence of vendor dependency is a real and legitimate appeal – particularly for organisations that have been burned by commercial platforms in the past.

As a company we have no ideological objection to open source. Contensis itself runs on open source infrastructure. Kubernetes manages our container orchestration. RabbitMQ handles our message queuing. Linux underpins our servers. We couldn’t build what we build without these technologies, and the communities behind them have our genuine respect.

We go further than just using open source, too. Where community involvement adds genuine value to our own tooling, we open source it. Contensis React Base, our starter framework for front-end developers, the Contensis CLI, and the Contensis MCP server are all open source and available on GitHub. For us, the decision about what to open source comes down to one question – where does it genuinely serve the customer?

Most discussions about open source versus commercial software start with licensing costs – what you pay, and who you pay it to. That's a reasonable place to start, but it rarely ends there. The more important question is where the operational burden falls.

With self-hosted open source, even in managed variants, the customer or their agency is responsible for the infrastructure, security patching, upgrade cycles, and integration maintenance. That’s the trade-off the model requires, and many organisations understand and accept it going in. In my experience, though, many don’t fully price it in until something goes wrong.

That's what happened with the Drupal 7 to 8 migration. When Drupal 7 reached end of life, organisations that hadn't migrated found themselves running a platform that was no longer receiving security updates. Many had known the deadline was coming. Many still weren't ready, not because they were negligent, but because re-platforming a large website is a big undertaking, and internal teams and budgets don't always align with a vendor's release schedule. The institutions left exposed were often those with the least capacity to respond quickly, whether that was due to under-resourced digital teams, stretched agencies, or procurement processes that made emergency spending difficult.

That's the reality of security in a self-hosted open source environment. Self-hosted open source platforms put the obligation to monitor for vulnerabilities, apply patches, and respond when something goes wrong on the customer or their agency. For many organisations, particularly those without dedicated platform engineering teams, that capability simply isn’t there.

With Contensis, that obligation sits with us. Security patching, infrastructure updates, and responding to emerging vulnerabilities are all our responsibility. That’s part of what the SaaS model means in practice.

There's a second form of dependency that gets far less attention – the people who understand the system. In a self-hosted open source environment, institutional knowledge tends to concentrate in one or two individuals, whether that’s the developer who configured the deployment, the agency who built the custom modules, or the architect who knows where everything is held together. When they leave, that knowledge goes with them.

This is a pattern I've heard described consistently by digital leaders across large organisations in both the public and private sector, people who discovered their dependency wasn't on a vendor, but on an individual. Some would argue that owning the codebase means you're never truly locked in. In practice, a codebase without the people who understand it is a liability, not an asset. At least with a vendor, there's a support contract and someone to call.

Some people assume that keeping Contensis proprietary is primarily a commercial decision, but the real reason has a lot more to do with architectural decisions than our business model.

Open sourcing the core platform would mean that the product would need to accommodate unknown deployment environments. That means either making Contensis significantly harder to run – frustrating any community we tried to build around it – or simplifying the architecture to enable self-hosting, which would mean dismantling the foundations that make the platform what it is.

Contensis runs on a microservices architecture. That means it's built from a set of specialised services, each doing a specific job, rather than one large monolithic codebase. When a better technology comes along for any part of that stack, we can swap it out. Customers get the benefit without ever having to think about it. No migration project, no agency engagement, no disruption. That only works because we control the environment. Open source the platform and every one of those components becomes something end users have to install, manage, and maintain themselves.

The SaaS architecture is foundational to Contensis. The structured content approach we introduced in 2016, the headless architecture, and the composable DXP direction we’ve been building toward all depend on knowing exactly how the platform is deployed and being able to maintain that environment to a consistent standard. Opening the codebase would change the product itself, not just the pricing model.

Running a commercial platform means constantly balancing competing priorities. There are features customers ask for directly. There are capabilities that come up time and again in procurement processes, requirements we need to meet to stay relevant and competitive. And there are investments we make because we believe they're where the platform needs to go, even if no one has explicitly asked for them yet.

Navigating those competing demands is genuinely hard. In an open source governance model, every one of those decisions becomes a negotiation with a distributed community. Roadmap decisions become debates. Features that one part of the community values and another doesn't can sit unresolved for years – not because anyone is making the wrong call, but because consensus takes time.

We've made some significant product bets at Zengenti. The move to a headless architecture was one. Building a deployment platform directly into Contensis – so customers can package, manage, and deploy their front-end sites without leaving the interface – was another. The move toward composable DXP was another still. Each of those came from a clear product vision that we could commit to and move on. That's not something you can do by committee.

I'm not suggesting that open source governance produces worse software. In many contexts it produces better software. But for the kind of coherent, fast-moving product development we do at Zengenti, the model we've chosen gives us something the alternative would take away.

Proprietary platforms have earned a bad reputation in parts of this market, and not without reason. Many organisations have experienced expensive, slow-moving, deeply embedded systems that make it painful to leave. I understand why organisations approach commercial platforms with caution, and I think that caution is rational.

The distinction that matters is between a platform that’s closed because it wants to trap customers, and one that’s proprietary because the architecture requires it. The former is a vendor problem. The latter is a design choice.

Contensis is a proprietary platform. But proprietary doesn't mean closed. Every piece of content and data in Contensis is stored as JSON and accessible through completely open APIs. There's no lock on your data. You can query it, export it, integrate it with whatever systems you need, and take it with you if you ever choose to leave. We're confident enough in the product that we don't need to make leaving difficult.

I started Zengenti almost 25 years ago. I’ve watched platforms come and go, and I’ve watched organisations make expensive decisions based on assumptions about cost, about flexibility, about what ownership of a codebase actually means in practice.

My view is that the job of a CMS vendor is to carry the complexity so that customers can focus on their content and their users. SaaS, done properly, is a commitment – a contract that says the hard parts are ours to manage.

That’s why Contensis is built the way it is. Not because open source is the wrong approach, but because the model we’ve chosen lets us do what we set out to do.

If you'd like to see what this looks like in practice, get in touch.