Open Source Mechanismen
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Über das Leben mit und das Arbeiten in OpenSource-Projekten.
| Inhaltsverzeichnis dieser Seite | |
|
|
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
Dort wird am Beispiel von fetchmail - einem flexiblem Mailreceiver - die Funktionsweise der OpenSource Entwicklung erklärt.
Ü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:
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
Gelenkt von einem spezifischen Interesse an dem Paket
- 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.
Dieses Beispiel zeigt auch wie es zu Verbesserungen im OpenSource Bereich kommt: Weil DavidSchmitt einen zweiten Prozessor hat und gerne beide beim Kompilieren benutzen würde wird er jetzt hergehen und vielleicht beim einen oder anderen Paket etwas reparieren, oder zumindest das Makefile so modifizieren, daß die parallelen Aufrufe vermieden werden. ("Weg des geringsten Widerstandes")
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
Ich sehe bei den ganzen Projekten mit offenen Programmtexten folgendes Problem, welches aber mit Projekten ohne offengelegte Entwicklungsdaten auch nicht gelöst wird: Jemand fängt ein Projekt ganz klein an. Meistens fangen sogar viele Leute mit ähnlichen Projekten an, weil sie von den anderen Projekten nichts wissen oder wissen wollen. Zum Beispiel entstehen interessante Projekte oft als Diplomarbeiten oder Dissertationen. Dort wird irgendwie erwartet, dass es was neues ist, und nicht dass etwas Bestehendes verbessert wird. Damit Fehler in der Struktur vermieden und die Struktur des Programmes oder der Bibliothek nicht allzu eng ausgelegt wird, sollten eigentlich mehr Leute daran mitwirken. Manche Entwickler sagen sich auch, dass das Projekt nichts großes werden soll, oder verlassen sich darauf, dass man "Weiche Ware" immer wieder einfach ändern kann. Der größere Entwicklerkreis stellt sich aber erst ein, wenn das Projekt schon eine gewisse Größe erreicht hat. Je größer das Projekt und je mehr Leute daran mitwirken, desto schwerer wird es aber aufzuräumen, also zu vereinfachen, logischer zu strukturieren, usw. Deswegen wird dann meistens nur noch geflickt, um die Fehler herumgebaut. Also das, was ein Projekt erfolgreich macht, macht es auf die Dauer auch kaputt. Der überwiegende Teil der frei verfügbaren Bibliotheken, die ich benutze, scheint durch diesen Mechanismus beeinträchtigt worden zu sein. -- HenningThielemann
- 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ö
Artikel:
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.
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:
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.
Definitiv lesenswert.
KategorieOpenSource
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 12. März 2005 15:58 (diff))