Wie Freie Software entsteht

Die Entwicklung von Freier Software unterscheidet sich grundlegend von der klassischen Software-Entwicklung, so wie sie an Universitäten gelehrt wird oder wie sie tatsächlich praktiziert wird.

Software-Entwicklung in 6 Phasen, mit möglicher Korrektur

Das ist ein theoretisches Universitäts-Modell.

Konventionelle Software-Entwicklung

• Auftrag
• Produktdefinition und Vertrag
• Entwicklung
  • Hierarchien
  • Kleine Programmierer-Teams (6 Personen)
  • Kontrollierter Informationsfluß
  • Kleiner Arbeitsbereich pro Team
• Meilensteine
• Deadlines
• Marketing, Werbung
• Vermarktung
• Support, Schulung und Wartung
• Erweiterungen

Konventionelle Software-Entwicklung beinhaltet auch

• Unvollständige Anforderungen
• Schwammige Spezifikationen
• Nachgereichte Wünsche
• Nicht eingehaltene Meilensteine und Deadlines
• Programmier-Sessions
• Halbfertige Produkte
• Verspätete Auslieferung
• Fehlerhaftes Ergebnis
• Hoher Wartungsaufwand
• Hohes Risiko
  • Sicherheit nicht nachvollziehbar
  • Produkt endet, wenn Hersteller pleite ist oder das Produkt nicht mehr weiterentwickelt wird

Hierarchische Kommunikationsstrukturen

Kommunikation jenseits der Hierarchie oft nicht erwünscht

• Antwort auf Bedürfnis
  • z.B. KDE
  • z.B. GNOME
  • z.B. MagicPoint
• Oft Eigenbedarf
  • z.B. isdn4linux
  • z.B. dtaus
• Oder Spielerei bzw. Experimentierfreudigkeit
  • z.B. Gerstensaft
  • z.B. ping
  • z.B. Linux
• Allgemein
  • Ergebnisorientiert
  • Akademischer Ansatz: Software ist Information

Erläuterungen

• KDE wurde von Matthias Ettrich ins Leben gerufen, weil er mit den vorhandenen grafischen Schnittstellen auf GNU/Linux-Sytemen nicht zufrieden war und sie sich zuweit von dem von Microsoft mit Windows gesetzten Quasi-Standard entfernten. Dadurch wurde es für viele Leute erheblich schwieriger, auf GNU/Linux umzusteigen. Mit KDE funktioniert die Oberfläche ähnlich wie in der Windows-Welt
• GNOME wurde als Antwort auf KDE erschaffen, da sich die KDE-Entwickler fatalerweise auf eine nicht-freie Bibliothek abgestützt haben, so daß KDE als ganzes zwar unter GNU/Linux zur Verfügung stand, jedoch nicht frei war wie der Linux-Kernel oder der Compiler.
• MagicPoint ist das von mir verwendete Präsentationsprogramm und bietet die wichtigesten Fähigkeiten, die man zum Präsentieren von Vorträgen braucht. Zweifellos stieg mit der Popularität von GNU/Linux auch das Bedürfnis, Vorträge nicht nur über, sondern auch mit diesem Betriebssystem zuhalten.
• isdn4linux wurde von den ursprünglichen Entwicklern erschaffen, damit sie ihr Netzwerk (IN e.V. - KNF e.V.) weiterhin und auch mit ISDN-Verbindungen betreiben können und bisherige "Lösungen" nicht praktikabel waren.
• dtaus wurde von mir entwickelt, damit die Verwaltung des ersten oldenburger Wohnheimnetzes vollständig mit Freier Software geschehen konnte und damit wir die Abhängigkeit zu einer vollkommen unbefriedigenden Windows-Software verlieren, mit denen wir zu Anfang in Ermangelung eines besseren Programms die Bankeinzüge gemacht haben.
• Gerstensaft wurde von mir geschrieben, hauptsächlich, damit ich ein reales Projekt hatte, um mich mit GTK zu befassen, einer ziemlich guten Grafikbibliothek (die auch hinter GNOME steht).
• ping ist genauso ein Abfallprodukt. Gerüchten zufolge hat der Erfinder mit TCP/IP herumgespielt beim Spielen ist ihm aufgefallen, daß die Pakete unterschiedlich lange brauchen und daß man das messen konnte.
• Linux wurde von Linus Torvalds begonnen, weil er sich mehr mit seinem neuen Rechner beschäftigen wollte und mehr über die Architektur lernen wollte. Daß daraus ein neues Betriebssystem wird und eine revolutionäre Bewegung in Gang kommt, hatte er sich nicht träumen lassen.

Keine Hierarchien Keine Einschränkungen Jeder mit jedem Teilnehmer sind gleichberechtigt Einfacher Draht zu den Entwicklern Kommunikation öffentlich Teilweise öffentlich archiviert

Mitarbeit

• Meistens in der Freizeit
• Als Hobby

Software-Projekte

• Räumlich getrennt, ohne Internet kaum möglich
• Kommunikation elektronisch
• Mitarbeit verursacht kaum Kosten
• Man ist, was man kann
• Jeder arbeitet soviel wie er möchte
• Jeder arbeitet dort, wo er möchte
• Keine Vorgesetzte
• Oft Zugriff auf alle Teile
• Programmier-Camps
• Gemeinsames Verantwortungsgefühl

Generell

• Offene Standards
• Offene Kommunikation

Damit Freie Software "funktioniert", wird eine Lizenz benötigt, die folgendes sicherstellt:

