English | Deutsch
Home »

Kurzstudie:

"Nachhaltige Freie Software: Vom Projekt zur Dauertätigkeit am Beispiel Gpg4win"


Autoren:
Dr. Jan-Oliver Wagner <jan-oliver.wagner@intevation.de>
Bernhard Reiter <bernhard.reiter@intevation.de>
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück
Tel: 0541/33508-30, Fax: 0541/33508-59


Diese Kurzstudie ist als PDF-Dokument zum Download verfügbar.

Stand Juni 2006, Fassung vom 20. September 2007 (Webfassung 30.09.2008)

Inhaltsverzeichnis

1 Zusammenfassung 3

2 Einleitung 3

3 Methodik 4

4 Allgemeine Erfolgsfaktoren für Freie Software Projekte 4

4.1 Beteiligten-Struktur 5

4.2 Beispiele für erfolgreiche Projekte 8

4.2.1 Apache 8

4.2.2 Samba 8

5 Betrachtung bisheriger Ansätze für GnuPG Windows Installer 9

5.1 GnuPP 9

5.1.1 Geschichte 9

5.1.2 Nutzerakzeptanz 10

5.1.3 Probleme 10

5.2 Windows Privacy Tools 11

5.2.1 Geschichte 11

5.2.2 Nutzerakzeptanz 12

5.2.3 Probleme 12

5.3 GnuPT 12

5.3.1 Geschichte 12

5.3.2 Nutzerakzeptanz 13

5.3.3 Probleme 13

5.4 GnuPG-Pack Basics 13

5.4.1 Geschichte 13

5.4.2 Nutzerakzeptanz 13

5.4.3 Probleme 14

6 Bisherige Erfolge von Gpg4win 14

7 Handlungsmöglichkeiten 15

7.1 Grundlegende Schwierigkeiten 15

7.2 Aufgaben bzw. notwendige Aktivitäten 16

7.3 Schätzung der Aufwände für notwendige Aktivitäten 17

7.4 Anwenderkreis 18

7.5 Wirtschaftliche Trägerschaft 18

7.6 Was könnte man mit einem einmaligen Geldbetrag erreichen? 20

8 Schlussfolgerungen und Empfehlungen 21

8.1 Qualifizieren und Einbinden 22

8.2 Wirtschaftliche Trägerschaft 22

Appendix A: Konkrete Handlungsempfehlungen 23

A.1 Als Freiwilliger 23

A.2 Als Geldgeber 23

1 Zusammenfassung

Wer in die Entwicklung einer Freien Software (Open Source) investiert, möchte meist langfristige Wirkung erzielen, trotz begrenztem Budget. Dazu sollte eine offene und eigenständige Weiterentwicklung gefördert werden.

Am Beispiel der Verschlüsselungs-Lösung „Gpg4win“ wird erörtert, welche Maßnahmen dieses Ziel erreichen können. Ausgangspunkt ist die Analyse bisheriger, vergleichbarer Initiativen zu der Windows-Version der Software GnuPG.

Zwei Schlüsselfaktoren werden sichtbar:

  1. Einbindung von weiteren Personen, hin zu einer ausgewogenen Beteiligten Struktur

  2. Wirtschaftliche Trägerschaft

Zur Vermittlung der notwendigen Kompetenzen sollte ein Prozess der Motivierung und Qualifizierung etabliert werden. Eine gute Ergänzung dazu stellt die Förderung der wirtschaftlichen Trägerschaft dar. Dessen Fernziel ist: Das Finanzieren der professionellen Erledigung eines Teils der nötigen Tätigkeiten. Der Weg dahin muss ermöglicht und kommuniziert werden.

Wie das für Gpg4win aussehen kann, wird ausgeführt. Die technischen Fortschritte bei Gpg4win stellen eine Grundlage für diese Maßnahmen dar. Ideal wäre ein langsamer Rückzug aus einer Investition, so dass jeweils andere Beteiligte übernehmen können.

2 Einleitung

Diese Kurzstudie ist parallel zum Produkt „Gpg4win“1 entstanden.

Gpg4win ist ein Installationpaket für Microsoft Windows und enthält neben der Verschlüsselungsanwendung „GnuPG“ zahlreiche Hilfsprogramme sowie eine umfangreiche deutsche Dokumentation. Ziel dieses Projektes ist es, die Benutzbarkeit der Verschlüsselungssoftware GnuPG zu verbessern und so einfachen Computer-Anwendern den Zugang und den Umgang mit Kryptographie zu ermöglichen. Zu diesem Zweck wurde, neben der einfachen Installation der Software, die Integration des Kommandozeilenwerkzeugs GnuPG in grafische Benutzerschnittstellen wie „Outlook 2003“ und „Sylpheed Claws“ vorangetrieben.

Gpg4win möchte damit das veraltete GnuPP2 ablösen, welches schon länger nicht aktualisiert wurde. Für Gpg4win soll ein solcher Stillstand vermieden werden. Diese Kurzstudie hat das Ziel entsprechende Maßnahmen zu diskutieren.

Die Version 1.0 von Gpg4win hat die Software aktualisiert. Diese Kurzstudie schlägt eine Strategie vor, wie ein sich selbst tragendes Projekt erwachsen kann. Ziel ist, mittelfristig eine nachhaltigere Weiterentwicklung von Gpg4win zu ermöglichen.

Ausgangspunkt für die Kurzstudie sind allgemeine Erfolgsfaktoren bei Freie Software Projekten, sowie die Probleme bzgl. einer nachhaltigen Weiterentwicklung bei GnuPP, Windows Privacy Tools3 und vergleichbaren Ansätzen.

Diese Studie befasst sich mit Gpg4win; es lassen sich aber auch allgemeine Schlüsse ziehen. Besonders für Produkte, welche aus einem größeren Projekt enstanden sind und auf Microsoft Windows als zugrunde liegendes Betriebssystem zielen.

Letztlich ist die vorliegende Arbeit als Schlaglicht auf die Thematik zu sehen. Es sind viele weitere Aspekte betrachtenswert, die nicht erwähnt oder besprochen werden konnten. So ist diese Kurzstudie als Startpunkt und Anregung geeignet, über die Fragestellung des nachhaltigen Fortbestandes von Freie Software Produkten nachzudenken.

3 Methodik

Die Vorgehensweise bei dieser Kurzstudie beinhaltet folgende, wesentliche Schritte:

  • Suche nach vergleichbaren Projekten.

  • Untersuchung der öffentlichen Informationen der vergleichbaren Projekte, nach Möglichkeit mit Kontaktaufnahme.

  • Ermittlung von Erfolgsfaktoren für Freie Software Projekte.

  • Analyse und Abgleich von Gpg4win und vergleichbaren anderen Projekten mit den Erfahrungen der Autoren und den Erfolgsfaktoren.

Die Literaturrecherche hat zu den Inhaltsschwerpunkten „Freie Software unter Windows“, „Sicherheitsoftware“ oder „Aufbau von Nachhaltigkeit aus einem kommerziellen Entwicklungs-Projekt heraus“ weder in deutscher noch in englischer Sprache hilfreiche Ergebnisse geliefert. Die Literatur beschränkt sich vor allem auf technische Erfolgsfaktoren für Freie Software Initativen und auf die Entwicklung von individuellen Geschäftsmodellen auf Basis eines Freie Software Produkts.

In die Kurzstudie fließt die langjährige Erfahrung der Autoren mit Freier Software ein, mit der sie sich seit 1999 professionell und ausschließlich befassen. Seit dem Jahr 2000 haben die Autoren verschiedene Projekte zur E-Mail-Verschlüsselung mit GnuPG durchgeführt.

4 Allgemeine Erfolgsfaktoren für Freie Software Projekte

Was ist überhaupt ein „Freie Software Projekt“?

