Publish your technical stack choices and the sovereignty reasoning behind them#
What this is, concretely#
This commitment consists of publishing, on your personal site, on a public repository, or on a blog, your preferred technical stack and the reasoning behind it from the sovereignty standpoint. The document spells out your choices by category (forge, language, framework, database, hosting, development tools, IDE, etc.), names the chosen solutions, and explains why you have chosen them — explicitly integrating the dimension of governance, jurisdiction, and funding model.
The document is not an ideological manifesto. It aims to document your real trade-offs, including the compromises. If you still use GitHub for reasons of professional network effect but start your new projects on Codeberg, say so. If you code in TypeScript despite Microsoft governance because you consider the ecosystem mature, explain the reasoning. Transparency on compromises is worth more than façade purity.
The commitment stands as an individual declaration. It bears on your personal and professional stack to the extent that you have control over the choices. For assignments where the stack is imposed, you can document what you would recommend if you had the choice.
Why this commitment matters#
The pedagogy of the ecosystem largely depends on practitioners who make their reasoning visible. An abstract thesis (thesis 6 on the entire chain, thesis 8 on maintainers, thesis 12 on the role of European providers) gains in force when it is embodied in concrete stack choices documented by working practitioners. Your readers — colleagues, potential clients, students, beginners — can then form their own judgement from concrete elements.
The commitment resonates with the general spirit of the manifesto: sovereignty is not a declaration but a chain of daily trade-offs. When you document your stack, you show what that chain of trade-offs looks like in real life. Thesis 11 of the manifesto — “a serious European digital sovereignty policy is recognised by its investment in foundations, maintainers, and distribution infrastructures” — translates into the concrete choices you document.
For you, the commitment has a reflexive effect. Simply having to publicly justify your choices forces you to examine them with rigour. Many developers discover, while drafting their published stack, inconsistencies or default choices they had not consciously registered. The document becomes both pedagogical and self-disciplining.
A concrete example#
A fullstack developer based in Lyon, freelance and active in the local Python community, takes this commitment in March 2026 with a 6-month horizon. Alongside her assignments she drafts a structured article that she publishes on her personal blog in September 2026: “My technical stack in 2026 — choices and sovereignty reasoning”.
The article runs to about 3,500 words and covers ten categories: forge (Codeberg for new projects, GitHub kept for existing client projects, with an explanation), main languages (Python via PSF / neutral foundation, TypeScript with full awareness of the Microsoft compromise), databases (PostgreSQL by default, SQLite for small needs, explicit mention of dropping MongoDB and of evaluating Valkey against Redis), hosting (Scaleway for personal projects, OVHcloud or Hetzner depending on the assignment), productivity tools (LibreOffice, self-hosted Nextcloud, ProtonMail), IDE (VSCodium rather than VS Code, choice explained), terminal and shell (alacritty + tmux, fish), CI/CD (Forgejo Actions on Codeberg for new projects), monitoring (Grafana with mention of the AGPL flip in April 2024), package management (uv for Python, with attention to Astral’s US governance).
The article is shared on professional networks and receives several hundred visits in two months. Three other developers publish their own documented stack in turn. The developer updates the article annually.
Anti-pattern to avoid#
A publication that reads like a panegyric to European open source without nuance or mention of compromises lacks technical credibility. Symmetrically, a publication that simply lists tools without explaining the reasoning does not serve pedagogy. The value of the commitment lies in the combination of explicit choices, honesty about compromises, and updating over time.
Success indicators#
By the 6-month horizon, you can reasonably consider this commitment fulfilled if a publicly accessible publication (blog, personal site, repository) documents your technical stack with sovereignty reasoning for each substantial choice. In the long term, the commitment takes shape with annual updating of the publication and the integration of governance changes affecting components.
JSON schema category: publication. Default horizon: 6 months. Applicable to: individual declarations only.