• Freier Zugang zum Quellcode
• Freier Zugang zu benötigten Werkzeugen
• Erlaubnis für Modifikationen
• Erlaubnis der unbeschränkten Weitergabe
• Uneingeschrängte Einsatzgebiete
• Für viele wichtig: Veränderungen müssen genauso freigegeben werden

Man ist, was man kann:

• Meistens Software-Entwickler
• Wenig Projektleiter
• Kaum Software-Ergnomen
• Selten Dokumentierer
• Support nebenbei
• Kein Marketing
• Kaum PR
• Geben und Nehmen

Also:

• Ein weites Feld für Mitarbeit
• Nicht-Technische Mitarbeiter gesucht
• PR, Marketing und Dokumentation stark ausbaufähig
• Dokumentation oft von Dritten (Bücher, Zeitschriften)

• Erste Version
• Tester
• Verbesserungen
• Fehlerberichte
• Zweite Version
• Mehr Entwickler
• Mehr Features
• Modularisierung
• Wiederverwendung
• Flexibilität

Resultat:

• Code-Cleanup
• Anpassung des Einsatzgebietes
• Verwerfen von ineffizienten/schlechtem Code
• Korrektur von inkorrektem Code
• Umstieg auf neues Produkt, falls es besser ist

Tatsächlicher Kreislauf Software-Reuse Kontinuierliche Weiterentwicklung Einbeziehung der Anwender Möglichkeiten zur Mitarbeit

Was passiert, wenn zu einem späten Zeitpunkt neue Mitarbeiter zu einem Software-Projekt hinzugfügt werden?

Konventionelle Software-Entwicklung Zusätzliche Zeit für Einarbeitung notwendig Zusätzliche Kommunikation Hält bisherige Mitarbeiter von der Arbeit ab Verlangsamt ein Projekt Ist nicht ratsam

Freie Software Einarbeitung weniger stark da: Kommunikation öffentlich und archiviert Neue Personen müssen Archive lesen Quellcode vorher verfügbar Fehlerbereinigung Einbringen neuer Aspekte

• Meist an eigenem Bedarf orientiert
• Saubererer Code
• Effizienter Code
• Offene Schnittstellen
• Standardkonform
• Sichererer Code
• Stark modularisiert
• Erweiterbar
• Flexibel
• Teilweise minimalistisch
• Schnittstellen
• Verteilt einsetzbar
• Immer nur so gut wie ihre Entwickler
• Endergebnis teilweise zu Anfang nicht bekannt
• Direkter Draht zu den Entwicklern

• Netzzugang für die Mitarbeiter
• Ansporn der Mitarbeiter
• Akzeptanz der eigenen Arbeit
• Verfügbarkeit von Werkzeugen
  • Beispiel: C- und C++-Compiler, lex und yacc
  • Gegenbeispiel: Modula2/3
• Infrastruktur
  • Mailing-Listen
  • Website
  • Archiv für Quellcode
  • evtl. Online-Diskussionsforen
  • Quellcodeverwaltung (CVS)

Sourceforge und BerliOS bieten:

• Website
• Mail-Adresse für Mitarbeiter
• CVS-Archiv, persönlich
• Anonymen Zugang zum CVS-Archiv
• Allgemeine Einsicht in CVS-Archiv
• Mailing-Listen

Open Projects Network (jetzt: Freenode) bietet:

• Online Diskussionsforen (Chat)
• Registrierung von Channels (ChanServ)
• Registrierung von Nicknames (NickServ)

• Entstehung
  • Experiment von Linus Torvalds
  • "Gefundenes Fressen"
• Entwicklung
  • Linus entscheidet letztendlich
  • Release wenn Kernel stabil ist
  • Quasi keine Zeitvorgaben
  • Mehrere Quellcode-Archive
• Mitarbeiter
  • Weltweit verteilt
  • Mehrere Hundert
  • Spezialisiert auf wenige Bereiche
  • Unterstützung durch Firmen
• Kommunikation
  • Haupt-Mailing-Liste
  • Themenbezogene kleine Mailing-Listen
  • Konferenzen

• Entstehung
  • Vision von Matthias Ettrich: Einfacher Desktop
• Entwicklung
  • Kern-Team
  • Programmier-Camps
  • Release-Pläne
  • Druck vor Release
• Mitarbeiter
  • Weltweit verteilt, Schwerpunkt Europa
  • Mehrere Hundert
• Kommunikation
  • Mailing-Listen
  • Konferenzen
  • Programmier-Camps (semi-regelmässig)

• Entstehung
  • Vision von Ian Murdock: Freie Distribution
• Entwicklung
  • Weltweit verteilt, Schwerpunkte: USA, Deutschland
  • Schwerpunkte: Ideologie und Technik
  • Core-Team und normale Entwickler
• Mitarbeiter
  • 800 registrierte Mitarbeiter
  • Mitarbeit wegen Ideologie
  • Kleine Arbeitsbereiche
• Kommunikation
  • Viele Mailing-Listen (ca. 150)
  • Online (Open Projects Network), hauptsächlich Core-Team

Akademische Frage:
Kann ein Software-Projekt scheitern?
Oder wann ist es gescheitert?

• Konventionelle Software-Entwicklung:
  • Nicht eingehaltene Termine
  • Unfertiges Endergebnis
  • Unergonomisch, fehlende Akzeptanz
  • Gescheitertes Marketing
  • Kein oder kaum Verkauf
• Freie Software:
  • Es gibt keine Deadlines
  • Halbfertige Produkte sind auch brauchbare Ergebnisse (Re-Use)
  • Falsche Ergebnisse sind Basis für Korrekturen
  • Wenn es nur einen einzigen Benutzer gibt, ist es ein Erfolg