Freie Software ist Software, welche mit der permanenten Erlaubnis kommt, von jedem für jeden Zweck eingesetzt werden zu können. Weiterhin ist es möglich, die Software weiterzugeben, sie zu verbessern und die Verbesserung ebenfalls kopieren zu dürfen. Freie Software wird in der Bedeutung der Free Software Foundation Europe (FSFE) verwendet. Andere Worte für Freie Software sind „Open Source“ oder „Libre Software“.

In der engeren Bedeutung ist ein Projekt ein einmaliges Vorhaben. Bei Freier Software hat sich diese Bedeutung etwas gewandelt, es geht nicht mehr um ein einmaliges Vorhaben, sondern meist um eine dauerhafte Aktivität rund um eine Software, welche erstellt und auf unbestimmte Zeit weiterentwickelt und gepflegt wird. Neben der Software sind auch die Dokumentation, die Infrastruktur, das Informationsangebot und die Beteiligten ein Bestandteil einer solchen Aktivität.

Bei jedem Softwareprojekt sind regelmäßig verschiedene Aufgaben zu erledigen. Die Aktivität funktioniert, wenn diese Tätigkeiten von direkt Beteiligten übernommen werden. In der Literatur lassen sich die Teilnehmer eines Freie Software Projekts in vier große Gruppen aufteilen:

  • Organisationen/Unternehmen für den Eigenbedarf

  • Dienstleister im Auftrag

  • Einzelpersonen in ihrer Freizeit

  • Forschung und Lehre zum Ausprobieren und Veranschaulichen.

Siehe (Lakhani et al. 2002)4 und in deutscher Sprache (Reiter 2004)5.

Für jedes funktionierende Freie Software-Projekt gilt also:

  • Welche Tätigkeiten müssen regelmäßig übernommen werden?

  • Wer führt diese Tätigkeiten durch?

Wer sich für eine Freie Software interessiert, kann sich auf zwei Arten beteiligten: mit Arbeitskraft oder mit Geld. Der Anteil ist frei wählbar. Die Tätigkeiten können jedoch nur mit Arbeitskraft umgesetzt werden; beigetragenes Geld muss darin umgewandelt werden. Hier schließt sich sich die Frage der Qualifizierung und des ökonomischen Modells an.

4.1 Beteiligten-Struktur

Ein erfolgreiches Freie Software Projekt zeichnet sich durch eine eine ausgeglichene Zusammensetzung aus Beteiligten aus wie in Abbildung 1 dargestellt. Besonders die jeweils aneinander grenzenden Schichten kommunizieren in der Regel viel miteinander, also beispielsweise Beitragende mit den engagierten Anwendern und mit den Entwicklern.


Abbildung 1: Zusammensetzung der Beteiligten bei einem erfolgreichen Freie Software Projekt: Aus einer breiten Basis von Anwendern läuft sie konisch über engagierte Anwender, Beitragender, Entwickler und Kern-Entwickler auf den Entwicklungs-Koordinator zu.


Anwender:

Normale Benutzer der Software. Sie holen sich Rat in der Dokumentation und bei anderen, zumeist engagierten Anwendern.

Engagierter Anwender: („Power-User“)

Ein Benutzer mit weitergehendem technischen Verständnis und Kenntnissen. Er nutzt die Software intensiver als ein normaler Anwender und hilft seinem Umfeld beim Umgang mit der Software. In der Regel sind engagierte Anwender auf entsprechenden Mailinglisten oder Foren eingeschrieben und beantworten auch dort Fragen von Anwendern.

Beitragender:

Ein Beitragender trägt regelmäßig aktiv zum jeweiligen Freie Software Projekt bei. Das geschieht zumeist noch nicht direkt in Bezug auf den Quelltext, sondern durch Übernahme anderer Tätigkeiten: Zum Beispiel dem Schreiben von Dokumentation oder dem Testen experimenteller Versionen oder dem Ausformulieren von Wünschen.

Entwickler:

Mitwirkende die regelmäßig Verbesserungen am Quelltext der Software, teilweise selbstständig, durchführen. Bei diesen Verbesserungen handelt es sich oft um Fehlerbeseitigungen oder kleine Funktionserweiterungen.

Kern-Entwickler:

Mitwirkende Entwickler, die einen guten Überblick über die Architektur der Software haben und deren Weiterentwicklung aktiv mitgestalten.

Entwicklungs-Koordinator:

Aus dem Kreise der Kern-Entwickler die Person, die das letzte Wort über Architektur-Entscheidungen, Einbau neuer Funktionen und ähnliches hat. Typischerweise ist dies nicht mit einem Diktat zu vergleichen, sondern es wird vielmehr die Aufgabe übernommen, die Diskussion um Architektur und Funktionalitäten zu moderieren. Rechte, Pflichten, Wahl und Abwahl des Koordinators sind in den vielen Freie Software-Projekten verschieden gelöst. In dem außerordentlich selten auftretenden Fall eines unlösbaren Dissens kommt es zu einer Aufspaltung des Freien Software Projekt in zwei Projekte.


Wichtig für eine Freie Software Aktivität sind die Prozesse Qualifizierung und Einbindung. Schafft es ein Projekt, aus Anwendern, engagierte Anwender zu machen, aus engagierten Anwendern Beitragende usw., dann führt das dazu, dass auch die ursprünglichen Kern-Entwickler sowohl motiviert als auch unterstützt werden. Sie können dann das eigentliche Produkt voranbringen und damit wiederum den Anwendern zuarbeiten.

Auf Grund von gewachsenen Strukturen ist es sehr schwer einen Kern-Entwickler oder Entwickler direkt zu rekrutieren. In diese Leitpositionen muss eine Person erst hineinwachsen. Eine große Anwenderzahl ist deshalb als Basis für die Einbindung ein wichtiger Faktor. Es gibt klassische Wege die Anwenderzahl zu erhöhen und die jeweilige Freie Software Aktivität bekannter zu machen. Bei der Freien Software ist das Gewinnen von Anwendern vor allem durch die Internationalisierung, den Eintrag in verschiedene Software-Verzeichnisse und den persönlichen Kontakt auf Mailinglisten und Treffen zu erreichen.

Ein kritischer Punkt für jede Freie Software Aktivität ist der Übergang der ersten Führungsgruppe zur zweiten. Oft ist es eine bestimmte Person, welche mit ihrem Interesse das Projekt begann und mit Leben füllte. Irgendwann verliert diese Person das Interesse an der Software oder kann aus einem anderen Grund nicht mehr daran weiterarbeiten und muss das Projekt übergeben. An diesem Punkt zeigt sich, ob genug kritische Masse vorhanden ist, eine neue Führungsgruppe zu formieren. Gut ist, wenn die Last bereits auf mehreren Schultern verteilt war. Je breiter der Kegel in Abbildung 1 also ist, desto besser.

Um die Schritte der Qualifizierung zu gehen, müssen die Beteiligten jeweils dazu motiviert werden. Bei Freiwilligen ist klar, dass hier eine entsprechende Freude oder Spaß and der Sache hilfreich ist.

Lakhani et al. geben als meistgenannte Motive beim Entwickeln Freier Software an:

  • Intellektuelle Herausforderung

  • Verbesserung der eigenen Fähigkeiten

  • Verbesserung der persönlichen Arbeitsprozesse

  • Freiheit, die Programme zu modifizieren

Eine gute Infrastruktur kann helfen, die nötige Kommunikation zu bündeln. Dazu zählen eine angemessene Anzahl an Mailinglisten, Foren, Webseiten, Ticket-Systeme für Fehlerlisten und Wünsche, ein offenes Versionskontrollsystem.

Sowohl Infrastruktur, wie auch Software und Dokumentation muss es Interessierten leicht machen, sich zu beteiligen. Unnötige Schwierigkeiten sind zu vermeiden, das gilt technisch, sprachlich und organisatorisch.

4.2 Beispiele für erfolgreiche Projekte

Die folgenden beiden Beispiele beschreiben erfolgreiche Freie Software Projekte, warum sie Erfolg haben und in welcher Weise sie sich von Gpg4win unterscheiden.

4.2.1 Apache

