Aufnahmekriterien
Europe Alternatives listet sowohl kommerzielle europäische Unternehmen als auch Open-Source-Projekte. Jeder Typ hat eigene Aufnahmekriterien, die unten beschrieben werden.
Kommerzielle Unternehmen
1. Europäischer Hauptsitz
Das Unternehmen muss seinen Hauptsitz in einem europäischen Land haben. Dies ist nicht auf EU-Mitgliedstaaten beschränkt — Unternehmen aus jedem europäischen Land qualifizieren sich, einschließlich des EWR, der EFTA und anderer europäischer Nationen.
2. Europäische Mehrheitsbeteiligung
Die Mehrheit der Gesellschafter des Unternehmens muss europäisch sein. Wenn ein europäisches Unternehmen eine Muttergesellschaft oder einen Mehrheitsaktionär hat, der nicht europäisch ist, qualifiziert es sich nicht für die Aufnahme. Dies stellt sicher, dass gelistete Unternehmen tatsächlich europäisch kontrolliert sind.
3. SaaS- oder Cloud-Dienst
Das Unternehmen muss ein Software-as-a-Service (SaaS) oder cloudbasiertes Produkt oder einen Dienst anbieten. Dies umfasst gehostete Software, Cloud-Infrastruktur, Plattformdienste und andere webbasierte Lösungen.
Europäische Länder und Handelsabkommen
Zur Referenz sind die folgenden die wichtigsten europäischen Wirtschaftsblöcke und Abkommen. Unternehmen mit Hauptsitz in einem dieser Länder sind qualifiziert.
Europäische Union (EU) — 27 Mitgliedstaaten
Österreich, Belgien, Bulgarien, Kroatien, Zypern, Tschechien, Dänemark, Estland, Finnland, Frankreich, Deutschland, Griechenland, Ungarn, Irland, Italien, Lettland, Litauen, Luxemburg, Malta, Niederlande, Polen, Portugal, Rumänien, Slowakei, Slowenien, Spanien, Schweden
Europäischer Wirtschaftsraum (EWR) — 30 Länder
Alle 27 EU-Mitgliedstaaten plus Island, Liechtenstein und Norwegen. Der EWR erweitert den EU-Binnenmarkt auf diese drei EFTA-Länder mit freiem Waren-, Dienstleistungs-, Kapital- und Personenverkehr.
Europäische Freihandelsassoziation (EFTA) — 4 Länder
Island, Liechtenstein, Norwegen und die Schweiz. Während Island, Liechtenstein und Norwegen am EWR teilnehmen, pflegt die Schweiz ihre Beziehung zur EU durch bilaterale Abkommen.
Andere europäische Länder
Vereinigtes Königreich, Ukraine, Moldawien, Albanien, Serbien, Montenegro, Nordmazedonien, Bosnien und Herzegowina, Kosovo, Georgien, Armenien, Türkei (europäischer Teil), Monaco, Andorra, San Marino und Vatikanstadt. Unternehmen aus diesen Ländern sind ebenfalls für die Aufnahme qualifiziert.
Open-Source-Projekte
Open-Source-Projekte werden in einer separaten Tabelle aufgeführt. Im Gegensatz zu kommerziellen Unternehmen benötigen sie keinen europäischen Hauptsitz oder Eigentum. Um aufgenommen zu werden, muss ein Projekt folgende Kriterien erfüllen.
1. Anerkannte Open-Source-Lizenz
Das Projekt muss unter einer von der OSI anerkannten Open-Source-Lizenz veröffentlicht sein (z.B. MIT, Apache 2.0, GPL-3.0, AGPL-3.0, MPL-2.0). Projekte mit „Source Available“, „Nicht-kommerziell“, „Commons Clause“ oder ähnlich restriktiven Lizenzen qualifizieren sich nicht.
2. Self-Hostbar mit offizieller Dokumentation
Das Projekt muss realistisch self-hostbar sein, mit offizieller Installationsdokumentation und mindestens einem Standard-Deployment-Pfad, wie:
- Docker und Docker Compose
- Helm Charts oder Kubernetes Manifeste
- Betriebssystempakete (deb, rpm, etc.)
„Nur aus Quellcode bauen“ ohne klare Deployment-Anleitung ist nicht ausreichend.
3. Aktiv gewartet
Das Projekt muss laufende Wartung zeigen: ein Release oder bedeutsame Commit-Aktivität innerhalb der letzten 12 Monate. Eine Ausnahme kann für Projekte gemacht werden, die sich explizit im „Wartungsmodus“ befinden, wenn ihre Betriebs- und Sicherheitsdokumentation stark ist.
4. Betriebsbereit (Day-2 Readiness)
Die Dokumentation muss mindestens die folgenden Bereiche abdecken, um sicherzustellen, dass das Projekt für den Produktiveinsatz über die Erstinstallation hinaus geeignet ist:
- Upgrades und Migrationen — wie man sicher zwischen Versionen aktualisiert
- Backup und Restore oder Export/Import — wie man Daten schützt und verschiebt
5. Sicherheitskontakt / Offenlegungspfad
Das Projekt muss einen klaren Weg bieten, Sicherheitslücken verantwortungsvoll zu melden. Akzeptable Methoden umfassen:
- Eine SECURITY.md-Datei im Repository
- Eine dedizierte Sicherheits-E-Mail-Adresse
- Ein dokumentierter Offenlegungsprozess oder Bug-Bounty-Programm
6. Keine „SaaS-Falle“
Die selbst-gehostete Version muss sinnvoll nutzbar sein, ohne ein proprietäres Anbieter-Cloud-Backend für Kernfunktionalität zu benötigen. Funktionen können zwischen selbst-gehosteten und anbieter-gehosteten Angeboten variieren, aber das Kernprodukt muss unabhängig funktionieren.