Startseite der Beteiligung
Dialog IT-Planungsrat | Open Government Moderne Verwaltung

Öffentlichkeitsbeteiligung zur Referenzarchitektur für E-Partizipationssoftware

Inhaltsverzeichnis

  • Referenzarchitektur für E-Partizipationssoftware
    • 2 Einführung E-Partizipation
    • 3 Anforderungen an die Software: Basisfunktionen
      • 3.1 User Stories
      • 3.2 Arbeitsprozesse beachten
    • 4 Konkrete Anwendungsfelder: Szenario-spezifische Anforderungen
      • 4.1 Szenario 1: Rückmeldungen zu einem Text einholen
        • 4.1.1 User Stories
        • 4.1.2 Notwendige und wünschenswerte Anforderungen
        • 4.1.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.2 Szenario 2: Rückmeldungen zu einer räumlichen Planung einholen
        • 4.2.1 User Stories
        • 4.2.2 Notwendige und wünschenswerte Anforderungen
        • 4.2.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.3 Szenario 3: Ideen zu einem Thema sammeln
        • 4.3.1 User Stories
        • 4.3.2 Notwendige und wünschenswerte Anforderungen
        • 4.3.3 Exkurs: Innovative Ansätze für die Anwendung der Funktionen
      • 4.4 Auswertung von Beteiligungsverfahren
    • 5 Technische Umsetzung
      • 5.1 Nicht-funktionale Anforderungen und Spezifikation
        • 5.1.1 Usability, Barrierefreiheit und Responsivität
        • 5.1.2 Mandantenfähigkeit
        • 5.1.3 Interoperabilität
        • 5.1.4 Operabilität
        • 5.1.5 Wartbarkeit, Erweiterbarkeit und Flexibilität
        • 5.1.6 Skalierbarkeit, Performanz und Verfügbarkeit
        • 5.1.7 Informationssicherheit und Datenschutz
        • 5.1.8 Open-Source-Basis
        • 5.1.9 Unterstützung offener Standards
        • 5.1.10 Exkurs: Innovative Ansätze für E-Partizipation
      • 5.2 Strukturelle Merkmale und Rahmenbedingungen
      • 5.3 Referenzarchitektur für E-Partizipationslösungen
        • 5.3.1 Zielsetzungen einer Referenzarchitektur
        • 5.3.2 Entwicklungsansätze
        • 5.3.3 Aufbau der Referenzarchitektur für E-Partizipationslösungen
        • 5.3.4 Interoperabilität als Schlüsselanforderung
        • 5.3.5 Exemplarischer Aufbau
34 von 43

5.1.8 Open-Source-Basis

Als Open-Source Software (OSS) wird Software bezeichnet, die von größtenteils freiwilligen Entwicklern entwickelt wird und deren Quellcode insbesondere offen, d.h. für jedermann zugänglich und in einem menschenlesbaren Format verfügbar ist. OSS ist heute allgegenwärtig und in nahezu allen Bereichen der Informationstechnik zu finden (etwa Linux, Android, der Web-Server Apache, das Content Management-System Drupal oder die Datenbank MySQL). Typischerweise wird OSS von einzelnen Personen oder Entwicklergemeinschaften (Communities) entwickelt und gepflegt. Oft sind jedoch auch Unternehmen an der (Weiter-) Entwicklung beteiligt, die ihr eigenes Produkt auf OSS aufsetzen und / oder Supportdienstleistungen kommerziell anbieten.

Beim Einsatz von OSS spielt die Lizenz eine entscheidende Rolle, unter der die Software bzw. Komponente steht. So ist Open-Source nicht als Freibrief zu verstehen, der jegliche Art der Nutzung, Anpassung und Weiterentwicklung ermöglicht. Vielmehr sind diese Punkte in der entsprechenden Lizenz verbindlich geregelt. Gängige Lizenzen sind die GNU General Public License (GPL), die GNU Lesser General Public License (LGPL) oder die Apache License. Diese Lizenzen ermöglichen uneingeschränkt einen produktiven Einsatz der Software (siehe Quellen) und nennen Bedingungen für das Anpassen der Software.

Hinweise für die Leistungsbeschreibung

In einer Leistungsbeschreibung sollte soweit erforderlich oder erwünscht die Verwendung von Open-Source-Software und -Komponenten gefordert werden. Ggf. sind erforderliche Projekte zu nennen.

Wie kann ich dies überprüft werden?

Ob eine eingesetzte Software „Open-Source“ ist und unter welcher Lizenz sie eingesetzt werden kann, lässt sich i. Allg. über die Webseite des entsprechenden Projektes in Erfahrung bringen. Im Rahmen einer Ausschreibung sollten Informationen hierzu eingefordert werden.

