Reading a Profile — Developer angle#

Reading a Profile at the moment when one arbitrates a technical dependency — library, framework, third-party service, PaaS — and must decide whether to build on it for the next five years.

Your stake#

A developer does not read a Profile in the same posture as a CIO, a CISO, a buyer, an investor or a journalist. None of them arbitrates technical dependency itself. The developer, for their part, chooses the brick on which their code will rest: the gesture is upstream of commercial trade-offs, and it propagates. To choose a single-vendor library five years ago for a project that is critical today is to have installed a breaking point that no later purchase decision can uninstall without cost. The Profile makes readable what the docs, the README and the number of stars do not say: the actual chain underneath the brick, hence the sovereignty debt taken on at the time of the choice. It is also the persona where action can be personal, independently of any collective purchase decision.

A 5-minute reading#

Five fields suffice to decide whether a dependency holds up to its own narrative or whether one should look for an alternative before the code takes root.

• Domain 1 — Strategic third-party components. If the domain is empty or names a single brick without transitivity, you do not know on what you are leaning: a component that itself depends on a single-vendor inherits the risk without saying so.
• Domain 3 — Supply chain. Forge, registry (npm, PyPI, Maven, NuGet, crates.io), CI/CD, artefact signing. A silent domain 3 leaves the blind spot that incidents of the XZ Utils, Heartbleed or Log4Shell type have documented.
• Domain 5 — Continuity in the event of failure. Is the fork viable or theoretical? Is the governance open? Is there a community of contributors beyond the single-vendor? Without an answer, your way out does not exist.
• Domain 7 — Assumed commitments and limits. A provider that says nothing about the longevity of its API, on its roadmap, on long-term support, forces you to assume the worst — silence here has value.
• Date of update vs release cycles. A Profile frozen while the project has shipped three major versions describes an obsolete target.

In-depth reading#

Seven domains, seven illuminations from the developer angle. This section does not rewrite the educational sheets — it says what a developer draws from them in order to arbitrate their stack choice.

Domain 1 — Strategic third-party components#

Domain 1 is the test of the transitivity of dependencies. A library that leans on a single-vendor upstream brick inherits the risk without saying so — the readability of the chain stops where the domain stops.

Domain 2 — Contingency plans#

Domain 2 says whether the project can survive the disappearance of a critical upstream brick. For the developer, this is the indication that a switchover has been thought through, not merely wished for — a theoretical plan does not hold under the test of the day.

Domain 3 — Supply chain#

Domain 3 is the heart of the developer reading on direct technical threat. Forge, registry, CI/CD, artefact signing: this is how incidents of the typosquatting, ev-builds, or XZ Utils-style upstream compromise type arrive. A domain 3 that names forge ownership and signing turns a systemic threat into an addressable risk.

Domain 4 — Hosting and data#

Domain 4 interests the developer when the brick is a third-party service consumed in production — PaaS, SaaS API, managed service. The effective jurisdiction of the host determines whether the API can be cut off by extraterritorial sanction, or whether a data transfer engages your downstream compliance. PaaS lock-in deserves dedicated attention here: a Heroku Procfile, an AWS Lambda handler, a Vercel or Netlify build, a Cloudflare Workers binding are not neutral stack choices — they encode orchestration in a proprietary format. The Profile of a PaaS provider must say what its runtime commits your code to, and what happens when you decide to leave.

Domain 5 — Continuity in the event of failure#

Domain 5 is the terrain of actual forkability on the code side, and of runtime portability on the execution side — two distinct but complementary conditions. On the code side: open license, broad community, readable governance, documented escrow; without these conditions, the fork remains a theoretical right that no team can activate the day the publisher closes. On the runtime side: provided Dockerfile, vendor-neutral Kubernetes manifests or canonical docker-compose.yml, reproducible build, contractual reversibility clause with a quantified deadline; without these, your application runs only where it was designed to run — exit is possible in theory, long in practice. A serious provider names these two conditions; a Profile silent on either leaves the way out virtual.

Domain 6 — Governance and capital#

Domain 6 indicates who decides the future of the project. An open foundation, multi-actor governance and readable capital give an expectation of continuity; a project entirely piloted by a single publisher, or hosted under a foreign foundation without an active European mirror, exposes to a license flip — MPL to BSL, AGPL to SSPL — whose history the open source culture now carries.

Domain 7 — Assumed commitments and limits#

