Skip to Content

Implementing free software: seven decisions to make before installing anything

Budget, project health, licence, customization, versions, support and exit: the practices that make a free software implementation last.

TL;DR: with free and open source software, nobody charges you for the right to use it, but nobody decides for you either when to update it, who to call when it breaks or how to leave. An implementation that lasts comes down to seven decisions made before installing anything: a budget that pays for people rather than a licence, a living project, a licence read to the end, a core that is never modified, versions on the calendar, access that stays with you and an exit tested before you go in. Quebec's Law 25 already makes part of this mandatory as soon as the system holds personal information.


In this article


The server was set up on a Friday afternoon by someone who knew what they were doing. Three years later, it is still running. Nobody remembers which version it is, the person who installed it has left, and the admin password sits in an email nobody can find. The day a vulnerability is announced, the question is not "should we patch?", it is "who can even log in?".

The software did nothing wrong. What was missing are decisions that a proprietary vendor usually makes for you, for better and for worse: when to move to the next version, who answers the phone, under what conditions you can leave with your data. With free software, those decisions come back to you. That is the whole point of it. It is also where many implementations go off the rails.

The human side of a system change (buy-in, resistance, super-users, the stabilization period) is covered in our article on strategies for a successful ERP implementation in SMBs. Here, we stick to what is specific to free software.

To keep the essentials at hand, the seven decisions fit on one printable page: the implementing free software checklist as a PDF. It is written in French.


Budget for people, not for a licence

The first mistake happens in the spreadsheet, before the tool is even chosen: writing "$0" on the software line and stopping there. The code costs nothing to download. Running it, keeping it up to date, training people and answering when something gets stuck: all of that costs money.

The difference with a proprietary subscription is not the total amount, which can be similar in the first year. It is what the money buys. A licence buys the right to use, renewed every year for as long as you pay. With free software, the same budget pays for hosting, support and skills: things you can move to another provider without losing the software, and that often stay in the local economy.

In practice, a realistic budget has four lines: hosting (or the time of the person who handles it in-house), setup and data migration, ongoing support and training, and then a reserve for the next major version. That last line is the one people forget, and we come back to it below. For five-year figures, our cost comparison between Microsoft 365 and a free software stack works through it line by line.


Choose a living project, not just a feature list

Two free software tools can tick exactly the same boxes in a comparison and have nothing in common over time. One is backed by a foundation, a company that makes its living from it and hundreds of contributors. The other is one person's evening project, brilliant, but with no one to take over. The second can be perfectly fine for a small utility. For your invoicing or your client files, it is a gamble.

The risk is not theoretical. On March 29, 2024, an engineer trying to understand why his SSH logins were using too much CPU discovered a backdoor in xz Utils, a small compression library found in most Linux distributions. The project was volunteer-run, and its maintainer had written on the project's mailing list in 2022 that his ability to care for it had been "fairly limited". The compromised releases had been signed by a contributor who had become co-maintainer over time. The affair showed everyone what a critical component is worth when its succession rests on a single person.

Before choosing, a few questions are enough, and you do not need to be technical to ask them:

The questionWhy it mattersWhere to find the answer
Who maintains the project, and how many are they?A single maintainer is a breaking point, whether they leave or burn out.The project's governance page, the list of contributors in the code repository.
How often do releases come out?A project with no release in over a year may be abandoned.The releases page or the changelog.
Where are security advisories published?Without public advisories, there is no way to know what to fix, or when.A "Security" page or an advisory registry on the repository.
Who holds the rights to the code?That is what determines who can, one day, change the licence.The licence file, the foundation or company behind the project, the agreement contributors are asked to sign.
Can you buy support, ideally close to home?Someone has to answer on a Monday morning, in French if possible.The vendor's partner directory, integrators in your region.

To go further, there are tools that measure these signals systematically: the community health metrics of the CHAOSS project, or the OpenSSF Scorecard, which rates the security practices of a repository. Your provider should be able to show you the results for the tools it proposes.

