Checkliste zur Evaluierung von Open-Source-Projekten

Kläre zuerst den Einsatzkontext. Definiere Muss-Anforderungen, regulatorische Vorgaben und Integrationsgrenzen. Lege gleichzeitig KO-Kriterien fest, bei denen ein Projekt sofort ausscheidet.

Diese Kriterien sollten stehen, bevor attraktive Funktionen oder eine starke Community die Bewertung verzerren.

• Typische KO-Kriterien sind eine unpassende Lizenz, kritische ungefixte Sicherheitslücken oder ein fehlender Datenexport

Ein kurzer Schnellcheck spart Zeit. So erkennst du früh, ob sich eine vertiefte Evaluierung lohnt. Er ersetzt aber keine Detailprüfung.

• Letzte Releases und Commit-Aktivität auf GitHub in den letzten 6-12 Monaten
• Wie lange existiert das Projekt und wie kontinuierlich wird es weiterentwickelt?
• Offene kritische Issues und bekannte CVEs
• Lizenztyp und offensichtliche Ausschlussgründe
• Qualität der Dokumentation für Installation, Betrieb und Migration
• Sichtbarer produktiver Einsatz in realen Organisationen

Ein Projekt ist nicht automatisch gut, nur weil es viel kann. Ein zu grosser Funktionsumfang erhöht oft die Komplexität, verlängert die Einführung und steigert den Betriebsaufwand.

Eine schlankere Lösung mit besserem Problem-Fit ist in der Praxis oft robuster und günstiger.

• Deckt die Lösung eure Muss-Anforderungen ohne Workarounds ab?
• Welche Funktionen sind für euch Ballast?
• Erhöht der Funktionsumfang den Schulungs- und Administrationsaufwand?
• Gibt es eine schlankere Alternative mit vergleichbarem Nutzen?

Viele Projekte wirken im Test überzeugend, scheitern später aber bei mobilem Einsatz, Sprachunterstützung oder beim Rollenmodell. Prüfe deshalb früh, ob die Lösung zu euren Abläufen und Verantwortlichkeiten passt.

• Ist Mobile-Support vorhanden als native App, PWA oder über Drittanbieter?
• Falls Mobile relevant ist, gibt es eine ausreichende Feature-Parität zur Web-Version?
• Unterstützt die Lösung die benötigten Sprachen für Benutzeroberfläche und Inhalte?
• Passt das Berechtigungssystem zu euren Rollen, Teams und möglichen Mandanten?
• Lassen sich Rechte granular und revisionssicher verwalten?
• Gibt es SSO-Support über OIDC oder SAML?
• Falls nötig, gibt es Provisionierung über SCIM oder eine gleichwertige Alternative?

Prüfe, ob die Lizenz zu eurer Nutzung passt. Entscheidend sind nicht nur Kosten, sondern auch Nutzungsrechte, Weitergaberegeln und Pflichten im Betrieb.

Mehr Grundlagen zu Lizenzmodellen findest du im Artikel «Softwarelizenzen».

• Passt die Lizenz zu internem Betrieb, Cloud-Nutzung und Weiterentwicklung?
• Gibt es Pflichten aus Copyleft-Lizenzen für eure konkrete Nutzung?
• Handelt es sich um echte Open Source oder eher um Open Core bzw. Source Available?
• Sind zentrale Funktionen nur in einer kostenpflichtigen Zusatzversion verfügbar?
• Sind Lizenztexte, Copyright-Hinweise und Drittkomponenten sauber dokumentiert?
• Gibt es ein klares Vorgehen für Lizenz- und Compliance-Prüfungen?

Sicherheit ist ein laufender Prozess. Entscheidend sind schnelle Reaktionen, Transparenz und ein Ablauf für Sicherheitsupdates, der im Alltag funktioniert.

• Gibt es eine öffentliche Security-Policy und einen Meldeprozess?
• Wie schnell werden kritische Sicherheitslücken behoben?
• Wie hoch ist das Risiko durch indirekte Abhängigkeiten, also weitere Bibliotheken im Hintergrund?
• Sind sichere Updates mit vertretbarem Aufwand planbar?
• Wie häufig und wie gravierend waren grössere Änderungen, durch die bestehende Funktionen nicht mehr wie erwartet funktionieren?

Die technische Grundlage entscheidet, wie gut ihr die Lösung im Alltag warten könnt und wie handlungsfähig ihr im Krisenfall bleibt.

• Wie gut sind Programmiersprache und Datenbank am Arbeitsmarkt verfügbar?
• Könnt ihr die Lösung im Ernstfall selbst weiterentwickeln oder zumindest stabil betreiben, ohne Spezialwissen einzelner Personen?
• Wie sparsam läuft das System mit CPU, RAM und Speicher unter eurer erwarteten Last?
• Wie aufwändig sind Einrichtung und Betrieb, zum Beispiel mit Docker Compose, Kubernetes oder Managed Hosting?
• Sind Backup und Restore im Betrieb praktikabel, schnell und verlässlich?
• Lassen sich Wiederherstellungstests regelmässig und zuverlässig gleich durchführen?
• Wie verständlich ist das Datenbanklayout für Analyse, Migration und Notfallbetrieb?
• Könnt ihr bei Bedarf eine alternative Anwendung auf dem Datenmodell aufbauen?