Der Web-Server „Apache“ ist mit über 60% Marktanteil6 seit Jahren das weltweit führende Produkt. Apache war von Beginn an Freie Software und wurde von verantwortlichen Systemadministratoren Stück für Stück weiterentwickelt und verbessert. Fast alle Arbeiten an Apache entsprangen konkreten technischen, teilweise dringenden und zwingenden Bedürfnissen. Diese Bedürfnisse entstanden vor allem bei einer Reihe von Unternehmen die den Web-Server intensiv nutzen.

Aufgrund der großen Nutzer- und Entwicklerzahlen wurde die Apache Software Foundation7 (ASF) gegründet. Sie unterstützt und koordiniert inzwischen über 30 Einzelprojekte im Bereich web-basierte Dienste. Insgesamt sind bei der ASF ca. 1000 aktive Entwickler registriert.

Entscheidende Erfolgsfaktoren sind sicherlich der konkrete technische Bedarf und die Tatsache, dass die Anwender, also die Administratoren technisch hochqualifiziert sind. Viele Anwender sind in der Lage Fehleranalyse und Fehlerbeseitigungen eigenständig durchzuführen. Außerdem können die Anwender und Entwickler Apache immer auf den Software/Hardware-Systemen einsetzen, auf denen sie sich auskennen, was eine zusätzliche Motivation darstellt.

Im Gegensatz dazu sind bei Gpg4win die Anwender in der Regel technisch weniger qualifiziert. Das liegt natürlich daran, dass Gpg4win ein Programm für Endanwender ist und eben keine Server-Anwendung, die sich an Administratoren richtet.

Desweiteren ist bei Gpg4win automatisch das Betriebssystem vorgegeben. Programmierern bietet Gpg4win keine echte Herausforderung, weil es als Meta-Projekt sich nicht der eigentlichen Programmierung widmet. Es werden Ergebnisse aus anderen Projekten (z.B. GnuPG) übernommen.

4.2.2 Samba

Samba ist eine Freie Software Implementierung der Datei- und Druck-Dienste für SMB/CIFS Klienten. SMB und CIFS sind proprietäre Protokolle der Firma Microsoft. Eine Samba-Installation kann sowohl einen entsprechenden Windows Klient oder Windows Server bzgl. Datei- und Druckdiensten bruchfrei ersetzen, also ohne dass die anderen Systeme im Netzwerk Kenntnis haben müssen oder es auch nur bemerken. Gleichzeitig stellt es eine Brücke zu Datei- und Druckdiensten unter GNU/Linux dar.

Samba hat bei sehr vielen Unternehmen Dateiserver von Microsoft oder Novell abgelöst. Es wird überall dort eingesetzt, wo gemischte Umgebungen aus GNU/Linux und Windows Arbeitsplätzen vorliegen, teilweise sogar in reinen Windows-Umgebungen.

Der entscheidende Erfolgsfaktor für Samba ist das sehr konkrete Interesse von vielen Unternehmen diese Lösung einzusetzen. Weiterhin ist es als Dateiserver eine sog. unternehmens-kritische Anwendung für praktisch alle Unternehmen. Für unternehmens-kritische Anwendungen sind immer entsprechende Budgets vorhanden und so haben sich zahlreiche Unternehmen etabliert, die Dienstleistungen zu Samba anbieten. Ein Teil dieser Unternehmen beschäftigt dann auch Mitarbeiter, die sich mit der Verbesserung und Fortentwicklung von Samba befassen.

Im Unterschied zum Apache Projekt sind wesentlich weniger Administratoren technisch qualifiziert, um Verbesserungen an Samba selbst durchzuführen.

Im Gegensatz zum Datei-Server stellt die Verschlüsselung von E-Mails für die allermeisten Unternehmen keine kritische Anwendung dar. Entsprechend gibt es geringere Budgets, die für Pflege- und Supportverträge verwendet werden. Ein kommerzieller Markt kann sich bei Gpg4win also nicht so leicht und schnell entwickeln wie bei dem Produkt Samba, dem durch die Schlüsselbedeutung der Anwendung eine einfachere Kommerzialisierung in die Wiege gelegt wurde.

5 Betrachtung bisheriger Ansätze für GnuPG Windows Installer

Die Betrachtung bisheriger Ansätze beinhaltet jeweils einen geschichtlichen Abriss und berücksichtigt insbesondere mögliche Gründe warum eine nachhaltig eigenständige Lösung durch andere Projekte bisher nicht etabliert werden konnte.

5.1 GnuPP

5.1.1 Geschichte

Ende 1999 startete ein Förderprojekt des Bundesministerium für Wirtschaft und Technologie mit dem Ziel, GnuPG auf Windows zu portieren, grafische Benutzerschnittstellen zu entwickeln und eine gute deutsche Dokumentation zu erstellen.

Projekt-Bezeichnung war „Freie Software und IT-Sicherheit“.

Beteiligt waren vor allem die Unternehmen G-N-U GmbH (Entwicklung), Werner Koch Software-Systeme (abgelöst durch OpenIT GmbH, Entwicklung) und Linuxland International (Vermarktung). Projektnehmer war der GUUG e.V. Gegen Ende des Projektes kam die Intevation GmbH hinzu (Projekt-Management und Entwicklung). Das Projekt-Management wurde in den ersten Monaten von einer Einzelperson übernommen, die dann aber ohne Ersatz frühzeitig ausschied.

Mit dem Jahr 2000 endete das Projekt erfolgreich und wurde in der Folgezeit auf Messen präsentiert. Im Rahmen des Projektes entstanden der grafische Schlüsselmanager Gnu Privacy Assistant (GPA), ein überarbeitetes GnuPG, die deutschen Web-Seiten www.gnupg.de, das Gnu Privacy Handbook in Deutsch und Englisch, die Krypto-Programmierbibliothek GpgME, einige Machbarkeitsanalysen zur Integration in verschiedene E-Mail-Programme und Integration in das E-Mail Programm Sylpheed. Weiterhin sind die Entwicklung von WinPT (Unterstützung bei der Verwendung des Windows-Clipboard für Verschlüsselung) und dem G-Data Outlook Plugin zur Verwendung von GnuPG im E-Mail Programm Outlook zu nennen. Beide Produkte wurden unabhängig von dritter Seite beigetragen und sind damit als Kollateralnutzen einzustufen.

Im Rahmen einer Anschluss-Förderung wird das Projekt in „GnuPP“ (Gnu Privacy Project) umbenannt. GnuPP lief über den Zeitraum Mai 2001 bis März 2002. Hauptziel und auch Ergebnis dieses Projektes sind ein aktualisiertes Installationspaket (GnuPP 1.1) sowie umfangreiche und illustrierte Handbücher, die auch als Broschüren in größerer Auflage erschienen sind (CD mit Broschüre „GnuPP für Einsteiger“). Zudem wurde eine, in der Zwischenzeit allerdings wieder deutlich reduzierte, Heimatseite zum Projekt erstellt (www.gnupp.de), ein Anwenderforum in Form einer Mailing-Liste und außerdem ein automatisches System (E-Mail Korrespondenz-Roboter „Adele“) zum Ausprobieren bereitgestellt. Letzteres findet im Rahmen des Tutorials in „GnuPP für Einsteiger“ Verwendung.

Beauftragt und beteiligt war, soweit bekannt, nur die G-N-U GmbH. Die Broschüren und Illustrationen wurden von externen Dienstleistern erstellt.

Web-Seite, Mailingliste und der Korrespondenz-Roboter „Adele" sind noch aktiv. Das Installationpaket GnuPP 1.1 wird nicht mehr zum Download angeboten, „Einsteiger“ und „Durchblicker“ jedoch schon (als PDF-Dokumente).

Das Installationspaket GnuPP ist von verschiedenen Websites noch immer herunterladbar.

5.1.2 Nutzerakzeptanz

Die initiale Nutzerakzeptanz und Aufmerksamkeit für GnuPP kann als beachtlich eingestuft werden.

