Nutzbarkeitsanalyse
Um existierende freie Software zu nutzen oder sogar weiter entwickeln zu können muss diese zunächst einer Nutzbarkeitsanalyse unterzogen werden. Diese soll jegliche freie Software, unabhängig ob diese als Framework, Library, Entwicklungstools fertige Software eingesetzt werden soll, durchlaufen.
Code Review
Die Bewertung des Codes erfolgt durch erfahrene Entwickler*innen, die mit der verwendeten Sprache und Technologie vertraut sind. Folgende Fragen sollen dabei beantwortet werden:
- Wird ein Framework genutzt? Falls nicht, was ist die Begründung? Falls ja, sollten Auswahl und Einbindung bewertet werden.
- Wie lange ist geschätzte Einarbeitungszeit für eine/n Entwickler*in?
- Alle Funktionen sollen nicht nur über die grafische Benutzeroberfläche (GUI), sondern auch über eine generelle, non-proprietäre und vollumfängliche Programmierschnittstellen (API) bereitstellt werden. Im Idealfall mit zugehöriger OpenAPI-Spec.
Der Fokus liegt dabei auf der potentiellen Wartbarkeit und Sicherheit der Software.
Sicherheit
Öffentlich zugänglicher Code lässt auf die IT-Sicherheit leicht überprüfen. Ein Vorteil von freier Software ist die Transparenz des Quellcodes, so können Sicherheitsforscher und Entwickler Open Source Software überprüfen. Allerdings muss geprüft werden ob die IT-Sicherheit auch aktiv sichergestellt wird und ob dazu geeignete Werkzeuge vorliegen:
- werden Codeänderungen ausschliesslich durch verantwortliche und benannte Hauptentwickler (Maintainer) in einem Freigabeverfahren durchgeführt (z.B. durch protected branches).
- wie schnell war die Reaktionsgeschwindigkeit bei vergangenen Sicherheitsvorfällen.
- werden Maintainer durch Unternehmen oder durch andere Geschäftsmodelle für ihre Aufgabe ausreichend finanziell unterstüzt.
- Liegt eine Auflistung von Common Vulnerabilities and Exposures (CVE) vor und wird diese entsprechend der Dringlichkeit bearbeitet.
- Sind alle Abhängigkeiten nicht nur einsehbar, sondern sind potenzielle Risiken auch durch eine Software Bill of Materials in diesen Abhängigkeiten transparent.
- Liegen externe Audits vor (z.B. wie bei curl), können diese positiv gewertet werden
Dokumentation
Eine umfassende Dokumentation ist für jede Software unerlässlich, insbesondere für Open Source Software, die von anderen genutzt oder verändert werden soll. Sie gewährleistet Transparenz, Nachvollziehbarkeit und eine einfache Nutzung und Weiterentwicklung. Eine klare und detaillierte Dokumentation, sowohl im Quellcode als auch in begleitenden Dateien, ist eine grundlegende Voraussetzung, um die Zugänglichkeit und Nutzbarkeit der Software sicherzustellen.
Jedes Softwareprojekt soll entweder einen strukturierten Dokumentationsordner /docs oder eine eigene Wiki oder Website bereitstellen. Die technische Dokumentation soll alle Funktionen, Schnittstellen und Benutzeroberflächen der Software beschreiben. Dazu gehören insbesondere:
- Nutzung und Benutzeroberflächen
- jede API-Referenzen
- Installations- und Wartungsanleitungen
- Technische Hintergründe und Architektur
Die technische Dokumentation muss in Englisch geschreiben sein, um international verständlich zu sein, weitere Sprachen sind sinnvoll.
Ein Benutzerhandbuch sollte idealerweise zweisprachig (Deutsch und Englisch) verfügbar sein.
Die Dokumentation muss frei im Internet zugänglich und in offenen Formaten (z. B. Markdown, HTML, Text) bereitgestellt werden. Es muss die Möglichkeit bestehen, Vorschläge zur Verbesserung der Dokumentation einzureichen (z. B. über Pull Requests).
Das Erstellen und Pflegen von Dokumentation erfordert 10–20% der Entwicklungszeit. Sie muss regelmäßig aktualisiert werden, um jede neue oder geänderte Funktion zu dokumentieren.
Jedes Softwarerepository muss eine README.md in englischer Sprache im Hauptverzeichnis enthalten und soll folgende Fragen beantworten:
- Was macht dieses Projekt?
- Warum ist es nützlich?
- Wie kann ich es nutzen oder dazu etwas beitragen?
- Wo erhalte ich Unterstützung?
Externe Unterstützung
Die Verfügbarkeit externer Unterstützung ist im professionellen Betrieb als auch bei Änderungswünschen wichtig. Diese Unterstützung kann durch eine aktive Community oder einen kommerziellen Anbieter angeboten werden.
Eine große und engagierte Community kann diese Unterstützung grundsätzlich auch liefern, aber wenn kommerzieller Support angeboten wird, sollte dieser grundsätzlich bevorzugt werden. Denn kommerzieller Support bietet in der Regel eine verlässlichere und professionellere Unterstützung an, was besonders in sicherheits- und betriebskritischen Situationen von Vorteil ist.
Sollte kein kommerzieller Support verfügbar oder zu teuer sein, muss sicher gestellt sein dass wir die notwendigen Kompetenzen im Haus haben. Dazu kann es notwendig sein, das wir Schulungen und Weiterbildungen für unsere Mitarbeitenden beschaffen.
Die Anzahl an Stars, Watchers, Contributors oder Pull Requests können eine Indikation für eine große Community sein, muss aber nicht sein.[1].
DevOps
Software besteht nicht nur aus Quellcode sondern ist eingebettet in Automatisierungen für Testing und Deployment. Daher prüfen wir ob ein öffentlich einsehbares Continuous Integration und Deployment (CI/CD) vorhanden ist, auch bei den von uns präferierten SaaS Lösungen als Teil der Exitstrategie.
- Sind Quellcode, Artefakte, Releases, Container etc. in gängigen Repositories verfügbar.
- Sind diese nach semver versioniert und werden auch kleinteilige Änderungen als neuen Versionen veröffentlicht.
- Ermöglicht die Software ein konfigurierbares Logging nach den gängigen Log-Levels.
- Gibt es dokumentierte Konfigurationsmöglichkeiten von:
- Ressourcen (Rechenleistung, Speicher etc)
- Ressourcenarten (z.B. unterschiedliche Speicherarten wie Block File, Object)
- Sicherheitseinstellungen, (z.B. nutzung lokaler Zertifizierungsstellen, Sicherheitskontexte)
Sonatype 2019 Software Supply Chain Report aus The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations Gene Kim, Jez Humble, Patrick Debois, John Willis ISBN-10: 1950508404 S. 365 ↩︎