Quellen

Allgemeine Definition und Erklärung des Begriffes (Wikipedia)

Liste und Beschreibung der gängigsten und relevantesten Open-Source-Lizenzen

34 von 43

4 Beiträge

Sortieren nach:
Datum
Anzahl Kommentare
Anzahl Bewertungen
Deutscher Bundesjugendring

Definition und Motiviation für OSS im Kontext gesellschaftlicher Teilhabe

Bei diesem Unterkapitel ist die Adressatengruppe der Leser_innen nicht klar. Eine Zielgruppe, die eine Definition von OSS benötigt, wird möglicherweise mit der vorliegenden Auflistung beispielhafter OSS-Projekte überfordert sein. Gängigere Beispiele und eine etwas veränderte Reihung wäre unserer Ansicht nach hilfreich: LibreOffice/OpenOffice, Content-Management-Systeme wie Wordpress, Typo3 oder Drupal, Datenbanken wie MySQL und der am weitesten verbreite Webserver Apache, sowie Android und Linux. Dass als erstes Detail zu OSS aufgeführt wird, dass OSS größtenteils von „freiwilligen Entwicklern entwickelt wird”, stellt die Professionalität von OSS etwas in den Schatten. Es gibt zahlreiche erfolgreiche Business-Modelle rund um OSS – gerade die großen OSS-Projekte sind alles gute Beispiele hierfür. Die Entscheidung eine Software quelloffen zu entwickeln, rührt gerade in Bereichen wie Bildung und gesellschaftlicher Teilhabe aus ganz anderen Motiven her. Hier haben die untenstehenden Beiträge von Liquid Democracy e.V. bereits ausreichend Gründe dargelegt, die wir ausdrücklich unterstützen.

Liquid Democracy e.V.

Unabhängigkeit vom Hersteller

Unabhängigkeit vom Hersteller Mit der Verwendung oder Entwicklung von Open-Source-Software behalten die initiierenden Verwaltungen ihre Unabhängigkeit, da die Open-Source-Software nicht nur von einem einzelnen Anbieter (weiter-) entwickelt werden kann (Lock-in Effekt). Durch den frei verfügbaren Quellcode und die öffentliche Dokumentation der Software können viele verschiedene Anbieter und interessierte Bürger*innen die Software weiterentwickeln. Darüber hinaus entfallen teure Lizenzgebühren und die initiierenden Verwaltungen behalten die Flexibilität, die Software auch in Zukunft an ihre Bedürfnisse anpassen zu können. Sicherheit Ein öffentlich zugänglicher Quellcode ermöglicht ein schnelles Finden und Beheben von Sicherheitslücken und Fehlern, sodass alle Nutzer*innen der Software darauf vertrauen können, dass diese reibungslos und wie intendiert funktioniert. Teilen des Wissens Open-Source bedeutet nicht nur das freie Teilen der Software an sich, sondern beispielsweise auch des gesamten Wissens, das in seine Entwicklung gesteckt wurde. Somit könnten sich Bundesländer nicht nur Kosten und Entwicklung einer E-Partizipationssoftware teilen, sondern auch die Erfahrung und das Wissen, das in die Software eingeflossen ist (Standardisierung von Beteiligungsverfahren). Die Darstellung von Open-Source als "von größtenteils freiwilligen Entwicklern entwickelt" ist ggfs. täuschend. Wie richtig beschrieben wird, ist Open-Source-Software allgegenwärtig und wird weltweit von professionellen Großunternehmen entwickelt.

Liquid Democracy e.V.

Open-Source als Standard