Die Mailing-Liste verzeichnete folgendes Aufkommen: 2002: 881 Emails, 2003: 877, 2004: 671, 2005: ca. 200. Knapp 500 Personen beteiligten sich aktiv, die Zahl der Eingeschriebenen ist nicht bekannt.

Die CD mit Broschüre erschien in einer 1. Auflage März 2002. Der Umfang der Auflage ist unbekannt, dürfte aber nicht unter 5000 Exemplare liegen. Eine zweite Auflage war angedacht, wurde dann aber verworfen. Die Gründe dafür sind unbekannt.

5.1.3 Probleme

Sowohl GPA, wie auch GnuPP sind keine offiziellen Projekte des GNU Projekts8, obwohl der Name es suggeriert. Nur GnuPG selbst ist ein offizielles GNU Projekt.

Seit etwa Ende 2002 hat die G-N-U GmbH vermutlich aufgrund fehlender weiterer Anschlussförderung den aktiven Support eingestellt, betreibt aber die Website und die automatisierten Prozesse (Anwenderforum und „Adele“) weiter.

Es wurden auf der Mailingliste zunehmend Probleme berichtet, die zwar teilweise in den Komponenten selbst (z.B. GnuPG durch das GnuPG Entwicklerteam) korrigiert wurden, es aber dann dafür kein aktualisiertes Installations-Paket gab.

Es wurde weder der Quelltext für den Installer noch eine Anleitung für den Bau des Installers allgemein zur Verfügung gestellt. Es steht jedoch zu vermuten, dass auf explizite Nachfrage die Quellen auch zur Verfügung gestellt wurden. Jedoch bleibt festzuhalten, dass es auch von dritter Seite letztlich nie eine Aktualisierung von GnuPP gegeben hat.

Im Rahmen von GnuPP sind keine Aktivitäten sichtbar, technisch Versierte zu interessieren und zu befähigen um ihnen Aktualisierungen des Installers oder der Web-Seite anzuvertrauen. Es ist daraus zu schließen, dass entsprechendes auch nicht erklärtes Ziel des Vorhabens war.

Inzwischen ist das GnuPP 1.1 Installationspaket in Bezug auf die integrierten Komponenten hoffnungslos veraltet.

5.2 Windows Privacy Tools

5.2.1 Geschichte

Das Projekt Windows Privacy Tools9 (verwirrenderweise leider mit WinPT genauso abgekürzt wie die dort integrierte Software Windows Privacy Tray10, daher wird ersteres im Folgenden als P-WinPT abgekürzt) wurde Januar 2003 auf der Softwareentwicklungsplattform Sourceforge registriert. Also zeitlich nachdem GnuPP keine Weiterentwicklung mehr zeigte. Treibende Kraft war eine einzelne Person aus Kanada.

Ziel und Anspruch entsprachen in etwa dem Projekt GnuPP, jedoch mit dem zusätzlichen Fokus auf gute Unterstützung von Mehrsprachigkeit, also Internationalisierung. Desweiteren wurde ein Handbuch in englischer Sprache geschrieben. Aktuellste Version (aus dem Jahr 2003) des Handbuches umfasst ca. 40 Seiten und beschreibt Installation und Verwendung von WinPT, GnuPG und einiger Plugins für E-Mailprogramme.

Im Prinzip ist nur für das Jahr 2003 nennenswerte Entwickler-Aktivität zu verzeichnen. Die letzte Veröffentlichung von P-WinPT ist Version 1.0rc2 vom 27. April 2003.

Im Mai 2005 stellte Fabian Rodriguez die Position des Projektleiters zur Disposition, da er ohnehin schon einige Zeit nicht mehr aktiv war. Es meldete sich jedoch offensichtlich niemand, diese Position zu übernehmen.

5.2.2 Nutzerakzeptanz

Trotz der kurzen Aktivitätsphase erfreut sich das Projekt scheinbar großer Beliebtheit. Die Download-Zahlen sind recht beeindruckend und liegen vermutlich über denen von GnuPP: P-WinPT 1.0rc2: über 270.000, P-WinPT Handbook 0.2rc2: über 42.000. Die hohen Zahlen liegen vermutlich darin begründet, dass ein internationales Publikum angesprochen wurde.

Auf der Mailingliste für Ankündigungen sind ca. 1000 Personen eingeschrieben. Eine englische Mailing Liste gibt es in diesem Sinne nicht, die Mailing Listen für verschiedene Sprachen (es gibt aber keine für Deutsch) zeigen keine nennenswerte Aktivität.

Weit über die aktive Phase hinaus wurden kontinuierlich Probleme, Wünsche und Anfragen auf den Projektseiten eingetragen. Eine Reihe davon auch noch im Jahr 2006. Bearbeitet werden sie nicht.

5.2.3 Probleme

Die Aktivität des Projektes war eng mit der Aktivität des Initiators verknüpft. Nachdem Fabian Rodriguez nicht mehr aktiv war, wurden auch keine neuen Versionen herausgegeben.

Als großes Problem ist sicherlich einzustufen, dass es keine englischsprachige Diskussionsliste gab auf der sich die Interessierten hätten koordinieren können.

Als weiteren Schwachpunkt kann man bewerten, dass die Verweisliste weder auf GnuPP noch auf andere vergleichbare Ansätze verweist. Erst wer die Alternativen kennt, kann auch Vergleiche anstellen. Die anhaltende Anzahl neuer Einträge im Bug-Tracker sind evtl. darauf zurückzuführen, dass dies der einzige sichtbare Ausweg für die Benutzer ist, mit den Problemen bzgl. P-WinPT umzugehen.

Schließlich machte das P-WinPT Projekt den Versuch, die Software WinPT in sich aufnehmen zu wollen. So finden sich keine Verweise auf die WinPT Heimatseite. Neue Versionen wurden nur noch bis August 2004 dort bekannt gegeben und auch dort zum Download bereitgestellt. Ohne zusätzliche Recherche finden Anwender nicht heraus, dass die Software WinPT ein eigenständiges Projekt ist und zwischenzeitlich umfangreich verbessert wurde. Dieser Versuch kann daher als taktischer Fehler gewertet werden.

5.3 GnuPT

5.3.1 Geschichte

Das Projekt Gnu Privacy Tools (GnuPT11) wurde von einer einzelnen Person aus Deutschland initiiert. Begonnen hat sie damit vermutlich Januar 2004.

Seit etwa Mai 2004 sind laut Aussage des Initiators etwa alle 2-3 Wochen jeweils eine neue Version von dem Windows Installationspaket GnuPT erschienen.

Das Web-Portal zu GnuPT ist als reine Forums-Plattform organisiert.

Nach Aussage des Autors wird die Weiterentwicklung von GnuPT in naher Zukunft zugunsten von Gpg4win eingestellt.

5.3.2 Nutzerakzeptanz

Aufgrund der Statistiken der Forums-Software kann man davon ausgehen, dass weniger als 50 aktive Teilnehmer und weniger als 3000 Leser vorliegen. Allgemein werden scheinbar alle Fragen auf dem Forum beantwortet, den Support kann man als gut einstufen.

Die Zahl der Downloads lässt sich nicht erkennen.

5.3.3 Probleme

Das Forum ist unübersichtlich strukturiert, da sämtliche Projekt-Organisation über dieses Forum erfolgt. Es gibt kein separates Problemverfolgungssystem, keine Mailinglisten und keine Historie der Installationspakete (es ist immer nur die aktuellste Version herunterladbar). Das Projekt scheint hauptsächlich in Deutsch betrieben zu werden und ist kein offizielles GNU Projekt.

Desweiteren fehlt der Quelltext des Installers, es ist also nur dem Projektleiter möglich jeweils eine neue Version zu erstellen. Der Installer selbst ist demzufolge keine Freie Software.

Insgesamt besteht die Gefahr, dass falls der Projektleiter aus irgendeinem Grund das Interesse verlieren sollte oder plötzlich (z.B. durch ein Unglück) an der Weiterarbeit gehindert wird, niemand in der Lage sein wird das Projekt ohne weiteres fortzuführen.

