The EU Open Source Solutions Catalogue is not a marketing directory. It is a federated inventory of open-source software already used—or recommended for reuse—across European public administrations, published under the Interoperable Europe programme. That framing matters: entries exist because governments, cities, and national platforms published them for reuse, not because a vendor paid for placement.
Most teams that hear “EU catalogue” either treat it as a compliance checkbox or ignore it entirely. Both miss the point. The catalogue is a discovery and reuse signal: if a ministry in another member state already runs a solution under a known license, your procurement and architecture reviews start from evidence instead of a blank spreadsheet. OpenSourceChoice mirrors that signal so you can filter and compare the same projects next to GitHub metrics, self-hosting posture, and country origin.
Use this guide to understand what the catalogue is, what it is not, how public admins should search it, and how OpenSourceChoice keeps EU listing metadata in sync without inventing projects. If you only need a shortlist of sovereign-friendly tools, jump to the related roundups; if you need provenance for a tender, stay for the sync and verification sections.
Key takeaways
- The EU OSS Catalogue federates national and city catalogues under Interoperable Europe—reuse and transparency first, marketing second.
- Treat catalogue presence as a discovery and provenance signal, not a security certification or SLA.
- Public admins should start from job-to-be-done, license, and operational ownership—then check EU listing metadata.
- OpenSourceChoice syncs eu_oss_url and source-catalogue fields monthly via a polite scrape and RPC apply_eu_oss_listing.
- Matching prefers existing catalog rows by EU URL, GitHub link, or slug—enrich first, insert only when new.
- Pair EU signals with self-hosted and country filters before locking a stack for residency-sensitive work.
What the Interoperable Europe catalogue actually is
Interoperable Europe publishes an EU Open Source Solutions Catalogue that aggregates solutions from member-state and city source catalogues—examples include Germany’s Open Code, France’s CodeGouvFr listings, Italy’s Developers Italia, the Netherlands’ Developer Overheid, Finland’s Avoinkoodi, and others. Each entry typically carries a title, description, license hints, repository or homepage links, and a pointer back to the federated source catalogue.
- Purpose: help European public-sector teams find reusable OSS with documented public-sector context.
- Shape: federated metadata, not a single curated “approved products” whitelist with warranties.
- Audience: CIOs, architects, procurement officers, and reuse communities—not only developers.
- Gap: operational maturity, security posture, and support contracts remain your due diligence.
How public administrations should use it
A useful search starts from the problem, not from the brand you want to replace. Catalogue browsing works best when you already know the capability class—document management, identity, case management, GIS, collaboration—and you are looking for peers who already adopted something under a clear license.
- Define the job: collaboration, identity, analytics, casework, infrastructure, or citizen-facing services.
- Filter for licenses your legal team already understands (EUPL, AGPL, MIT/Apache, MPL, and so on).
- Prefer solutions with an active public repository and a named maintaining organization.
- Ask operators—not vendors—how upgrades, backups, and identity integration actually work.
- Record data residency and subprocessors before pilots; EU listing does not imply EU hosting.
- Pilot on a non-critical workload with restore drills before any cutover commitment.
What OpenSourceChoice syncs—and what it does not
OpenSourceChoice runs a monthly sync against the EU Open Source Solutions Catalogue. The sync is deliberately polite (bounded concurrency and delay), matches listings to existing catalog projects when possible, and stores EU metadata such as the catalogue URL and federated source-catalogue label. That lets the UI surface an EU OSS badge and country/source context without rewriting project facts that already come from GitHub and catalog curation.
| Signal | What it means | What it does not mean |
|---|---|---|
| eu_oss_url | Project appears in the EU catalogue with a stable listing URL | Security audit, accessibility certificate, or support SLA |
| Source catalogue | Which national/city catalogue federated the entry | That the project HQ is in that country |
| Enrich existing row | Known project gains EU provenance metadata | Automatic ranking boost without GitHub/activity evidence |
| Insert when new | A catalogue-only project may appear if matching fails | Every federated entry is already production-ready for you |
Practical workflow: from catalogue hit to stack decision
- Find candidate solutions in the EU catalogue or via OpenSourceChoice EU badges.
- Open the project page: license, self-host signal, GitHub activity, and origin country.
- Compare two or three options in the same category—never pick the first familiar logo.
- Check whether you need self-hosting for residency or whether a European-hosted FOSS SaaS is enough.
- Build a minimal stack in the stack builder (identity + storage + observability) before buying seats elsewhere.
- Write the go/no-go: owner, RTO/RPO, upgrade cadence—same bar as any other self-hosted system.
Common mistakes
- Treating “listed in EU catalogue” as a substitute for a security review or DPIA.
- Assuming EU listing implies EU data residency for the hosted product or its CDN.
- Ignoring license obligations (especially copyleft and SaaS-triggered AGPL/SSPL debates).
- Skipping national source-catalogue context—local reuse communities often know failure modes.
- Syncing expectations: OpenSourceChoice updates metadata; it does not operate the software for you.
Frequently asked questions
- Is the EU Open Source Solutions Catalogue an official approved-software list?
- No. It is a federated reuse catalogue under Interoperable Europe. Presence helps discovery and provenance; it does not replace your security, accessibility, or procurement controls. Treat it as evidence that peers published a solution for reuse—not as a warranty.
- How does OpenSourceChoice keep EU listings up to date?
- A monthly sync job (GitHub Action or npm run eu-oss:sync) fetches catalogue data politely and applies listings through the apply_eu_oss_listing RPC. Matching prefers existing projects by EU URL, GitHub link, or slug; new rows are inserted only when no match exists. Secrets stay on the sync path—never a Supabase service_role key in the Worker.
- Should public admins prefer EU-listed projects over popular global OSS?
- Prefer fit: license, ops ownership, residency, and community health. EU listing is a positive signal for public-sector reuse, but a well-operated global project can still win. Use listing status to shortlist and justify reuse—not as a hard filter that excludes better operational fits.
- Where should I browse after reading a catalogue entry?
- Open the project in OpenSourceChoice, check self-hosted and country views, then compare category peers. For sovereignty-oriented stacks, continue with the GDPR/NIS2 stack guide and the European alternatives roundup, then validate ownership with the self-hosting decision framework.
- Does catalogue sync change rankings?
- EU metadata is a provenance badge and filterable context. Ranking still follows the catalog’s normal signals (such as public GitHub activity). Do not expect an EU badge alone to outrank a more active, better-documented alternative.
Conclusion
The EU Open Source Solutions Catalogue is most valuable when you treat it as federated public-sector memory: which solutions peers published for reuse, under which source catalogues, with which links and licenses. Combine that provenance with OpenSourceChoice’s self-hosted filters, country views, and stack builder so the next architecture review starts from evidence—not from the loudest US SaaS brand.
If you are choosing tools this week, open the country and category browsers, shortlist two options per job, and only then debate hosting models. Catalogue presence gets you into the room; operational honesty keeps you there.
Build a stack for this use case.
Answer nine practical questions and compare three transparent architectures with costs, free limits, lock-in, and migration paths.
Build my stack
