Aufnahmekriterien
Europe Alternatives listet sowohl kommerzielle europaeische Unternehmen als auch Open-Source-Projekte. Jeder Typ hat eigene Aufnahmekriterien, die unten beschrieben werden.
Kommerzielle Unternehmen
1. Europaeischer Hauptsitz
Das Unternehmen muss seinen Hauptsitz in einem europaeischen Land haben. Dies ist nicht auf EU-Mitgliedstaaten beschraenkt — Unternehmen aus jedem europaeischen Land qualifizieren sich, einschliesslich des EWR, der EFTA und anderer europaeischer Nationen.
2. Europaeische Mehrheitsbeteiligung
Die Mehrheit der Gesellschafter des Unternehmens muss europaeisch sein. Wenn ein europaeisches Unternehmen eine Muttergesellschaft oder einen Mehrheitsaktionaer hat, der nicht europaeisch ist, qualifiziert es sich nicht fuer die Aufnahme. Dies stellt sicher, dass gelistete Unternehmen tatsaechlich europaeisch 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 Loesungen.
Europaeische Laender und Handelsabkommen
Zur Referenz sind die folgenden die wichtigsten europaeischen Wirtschaftsbloecke und Abkommen. Unternehmen mit Hauptsitz in einem dieser Laender sind qualifiziert.
Europaeische Union (EU) — 27 Mitgliedstaaten
Oesterreich, Belgien, Bulgarien, Kroatien, Zypern, Tschechien, Daenemark, Estland, Finnland, Frankreich, Deutschland, Griechenland, Ungarn, Irland, Italien, Lettland, Litauen, Luxemburg, Malta, Niederlande, Polen, Portugal, Rumaenien, Slowakei, Slowenien, Spanien, Schweden
Europaeischer Wirtschaftsraum (EWR) — 30 Laender
Alle 27 EU-Mitgliedstaaten plus Island, Liechtenstein und Norwegen. Der EWR erweitert den EU-Binnenmarkt auf diese drei EFTA-Laender mit freiem Waren-, Dienstleistungs-, Kapital- und Personenverkehr.
Europaeische Freihandelsassoziation (EFTA) — 4 Laender
Island, Liechtenstein, Norwegen und die Schweiz. Waehrend Island, Liechtenstein und Norwegen am EWR teilnehmen, pflegt die Schweiz ihre Beziehung zur EU durch bilaterale Abkommen.
Andere europaeische Laender
Vereinigtes Koenigreich, Ukraine, Moldawien, Albanien, Serbien, Montenegro, Nordmazedonien, Bosnien und Herzegowina, Kosovo, Georgien, Armenien, Tuerkei (europaeischer Teil), Monaco, Andorra, San Marino und Vatikanstadt. Unternehmen aus diesen Laendern sind ebenfalls fuer die Aufnahme qualifiziert.
Open-Source-Projekte
Open-Source-Projekte werden in einer separaten Tabelle aufgefuehrt. Im Gegensatz zu kommerziellen Unternehmen benoetigen sie keinen europaeischen Hauptsitz oder Eigentum. Um aufgenommen zu werden, muss ein Projekt folgende Kriterien erfuellen.
1. Anerkannte Open-Source-Lizenz
Das Projekt muss unter einer von der OSI anerkannten Open-Source-Lizenz veroeffentlicht 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 aehnlich 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-Aktivitaet innerhalb der letzten 12 Monate. Eine Ausnahme kann fuer 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 fuer den Produktiveinsatz ueber die Erstinstallation hinaus geeignet ist:
- Upgrades und Migrationen — wie man sicher zwischen Versionen aktualisiert
- Backup und Restore oder Export/Import — wie man Daten schuetzt und verschiebt
5. Sicherheitskontakt / Offenlegungspfad
Das Projekt muss einen klaren Weg bieten, Sicherheitsluecken 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 proprietaeres Anbieter-Cloud-Backend fuer Kernfunktionalitaet zu benoetigen. Funktionen koennen zwischen selbst-gehosteten und anbieter-gehosteten Angeboten variieren, aber das Kernprodukt muss unabhaengig funktionieren.