5.4 GnuPG-Pack Basics

5.4.1 Geschichte

Das Installationspaket GnuPG-Pack Basics12 wird seit etwa 2003 von einer einzelnen Person aus Deutschland betreut.

Zur Geschichte ist wenig bekannt, da es keine Mailing Listen, Foren oder ähnliches gibt die Rückschlüsse zulassen würden.

Der Autor ist einer Abstimmung mit und Mitarbeit bei Gpg4win nicht abgeneigt, vorerst wird es aber GnuPG-Pack Basics auch weiterhin geben.

5.4.2 Nutzerakzeptanz

Es ist wenig darüber bekannt wie viele Benutzer dieses Installationspaket hat. Hin und wieder meldeten sich vereinzelte Benutzer auf den Mailing Listen von GnuPP oder GnuPT.

5.4.3 Probleme

Analog zu GnuPT besteht die Gefahr, dass falls der Projektleiter aus irgendeinem Grund das Interesse verlieren sollte oder plötzlich (z.B. durch ein Unglück) an der Weiterarbeit gehindert wird, niemand in der Lage sein wird das Projekt ohne weiteres fortzuführen. Ebenfalls sind die Benutzerführung, Dokumentation und Diskussionsforen ausschließlich in Deutsch. GnuPT ist kein offizielles GNU Projekt.

Darüber hinaus existiert keine projekt-spezifische Infrastruktur in der die Benutzer und potentielle Entwickler sich untereinander austauschen könnten.

Auch der Quelltext des Installationspaketes wird nicht zur Verfügung gestellt. Der Installer selbst ist demzufolge keine Freie Software. Damit ist der Projektleiter der einzige, der Updates leicht erstellen kann.

6 Bisherige Erfolge von Gpg4win

Zur Schriftlegung ist Gpg4win in Version 1.0.2 (2006-05-30) veröffentlicht.

Auf der technischen Seite des eigentlichen Installationspaketes ist folgendes erreicht worden:

  • Aktualisieren der Software-Komponenten GnuPG, WinPT und GPA. Insbesondere wurde die aktuelle Version von GPA (0.7) wieder für Windows nutzbar gemacht. GPA war nach Version 0.5 (enthalten in GnuPP 1.1) nur noch auf GNU/Linux getestet worden.

  • Integration neuer Module: GPGol (Outlook Plugin), GPGee (Explorer Plugin) und Sylpheed-Claws (Komplettes E-Mail Programm inklusive Plugin für GnuPG). Insbesondere wurde Sylpheed-Claws überhaupt erst wieder für Windows nutzbar gemacht. Desweiteren wurde GPGol erheblich erweitert und verbessert.

  • Aktualisieren und Erweitern der beiden Handbücher „Einsteiger“ und „Durchblicker“. Insbesondere sind diese nun neben der PDF-Version auch als Online-Version verfügbar.

  • Neue Installer-Technologie (NSIS) mit weitgehender Automatisierung.

Darüber hinaus wurden bereits einige Maßnahmen ergriffen die für eine nachhaltige eigenständige Weiterentwicklung hilfreich sind:

  • Der Mechanismus zum Bau von Installationspaketen ist nun transparent, dokumentiert und vollständig Freie Software. Das Paket muss auf einem GNU/Linux System „quer“-gebaut werden. Das bringt viele Vorteile bezüglich Automatisierung und Integration von Programmen mit GNU/Linux-Herkunft (GnuPG, GPA, Sylpheed-Claws), birgt aber auch den Nachteil, dass ein reiner Windows-Entwickler nicht ohne weiteres ein Installationspaket selbst erstellen kann.

  • Eine neue Heimatseite fasst die wichtigsten Informationen zu Gpg4win zusammen. Sie ist durchgehend zweisprachig in Englisch und Deutsch.

  • Für den Kreis der Anwender und Entwickler steht eine technische Infrastruktur mit den üblichen Standard-Diensten zur Verfügung: Bug-Tracker für Fehlermeldungen, Mailinglisten für Diskussionen jeweils der Anwender und der Entwickler, Webforen für verschiedene Diskussionsthemen und ein Quelltext-Management-System für die Entwickler.
    Realisiert ist dies auf Basis einer GForge-Plattform, die es zudem erlaubt, interessierten Anwendern und Beitragende schreibenden oder administrativen Zugang zu den einzelnen Elementen der technischen Infrastruktur zu geben.
    Sämtliche dieser Strukturen werden bereits rege von Anwendern genutzt.

7 Handlungsmöglichkeiten

7.1 Grundlegende Schwierigkeiten

Die Beteiligten-Struktur wie sie bisher bei Gpg4win vorliegt und wie sie letztlich auch bei GnuPP, GnuPT, WinPT und GnuPG-Basics noch immer vorliegt, entspricht nicht der Form für ein erfolgreiches Freie Software Projekt (vergl. Abbildung 1, Seite 6).


Abbildung 2: Zusammensetzung der Beteiligten aktuell bei Gpg4win: Einer breiten Basis von Anwendern fehlen die Ebenen der engagierten Anwender, Beitragenden und Entwickler. Es gibt ein Team von Kern-Enwticklern und es fehlt wiederum die Bestimmung eines Entwicklungs-Koordindators.


In der aktuellen Beteiligten-Struktur von Gpg4win fehlt der Bereich vom engagierten Anwender bis Entwickler wie mit Abbildung 2 illustriert. Es fehlt auch ein verantwortlicher Projekt-Koordinator, sobald das beauftragte Projekt zur Erstellung von Gpg4win beendet ist.

Im Vergleich dazu fehlen bei GnuPP und WinPT auch noch die Kern-Entwickler, da die Entwicklung eingestellt wurde.

Bei GnuPT und GnuPG Basics ist die Einzelperson des Koordinators identisch mit der Ebene der Kern-Entwickler und Entwickler, also eine sehr dünne Schicht.

Eine Schwierigkeit für den Qualifizierungsprozess vom Benutzer zum engagierten Anwender usw. ist sicherlich die Tatsache, dass es hier um die Plattform Microsoft Windows geht. Im Vergleich zu GNU/Linux sind typischerweise weniger qualifizierte Anwender verfügbar bzw. weniger Anwender, die sich qualifizieren wollen. Sich in ein Projekt aktiv einzubringen, kennen vor allem Anwender Freier Software. GNU/Linux besteht aus Freier Software. Man könnte also sagen, dass es GNU/Linux in die Wiege gelegt wurde, die Anwender durch Motivation und Qualifizierung in die Fortentwicklung einzubeziehen.

Auch ist die Softwareentwicklung für Microsoft Windows technisch aufwändiger, da die meisten Elemente proprietär sind und nicht wie bei Freier Software üblich leicht analysiert und ggf. korrigiert werden können. Im Rahmen von Gpg4win ist GPGol, das Plugin für Outlook, ein gutes Beispiel: Aufgrund mangelnder Dokumentation und Programmierfehlern bei Outlook ging ein großer Teil der Arbeitszeit in sog. Reverse-Engineering und das Ausarbeiten sog. Workarounds anstatt in die Ausgestaltung der Funktionalität. Ebenfalls unterschiedlich ist die Verfügbarkeit der Entwicklungswerkzeuge: Entwickler unter Windows haben oft einen proprietären Werkzeugkasten. Das behindert, wenn ein anderer Entwickler an entsprechender Stelle weiter machen möchte. Das daraus entstehende Problem hat die Firma Microsoft inzwischen dazu bewogen, einige der Entwicklungswerkzeuge aus dem kommerziellen Vertrieb herauszunehmen. Trotz Gratis-Verfügbareit bleiben die Werkzeuge aber proprietär, sind also unter anderem nicht im Quelltext erhältlich.