Domain 7 is the test of sincerity. A project that assumes its limits — “our public API is stabilised only on such a perimeter”, “long-term support depends on the funding of such a maintainer”, “this integration will remain best-effort” — gives you an honest starting point. An empty domain 7 leaves you to assume the worst, particularly on the longevity of the API you consume.

Warning signs#

Six signals that should trigger reinforced examination before writing the dependency into your package.json, your pom.xml or your Cargo.toml. None on its own suffices to disqualify; their accumulation indicates a dependency whose future is not in your hands.

• Single-vendor dependency. More than 80% of commits come from a single publisher, without a broad community. Consequence: the fork is theoretical but not viable — see family 6 — supply chain fragility for cases where the upstream event has hit the entire downstream field.
• Foreign foundation without an active European mirror. The project is hosted under the Linux Foundation, Apache or CNCF without a European equivalent — Eclipse, NLnet, certain PolyForm foundations. Not an automatic disqualification, but a signal to weigh: the LF decision of October 2024 documented that a foreign foundation can apply sanctions to its contributors.
• Captive registry without a tested alternative. npm, PyPI or GitHub Container Registry as the sole point of distribution, without a Codeberg, Forgejo or verified European mirror. Consequence: if the registry becomes unavailable or applies a sanction measure, your chain stops.
• Absence of an upstream commitment from the SaaS provider. A provider that consumes open source massively but does not contribute back — zero equivalent of pub-008-contribute-to-upstream. Consequence: the base on which it rests is funded by no one, and you with it.
• Domain 7 silent on the API, the roadmap, the support. The project says nothing about what it guarantees over time. Consequence: your integration can be broken at the next major version without recourse — see the turn documented in family 7 — the AI turn, where APIs taken for granted changed economics within a few months.
• Frozen declaration vs release cycle. The project has shipped two major versions since the last update of the Profile. Consequence: the chain described is no longer the current chain.
• Proprietary PaaS without a portability plan. Deployment rests on a specific runtime (Heroku, Vercel, Netlify, AWS Lambda, Cloudflare Workers) without an equivalent Dockerfile, without vendor-neutral manifests, without a quantified contractual reversibility clause. Consequence: your application is executable only where it is designed to run — the cost of migration is not budgeted, so it will fall in full on your future team.

How to act#

Reading a Profile is not enough — the reading must be turned into stack practice. Five gestures specific to the developer make the reading operational, and the specificity of this persona matters: the action can be individual, without passing through a collective purchase decision.

First, treat the Profile as an element of the dependency choice, on the same footing as the license and the known CVEs — a new gesture to acquire. The commitment dev-002-document-dependencies-jurisdiction formalises the documentation of the jurisdictions of the dependencies you pull.

Next, host your new projects on European forges when the context allows — Codeberg, Forgejo, EU self-hosted GitLab. This is dev-001-european-forge-new-projects, one of the rare commitments activatable without hierarchical validation.

Then, contribute to European projects rather than merely consuming them — dev-003-contribute-european-projects — and recommend to your peers to use a Profile to assess their own dependencies. dev-004-recommend-european-alternatives anchors this lever, decisive since dev choices often precede purchase decisions.

Documenting your own stack — dev-005-document-personal-stack-choices — makes your own technical choices readable and feeds the collective cartography.

Favour portable architectures — Dockerfile versus proprietary Procfile, docker-compose.yml or vendor-neutral Kubernetes manifests versus specific PaaS bindings, reproducible builds versus pipelines coupled to a single provider. The operational gesture, for a developer who already inherits a locked-in architecture, consists in requiring that an equivalent Dockerfile exist and that it be tested in CI on an alternative target — that is the guarantee that the exit is executable, not merely contractual. This preference joins the manifesto’s Compose-first posture: prefer lightweight self-hosting via Docker Compose to a Kubernetes-as-default-target whose American governance and heavy infrastructure weaken as much as they standardise.

Finally, fund maintainers — set aside an annual envelope for NLnet, Eclipse, Sovereign Tech Fund, or for the maintainers of the bricks one consumes. This is dev-006-fund-maintainers, a material alignment and not merely a declarative one. The assumed limits of the device clarify what these commitments claim to carry.

Prepare your own declaration#

The developer is not a provider in the strict sense of the manifesto, but the device opens a path to them that is open to no other persona: the declaration can be personal. A developer can publish their own list of commitments — forges used, projects they contribute to, maintainers they fund, documented stack choices. This is axis 4 of the manifesto applied to the individual: the grammar of the chain comes down to the personal gesture and structures the market from below. The basket below proposes the commitments and domains relevant to this persona, and the full philosophy of the device sets the frame.