“It is open source, so I can never be trapped” is the most common sentence in this category, and it is doing four different jobs at once.
Open source is a statement about the code. Whether you can leave, whether your work survives, whether the project will exist in five years, and whether it costs you anything are four separate questions, and open source answers only part of the first one.
Taking them apart is the whole of this article.
What this page will not do
Before anything else, a limit worth stating plainly.
No licence is named here and no licence text is quoted or paraphrased. Licence terms are legal instruments, they differ in ways that matter, and this site’s own rule on this row is that they must be quoted from the source with the date they were read, never paraphrased. No licence document was read at its own address in this session, so no claim about any licence appears.
This is not legal advice. If the answer to a licence question decides real money or real risk for your business, that is a lawyer’s question rather than a blog’s, and the primary source is the project’s own LICENSE file, in the repository, at the version you are actually running.
What this page can usefully do is name the four questions, so you know what to go and ask.
Question one: can you take your content with you?
This is the one people believe open source answers, and it does not, at least not automatically.
Owning the code means you can run the software. It does not mean the software exports your content in a form another system can read.
The specific failures are the same ones this site’s migration cluster documents over and over: an export that contains the posts but not the relationships, an export that references assets rather than containing them, an export missing drafts, revisions, taxonomy assignments or metadata. What actually breaks during a CMS migration is the catalogue, and it is not a catalogue of proprietary platforms.
The test is the same regardless of licence. Export everything, open the file, and check whether what you would need is in it. Exporting your content from a CMS covers what to look for. Do it before you commit, not when you want to leave.
There is a second half of this that open source genuinely does help with: if the export is inadequate, you have the source and the database, so a determined developer can get the content out by other means. That is a real advantage, and it is an advantage measured in a developer’s time rather than in a button.
Question two: does your own work survive?
The code you got is open. The work you did on top of it may not travel as well as you expect.
Custom fields and content models built through an interface may live in a database in a shape that is specific to that product’s version.
Extensions and plugins, yours or third-party, are the usual casualty. Their fate at a major version change is decided by their maintainers rather than by the licence, and an extension whose maintainer stops is a component you now own.
Themes and templates built against one version’s API.
Configuration, which is frequently the least documented and most load-bearing thing in a running system.
None of that is a licence question and all of it is a portability question. It behaves the same on a proprietary platform, which is precisely why “it’s open source” does not settle it.
Question three: will the project still be there?
Open source removes one risk and leaves another.
Removed: a company cannot switch the software off, revoke your access, or take the product away. What you are running, you keep running.
Not removed: a project can stop being maintained. Contributors move on, a sponsoring company changes direction, the maintainer burns out. Nobody takes anything from you, and there are simply no more security patches.
That is a genuinely different failure from a vendor shutting down, and it is slower and quieter. The risks are compared properly in what happens if the vendor shuts down or gets acquired, and the important distinction is that an abandoned open-source project leaves you with running software and an accumulating security problem, which is a decision with a deadline rather than an emergency.
“You can always fork it” is technically true and practically expensive. Forking a project means becoming its maintainer, and that is a permanent staffing commitment, not a fallback plan. It is worth counting as an option only if you would actually do it.
The signals worth checking before you commit, all of them public: how recent the last release is, how many people have commit access rather than how many stars it has, whether security issues get responses, and whether the project is one company’s product or a genuine community.
Question four: what does it cost?
Free licence, real costs, and they are not hidden so much as located somewhere the comparison does not look.
Operating it. Updates, verified backups, monitoring, scale, incidents. Self-hosted or cloud: who is on call at 2am covers what that involves, and the deciding question is whether you can name a second person who could handle a 2am incident.
Hosting, which is a bill regardless of the licence.
The paid tier. Many open-source projects have a commercial hosted offering, and it is entirely legitimate for some capabilities to be there rather than in the free version. Which capabilities is a question to ask early, because discovering it in month six is expensive.
Time, which is the one that is never on any page and is usually the largest.
The one thing open source genuinely guarantees
It is worth ending on the real benefit rather than only the caveats, because the benefit is substantial.
Nobody can take the running system away from you. No account suspension, no end-of-life notice that switches something off, no pricing change that forces a decision this quarter. Whatever is running keeps running, and any move you make is a move you chose to make and timed yourself.
For a content archive that is meant to last, that is not a small thing. It converts an emergency into a planned project, and a planned migration is a very different proposition from a forced one. This site’s whole position on migration is that the timing is most of the cost: when not to migrate a CMS makes the case that a move made on your own schedule, for a real reason, is the only kind worth making.
Before you commit, in order
- Read the LICENSE file in the actual repository, at the version you would run. Not a summary of it.
- Export everything from a trial and open the file. Whatever the licence says, this is what portability actually looks like.
- Check the project’s health: last release, number of maintainers, response to security issues.
- Ask what is in the paid tier, in writing.
- Ask who operates it, and name the second person.
- If money or risk depends on a licence question, ask a lawyer. Not this page.
The short version
- Open source is a statement about code, not about your content, your extensions, the project’s future, or your costs.
- No licence is named or quoted here, because none was read at source. Read the LICENSE file yourself, at your version.
- Portability is decided by the export, not by the licence. Test it before you commit.
- Your customisations, extensions and configuration are the part most likely not to survive, and that is version risk rather than licence risk.
- A company shutting down and a project going unmaintained are different failures. The second is slower and still has a deadline.
- The real guarantee: nobody can switch off what you are already running. That converts an emergency into a project.
