By Briana Sim, SimpliCity
Across Canada, many municipal RFPs specify open source platforms such as Drupal as a requirement for their CMS.
These requirements are typically well-intentioned. They aim to protect public investment, ensure long-term ownership, and avoid vendor lock-in.
Yet in practice, they often fall short of those goals.
In some cases, they may even create the very constraints they were designed to prevent.
What municipalities are really trying to achieve
When an RFP specifies open source, it is rarely about the CMS itself. It is about outcomes.
Municipalities are trying to ensure that:
They retain control over their content and data
They can change vendors if needed
They are not tied to proprietary systems
Their platform will last for many years
These are entirely reasonable goals. They are also goals we share.
The challenge is that platform choice alone does not guarantee these outcomes.
Ownership is not the same as independence
Many municipalities technically “own” their open source codebases. But in practice, they still rely heavily on external agencies for:
Routine changes
Security updates
Performance tuning
Major version upgrades
This creates a gap between theoretical ownership and operational reality.
Ownership on paper does not translate into independence if the system requires specialised expertise to maintain or evolve. In some cases, organisations find themselves rebuilding every few years just to stay current.
True ownership means being able to move forward without being forced into costly resets.
Portability is an architectural decision
Portability is often framed as the ability to export code or download a database.
In reality, portability depends on how content is structured and delivered.
For example:
Systems that store content as tightly coupled HTML make reuse and migration difficult
Systems that treat content as structured data, exposed through well-documented APIs, make it far easier to adapt, extend, and integrate
Portability is not about leaving tomorrow. It is about keeping options open for the future.
Open source does not automatically mean no lock-in
Open source platforms are often positioned as the antidote to vendor lock-in. In practice, many municipalities experience a different reality.
Custom modules, bespoke themes, and vendor-specific DevOps practices can make switching partners complex and expensive. Over time, the cost of change increases, even though the underlying platform is open.
Lock-in is not created by licensing models. It is created by tight coupling, customisation, and operational dependency.
Open source can absolutely support flexibility. But it does not guarantee it.
The myth of self-support
Very few municipalities actually want to run and evolve a CMS entirely on their own.
What they are really looking for is confidence that:
The platform will be secure
The system will scale
They can work with different partners over time
They are not accumulating technical debt
They have full access to their code, content, assets, and data
A modern platform should reduce the burden on internal teams, not shift it onto them.
Rethinking how requirements are written
When RFPs specify a particular CMS rather than the outcomes that matter, they unintentionally narrow the field of possible solutions.
They can also exclude newer approaches and, in some cases, Canadian companies like ours that are building platforms designed specifically around these outcomes.
An alternative is to define requirements in terms of capabilities rather than tools.
For example:
Instead of:
“The CMS must be open source (e.g. Drupal)”
Consider:
Content must be stored as structured data and accessible via APIs
All content and assets must be exportable in standard formats
The platform must support vendor transition without full rebuild
Data must be stored in compliance with sovereignty requirements
The system must minimise ongoing operational overhead
This approach keeps the intent intact while creating space for different architectural approaches to meet it.
Moving the conversation forward
Municipal digital services are evolving, and citizen expectations continue to rise.
The platforms that support these services need to evolve as well.
Open source has played, and continues to play, an important role in this ecosystem. But it should be understood as one possible path, not a proxy for outcomes like ownership, portability, or flexibility.
By framing requirements around intent rather than tools, municipalities can better protect public investment while encouraging innovation, collaboration, and long-term adaptability.
At SimpliCity, we believe this is an important conversation for the sector. Not to replace existing approaches, but to ensure that digital foundations are built to serve communities today and adapt to what comes next.
It is a conversation worth having. And one we are keen to contribute to.