Die Open CoDE Richtlinie zum Softwareverzeichnis ist das Rahmenwerk für die Aufnahme und Darstellung von Projekten und Lösungen unterschiedlicher Entwicklungszyklen und Stadien im Softwareverzeichnis. Ziel ist mithilfe dieser Richtlinie den Nutzenden transparent zu signalisieren, ob und wie eine Software für sie bzw. den Anwendungsfall verwendbar sein kann. Zudem soll frühzeitig die Kollaboration mit Fokus auf Rechtssicherheit im Kontext von OSS Lizenz Compliance Förderung finden.
Die Richtlinie definiert die Stadien des Softwareverzeichnis und sind zudem in die weiteren Strukturen von Open CoDE integriert. So stellen verschiedene Bestandteile der Nutzungsbedingungen bereits urheberrechtliche Eckpfeiler auf, um ein Mindestmaß an Anforderungen auf der Plattform zu forcieren.
Abbildung 1: Darstellung der Stadien im Softwareverzeichnis
Das Softwareverzeichnis ist in verschiedene Stadien mit jeweils dazugehörigen Qualitätssicherungsmaßnahmen und Anforderungen untergliedert. Diese stellen jeweils ausgewählte Prüfungskategorien dar. Zusätzliche Qualifikationen, etwa durch die Detailprüfungen des ZenDiS[1] werden zusätzlich ausgewiesen.
¶ 1. Stadien im Softwareverzeichnis und deren Anforderungen
¶ 1.1. Stadium „Steckbief“
Die Einordnung durch die Repository Owner in das Stadium „Steckbrief“ bringt zum Ausdruck, dass sowohl Entwicklungsstand als auch Reifegrad der Lösung am Anfang stehen. Beispielsweise können hier auch konzeptionelle Ideen oder Anforderungen ohne existierenden Quellcode aufgenommen werden.
Entsprechend der kollaborativen Zielsetzung ist es für dieses Stadium ausreichend, wenn ein Repository angelegt, sich auf Rahmenbedingungen verständigt und mit Konzeptionsdokumenten befüllt ist. Durch die Darstellung im Softwareverzeichnis kann frühzeitig Kollaboration ermöglicht und Transparenz geschaffen werden.
¶ 1.1.1. Qualitätssichernde Anforderungen
Zur Erreichung der Zielsetzung sind im Softwareverzeichnis qualitätssichernde Maßnahmen notwendig. Die Einhaltung der folgenden Anforderungen der Richtlinie ist erforderlich, um in dem Stadium „Steckbrief“ gelistet zu werden:
- Rahmenbedingungen der Plattform müssen akzeptiert und eingehalten werden, bspw. Nutzungsbedingungen, Code of Conduct.
- Werthaltige und verständliche Beschreibung des Vorhabens bzw. Projekts muss vorliegen.
- Das Projekt muss durch die Öffentliche Verwaltung oder in deren Auftrag auf Open CoDE eingestellt sein.
- Verantwortlichkeit für das Vorhaben bzw. Projekt muss eine reale Person sein.
¶ 1.2. Stadium „Projekt“
Eine Einordnung in die Kategorie „Projekt“ bringt zum Ausdruck, dass der Entwicklungsstand fortgeschritten ist und der Reifegrad des Projekts sich durch existente Strukturen auszeichnet.
Durch die Darstellung im Softwareverzeichnis kann Kollaboration für zu einem frühen Entwicklungszeitpunkt ermöglicht werden. Ebenso sollen fertige Lösungen in diesem Zustand verweilen können, sofern deren Prüfung und Sicherung nicht durch das ZenDiS[1] angestrebt werden.
Zusätzlich wird der „Developmentstatus“, prominent dargestellt, um Produktionsreife darzulegen. Hierbei wird unterschieden zwischen dem Status „beta“ und Status „stable“.
¶ 1.2.1. Qualitätssicherende Anforderungen
Zur Erreichung der Zielsetzung sind im Softwareverzeichnis qualitätssichernde Maßnahmen notwendig. Die Einhaltung der folgenden Anforderungen der Richtlinie ist zusätzlich zu allen Anforderungen des Steckbriefes erforderlich, um in dem Stadium „Projekt“ gelistet zu werden:
- Ein Management der CVEs der Abhängigkeiten muss implementiert und funktionstüchtig sein.
- Automatisierte Tests müssen implementiert und funktionstüchtig sein.
- Kontaktstelle zur Meldung von Sicherheitslücken muss implementiert und funktionstüchtig sein.
- Kontaktstelle zur Meldung von Bugs muss implementiert und funktionstüchtig sein.
- Eine Komponentenliste(SBOM) muss dokumentiert sein.
- Releases und zugehörige Release Notes müssen vorliegen.
- Dokumentation für die Nutzenden über Installation, Verwendungszwecke und Integrationen muss existieren.
- Das Projekt muss in einer für das Projekt üblichen Weise installierbar sein.
¶ 2. Aufnahme ins Softwareverzeichnis
Das Interesse zur Aufnahme in das Softwareverzeichnis muss durch die Projekte der Plattform ausgedrückt werden. Die Interessensbekundung wird durch Existenz einer publiccode.yaml innerhalb der Repositories geäußert. Die Repositories der Plattform werden kontinuierlich nach diesen Dateien überprüft.
Ist als „developmentStatus“ dabei „concept/development“ angegeben, wird das Projekt für das erste Stadium „Steckbrief“ vorgesehen. Alle anderen Angaben führen zur automatischen Prüfung nach dem zweiten Stadium „Projekt“.
Ergänzende Dokumentation zu den Prüfungsinhalten und Methodik des jeweiligen Stadiums im Softwareverzeichnis kann zu späterer Stelle dann [hier] eingesehen werden.
¶ 2.1 publiccode.yml
Die notwendigen Schlüsselworte und Anforderungen an die publiccode.yml entspringen dem Metadaten Standard für Software von Öffentlichen Verwaltungen [extern] und sind dem Standardisierungsprojekt entnommen. Die Mindestangaben sind im Folgenden mit einem Beispiel angegeben. Optionale, aber als sinnvoll erachtete Schlüsselworte sind als solche gekennzeichnet.
¶ Die minimum viable Publiccode.yml
¶ publiccodeYmlVersion
- Datentyp: String
- Beispiel: “0.2.1”
¶ name
- Datentyp: String
- Beispiel: “Hundesteuer App”
¶ url
- Datentyp: String (URL)
- Beispiel: “https://gitlab.o4oe.de/owner/Hundesteuer-App”
¶ releaseDate
- Datentyp: String (Datum) in “YYYY-MM-DD”
- Beispiel: “2022-02-22”
¶ softwareVersion
- Datentyp: String
- Beispiel: “1.0”
- Optional
¶ platforms
- Datentyp: Array an Strings
- Werte: [web, windows, mac, linux, ios, android]
- Beispiel: - web
- linux
¶ categories
- Datentyp: Array an Strings
- Werte: siehe Tabelle aller Möglichen Kategorien
- Beispiel: - email-management
- email-marketing
¶ developmentStatus
- Datentyp: String
- Werte: [concept, development, beta, stable, obsolete]
- Beispiel: stable
¶ softwareType
- Datentyp: String
- Werte: ["standalone/mobile", "standalone/iot", "standalone/desktop", "standalone/web", "standalone/backend", "standalone/other", "addon", "library", "configurationFiles"]
- Beispiel: standalone/web
¶ description/[lang]/genericName
- Datentyp: String, generischer Name für die Tätigkeit des Projekts
- Beispiel: “Steuerberechnung App”
¶ description/[lang]/shortDescription
- Datentyp: String
- Beispiel: “Eintragung und Abrechnung der Hundesteuer”
¶ description/[lang]/longDescription
- Datentyp: String
- Beispiel: “[…]” Überblick über die Fähigkeiten des Projekts für potentielle Nutzende
¶ description/[lang]/features
- Datentyp: Array an Strings
- Werte: Freitext für Worte bis 100 Zeichen
- Beispiel: - Hundeanmeldung
- Hundesteuer Berechnung
¶ legal/license
- Datentyp: String mit Logikverbindung (OR/AND/WITH) bei Mehrfachlizenzierung (SPDX Identifier)
- Beispiel: BSD-3-Clause
¶ maintenance/type
- Datentyp: String
- Werte: ["internal", "contract", "community", "none"]
- Beispiel: community
¶ maintenance/contractors
- Datentyp: Array an Strings WENN maintenance/type “contract” ist
- Werte: Angaben für Name, Email, Website, Vertragsablauf
- Beispiel: - name: “Dienstleister XYZ”
email: “dienstleister@xyz.de”
website: “xyz.de”
until: “2023-01-01”
¶ maintenance/contacts
- Datentyp: Array an Strings WENN maintenance/type “internal” oder “community” ist
- Werte: Angaben für Name, Email, Zugehörigkeit der Öffentlichen Verwaltung, ggf. Telefonnummer
- Beispiel: - name: “Erika Mustermann”
email: “Erika@mustermann.de”
affiliation: “Bundeshauptstadt Berlin”
phone: “[…]”
¶ localisation/localisationReady
- Datentyp: Boolean, Eigenschaft zur Möglichkeit mehrere Sprachen (muss nicht aktuell vorliegen)
- Beispiel: yes
¶ localisation/availableLanguages
- Datentyp: Array an Strings
- Werte: IETF BCP 47 Sprachkürzel
- Beispiel: - de
- en
¶ de/countryExtensionVersion
- Datentyp: String
- Beispiel: “0.2”
- Optional
¶ de/leika
- Datentyp: Array an Strings
- Werte: Angaben verpflichtend: Leika-ID, optional: Themenfeld, Lebenslage, OZG-ID,
- Beispiel: - themenfeld: “Engagement & Hobby”
lebenslage: “Tierhaltung”
ozg-id: “10160”
leika-id: “99102013000000” - Optional
¶ Verfügbare Kategorien
| - accounting - agile-project-management - applicant-tracking - application-development - appointment-scheduling - backup - billing-and-invoicing - blog - budgeting - business-intelligence - business-process-management - cad - call-center-management - cloud-management - collaboration - communications - compliance-management - contact-management - content-management - crm - customer-service-and-support - data-analytics - data-collection - data-visualization - digital-asset-management - digital-citizenship - document-management - donor-management - e-commerce - e-signature - email-management - email-marketing - employee-management |
- enterprise-project-management - enterprise-social-networking - erp - event-management - facility-management - feedback-and-reviews-management - financial-reporting - fleet-management - fundraising - gamification - geographic-information-systems - grant-management - graphic-design - help-desk - hr - ide - identity-management - instant-messaging - inventory-management - it-asset-management - it-development - it-management - it-security - it-service-management - knowledge-management - learning-management-system - marketing - mind-mapping - mobile-marketing - mobile-payment - network-management - office - online-booking |
- online-community - payment-gateway - payroll - predictive-analysis - procurement - productivity-suite - project-collaboration - project-management - property-management - real-estate-management - remote-support - resource-management - sales-management - seo - service-desk - social-media-management - survey - talent-management - task-management - taxes-management - test-management - time-management - time-tracking - translation - video-conferencing - video-editing - visitor-management - voip - warehouse-management - web-collaboration - web-conferencing - website-builder - workflow-management |
[1] Hinweis zum ZenDis: Dieser Punkt wird zukünftig geplant, jedoch noch nicht aktiv zum aktuellen Zeitpunkt (Februar 2022).