And a project's health is also maintained on your side. Reporting a bug properly, translating a page, paying a membership to the association that brings contributors together: it is the cheapest insurance premium there is on a tool you depend on. The federal government asks the same of its own departments: its Directive on Service and Digital asks them to encourage open source software and to contribute to the communities whose work they use. We covered this in our article on free software and mutualism and in the one on open source contribution models.


Read the licence, and check who can change it

For an organization that uses free software without reselling it, most licences impose very few obligations. So-called permissive licences (MIT, Apache) impose almost none. Reciprocal licences (GPL, AGPL, LGPL) mostly impose obligations when you modify the code and distribute it, or, for the AGPL, when you have a modified version used over a network. Using Nextcloud (AGPLv3) or Odoo Community (LGPLv3) for your own teams does not require you to publish your data or your settings.

Two traps, however, deserve a closer look.

The "open core" model

Many projects have a free version and a commercial version, where certain features live. It is a legitimate model. It often funds the free project itself. You just need to know, before signing, on which side of the line the features you need fall. Odoo is the best-known example, and our article on Odoo Community and Odoo Enterprise details where the line is.

The licence that changes along the way

When a single company holds all the rights to the code, it can decide to change the licence of future versions. It has happened to very well-known projects. In August 2023, HashiCorp moved Terraform from a free licence (MPL 2.0) to the Business Source License, whose own text states that it is not an open source licence. Elastic had made the same kind of turn in January 2021, and Redis did it in March 2024.

Versions already released, however, remain available under the old licence. The community was therefore able to start again from the last free version: OpenTofu for Terraform, Valkey for Redis, both under the umbrella of the Linux Foundation. And Elastic in 2024, then Redis in 2025, ended up adding a free licence, the AGPL, alongside the others. Free software does not protect you from a vendor changing course. It does leave you a way out: the last free version, which anyone can pick up.

The practice that follows is simple: favour projects whose rights are spread among many contributors or entrusted to a foundation, and, if the tool is carried by a single company, know in advance whether there is a community able to take over. That is in fact the stated purpose of the OCA: making sure Odoo remains a viable open source ERP, whatever the vendor decides one day.


Configure before you customize, and never touch the core

Having the source code means having the right to change everything. It is also the most expensive temptation of free software. Every change made directly in the original code will have to be redone, checked and tested with each new version, by someone who understands why it exists. After two or three versions, nobody dares to update anymore. You end up with frozen software, like an old proprietary system, minus the licence.

The order of solutions, from cheapest to most expensive to maintain:

  1. Change the way you work to follow the software, when the gap is small and the current process has nothing special about it.
  2. Configure: fields, stages, permissions, document templates. Anything set on screen survives version changes.
  3. Add an existing module, maintained by a community. In the Odoo world, that is the role of the Odoo Community Association (OCA), which publishes thousands of modules under free licences and provides tooling to migrate them from one version to the next.
  4. Develop your own module, next to the original code, never inside it, and ideally published under a free licence so that others can maintain it with you.

Modifying the core directly is not on the list. If someone suggests it, ask who will redo it at the next version, and how much it will cost.


Put versions on the calendar from day one

Proprietary subscription software updates itself, whether you are ready or not. Free software installed on your side waits for someone to do it. Both have their flaws, but the second has a particular trap: nothing forces you to move, until the day the version you use no longer receives security fixes.

Serious projects publish this calendar in advance. Odoo releases one major version per year (version 20 arrived in September 2026) and supports each one for three years. Those three years run from the release, not from your installation: installing version 18 today means planning a migration in less than a year. Nextcloud releases three major versions per year, and each one receives fixes for one year in its community edition. The vendor's Enterprise subscription extends that support. These are not surprises: they are deadlines known on the day of installation.

The practice is therefore to treat updates as a budget item, not as an unexpected event:

  • security fixes (minor versions) are applied quickly and continuously, by a named person who follows the project's security advisories
  • major versions are planned once per cycle, with a copy of the database to test before switching over
  • the end-of-support date of each installed piece of software is written down somewhere someone will see it coming.

