Vielen Dank für den Beitrag über und die Initiative hinter dem Funkzellenabfragen-Transparenz-Systems. Eine, wie wir finden, äußerst lobenswerte Sache und in der Art der Umsetzung (“in-house” inkl. Kompetenzaufbau nicht nur in der Softwareentwicklung, sondern auch im erweiterten Ökosystem für Betrieb, Fachverfahren) ein Vorbild für die öffentliche Verwaltung, nicht zuletzt im Sinne der Digitalen Souveränität.
Trotzdem hat das Zögern bezüglich der Veröffentlichung des Quellcodes einige Diskussionen ausgelöst. Wir möchten uns daher einigen Vorrednern anschließen und unsere Sichtweise nachfolgend darstellen:
In dem Beitrag wird unter anderem darauf eingegangen, dass Software,welche von privatwirtschaftlichen Unternehmen entwickelt wird, auch von diesen Unternehmen “besessen” wird. Dies muss nicht der Fall sein. Selbstverständlich, liegt das Urheberrecht beim Unternehmen, aber über eine entsprechende offene Lizenz kann die Nutzung der Software so geregelt werden, dass die damit beschriebene Abhängigkeit nicht entsteht.
In diesem Fall wurde die Software vom Land Berlin entwickelt. Sie sind sicher mit der Kampagne “Public Money, Public Code” (https://publiccode.eu/de/) vertraut. “Public Code” wird im Rahmen der Kampagne - und allgemein seit Begründung dieser Terminologie - als freie Software, im Sinne der Definition der Free Software Foundation, verstanden. Daher ist klar, wie diese Software lizenziert wird: Der Berliner Senat hat mit den Geldern der Steuerzahler:innen dieses Projekt realisiert und daher sollte es auch allen Berliner:innen und Bundesbürger:innen frei zur Verfügung stehen. Es geht hier nicht um die Frage, ob Ulf seine Zeit in diese Software investiert hat, denn er wurde vom Land Berlin mit dieser Aufgabe betraut. Unter Umständen wurde auch private Zeit investiert, aber das ist an dieser Stelle eher nebensächlich. Die Idee der Refinanzierung geht daher vollkommen an der Idee von “Public Money, Public Code” vorbei. Mit ihrem in der Sendung vorgestellten Ansatz müssten Steuerzahler:innen unter Umständen zweimal für die gleiche Software bezahlen!
Im Bereich Open Source existieren eine Vielzahl von Open Source Geschäftsmodellen (https://de.wikipedia.org/wiki/Gesch%C3%A4ftsmodelle_f%C3%BCr_Open-Source-Software). Daher steht es in keinem Widerspruch, die Software als Open Source Software zu lizenzieren und sich z.B. den Aufwand bei Beratung oder Betrieb der Software bezahlen zu lassen. Eine gute Beratungsstelle für potentielle Geschäftsmodelle ist die FSFE (https://fsfe.org/index.de.html).
Das Prinzip “Public Money, Public Code” wird nicht unterstützt, wenn die Software nicht unter einer Open Source Lizenz in einem Repository (z.B. Github oder einer lokale Git-Instanz) veröffentlicht wird. Des Weiteren kann durch eine solche Verfügbarmachung, der Quelltext auch von externen Personen - ebenfalls kostenlos - auf eventuelle Sicherheitslücken geprüft werden. Und selbst wenn eine Software-Firma den Code nehmen würde und daraus ein eigenes Angebot macht: Sämtliche Verbesserungen müssten wieder öffentlich zur Verfügung gestellt werden. Genau das ist die Idee bei Open Source Software.
Wir würden uns sehr freuen, wenn unsere Anmerkungen bei den Überlegungen einer Lizenzierung einfließen und ggfs. in einer späteren Sendung das Thema “Public Money, Public Code” noch einmal näher beleuchtet wird. Wir stehen sehr gern bei weiteren Fragen zur Verfügung.
Wir sind eigentlich begeisterte Hörer:innen des Podcasts. Wir sind Informatiker:innen und setzen uns aktiv für Offene Software und Offenes Wissen ein. Gerade in der öffentlichen Verwaltung bedarf es Projekten, welche die Idee von „Public Money, Public Code“ endlich in die Tat umsetzen. Wir waren erstaunt welche Missverständnisse bezüglich dieser Idee immer noch bestehen und hoffen mit unseren Ausführungen die Thematik ein weniger klarer eingeordnet zu haben. Des Weiteren würde die Open Source Lizenzierung des FTS eine Reihe von Vorteilen mit sich bringen, denn, wie bereits ausgeführt, würde es Dritten ermöglichen, die Qualität und auch die Sicherheit der Software zu verbessern.
Herzlichst,
Claudia Müller-Birn und Benedikt Brecht
Ich wollte just über dasselbe Problem schreiben, das mir beim Hören der letzten Ausgabe (219) aufgefallen ist. Für „Public Money, Public Code“ ist die Lizenz entscheidend – es muss eine Freie Software/Open Source-Lizenz sein, und das Programm als solches auch veröffentlicht sein.
Freie Software heißt aber nicht, dass etwas gratis sein muss. Die Finanzierungsmodelle sind divers: Bezahlen für das Medium, für Dienstleistungen, für zusätzliche Features, Support etc. Siehe auch die jüngste Folge des Software Freedom Podast genau zu diesem Thema.
Für das Land Berlin wird sicher nicht ganz uninteressant sein wie sie den Mehraufwand den eine solche Eigen-Entwicklung doch bestimmt erstmal mit sich bringt „wieder rein bekommen“. Wer den Code zum Gemeingut machen will, muss ihn ja trotzdem (vor-) finanzieren - ich sehe das nennt man auch Bereitstellungsproblem, wenn der Anreiz dazu fehlt. Zwar könnte man die Entwicklung auch anders finanzieren (Bund?), aber für das Praxisbeispiel FTS hat es auch seinen Reiz wenn solche Projekte von Ländern aus angegangen werden können.
Genau dieses Interesse, die Ausgaben für die Entwicklung von Software „wieder herein zu bekommen“ sollte doch eine öffentliche Stelle nicht haben müssen. Hinter einer Investition steht immer die Chance auf Ertrag, und der Ertrag des FTS sollte doch vor allem die Information der Betroffenen sein.
Ganz anders bei einer kommerziellen Software-Firma: die investiert, weil sie sich Ertrag in Form von Umsatz und dadurch Gewinn erhofft.
Und das ist m.E. gerade nicht das Ziel einer Behörde.
Ich würde mich freuen, wenn die Gründe, warum eine von der öffentlichen Hand selbst entwickelte Software nicht unter einer OSS-Lizenz stehen kann, öfter transparent gemacht würden.
“Refinanzierung” geht halt komplett an “public money, public code” vorbei. Warum soll man etwas mit Steuermitteln refinanzieren, das bereits mit Steuermitteln bezahlt wurde?
@vieuxrenard Vielen Dank für deinen Einsatz für Bürgerrechte an dieser Stelle. Kannst du bei Gelegenheit darauf eingehen warum es nicht möglich ist ein Bundesweites Transparanzsystem einzuführen? Ich denke es ist selbst für viele Nerds, geschweige denn für den interessierten Bürger, einfach zu viel Arbeit sich in allen Bundesländern einzeln regelmäßig zu registrieren. (Annahme wäre, dass das System nicht nur in Berlin verfügbar wäre)
Vielleicht wäre es sinnvoll den Beitrag genau zu lesen, bevor man reflexartig behauptet eine öffentliche Körperschaft hat eher kein Interesse die Ausgaben zu refinanzieren. Ich sprach vom Mehraufwand den eine Stelle hat wenn sie alleine neu ein solches Projekt angeht, was führt dazu das sie kein finanzielles Motiv hat öffentliche Güter (Public Code) bereitzustellen. Man nehme an man hat 2 Möglichkeiten:
Einmal teuer selber entwickeln und zum Gemeingut erklären (aber auf den Kosten sitzen bleiben) oder vielleicht eine kostengünstigere proprietäre Version einfach zu nutzen. Bei letzteren übernimmt eben die Firma diese Kostenteilung zwischen den verschiedenen Endkunden und greift dafür nochmal ordentlich in die Haushalte der Länder.
Die öffentliche Stelle wird einfach das (für Sie erstmal) kostengünstigere wählen und darauf verzichten Gemeingüter zu produzieren. Und da kann man natürlich mit den Füßen stampfen wie man will, das ist eine Überlegung die sich jede untergeordnete Ebene stellt die ein solches Projekt angeht. Das heißt es braucht ein Mechanismus die Entwicklungskosten (auch im nachinein) gleichmäßig unter den Körperschaften zu verteilen.
Gerade das FTS zeigt ja das nicht immer nur den Bund übergeordnet übernehmen kann, weil solche Projekte auch „vor Ort“ den Bedarf abdecken und enstehen. Da wäre es spannend wie der FSFE (@clmb) aktiv werden kann um dieses Problem der institutionellen Refinanzierung anzugehen.
ich habe in der aktuellen Folge (LdN 220) eure Kommentare zu „Public Code“ gehört. Ich vertrete auch die Meinung, dass Software, die u.a mit meinen Steuergeldern finanziert wird, Open-Source sein soll.
Das Argument, dass Software, die im „sicherheitsrelevanten Bereich“ mit „Daten der Bürger“ arbeitet, nicht „public“ sein soll, erschliesst sich mir nicht so ganz. Gerade hier muss ein Paradigmenwechsel stattfinden, denn auch „Sicherheits-Software“ wird nur dadurch besser, indem unabhängig voneinander Code-Reviews seitens der Open-Source-Community durchgeführt werden.
Außerdem: Wenn man Industrie-Standards bei der Entwicklung setzt, dann werden Konfigurationen und Daten eh vom eigentlichen Code getrennt. Wenn die Behörden Angst davor haben, dass deren Software öffentlich einsehbar ist, dann muss davor vieles nicht stattgefunden haben:
Sicherheit im SDLC (Security Development Life Cycle) wurde nicht berücksichtigt
Entwickler haben auf „sichere Programmierung“ nicht geachtet (weil keine Zeit, kein Know-How etc.)
Code-Reviews/Pentests hat man nicht durchgeführt
Es wurde nicht darauf geachtet, den Code von Konfiguration/Test-Daten etc. sauber zu trennen
und, und, und …
Aus gutem Grund ist u.a. Kryptografie (SSL/TLS, AES usw.) Open-Source, denn diese Software hat die Angriffe einer breiten Masse überstanden und sich als „sichere“ Software etabliert.
PS: Ich arbeite in der IT-Sicherheit, mein Schwerpunkt ist Applikations-Sicherheit und ich schreibe selber Code
PPS: Ich habe bewusst auf Details verzichtet, damit auch Nicht-Techies den Text verstehen.
Ich muss offen gestehen, bei der ersten Nennung des Themas war ich nur kurz irritiert und dachte mir dann nichts weiter dabei. Die Erlaeuterung in LdN220 fand ich aber wirklich aergerlich.
Ich bin selber im oeffentlichen Dienst und setze mich dort seit einigen Jahren im Rahmen meines Wirkungskreises dafuer ein, „Public Money – Public Code“ zu einem Arbeitsgrundsatz zu machen und durch geeignete Ratsbeschluesse auch zu verankern. Gleiches gilt fuer die „Oeffentliche Gelder – Oeffentliche Gueter“-Kampagne von u.A. Wikimedia Deutschland. Das machen wir hier vor Ort ganz praktisch, indem die Kommune selbst an F/LOSS weiterentwickelt und mit anderen Behoerden ganz unkompliziert zusammenarbeitet.
Ich kann das Argument gut nachvollziehen, dass die fuer das Informationssystem gefundene Regelung pragmatischerweise die ist, die in der dafuer geltenden Situation durchsetzbar war. Vermutlich haette ich an der Stelle nicht anders gehandelt.
Dennoch halte ich die willfaehrige Umbesetzung des Kampagnenbegriffs fuer ein System, das nicht freie Software ist und auch nicht sein soll, fuer gefaehrlich. Gerade der Ansatz, durch oeffentliche Gelder entwickelte Systeme (oder von der oeffentlichen Hand erhobene Daten) merkantilisieren zu wollen, ist ein regelmaessiges Killerargument, gegen das es sich zu stellen gilt. Es mag zwar nicht immer leicht zu vermitteln sein, dass gemeinschaftlich entwickelte Systeme einen hoeheren gesamtgesellschaftlichen Nutzen entwickeln als wenn ein Return on Invest zum Spiel gehoeren soll. Das entbindet jedoch nicht von der Verantwortung, dieses groessere Bild im Blick zu behalten und nicht diejenigen Akteure unter den Bus zu werfen, die hierfuer werben und Allianzen aufbauen – und vor allem, den Kampagnenbegriff, der fuer etwas ganz anderes steht, oeffentlichkeitswirksam umzudeuten.
Ich finde es gut und richtig, dass das System so entwickelt wurde wie du das durchgefuehrt hast – hierfuer notwendiges Wissen zu internalisieren und nicht von Dienstleistern abhaengig zu sein, ist ein Ziel fuer sich. Und auch wenn ich das Ziel einer Vermarktung und Refinanzierung des Systems eher so lala finde, nungut. Das ist eure politische Entscheidung in Berlin. Aber bitte fahr nicht wohlmeinend den oeffentlichen Stellen in die Beine, die hier etwas freiheitlichere Ziele verfolgen moechten.
Nein.
Das ist für DEN STEUERZAHLER rechte Tasche linke Tasche da das Geld zwischen den Behörden der Länder hin und her geschoben wird.
Für die Steuerzahler des Landes Berlin ist es nicht egal, da mit dem zurückgeflossenen Geld andere Projekte voran getrieben werden können.
Das geht davon aus, dass all diese Projekte kuenftig untereinander bezahlt werden sollen – wie die Interne Leistungsverrechnung bei Behoerden. Dort ist es ja auch so, dass es fuer den Steuerzahler Rechte Tasche, Linke Tasche ist, wie das Geld z.B. zwischen Vermessungsabteilung und Verkehrsplanung verschoben wird. Das aendert aber nichts daran, dass allein der Verwaltungsoverhead fuer die Vertragsvereinbarung und Mittelvereinnahmung faktisch und praktisch die Zahlkraft dieses Steuergeldes mindert.
Der Grundsatz Public Money, Public Code sollte ja eigentlich bedeuten, dass auch andere Laender oder Kommunen ihrerseits Beitraege zum FTS leisten oder gar gaenzlich eigene Systeme entwickeln koennten, von denen dann wieder das Land Berlin profitiert. Mich verwundert offen gestanden diese Quid-pro-Quo-Haltung, gerade nach den Erfahrungen mit den ueblichen Dienstleistungsbuden und dem Overhead bei ILV.
Diese Kürzel sagen mir nichts. Ich wollte lediglich die Aussage „ Mit ihrem in der Sendung vorgestellten Ansatz müssten Steuerzahler:innen unter Umständen zweimal für die gleiche Software bezahlen!“ wiederlegen
Ich ging davon aus, dass FTS die Abkuerzung fuer das Funkzellentransparenzsystem ist. ILV ist die weiter oben bei mir angefuehrte Interne Leistungsverrechnung bei Behoerden und Verwaltungen, siehe das Beispiel mit dem Vermessungsamt einer Kommune oder eines Landes, das intern Rechnungen stellt. Das alles kommt aus dem Prinzip des „New Public Management“, in dem einzelne Einheiten der Verwaltung als untereinander wirtschaftende Profit Center agieren und sich gegenseitig Dienstleistungen abrechnen.
Widerlegt ist mit der Aussage IMO die urspruengliche These mit der Mehrfachbelastung nicht. Es ist allenfalls so, dass nun erneut Steuermittel anderer Laender (bzw. aus den Taschen der Steuerzahlenden anderer Laender) aufgewendet werden, um einen Return on Invest beim Land Berlin vorzunehmen. Es ist ja nicht so, dass durch diese Zahlungen die Steuerlast der Berliner Buerger:innen gesenkt werden wuerde. Allenfalls koennte man argumentieren, dass damit kuenftige weitere eigene Entwicklungen verargumentiert werden koennten. Ich wage aber zu behaupten, dass ein gemeinschaftlicher Einsatz der 16 Laender, knapp 12000 Kommunen und vielleicht irgendwann auch mal des Bundes einen groesseren gesellschaftlichen Nettonutzen erzielen wuerde als eine staendige interne Leistungsverrechnung.
Ich finde schon, dass eine derart öffentlichkeitswirksame Umdeutung des Begriffs „public money, public code“ entsprechenden Initiativen das Leben unnötig schwerer macht.
Das hat, wie die Vorredner davor auch schon gesagt haben, nichts mit dem äußerst lobenswerten Ansatz der Eigenentwicklung zu tun. Veröffentlicht den code oder verkauft es nicht unter einem Label, unter das es einfach nicht passt.
Warum gibt es eigentlich keine staatliche IT-Firma, die für die Entwicklung von Software für verschiedene Zwecke in der Bundesrepublik Deutschland zuständig ist? Hier immer auf private Firmen zurück zu greifen ist doch ultra ineffizient. In einer solchen Firma - nennen wir sie mal Konrad-Zuse-Institut - könnten Open Source, Transparenz und Privatsphäre groß geschrieben werden - ja vielleicht sogar als Nebenprodukte öffentliche Frameworks und Konzepte bereitgestellt werden, welche das Erreichen dieser Ziele auch für private Unternehmen vereinfachen.
Ich habe schon von etlichen meiner Kolleg*innen gehört, dass sie auf der Suche nach etwa datenschutzfreundlicheren Alternativen zu notwendigen Tools einfach nicht fündig werden. Und wenn dann mal in einer Krisensituation schnell eine Lösung für die Kontaktnachverfolgung im Zuge einer Pandemie entwickelt werden soll, gibt es nicht nur ein eingespieltes Team, das bereits mit öffentlicher Arbeit Erfahrung hat, sondern man zahlt auch nur einen Bruchteil des Preises.
Alleine mit dem, was für die Corona-App ausgegeben wurde, könnte man solch ein Institut ins Leben rufen. Liebend gern hätte ich mich nach meinem Studium dort beworben. Unmöglichkeiten wie die Ablehnung von Unterstützung durch Community-Beiträge wie durch die Leute von SAP am Anfang der Entwicklung der App hätten so auch vermieden werden können. Alleine, wie lange es gebraucht hat, sie von der Übersetzung in andere Sprachen zu überzeugen, das hat mich als aktiver GitHub-Contributor schon stark abgeschreckt.
Fraglich ist, ob eine staatliche Firma bessere oder preiswertere Software entwickeln würde. M.E. sollte die Kompetenz von Behörden darin liegen, die benötigte Software zu beschreiben, auszuwählen und abzunehmen. Der (kommerziellen) Anbieter mit dem besten Preis-Leistungsverhältnis kann die Umsetzung vornehmen.
Wenn die Rahmenbedingungen gut gesetzt sind (offene Schnittstellen und Dokumentenformate, Code als Open Source) sollte dadurch kein Nachteil für die Öffentlichkeit entstehen, aber man bekommt durch den Wettbewerb der Anbieter die bestmögliche Qualität (klar, Gegenbeispiele gibt es genug).
Bliebe noch die Frage, wie man dafür sorgen kann, dass Behörden die o.g. Kompetenzen bekommen. Dafür habe auch auch kein Patentrezept, denn richtig gute Anforderungen entstehen dort, wo Sach- und IT-Kompetenz zusammenkommen. Leider trifft man/frau oft entweder das eine oder das andere; selten aber beides zusammen an.