Da es sich bei Gpg4win um Sicherheitssoftware handelt, welche teilweise fortgeschrittener Konzepte bedarf, ist der Kreis der potenziellen Beitragenden recht begrenzt. Schon das Schreiben einer guten Dokumentation erfordert in der Regel tiefergehende Sicherheitskenntnisse. Um ein konstantes Vertrauen in die Software sicher zu stellen, ist ein entsprechendes Qualitätsmanagement sinnvoll. Freiwilligen fehlt hierzu in der Regel der Spaß.

Zuletzt besteht ein Unterschied zwischen GNU/Linux und Windows darin, dass die GNU/Linux Distributionen (Debian, SUSE, Fedora, etc.) sinnvolle und gute Produkte als festen Bestandteil integrieren. Bei Windows passiert dies nicht; Produkte müssen separat installiert werden. Während also die Anwendung GnuPG auf praktisch jedem GNU/Linux Systemen bereits vorinstalliert ist, muss sie, z.B. per Gpg4win, erst auf jeden einzelnen Windows-Rechner separat installiert werden.

7.2 Aufgaben bzw. notwendige Aktivitäten

Gpg4win ist ein Meta-Projekt. Damit unterscheidet es sich von vielen anderen Projekten die sich jeweils einer konkreten Software-Implementation widmen.

Es werden bei Gpg4win verschiedene Produkte aus anderen Projekten integriert. Hauptergebnis ist ein Installationspaket für Windows-Betriebssysteme welches zum Download bereitgestellt wird. Als „echter“, eigener Teil des Projektes zählen neben der automatisierten Routine für das Erstellen der Installationspakete noch die beiden Handbücher „Gpg4win für Einsteiger“ und „Gpg4win für Durchblicker“.

Man kann fünf Aufgaben identifizieren die auf Dauer zu erledigen sind:

1. Aktualisierung des Installers

Dies erfordert gewisse technische Kenntnisse. Die Einarbeitung kann durch ein gutes Tutorial noch weiter erleichtert werden. Es sollte aus Beispielen bestehen, die illustrieren, was getan wurde, um die eine oder andere Komponenten zu aktualisieren. Dabei sollten auch einige „Extremfälle“ berücksichtigt werden, z.B. Änderungen von Pfaden und Umgebungsvariablen.

Desweiteren fällt es in diesen Aufgabenbereich, eingegangene Fehlerberichte, die sich auf den Gpg4win Installer beziehen, zu bearbeiten. Das kann auch das Hinzufügen kleinerer neuer Features beinhalten.

2. Aktualisierung der Handbücher

Mit Aktualisierungen des Installers oder einzelner Komponenten können sich Dialoge oder Vorgehensweisen ändern. Diese müssen in die Handbücher eingepflegt werden.

3. Außendarstellung und Öffentlichkeitsarbeit

Zur Außendarstellung gehören die Pflege der Website sowie Bekanntmachungen für besonders bedeutende Aktualisierungen. Die Öffentlichkeitsarbeit umfasst werbende Maßnahmen zur Gewinnung weitere Nutzer und weiterer Beitragender.

4. Nutzerbetreuung

Zur Betreuung der Benutzer gehört es, auf den Foren und Mailing-Listen zu antworten und bei Fehlerberichten zu beurteilen, ob sie zu Gpg4win gehören oder zu einer der Komponenten. Im letzteren Fall ist der Fehlerbericht beim jeweiligen Projekt einzutragen.

5. Technische Administration

Hauptaufgabe ist es, die technische Infrastruktur zu betreuen. Typische Aufgaben sind die Moderation hängengebliebener E-Mails in den Mailing-Listen und allgemeine Verwaltungsaufgaben für die von Gpg4win benutzte Entwicklungsplattform „GForge“.

Die Aufgabe der Koordination bzw. Steuerung des gesamten Projektes erfolgt gemeinsam durch die Aktiven in diesen fünf Bereichen. Hinzu kämen Aufwände ausser der Reihe, wenn sich die Zielplattform entscheidend ändert oder die ausgelieferten Software-Produkte.

7.3 Schätzung der Aufwände für notwendige Aktivitäten

Die folgenden Abschätzungen resultieren aus grundsätzlichen Überlegungen sowie Erfahrungswerten der bisherigen Entwicklung von Gpg4win bis zu Version 1.0.2.

1. Aktualisierung des Installers: ca. 12 Stunden pro Monat.

Dies ergibt sich aus folgender Überlegung: Eine einzelne Aktualisierung dauert durchschnittlich 4 Stunden plus 2 Stunden Tests. Es ist durchschnittlich eine Aktualisierung pro 2 Wochen zu erwarten.

2. Aktualisierung der Handbücher: unregelmäßig nach Bedarf.

Grundsätzlich sind Änderungen eher selten zu erwarten. Notwendig werden sie u.U. dann, wenn wesentliche Änderungen an den Komponenten stattfanden oder aber neue Komponenten Einzug halten.

Es ist davon auszugehen, dass in naher Zukunft noch 2-3 weitere Komponenten aufgenommen werden. Wesentlich Änderungen der bestehenden Komponenten sind nicht absehbar.

Kleinere Änderungen am Installer selbst werden für die nahe Zukunft erwartet und sollten entsprechend im Handbuch für Einsteiger berücksichtigt werden.

3. Außendarstellung: Durchschnittlich ca. 8 Stunden pro Monat.

4. Nutzerbetreuung: Durchschnittlich ca. 8 Stunden pro Monat.

5. Technische Administration: Durchschnittlich ca. 2 Stunden pro Monat.

Mit einem sich vergrößernden Nutzerkreis werden auch die notwendigen Aufwände für die verschiedenen Aufgaben steigen.

7.4 Anwenderkreis

Die Anwender von Gpg4win lassen sich grob in drei Gruppen einteilen: Behörden, Unternehmen und Privatleute. Aus diesem Kreis können potentiell Beteiligte rekrutiert werden oder sich eine Finanzierung ergeben.

Die Privatnutzer, sowie Einzelanwender aus Unternehmen und Behörden werden, zumindest in den ersten Jahren, den größten Anteil stellen. Diese Gruppe machte auch bisher bei GnuPP und GnuPT den größten Anteil aus.

Für den systematischen Einsatz in Unternehmen und Behörden sind u.U. nur Versionen von Gpg4win interessant, für welche standardisierte Unterstützungsleistungen einkaufbar sind. Gegebenenfalls geht das Interesse auch stärker in Richtung eines Installers, der bestimmte Verfahren zur Software-Verteilung unterstützt.

7.5 Wirtschaftliche Trägerschaft

Kommerzielles Interesse für eine Freie Software ist oft der Schlüssel zu einer nachhaltigen Fortentwicklung. Kurzfristige wirtschaftliche Einzelinteressen dürfen jedoch nicht den Haupteinfluss erhalten; diese Art von Kommerzialisierung wäre schädlich. Vor Allem müssen die vier Freiheiten, sprich die Lizensierung als Freie Software, erhalten bleiben. Trotzdem bleibt Raum für das Geldverdienen und Beruf – beides ist sogar wünschenswert. Eine Professionalisierung ist vorteilhaft, besonders für notwendige langweilige Aufgaben und gleichbleibende Qualität.

Erreicht werden kann dies in der Regel nur aus einer ausgewogenen Beteiligten-Struktur heraus, jedoch nicht umgekehrt.

Ziel der wirtschaftlichen Trägerschaft ist die nachhaltigere Bindung von Hauptentwicklern an das Projekt. Denn die Entwickler können dann Ihren Lebensunterhalt, ggf. anteilig, über die Aktivitäten für das Projekt bestreiten. Sie sind damit nicht anderen Verpflichtungen unterworfen, welche eine Beteiligung, unter Umständen recht spontan, unterbrechen oder beenden könnten. Dieser Punkt ist im Falle von Gpg4win besonders wichtig, da die beschriebenen Schwierigkeiten (vergl. Abschnitt 7.1) eine geringere Anzahl freiwilliger Mitarbeiter erwarten lassen, als es bei anderen Freie Software Produkten der Fall ist.

