Explicitly recommend European or neutral-foundation alternatives to your clients and colleagues#
What this is, concretely#
This commitment consists of integrating, into your daily professional practice, the explicit recommendation of European or neutral multi-vendor foundation alternatives where these alternatives exist and are functionally credible. The recommendation bears on the technical choices that arise in your work: components to integrate into a stack, hosting providers to propose, third-party services to connect, development tools to adopt. It is addressed to your clients (if you are a contractor), to your team (if you are an employee with technical influence), to your colleagues, and to your professional community.
The commitment does not require you to impose these alternatives — you usually do not have the power to do so, and rigidity would be counter-productive. It asks that you propose them explicitly, with arguments, in the technical discussions where the choice arises. The typical form: “We can go with Redis as planned, but I should flag that since the BSL/SSPL flip in March 2024, Valkey is a robust alternative under a neutral foundation — the Linux Foundation. Here are the implications of each choice for our project.”
The commitment also implies that you explain the underlying reasoning. A recommendation without argument looks like dogma and convinces no one. A recommendation that explains the nature of governance, the associated risks, the equivalent features, and the possible technical differences creates a real transfer of understanding.
Why this commitment matters#
The diffusion of European and neutral-foundation alternatives largely depends on practitioners who know them and who dare to recommend them in technical discussions. Many trade-offs are made by default, by habit, or out of unfamiliarity — “we go with Redis because we always have”, “we deploy on AWS because that’s what everyone does”. When an experienced developer explicitly proposes an alternative with their arguments, the debate opens.
The commitment resonates with thesis 12 of the manifesto: “as long as European providers position themselves as distributors of bricks under foreign governance, they deprive sovereign alternatives of the clients, the capital, and the critical mass that would let them exist.” You, as a developer in a recommending position, are one of the relays through which this dynamic transforms — or perpetuates itself.
The collective effect is powerful. When several developers in several teams recommend OpenTofu over Terraform, Valkey over Redis, Codeberg over GitHub for new projects, the ecosystem of these alternatives grows. Feedback accumulates. Features improve. Critical mass forms. This is exactly the inverse mechanism of thesis 12.
A concrete example#
A freelance technical architect, who works on 2-to-6-month assignments with French ETI and large-account clients, takes this commitment in April 2026 with no defined horizon. On his first assignment after the commitment (architecture review for an e-commerce platform), he identifies three trade-off points where a European or neutral-foundation alternative is relevant: container orchestration (proposing to replace a planned migration to OpenShift with a direct deployment on managed Kubernetes at OVHcloud), secrets management (proposing OpenBao instead of Vault), and the product search engine (proposing to evaluate PostgreSQL full-text before going with Elasticsearch).
For each of the three proposals, he writes a one-page note explaining the context, the alternative, the arguments for, the arguments against, and the final recommendation. The client retains two of the three proposals (managed Kubernetes at OVHcloud and OpenBao), declines the third for reasons of existing skills in the team (Elasticsearch is kept). The architect documents this assignment as anonymised feedback on his professional blog, contributing to the ecosystem’s pedagogy.
Anti-pattern to avoid#
A recommendation that sounds like a militant sermon (“we absolutely have to stop using Redis”) without technical arguments or nuance disengages your interlocutor and discredits the alternative. A recommendation that omits the alternative’s downsides (relative immaturity, smaller ecosystem, learning curve) lacks intellectual honesty and weakens your credibility. The strength of the recommendation lies in its technical rigour, in its nuance, and in its pedagogy.
Success indicators#
You can reasonably consider this commitment fulfilled if your recent assignments or professional interactions include at least several cases of explicit recommendation of European or neutral-foundation alternatives, if these recommendations are argued and documented (notes, slides, written records), and if you can cite at least a few cases where the recommendation actually steered the final decision. Publishing anonymised feedback enriches the collective value.
JSON schema category: communication. Default horizon: no defined horizon (lasting commitment). Applicable to: individual declarations only.