Links: * The Rules of Open-Source Programming

Über das Leben mit und das Arbeiten in OpenSource-Projekten.

Inhaltsverzeichnis dieser Seite Mechanismen für Projektleiter    Mechanismen für Mitwirkende    Mechanismen für User    Allgemeines    Problem: Akzeptanz von Verbesserungen    Links    Diskussion    Patente und OpenSource im kommerziellen Umfeld

Mechanismen für Projektleiter

Ein wichtiger Beitrag für Entwickler zu dem Thema ist dieser Artikel von EricRaymond:

"The Cathedral and the Bazaar" (1997)

...wie und warum Open Sorce Softwareentwicklung funktioniert

Überblicksmäßig braucht es zum Erfolg eines Projektes zuerst einen Prototypen um Interesse zu generieren. Dann engagierte Benutzer, die Ideen und Arbeit beisteuern. Dazu eine zentrale Figur, die es versteht den Beteiligten das Gefühl zu geben nützlich zu sein.

Links:

• The Rules of Open-Source Programming

Mechanismen für Mitwirkende

• mitwirkende Programmierer:
• Gelenkt von einem spezifischen Interesse an dem Paket
• Bringt seine individuellen Fähigkeiten ein
• Meist mit dem Ziel eine gewisse Funktionalität zu implementieren
• Erwartungen:
• Akzeptanz
• Beachtung seiner Beiträge
• Möglichkeit Probleme zu lösen
• Steigerung des Ansehens
• anderen helfen können

• Vorraussetzungen zur Erfüllung der Erwartungen:
• Beachtung der projektlokalen Gegebenheiten
• Einhaltung der CodingStandards?
• technische Kompetenz
• konstruktive Beiträge
• Kooperation

Diese Motivation ist der eigentliche Kernpunkt von freier Software und OpenSource. Die "spezifischen Interessen" reichen von egoistischen Motiven (z.B.: neue Hardware soll funktionieren) über kommerzielle Interessen (z.B.: Kunde verlangt gewisse Funktionalität) bis zu altruistischen Motiven (z.B.: Ermöglichung einer vollständigen asiatischen L10N?).

• mitwirkende Nicht-Programmierer:
• User
• Tester
• Dokumentierer
• Gelenkt von einem spezifischen Interesse an dem Paket
• Bringt seine individuellen Fähigkeiten ein
• Meist mit dem Ziel eine gewisse Funktionalität zu benutzen
• Erwartungen:
• Akzeptanz
• Beachtung seiner Beiträge (vorallem Bugreports)
• Möglichkeit Probleme aufzuzeigen
• Lösungen für Probleme erhalten
• Funktionalität
• anderen helfen können

• Voraussetzungen zur Erfüllung der Erwartungen:
• Beachtung der projektlokalen Gegebenheiten
• Einhaltung der CodingStandards?
• konstruktive Beiträge
• Verfassen sinnvoller Bugreports
• Kooperation
• Geduld

Mechanismen für User

Provokant gesagt: Es gibt keine User. Nur Mitwirkende.

Die WikiKultur ist für diesen Aspekt ein sehr gutes Beispiel: Jemand der nur liest hat praktisch keinen Einfluß auf das was hier passiert. Er bleibt deswegen auch bei Entscheidungsprozessen und subtileren Entwicklungen außen vor.

Sobald der hypothetische Leser jedoch in die Diskussion eingreift wird er zum Mitwirkenden und nimmt aktiv auf das Geschehen Einfluß. Im Kontrast dazu nehmen Kunden kommerzieller Firmen schon alleine durch die auf sie projizierten Vorstellungen der Firmenleitung (z.B. ihr erwartetes Kaufverhalten) Einfluß auf die Aktionen einer Firma. Natürlich ist das in OpenSource Projekten kein schwarz-weiß Vorgang (siehe Mechanismen für Mitwirkende), da hier ja zumindestens mit einer Kerngruppe von Usern Kontakt gehalten wird.

Im Gegensatz zur WikiKultur, wo die meisten sozialen Aspekte einem genauen Beobachter offenliegen, sind die internen technischen Zusammenhänge in einem OpenSource Projekt dem a-technischen Beobachter meist nicht zugänglich. Man kennt das ja aus diversen SoftwareProjekten?, wo die Vorstellungen des Kunden über die Komplexität von Eingriffen weit weg von den tatsächlihcen Gegebenheiten liegt.

Sehe ich nicht unbedingt so. Wenn sich jemand, der sonst praktisch nie schreibt, mit einem guten und überzeugenden Argument (in Bezug auf irgend eine das Wiki betreffende Sache) zu Worte meldet, dann würde ich das schon berücksichtigen; zumindest aber "bedenken"... :-)

// Hier zeigt sich wieder mal ein gewisser "Auffassungsunterschied"... :-)