Es wird empfohlen für Gpg4win eine wirtschaftliche Trägerschaft anzustreben. Als sinnvolles Geschäftsmodell bieten sich verschiedene Formen von Unterstützungsleistungen an: Wer mit Gpg4win arbeitet und zu einem gewissen Teil vom guten Funktionieren abhängig ist, hat ein starkes Interesse an der Qualität der Software, deren Kontinuität, sowie an Ansprechpartnern mit vertieftem technischen Verständnis und kurzen Reaktionszeiten. Ein sich tragendes Geschäft entsteht jedoch nur schrittweise. Hier ein Vorschlag:

Gpg4win hat bereits eine beachtliche Nutzerzahl und damit eine gewisse Sichtbarkeit erreicht. Hier besteht ein Ansatzpunkt, um Sponsoren aus dem Kreis der Anwender anzusprechen. Eventuell können diese Sponsoren auch um Bandbreite, Finanzierung von Messeauftritten oder Treffen gebeten werden.

Weiterhin ist es wichtig, auch den Wert der Software für die Nutzer zu ermitteln, denn der steht in Zusammenhang mit der Zahlungsbereitsschaft. Viele Freie Software Projekt ermöglichen bereits, „Spenden“ genannte, Kleinzahlungen. Hier ist langfristig ein großes Potential13. Der Dialog mit Sponsoren und die Zahl der Spenden kann wertvolle Hinweise ergeben, was bei Gpg4win technisch besonders gut gelöst wurde und wo noch Bedarf besteht. Die Hinweise sind deshalb wertvoll, weil es ein Unterschied ist, ob auf einer offenen Wunschliste steht "Ich hätte gerne, dass Funktion X bei Gpg4win erweitert wird" oder eine Spende von 100 Euro eingeht mit dem Kommentar "Mir hat Funktion Y sehr weitergeholfen, es wäre schön wenn es erweitert wird". Ersteres kann einer Laune entspringen, letzteres ist jedoch vermutlich wohlüberlegt.

Was aber mit dem Geld anfangen? Geringe Beträge, also Summen unter 10.000 Euro pro Jahr, sollten mit dem Ziel verwendet werden, weitere Personen einzubinden. Also bisherige Nutzer oder engagierte Nutzer zu qualifizieren und motivieren (Öffentlichkeitsarbeit und Marketing, vergleiche dazu Abschnitt 7.6). Eine direkte, beauftragte Bezahlung für Entwicklungsleistung ist voraussichtlich erst bei größeren Summen sinnvoll. Priorität sollten in diesem Falle Maßnahmen zur Absicherung der nachhaltigen Weiterentwicklung haben. Darüber hinaus käme auch der beauftragten Weiterentwicklung der Basiskomponenten eine wichtige Bedeutung bei, denn Gpg4win ist weiterhin ein Meta-Projekt und stellt in gewissem Umfang die Schnittstelle zwischen Windows-Anwender und den eigentlichen Software-Projekten dar. Eine Weitergabe an diese erscheint nicht nur grundsätzlich als fair. Er ist auch sinnvoll für den Erfolg von Gpg4win, denn diesem Meta-Projekt nützt das explizite Wohlwollen der Entwickler der zugrundeliegenden Software-Module.

Nächste Schritte könnten die Etablierung von Geschäftsmodellen durch entsprechende Unternehmen sein, beispielsweise für Pflege, Unterstützungsleistung, Schulung oder Weiterentwicklung.

Die Sicherung des Grundfortbestandes kann durchaus bereits hergestellt sein, sobald nur ein einziges Unternehmen genügend Interesse hat, sei es als Nutzwert oder als Marketingwert. Allerdings wäre der Fortbestand anfällig gegen Rückzug dieses einen Unterstützers. Weiteres Ziel sollte es also sein, mehr als einen Unterstützer zu finden, und dass diese Unterstützer nicht von der selben Quelle (z.B. ein bestimmter Kunde) abhängen.

7.6 Was könnte man mit einem einmaligen Geldbetrag erreichen?

Dieser Abschnitt fasst Ideen zusammen, wie man dem Ziel einer nachhaltigen eigenständigen Weiterentwicklung zuarbeiten könnte, falls man einen einmaligen Geldbetrag zur Verfügung hätte.


  • Verbesserung des Qualifizierungsprozesses:

    • Aufbau eines Anreizsystems zur Motivierung und Qualifizierung von Anwendern zum engagierten Anwender, vom engagierten Anwender zum Beitragenden usw.

      Es erscheint nicht sinnvoll oder machbar, hier mit einem finanziellen Anreizsystem zu arbeiten. Es wird vermutlich wesentlich besser auf Basis von individueller Anerkennung funktionieren.

      Eine Idee ist die Verteilung, Vergabe oder Verleihung von Gegenständen, die gleichzeitig eine Zugehörigkeit oder Zugehörigkeitsbekenntnis darstellen. Für Freie Software Projekte sind das typischerweise Dinge wie T-Shirts, Kaffeetassen oder Ansteck-Pins.

      Ein Anreizsystem auf Basis von Pins könnte beispielsweise wie folgt aussehen:

      Bronze-Pin: für umfangreiche Anwender-Unterstützung in den Foren oder für gute Fehlerberichte (also für engagierte Anwender).

      Silber-Pin: für Web-Seiten-Wartung, Prüfung von Fehlerberichten oder Arbeiten an der Außendarstellung (also für Beitragende).

      Gold-Pin: für die aktive Beseitigung von Fehlern, für die Erstellung von aktualisierten Gpg4win Installern oder die Integration eines neuen Moduls (also für Entwickler).

      Platin-Pin: für Kernentwicklung an den eigentlichen Komponenten (also für Kern-Entwickler).

      Blue-Pin: für die Übernahme der Projekt-Koordination ab einer bestimmten Anzahl von Monaten.

      Green-Pin: für finanzielles Sponsoring ab einer bestimmten Höhe.

      Begleitet würde die Verteilung der Pin mit einer „Hall of Fame“, welche die Empfänger der jeweiligen Pins auflistet und damit ehrt.

    • Automatisierungen

      Ziel der Automatisierungen sollte es sein, es zu gestatten, sich auf die interessanten Dinge zu konzentrieren, anstatt langweilige Dinge erledigen oder verstehen zu müssen.

      Mögliche weitere Automatisierungen bei Gpg4win finden sich im Bereich Installerbau, Erstellung von Neuigkeiten und Bekanntgaben, Plausibilitätsprüfungen, Tests auf aktuellere Versionen der bei Gpg4win integrierten Module oder des Veröffentlichungs-Verfahrens.

      Ein erster Schritt vor einer Automatisierung ist die ausführlicher Dokumentation der jeweiligen Prozesse.

    • Dokumentation

      Eine gute Dokumentation der verschiedenen Aufgaben, Hintergründe und Zusammenhänge wird nicht nur die Qualifizierung erleichtern. Es kann auch die Motivierung unterstützen, da die Dokumentation der Aufgaben klären kann, ob sich jemand dieser Aufgabe gewachsen fühlt. Letztlich geht es oft darum, zu vermitteln, dass die Aufgaben wesentlich einfacher sind als zunächst gedacht.

    • Treffen

      Persönliche Treffen erhöhen die Chancen auf Bildung einer harmonierenden Gruppe und deren Qualifikation. Ab dem engagierten Anwender ist eine Teilnahme möglich. Über Treffen kann gleichzeitig eine Anerkennung erfolgen und manchmal auch eine Umsetzung bestimmter technischer Ziele. Ein aktuelles Beispiel für ein erfolgreiches, bezahltes Treffen mit einem technischen Ziel ist der Python-„Sprint“14. Andere Beispiele für motivierende Treffen sind die KDE-Pim-Treffen, die seit ein paar Jahren regelmäßig im Januar in Osnabrück stattfinden.

  • Verbesserung der Attraktivität für Anwender:

    • Integration weiterer Module zur Erhöhung der Attraktivität für Privatnutzer:

      GPGoe (Plugin für Outlook Express).

    • Integration weiterer Module zur Erhöhung der Attraktivität für Vielbenutzerinstallation:

      GPGRelay (Verschlüsselung im Hintergrund und damit unabhängig vom benutzten E-Mail Programm).

    • Unterstützung von Softwareverteilungs-Systemen zur Erhöhung der Attraktivität für Unternehmen/Behörden:

      Im Vordergrund steht dabei die Erstellung von sog. MSI-Paketen.

  • Aktive Suche nach Sponsoren und Förderern

  • Internationales Marketing im Regierungsumfeld, um Interesse für eine regelmäßige Überprüfung von Gpg4win zu schaffen

  • Einbringen von Gpg4Win in übliche Softwarequellen für Windows, um die Nutzerzahlen zu erhöhen