The Canadian Centre for Cyber Security makes it the second of its top 10 IT security actions: as soon as a vendor releases a security patch, it asks organizations to apply it as quickly as possible. With free software, you are the one who carries that measure, or the person you entrust it to in writing.


Know who to call, and keep the keys on your side

With free software, support does not come with the licence, since there is no licence to pay for. At Odoo, for example, the vendor's functional support and its upgrade service are reserved for Enterprise subscribers, who also receive security advisories privately before they are published. On Community, support comes from an integrator, a consultant or your own team. That is not a flaw, it is a choice to make deliberately, and in writing: who answers, how quickly, for what kinds of problems, and at what price.

But the real trap lies elsewhere. Free software frees you from the vendor. It does not automatically free you from your provider. If the integrator holds the only admin access, runs the backups on its own servers and has undocumented changes tucked away, you have swapped one dependency for another, without a licence agreement to frame it.

A few reasonable requirements, to set from the start:

  • an admin account in the organization's name, whose password lives in your vault, not only in the provider's
  • backups you hold a copy of, with a restore tested at least once
  • documentation of the installation: versions, added modules, specific settings, technical accounts
  • the code of any development done for you, with the right to hand it to someone else.

A good provider accepts all of this without arguing. One who hesitates is telling you something important about the relationship.


Plan the exit before you go in

Nobody chooses software thinking about the day they will leave it. Yet that is the best moment to think about it, because it is the only one when you still have all the negotiating power.

Free software starts with a head start: open, documented formats, standard databases, and the right to run the same software elsewhere. But a way out has to be checked. Before going live, ask for a full export of a real data set, open it with something other than the original tool, and look at what is missing: attachments, history, links between records.

In Quebec, part of this thinking is no longer optional. Since September 2023, Law 25 has required a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, with the person in charge of the protection of personal information consulted from the start. The same section requires the system to be able to give people the personal information collected from them in a structured, commonly used technological format. Software you do not know how to get your data out of does not pass that test.

The assessment must be proportionate to the sensitivity and quantity of the information: a small system calls for a small assessment, and the Commission d'accès à l'information publishes a guide to help carry it out. The same Commission specifies that the law can also apply to a non-profit, based on a case-by-case analysis of its activities.

To decide where to start when several tools are involved, the order proposed in our article on what is left standing when the American cloud closes still holds: the password vault, then files, then the core business system, and identity last.

Before signing with anyone to implement free software, ask to see:

  1. the version being installed for you and its end-of-support date
  2. the admin account in your organization's name, and where its password is kept
  3. a restored backup, and a full export opened outside the tool
  4. the list of added modules, and any change made to the original code (ideally none)
  5. the written response time for an incident, and the name of the person who follows security advisories.


What free software does not fix

Free software does not improve a poorly designed process. It reproduces it faithfully, often faster. If invoicing is confusing today, it will be confusing in the new tool. The system change then becomes an opportunity to blame the software rather than fix the process.

Nor does it cover every need. Some niche software, specific to a sector or a regulation, has no mature free equivalent. A coherent stack can perfectly well include one or two proprietary pieces, as long as you know which ones and keep the data they hold recoverable.

Finally, it requires a skill that a subscription spares you. Someone, in-house or at a provider, has to understand the installation well enough to make it evolve. If that skill exists nowhere, the licence savings will be paid for later, in an emergency. And when something breaks, there is no big vendor to blame: responsibility is shared between you and the people you chose. That is the price of the freedom to choose. Better to know it before signing.


How we go about it

Our approach follows that order. We start with the process and the data, we configure before developing, and what we develop lives in separate modules, published under a free licence, like our in-house Odoo modules on GitHub. The version calendar is part of the agreement from the start, and the organization keeps its admin access, its backups and the documentation of its installation.

We prefer free software hosted in Quebec, under the organization's control. The reason is practical. It is the only way to give a clear answer to the three questions that always come back: where the data lives, who can read it and how you get out.

Let's explore your project together, whether you are starting from scratch or from an installation nobody knows the version of anymore.


Sources

Blue Fox OS: a workstation that configures itself from a record
Replacing Windows, Active Directory and Group Policy with a free Linux desktop driven from Symbifox