Damit ist er aber ein Mitwirkender. Außerdem denke ich, daß es in der sozialen Welt des Wikis einfacher ist ein gutes und überzeugendes Argument zu formulieren, als in der technischen Welt, wo viele Faktoren zu berücksichtigen sind, die dem beiläufigen Beobachter entgehen.

"Mitwirkender" aber nur im "weitesten" Sinne. In Bezug auf "technische" Fragen kann gerade auch ein "Außenstehender" interessante Anregungen geben (gelegentlich) - vor allem dürfte der zumindest nicht "betriebsblind" sein... ;-)

Eine "interessante Anregung" ist aber kein "gutes und überzeugendes Argument". Gerade das macht aber in (schweren) Fällen von Betriebsblindheit einen großen Unterschied.

Sagtest Du nicht gerade selber, dass im technischen Bereich, der Außenstehende nicht so "mitreden" kann? (Recht hast Du!) - Daher muss man sich hier mit "interessanten Anregungen" zufrieden geben; wenn man denn nicht GANZ einen "geschlossenen Verein" darstellen will... :-) // OpenSource - OpenMind?

Ja. Leider funktioniert das (wie in Diskussionen mit den Entscheidungsträgern zu sehen ist) nicht.

Allgemeines

Generell kann man festhalten: Je weiter man sich von dem (projekt- und gesellschaftsspezifischen) "Mainstream" entfernt, desto mehr ist man in OpenSource Projekten auf sich selbst gestellt.

Das reicht von technischen Kleinigkeiten (wenig getestete Funktionalitäten und Optionen) bis zu globaleren Problemen wie immer noch mangelhafte UTF-8 und i18n/l10n Unterstützung.

Als Beispiel für den Teufel im Detail: von DavidSchmitt wurde einmal versucht, OpenSource Softwarepakete statt mit dem üblichen seriellen GnuSoftware:make mit einem parallelen make zu kompilieren. Bei einer Auswahl von 40 populären und zentralen Paketen hat rund ein Viertel der Pakete nicht kompiliert, da Abhängigkeiten innerhalb des Kompilationsvorganges unvollständig im Makefile abgebildet waren.

Damit das beim nächsten Mal dann automatisch funktioniert, muß David die Veränderungen dann flußaufwärts ("upstream") einreichen. Werden sie dort angenommen (entsprechen den qualitativen und inhaltlichen Vorstellungen des Autors) dann wird beim nächsten Release das parallele Kompilieren zumindest nicht fehlschlagen.

Problem: Akzeptanz von Verbesserungen

Und? Nehmen es die Autoren auf? Wenn ich ein C-Header mit typedefs anreichere (z.B. typedef int PlotFlags?;), um leichter Schnittstellen für die SpracheModula3 mit SWIG generieren zu können, ist das auch eine kompatible Verbesserung. Von dieser könnten die Nutzer anderer Sprachen mit ausgefeiltem Typsystem profitieren. Was ich in dieser Richtung bisher gemacht habe, wurde von den Autoren aber ignoriert. -- HenningThielemann

Möglich, dass deine Änderungen als stilistische Änderungen gesehen wurden. Hier wird die Akzeptanz geringer sein, als bei Änderungen, die zusätzliche Funktionalität bringen. Vermutlich wirken die gleichen Mechanismen, wie in anderen Online-Communities: Man muss zunächst einmal Vertrauen erwerben und eine persönliche Beziehung aufbauen, bevor eine Kooperations flüssig zu laufen beginnt. -- HelmutLeitner

Das Patchwork-artige Dazubauen von Funktionalitäten ist sicher ein Problem der meisten OpenSource-Projekte. Zu einem erfolgreichem OS-Projekt gehört sicher ein gelungener Start mit einer ausreichenden Größe und Professionalität. Der Rest ist dann ein Balanceakt zwischen konsistenter Weiterentwicklung der Software und guter Kommunikation mit der Community, die das Gefühl haben muss, dass ihr Feedback und ihre Anregungen auch fair umgesetzt werden. Ablehnungen so zu machen, dass sie nicht verärgern, ist eine hohe Kunst. -- HelmutLeitner

Das EclipseProjekt scheint eine gangbare Lösung für das Problem gefunden zu haben. Der Kern der Entwicklung liegt bei OTI (siehe VisualAge). Diese Firma entwickelt schon lange erfolgreiche Entwicklungsumgebungen. OTI hat viel in SpracheSmalltalk entwickelt und das Verstecken von Sourcen ist in dem Bereich eher unüblich. Trotzdem waren OTI-Entwicklungen früher eher ClosedSource. Dass in so einem Unternehmensumfeld plötzlich auf OpenSource gesetzt wird, ist schon erstaunlich. Die Plugin-Architektur ermöglicht es OTI aber, für eine stabile, akzeptierte Codebasis zu sorgen. Wer nämlich am System rumpfuschen möchte, kann das ausgiebig in einem eigenen Plugin tun. Es ist ein bischen wie bei Linux: An den Kernel wird nicht jeder rangelassen aber beim Drumherun gibt es viel Wildwuchs. Und auch zum aktuell so erfolgreichen Firefox gibt es Parallelen. Siehe auch das Interview mit Erich Gamma im eclipse magazin. -- SDö