Die Vorteile von Open-Source-Software - besonders im Kontext von öffentlicher digitaler Bürger*innenbeteiligung - kann nicht genug betont werden. Genau wie Barrierefreiheit, Datenschutz und andere nicht-funktionale Anforderungen, muss Open-Source als notwendige Anforderung für E-Partizipationssoftware verstanden werden. In einer Leistungsbeschreibung sollte daher notwendigerweise auf die Verwendung von Open-Source-Software bestanden werden. Open-Source als Standard Wie in dieser Referenzarchitektur in Bezug auf funktionale Anforderungen definiert wird: "Notwendige Funktionen beschreiben somit den Standard, den neueingeführte Systeme heute nicht mehr unterschreiten sollten.“ (S.14) lässt sich analog sagen, dass Open-Source eine notwendige nicht-funktionale Anforderung ist, die kontemporäre und neueingeführte Systeme nicht mehr unterschreiten dürfen. Vertrauen der Bürger*innen - transparenter Quellcode Wenn wir in Deutschland langfristig eine nachhaltige demokratische Kultur etablieren wollen, in der Bürger*innen in politische und administrative Vorgänge eingebunden werden und sich einbringen möchten, müssen wir besonders im Bereich E-Partizipation eine Vertrauensbasis schaffen. Doch wie ist das möglich, wenn Bürger*innen und Verwaltungsmitarbeitenden nicht einmal Einblick in die Funktionsweise der E-Partizipationssoftware gewährt wird, mit der die Beteiligung durchgeführt werden soll? Der Quellcode und damit die Funktionsweise von E-Partizipationssoftware muss daher für alle frei und offen verfügbar sein (Open-Source). Besonders wenn es um rechtsverbindliche Verfahren geht, sollte es im besonderen Interesse der Verwaltung sein, die Funktionalität der E-Partizipationssoftware so transparent wie möglich zu machen. Nur so können alle Teilnehmer*innen drauf vertrauen, dass die E-Partizipationssoftware im Interesse aller funktioniert und eine hohe Quellcodequalität hat. Gemeinnützigkeit & Kostenersparnis Wenn öffentliche Gelder für Softwareprodukte ausgegeben werden (Weiter-/Entwicklung, Miete, etc.), dann müssen die Ergebnisse der Allgemeinheit durch die Bereitstellung des Quellcodes und die freie Nutzung der Software zur Verfügung gestellt werden. Langfristig ist dies wirtschaftlicher für die Verwaltungen und Allgemeinheit, da alle Weiterentwicklungen der Software im gemeinnützigen Sinne immer allen interessierten Nutzer*innen kostenfrei zur Verfügung steht. Wenn also beispielsweise ein Bundesland in eine Open-Source E-Partizipationssoftware investiert, profitieren alle weiteren Bundesländer, die auch eine E-Partizipationssoftware benötigen, ebenfalls davon, da ihnen die Ergebnisse kostenlos zur freien Verfügung stehen. Anstatt immer wieder in proprietäre Einzellösungen zu investieren, für die nur eine kurzzeitige Lizensierung finanziert werden kann, sollte nachhaltig in Open-Source Lösungen investiert werden, von deren Weiterentwicklung und Nutzen alle profitieren.

Open Source Freibrief

"So ist Open-Source nicht als Freibrief zu verstehen, der jegliche Art der Nutzung, Anpassung und Weiterentwicklung ermöglicht. Vielmehr sind diese Punkte in der entsprechenden Lizenz verbindlich geregelt. Gängige Lizenzen sind die GNU General Public License (GPL), die GNU Lesser General Public License (LGPL) oder die Apache License. Diese Lizenzen ermöglichen uneingeschränkt einen produktiven Einsatz der Software (siehe Quellen) und nennen Bedingungen für das Anpassen der Software." Eine herrliche Formulierung: Es ist wahr, diese Lizenzen ermöglichen einen uneingeschränkten produktiven Einsatz, aber die GPL ermöglicht *keine* uneingeschränkte Weiterentwicklung, sondern erfordert eine Weiterentwickung unter der GPL in den meisten Szenarien (ich lasse hier bewußt lose Kopplungen heraus). Bitte stellen Sie hier auf (wie in der Verlinkung erläutert) den strengen Copyleft Aspekt der GPL heraus und das dies ein Spektrum ist. Es ist essentiell das in einem Referenzdokument dieser Aspekt zur Entscheidungsfindung beleuchtet wird: Es gibt eben sehr wohl restriktive Open Source Software Lizenzen die einen "Zwang" zu Open Source bedingen, der ja gewünscht und berechtigt sein kann. Dieser Zwang muss aber mit seinen Konsequenzen bekannt sein (Weiterentwicklung, Verbindung mit anderen Lizenzen, Überlassung,...). Im Deutschen Raum ist die Apache Lizenz V2.0 übrigens genau aus diesem Grund auch sehr häufig genutzt, weil die MIT Lizenz nicht anwendbar ist, und die Apache Lizenz V2.0 alle Freiheiten lässt und nicht zwingt, sondern sallopp gesagt nur die Haftung regelt.

Gegenstände

Übersicht

Informationen

Übersicht
  • Hintergrund zur Beteiligung
  • Design Thinking-Workshop
  • Entwurf Referenzarchitektur (Download *.pdf 1.8 MB)
zum Seitenanfang
Anmelden

Anmelden

Anmelden

Datenschutzeinstellungen

Es werden für den Betrieb der Seite technisch notwendige Cookies gesetzt. Darüber hinaus können Sie Inhalte von Drittanbietern erlauben. Ein Widerruf ist jederzeit möglich.
Weitere Informationen finden Sie unter Datenschutzerklärung und Impressum.