Die Qualität eines Projekts hängt stark von Menschen und Prozessen ab. Einzelne Schlüsselpersonen helfen, ersetzen aber keine tragfähige Governance.

• Wie viele aktive Maintainer und regelmässige Beitragende gibt es auf GitHub, und wie sind die Beiträge verteilt?
• Wie schnell reagieren Maintainer auf Issues und Pull Requests?
• Sind Roadmap, Release-Prozess und Entscheidungswege transparent?
• Wie hoch ist das Risiko, wenn zentrale Personen ausfallen?

Beliebtheit kann ein Hinweis sein, ist aber kein Qualitätsbeweis. Ordne GitHub-Signale immer im Zusammenhang ein.

• Wie entwickelt sich die Anzahl Sterne über die Zeit, zum Beispiel mit star-history.com? Berücksichtige, dass Sterne manipulierbar sind und nicht die technische Reife messen.
• Passt die Entwicklung der Sterne zur Aktivität bei Issues und Pull Requests?
• Lassen sich starke Wachstumssprünge gut erklären, zum Beispiel durch ein Release oder Medienaufmerksamkeit?

Beide Modelle können gut funktionieren. Entscheidend ist, welche Risiken für euren Einsatz schwerer wiegen.

Community-getragene Projekte sind oft offener und senken die Abhängigkeit von einem einzelnen Anbieter. Company-getragene Projekte bieten häufig klarere Produktführung und professionellere Services. Bei VC-finanzierten Unternehmen kann zusätzlicher Druck entstehen, schneller Geld zu verdienen oder die Richtung zu ändern.

• Wer kontrolliert Repository, Marke und Release-Rechte?
• Wie unabhängig ist das Projekt von einem einzelnen Unternehmen?
• Ist das Open-Source-Modell stabil oder stark vom Verkauf kostenpflichtiger Zusatzfunktionen abhängig?
• Gab es früher Lizenzwechsel oder starke Produktverschiebungen?
• Wie stabil wirkt das Modell bei ausbleibendem Wachstum oder sinkender Finanzierung?

Auch bei Open Source kann professioneller Support entscheidend sein. Gerade für kritische Systeme brauchst du planbare Reaktionszeiten und klare Wege, wenn Probleme eskalieren.

• Gibt es kommerziellen Support direkt vom Kernteam oder von Partnern?
• Wie viele unabhängige Dienstleister mit Praxiserfahrung gibt es im Markt?
• Welche SLAs mit garantierten Reaktionszeiten sind verfügbar und passen sie zu euren Betriebszeiten?
• Gibt es Unterstützung für Migration, Upgrades und Sicherheitsvorfälle?
• Sind Kosten, Vertragslaufzeiten und Leistungsumfang klar planbar?

Digitale Souveränität zeigt sich spätestens beim Wechsel. Ein Exit-Szenario sollte deshalb schon in der Evaluierung mitgedacht werden.

• Sind Schnittstellen (APIs) und Datenmodelle gut dokumentiert und stabil?
• Gibt es dokumentierte Schnittstellen für Plugins oder Erweiterungsmodule?
• Ist ein vollständiger Export in offenen Formaten möglich?
• Könnt ihr den Betrieb bei Bedarf selbst übernehmen oder mit einem anderen Partner fortführen?
• Wie hoch ist der Aufwand für Migration oder einen Fork im Ernstfall?

Prüfe als Praxistest, ob eure Annahmen zu Betrieb und Exit auch dann tragen, wenn ein Projekt während 12-24 Monaten kaum gepflegt wird.

• Könnt ihr auf einer stabilen Version sicher weiterarbeiten?
• Habt ihr Zugriff auf Wissen, um kritische Fehlerbehebungen umzusetzen oder zu beauftragen?
• Gibt es realistische Alternativen inklusive Migrationsweg?
• Sind Daten, Konfigurationen und Automatisierungen gut genug übertragbar für einen Wechsel?

Filtere zuerst mit deinen KO-Kriterien aus dem Schnellcheck und bewerte dann die übrigen Kandidaten mit einem einfachen Bewertungsmodell. Bewerte beispielsweise jedes Kriterium auf einer Skala von 0 bis 10 und multipliziere es mit einer Gewichtung von 1 bis 3.

• 0 = nicht erfüllt, 5 = ausreichend, 10 = sehr gut
• Gewichtung 3 für kritische Bereiche wie Sicherheit, Lizenz und Datenportabilität
• Beispiel: Sicherheit mit 8 Punkten und Gewichtung 3 ergibt 24 Punkte

Vergleiche am Schluss die Gesamtpunktzahl der verbleibenden Kandidaten und berücksichtige nicht nur Features, sondern auch, wie sich die Software beim Testen anfühlt. Mehr dazu findest du im Artikel «Kriterien für die Softwareauswahl».