|
fit 2002 > Softwareentwicklungsmodelle > Bazaarmodell >
die reale Praxis |
|
Überblick |
|
Das Bazaarmodell ist, wie bereits beschrieben, eine Entwicklung aus dem Open Source Software Development Bereich. Dort findet es auch seine größte Akzeptanz. Der Bereich der Open Source Software Entwicklung hat auf gewisse Segmente der Anwender immer schone eine große Anziehung ausgeübt, aus dem einfache Grund da im Gegensatz zu den kommerziellen Entwicklungen auch die Quellcodes verfügbar gemacht werden. Diese Offenheit war allerdings oftmals auf den Quellcode beschränkt, Eingriffe in den Entwicklungsprozess waren so gut wie nicht möglich. Dies hingegen ist eine der größten Stärken des Bazaarmodells. Durch die Proliferation des Internets auch im privaten Bereich im letzten Jahrzehnt hat sich die Praxis von internationaler Kooperation verbreitet und dadurch auch die Möglichkeit geboten für Projekte wie Linux wo eine große Anzahl von Personen an der Entwicklung beteiligt ist. Das Bazaarmodell hat in diesem Zusammenhang seine größte Bedeutung und Anwendung in einem essentiell gesehen riesigen Debugnetzwerk. Viele Leute versuchen Fehler zu finden in existierender Software und arbeiten auch gleich daran diese Fehler zu eliminieren bzw. die Software überhaupt zu verbessern. Wie Eric S. Raymond schon bemerkt in seinem Paper über Cathredral und Bazaar: Debugging is parallelizable Eric S. Raymond Viele Personen können und arbeiten auch gemeinsam daran Fehler zu finden. Für die Suche nach Fehlern müssen sie nicht miteinander in direktem Kontakt stehen, sondern können unabhängig von einander die Fehler suchen. Das einzige was sie brauchen ist eine zentrale Sammelstelle für die gefundenen Fehler. Etwas das in vielen Fällen entweder eine Mailingliste oder ein messageboard ist. Durch diese öffentliche Form der Kommunikation ist es auch nicht notwendig das der Fix für einen Bug von der Person kommen muss die ihn gefunden hat. 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Eric S. Raymond Hier kommt es zu der Nutzung der sehr breiten Wissensbasis die durch die Internetgemeinschaft gegeben ist. Ein unlösbareres Problem von einer Person mag ein einfachst zu lösendes für eine Andere sein. Es gibt somit so gut wie keine unlösbaren Probleme. Obwohl es eines der Hauptanwendungsgebiete für das Bazaarmodell ist, ist das Modell nicht darauf beschränkt auch in der Praxis eine Form von dezentralisiertem Debugging zu sein. Wie in dem Zitat oben bereits angedeutet, fallen viele Anwender des Modells in sowohl die Kategorie Beta-Tester als auch Mitentwickler. Dies bedeutet das sie nicht nur einfach nach Fehlern suchen, bzw. Fixes für diese Fehler erstellen, sondern das sie auch gewisse Aspekte der Software weiter entwickeln oder gar völlig neue Features zu einer Software hinzufügen. Ein derartiges Verhalten würde eigentlich zu einem riesigen Chaos führen im Normalfall, aber hier liegt eben die stärke des Bazaarmodells, das eine derartig weitreichende Kooperation funktioniert, und auch gut funktioniert. Ein Fakt der sehr stark vom Haupt-Entwickler, oder auch Maintainer der Software abhängt. In der Praxis hat sich gezeigt das für derartige Positionen am besten Personen geeignet sind die in der Lage sind mit anderen zu kommunizieren, die eher Vokal veranlagt sind und zu einem gewissen Grad eine Gabe haben sich 'hörbar' zu machen. Ebenso sollten sie sachlich versiert genug sein um die Thematik des Projektes das sie maintainen zu verstehen, auch wenn sie in Teilen mehr administrative Tätigkeiten durchführen bei steigender Größe des Projektes. Gute Beispiel hierfür sind Eric S. Raymond und Linus Torvalds. Beide waren und sind in der Lage das Interesse von anderen zu wecken und dann die daraus entstehende Flut von Antworten auch zu verarbeiten. Die Rolle des Maintainer Was bedeutet diese Rolle nun genauer in der Praxis? Ein Open Source Projekt, speziell eines welches auf das Bazaarmodell setzt fängt im Gegensatz zu den klassischen Modellen nicht mit einer Idee an, sondern vielmehr mit einer ersten, lauffähigen Version dieser Idee. Diese erste Version muss nicht gut sein, sie muss nicht vollständig funktionieren, aber sie muss ein Stück Code sein. Dies ist ein doch sehr starker Bruch von allen Ansätzen der klassischen Entwicklung. Die Person die diese erste Version ins Netz stellt und die Leute darauf aufmerksam macht und somit den Prozess startet der das Bazaarmodell darstellt, ist dann auch der Maintainer der Software. Die finale Instanz dafür was und was nicht in die Software integriert wird von allen Bugfixes, neuen Features und dergleichen welche von den 'Mitentwicklern' geliefert werden. Dies bedeutet das der Maintainer eine Sammelstelle für alles ist, und am Ende auch das letzte Wort hat in welche Richtung sich das Projekt entwickelt. Eine derartige Situation kann natürlich gut oder schlecht sein, und führt dazu das ein Projekt mit seinem Maintainer steht oder fällt. Diese Rolle ist auch von solcher Bedeutung das es zu einer interessanten Dichotomie kommt hierbei. Viele Befürworter von Open Source Entwicklung weisen immer wieder darauf hin wie viel besser es doch ist alles frei zu lassen, und sich loszusagen von den abgeschlossenen und abgekapselten Prozessen der klassischen Modelle wie sie zum Einsatz kommen in kommerziellen Firmen. Dieser Stellung ist für kleinere bis mittlere Projekte auch vertretbar, aber sobald sich ein Open Source Projekt einem großen Rahmen nähert scheitern diese Ansätze doch eher kläglich und werden dann ersetzt durch die klassischen Modelle des Projektmanagements. While noting that "a lot of the actual technology that built the Internet was open source," Baker made the point that in order to keep a software project "stable," it must inevitably be managed by a commercial company. "Managed development is the key to a quality product," he said. from Dies ist allerdings nicht so sehr ein scheitern des Bazaarmodells als vielmehr ein scheitern des alles soll frei sein Gedankes hinter Open Source. Speziell einige Aspekte und Gedanken der FSF stehen in starken Konflikt mit dieser Realität. Das beste Beispiel in diesem Zusammenhang ist das Vorzeigekind des Open Source Gedankens und Bazaarmodells. Linux zeigt sowohl die Stärken als auch die Schwächen des Modells und Gedankens. Obwohl viele professionelle Entwickler für eine lange Zeit der Meinung waren das das Projekt zum scheitern verurteilt ist und in nächster Zeit irgendwo fundamentale Probleme entwickeln würde, hat es Linux wieder erwarten doch geschafft bis jetzt stabil zu bleiben und sich weiter und weiter zu entwickeln. Diese Entwicklung ist aber nicht ohne ihre Probleme. Durch die im Grunde private Natur der Entwicklung werden Entscheidung immer wieder auf Grund von persönlichen Gefühlen für die involvierten Personen getroffen, nicht aufgrund davon was am Besten wäre für das Projekt. Dies ist sehr gut am Beispiel der Virtual Machine von Linux zu sehen. Ein weiterer, sehr wichtiger Punkt für die Open Source Entwicklung im Allgemeinen und für die Linux VM im speziellen, ist auch das manche Aspekte nicht von Personen bearbeitet haben die dafür am besten Qualifiziert sind. Entweder sind besagte Experten nicht gewillt an den Projekten mitzuarbeiten, sind sich nicht bewusst das diese existieren, oder es ist nur ein Experte präsent beim Projekt wenn es besser wäre mehrere zu haben für einen Dialog bezüglich des Problems. Dieses Problem geht so weit das viele Projekte sterben weil niemand gewillt ist sich um gewisse Aspekte zu kümmern. Oder um es in der durchaus Hacker-artigen Mentalität vieler Open Source Programmierer zu sagen: "How to get cool people to do un-cool things."Wirtschaftliche Aspekte Viele Open Source Projekte entstehen weil ein Entwickler etwas hat was ihn oder sie stark stört an einer existierenden Lösung, bzw. das es ein feature gibt das er oder sie unbedingt will, aber von nichts angeboten wird. Dies ist der Grund für viele existierende Programme im Open Source bereich, manche mit einem großen Nutzbarkeitsfaktor, manche mit einem sehr kleinen. Alles in allem, ist ein Aspekt aber bei allen zu finden, es sind private Projekte von Privatpersonen. Diese mögen in ihrem 'Dayjob' als Programmierer tätig sein, oder auch nicht. Sie werden auf jeden Fall nicht (oder wenn dann nur in den seltensten Fällen) dafür bezahlt das sie im Open Source Bereich tätig sind. Es wurden im Bereich Entwicklung und Auswirkung bereits auf die unterschiedlichsten Businessmodelle eingegangen. Viele wurden erdachte, viele haben nicht funktioniert. Das Hauptproblem bei ihnen ist am Ende auf jeden Fall, dass die Leute die Open Source Software programmieren auch von etwas leben müssen. Open Source, durch den dahinter stehenden Gedanken der freien Verfügbarkeit, ist nicht sehr geeinigt dafür den Erstellern einen Lebensunterhalt zu garantieren. Linux, das oft zitierte Vorzeigekind des Open Source Gedankens ist hier sehr leicht zu sehen als Problem. Die Befürworter sehen es als Möglichkeit ein OS zu bekommen ohne wirklich dafür bezahlen zu müssen. Durch die Open Source Wurzeln ist Linux allerdings in den seltensten Fällen für die Massenmarkt geeignet. Es wurden in den letzten Jahren große Fortschritte gemacht in diesem Zusammenhang, aber Linux an sich wird von vielen Leuten in der Industrie nicht als vertretbare Alternative als Desktop OS gesehen. Seine Zukunft und Stärke wird im Server Bereich gesehen. Open Source hat natürlich auch Einfluss auf die Bemühungen der großen Softwareunternehmen gehabt und hat sie immer noch. Microsoft hat sich mit Linux als Konkurrent auseinander gesetzt, ist soweit gegangen um Dokumente zu verfassen wie mit dieser 'Bedrohung' umgegangen werden kann. Solche High-Profile Bemühungen sind allerdings sehr selten geworden in letzter Zeit. Wirtschaftmodelle die Versuchen klassische Ansätzen eins zu eins auf Open Source umzulegen scheitern. Linux, mit all seinen Vorzüge hat keinen Weg wie es seine Entwickler von nichts leben lassen kann, was eine Weisheit ist die auch viele Unternehmen erkannt haben. Open Source ist als Schlagwort viel verwendet worden von den großen Unternehmen, aber trotz aller zusagen die Entwicklung von Open Source Software zu fördern, sehen sie Projekte wie Linux mehr als Mittel zum Zweck als eine gute Idee die gefördert werden sollte. IBM, Sun, Intel und auch Microsoft haben Linux und auch den Rest der Open Source Gemeinde als Spielball der Macht zwischen sich. Sie versuchen (im Fall der ersten drei) Microsoft's Vormachtstellung zu untergraben, ebenso wie die der anderen Konkurrenten. Im Fall von Microsoft kommt es sogar zu einer ziemlichen Ironie, viele Gegner von Microsoft in der Open Source Gemeinde verwenden Dienste die von Microsoft (und auch Intel) angeboten werden, und treffen immer wieder Aussagen wie froh sie doch sind von diesen Unternehmen weg zu kommen. Dies ist aber nicht möglich in der Praxis. Am Ende, trotz aller Bemühungen auf allen Seite mehr daraus zu machen, Linux scheint seit es die Aufmerksamkeit von den 'Großen' der Softwarebranche bekommen hat wenig mehr zu sein als ein sich entwickelnder offener Standard der es erlaubt eine Einheit zu schaffen die es dem Benutzer erlaubt mit einem gleich bleibenden Front-End auf den unterschiedlichsten Systemen zu arbeiten. Siehe hier Auf dem obersten Ende des Spektrums scheint dies das beste zu sein was mit dem Bazaarmodell zu erreichen ist. Linux ist an einem Punkt angekommen wo es Arbeit ist, und nicht Spaß daran zu arbeiten. Fehler werden immer noch gefunden, die Entwicklung geht noch weiter, aber die Probleme die bereits gelöst wurden von kommerziellen Konkurrenten zu Linux sind größere Brocken und meistens nicht was Personen in ihrer Freizeit angehen. Der gesamte Open Source Bereich, speziell das Bazaarmodell, zeigt immer wieder das er/es auch die unerwarteten Probleme lösen kann, meist in einer Zeit die nicht im Ansatz erreicht werden kann mit anderen Methoden. Als Hype ist es allerdings nicht mehr so stark wie vor noch einem Jahr. Die Entwickler sind nicht abgesprungen, aber es ist einfach nicht mehr im Fokus des Medienrummels.
|
|
Weiterführende Informationen |
|
|
|
Verweise auf Arbeiten anderer gruppen |
|
|
|
>Entstehungskontext | Konzepte und Techniken | Entwicklung und Auswirkungen | Praxis | Bewertung |
Für den Inhalt verantwortlich: Roman Stoiber, E881, 9725687 |