8 Schlussfolgerungen und Empfehlungen

Ziel ist der nachhaltige, unabhängige, eigenständige Fortbestand von Gpg4win, so dass aktualisierte Versionen veröffentlicht werden, Fragen beantwortet werden und die Web-Seite aktuell gehalten wird.

  • Das wichtigste Teilziel ist die Etablierung einer ausgewogenen Beteiligten-Struktur wie in Abbildung 1, Seite 6 dargestellt. Es wird empfohlen, Nutzer zu motivieren und zu qualifizieren, beziehungsweise den Prozess dafür aufzubauen.

  • Das zweitwichtigste Teilziel ist die wirtschaftliche Trägerschaft. Es wird empfohlen, mit einem Sponsoring-Konzept und der Annahme von Kleinzahlungen zu beginnen.

  • Die technischen Aufgaben (Abschnitt 7.2) stellen die Grundlage für die beiden obigen Maßnahmen dar. Kurzfristig und kostengünstig ist dies nur durch die derzeit aktive und damit eingearbeitete Gruppe zu leisten.

Ideal wäre eine Finanzierung durch einen Geldgeber, welche die Umsetzung aller drei Punkte absichert. Hauptziel hierbei ist gleichzeitig der stückweise Rückzug aus der finanziellen Beteiligung, sobald die angestrebten Strukturen sich selbst tragen und nachhaltig zu wachsen beginnen.

8.1 Qualifizieren und Einbinden

Um die Motivation der Anwender, Entwickler und Sponsoren zu steigern, wird ein Anreiz-Konzept empfohlen wie z.B. besondere Pins als Nachweis/Anerkennung für hilfreiche Mitarbeit (vergleiche dazu Abschnitt 7.6). Benötigt wird in diesem Rahmen auch der Entscheidungsprozess für die Vergabe und letztlich eine Person, die die Pins auch versendet.

Ebenfalls hilfreich sind die Durchführung von Treffen bei denen engagierte Anwender und Entwickler zusammenkommen, sich persönlich kennenlernen und weitere Arbeiten direkt koordinieren können.

Für die Qualifizierung ist es notwendig, dass bereits qualifizierte Personen verfügbar sind und bei der Qualifizierung unterstützen. Es ist also empfehlenswert, darauf zu achten, dass diese bereits qualifizierten Personen entsprechend eingebunden werden.

Die Dauer des Qualifizierungsprozesses bis zur Etablierung einer ausgewogenen Beteiligten-Struktur kann schätzungsweise zwischen 6 und 24 Monaten liegen.

8.2 Wirtschaftliche Trägerschaft

Es ist empfehlenswert, auf eine wirtschaftliche Trägerschaft hinzuarbeiten.

Eine empfohlene Maßnahme ist die Suche nach Sponsoren. Dieser im englischen „Fund-raising“ genannte Ansatz ist gleichzeitig ein Indikator bzw. eine Form der Abstimmung, inwieweit ein nächster Schritt hin zu einem weitergehenden Angebot für Dienstleistungen erfolgen kann bzw. sollte.

Weiterhin wird für Gpg4win empfohlen, die Möglichkeit von monetären Spenden technisch über die Heimatseite einzurichten, und ein organisatorisches Verfahren zur Entgegennahme und Verteilung des Gelds zu finden (siehe Abschnitt 7.5).

Über die nächsten Schritte sollte aufgrund der Rückmeldung zu beiden Maßnahmen entschieden werden.

Appendix A: Konkrete Handlungsempfehlungen

Sie finden Gpg4win gut? Dann unterstützen Sie das Projekt. Es ist leichter als allgemein angenommen und selbst Wenig kann Erstaunliches bewirken. Wie bei jeder Freien Software können Sie entweder Zeit oder Geld geben15.

A.1 Als Freiwilliger

Egal, was Ihre Stärken und Schwächen sind, sie können Gpg4win mit Tat zur Seite stehen:

  • Arbeiten Sie sich ein und werden Sie erst engagierter Anwender und dann Beitragender. Beteiligen Sie sich an Foren oder Mailinglisten. Schon kleine Hinweise von Ihnen können andere Nutzer von Gpg4win oder einer Komponente freuen. Nehmen Sie sich einfach eine Aufgabe, sagen auf der Mailingliste Bescheid und fangen Sie damit an.

  • Schreiben Sie Ihre Meinung. Was ist gut? Was ist schlecht? Wo liegt ein Problem? Ist die neue Version besser? Tun Sie das respektvoll, da die Adressaten oft auch Freiwillige sind.

  • Werben Sie andere Freiwillige und Geldgeber. Sprechen Sie beispielsweise andere Nutzer freundlich an. Wenn Sie Unternehmen oder Behörden kennen, welche Gpg4win schon einsetzen, lohnt vielleicht die Anregung etwas für die Sicherung der Software zu tun. Einige Behörden haben die Entwicklung bereits gefördert. Nehmen Sie auf die Politik Einfluss: Loben Sie die bisherigen Ergebnisse und fordern Sie eine Fortführung der Unterstützung.

  • Verbreiten Sie Gpg4win aktiv. Sie können Zeitschriften anregen, dass Sie sich das Thema wünschen oder Softwareverbreiter darauf aufmerksam machen, dass Ihnen Gpg4win fehlt. Sprechen oder schreiben Sie über Gpg4win. Motivieren Sie andere zur Nutzung.

A.2 Als Geldgeber

  • Geben Sie einen kleinen Betrag über die Zahlmöglichkeit der Webseite, versehen mit einem kurzen Kommentar für welche Verbesserung Sie wieder etwas geben würden und was Ihnen besonders an Gpg4win gefällt. Auch einstellige Euro-Beträge können helfen und motivieren.

  • Bei einem mittleren Betrag, kontaktieren Sie einen der Projektbeteiligten und zahlen gegen Rechnung. Eventuell können Sie ein bestimmten Schritt wie Aktualisierung, Beseitigung eines Problems oder Hinzufügen einer Funktion beauftragen. Achten Sie darauf, dass jede beauftragte Verbesserung dem Gpg4win-Hauptstrom zu Gute kommt.

  • Als Unternehmen oder Behörde beauftragen Sie die drei Maßnahmen aus Abschnitt 8 und sichern damit eine nachhaltige Fortführung des Projekts. Sie erhalten damit Gpg4win dauerhaft für Ihre Organisation. Einher geht der Kollateralnutzen, dass darüber hinaus die Sicherheit beim Datenverkehr im Allgemeinen verbessert wird.

4 Karim Lakhani, Bob Wolf, Jeff Bates and Chris DiBona, Hacker Survey v0.73, 24.6.2002, Boston Consulting Group http://www.osdn.com/bcg/

5 Bernhard E. Reiter, Wandel der IT: Mehr als 20 Jahre Freie Software; in HMD, Heft 238, August 2004, Seiten 83-91 http://intevation.de/~bernhard/publications/200408-hmd/200408-wandel_der_it_20j_fs.html

13 Dazu auch Reiter 2002: Arbeitsteilung im Massenmarkt, Linux-Magazin 06/2002, http://www.linux-magazin.de/Artikel/ausgabe/2002/06/geld/geld.html

15 Allgemeine Hinweise finden sich oft im Wiki http://www.deshalbfrei.org/moinmoin/freiheit_helfen.