Links

• OpenSourceHosts
• OpenSourceProjekte
• WieFunktioniertOpenSource
• OpenSourceProjekteMitCVS
• OpenSourceLizenzen
• OpenSourceUndOekonux

• Eugene Eric Kim:
• An Introduction to Open Source Communities
• A Manifesto for Collaborative Tools

Diskussion

Zu einer "Mechanik" gehört, dass der rechtliche Rahmen genau abgesteckt ist (OpenSourceLizenzen, wer hat welche Rechte und Pflichten), und dass die technische Form der Zusammenarbeit (meist CVS) klar ist. So kann man also - ohne viel herumzudiskutieren - gleich zur Sache kommen, also die Software für die eigenen Zwecke verwenden und adaptieren bzw. Verbesserungen zur allgemeinen Version beisteuern.

Patente und OpenSource im kommerziellen Umfeld

Ich denke schon seit längerem darüber nach, kommerzielle Software unter GPL freizugeben und sehe da aber noch ein paar Probleme:

Mir fallen dazu folgende Szenarien ein:

• Eine Firma veröffentlicht ein bisheriges ClosedSource Projekt als OpenSource - damit können dann alle Konkurrenten und solche die es werden wollen den Code auf Patentverletzungen prüfen und davon gibt es in jedem Trivialcode unzählige. Als Folge davon hätte die Firma beliebig viele Verfahren am Hals, die per se schon Ressourcen fressen und darüber hinaus droht noch das Nachzahlen von Lizenzgebühren und gebührenpflichtige Abmahnungen.

Das ist tatsächlich ein pikantes Thema. Sollten realistische Befürchtungen in diese Richtung existieren, empfiehlt sich der Abschluß einer guten Rechtsschutzversicherung. Die meisten dieser Trivialpatente halten keiner genaue Prüfung stand, da genügend PriorArt? existiert um zu beweisen, daß es sich dabei um keinen patentierbaren Mechanismus handelt. Ich bin allerdings kein Anwalt.

Leider ist damit dann die beklagte Firma nachweispflichtig. Dies und auch der Prozess an sich ist natürlich nicht ganz kostenlos ... -- mj

In Europa klafft hier ja speziell eine Lücke zwischen den rechtlichen Gegebenheiten (keine Patente auf Software) und der Praxis der einzelnen Patentämter (speziell das EPA), die sehr freizügig Patente vergeben.

Befindet man sich in einem so starken Wettbewerb, daß man mit solchen "Kampfmaßnahmen" rechnen muß, sollte man sich auch die Konsequenzen und erwarteten Vorteile besonders genau und objektiv versuchen gegeneinander abzuwägen.

Ich denke mal, jeder der auf irgend eine Art und Weise erfolgreich ist, hat genügend Neider und Projekte, die nicht erfolgreich sein dürfen, will ja keiner machen :-). Auch wenn die Wahrscheinlichkeit einer Klage nicht wirklich groß sind, so schätze ich das damit verbundene Risiko doch zimlich hoch ein .... wie sieht denn der schlechteste Fall aus ? Haben wir hier einen Juristen ? -- mj

damit verbundenes Risiko: Du meinst doch Kosten, oder? Risiko gering, Kosten hoch.

Ich meine damit Risiken ... also z.B. "nicht Erteilen einer Lizenz", "Nachforderung v. Lizenzgebühren", "Schadenersatz Forderung", "Gerichtskosten" oder "Motivationsproblem durch Rechtsunsicherheit". Diese Risiken sind natürlich mit Geld bewertbar, aber es steckt noch mehr dahinter.

• Eine Firma setzt OpenSource Produkte oder Libraries ein, ein Mitbewerber entdeckt in dem OpenSource Code eine Patentverletzung - und kann die Firma auf Unterlassung oder auf Lizenzzahlung (auch rückwirkend) verklagen.

Schwierige Situation. Allerdings: Je länger das Projekt existiert, desto länger gibt es PriorArt? und desto größer ist die betroffene Community, die in einem eventuellen Rechtsstreit zusammen auftreten kann.

Die Projektdauer schützt aber nicht vor der Rechtsunsicherheit. In einem lebenden Projekt werden laufend neue Sachen eingebaut.

Über das ganze doch hat sicher schon mal jemand nachgedacht ... wer kennt ein weiterführendes Buch oder Forum ? -- mj

Ist zwar nicht speziell OpenSource, aber scheint zumindest eine gute Übersicht zu bieten:

• http://slashdot.org/features/99/10/19/1032254.shtml

Hier ein excellentes Mail zum Thema SoftwarePatente:

http://lists.debian.org/debian-devel/2002/debian-devel-200209/msg00102.html

Quote: As a one who lives in a post-communist dictatorship, I have a different moral position on this issue.