ARCHIV 1999-2006

ARCHIV :: # 2126

Open Source Software & Effizienz

OSS ist besser, schneller fertig & sympathischer

Autor: mike - Datum: 27.06.2003

Einem Artikel der Onlineausgabe des Nature zur Folge entwickelt sich Computer Software effizienter, wenn der Code dazu von Allen eingesehen werden kann. Dies ist das Ergebnis, zu dem britische Forscher in einer Studie kamen. Für Verfechter des Open-Source Softwaremodells ist dies keine Überraschung, kommt bei Ihnen doch die Überlegenheit frei verfügbaren Codes wie etwa Linux oder Apache einem Glaubensbekenntnis gleich - eine ebenso ideologische Bekenntnis als auch eine rein technische.

Das von Damien Challet und Yann Le Du vom Bereich Theoretische Physik der Oxford Univerität ausgedachte theoretische Modell für das Debuggen von Software sendet denn auch ernüchternde Botschaften an Firmen, die ihre Software für sich behalten wollen. "Closed Source" Software, die feingeschliffen werden muss, indem ein dediziertes Programmiererteam quasi einzelnes User-Feedback auswerten muss, erfordert viel höhere Qualifizierungen seitens der Softwarebauer. Ganz zu schweigen von der höhere Anzahl an User, die erforderlich ist, damit die Software ebenso ausgereift ist wie ihr Open Source Pendant in vergleichbarer Zeit.

Mit anderen Worten wird bei gegebener Anzahl Anwender, die Feedback geben und vergleichbaren Programmiererteams zur Verbesserung der Software immer das Open Source Modell schneller debuggt sein, wie die Forscher anerkennen.

So klar muss das aber nicht sein. Bei identischen Entwicklungsteams scheint es naheliegend zu sein, dass es keine Rolle spielt, ob der Quellcode verfügbar ist oder nicht. Jedoch weist die Open Source Gemeinde nebst dem durch die Offenlegung erweiterten Informationsangebot auch eine grundsätzlich bessere Kommunikation auf, während es weitaus öfter zum Informationsaustausch zwischen Programmierer und Endanwender kommt.
Durch das breite Fundament bei offener Software kann sogar dann eine "bugfreie" (Bugfrei ist philosophisch zu betrachten) Software erreicht werden, trotz der latenten Möglichkeit, dass ein einzelner Programmierer plötzlich einen gemeldeten Bug nicht zu beheben vermag.

Die Open Source Gemeinde blickt auf eine über zehnjährige vergangenheit zurück und wirde in der Zeit hervorgebracht, als das Internet und das World Wide Web langsam zu den neuen Hypes heranwuchsen. Diese Philosophie forderte alle bisherigen Modelle heraus, seien sie noch so komplex. "Früher dachte ich", so der Entwickler Eric Raymond, "man müsse die wichtigsten Programme wie Kathedralen bauen, mit grosser Sorgfalt von ausgewählten Spezialisten gebaut oder von sich isolierenden kleinen Gruppen".

Viele Firmen - anvorderster Front unser winzigweicher Kontrahent aus Redmond - beschäftigen kleine Gruppen von Experten und Programmierern, die sich die Produkte ausdenken, sie programmieren und in regelmässigen Abständen "verbessern", teilweise aufgrund von User Feedback. Die der Öffentlichkeit präsentierten Updates sind aber Black Boxes, in die man nicht hineinsehen kann.

Unix aber, und das wissen mittlerweile viele, wurde Ende der 60er Jahre in den Bell Labs von AT&T geboren. Und es war anders. Es wurde für einen kleinen Betrag an die Anwender abgegeben wobei diese das Recht hatten, die Software zu modifizieren. Sie konnten damit tun was sie wollten, ja sie wurden dazu ermutigt.

1991 began dann ein Student an der Universität von Helsinki, an einem Stück Software zu basteln. Es war Linus Torvalds. Und er wollte ein Linus Unix haben - ein Linux eben. Zwar sollen auf die speziellen Gegebenheiten beim Linux Software Modell oder auf den Unterschied zu Unix nicht näher eingegangen werden, aber im Grunde konnte auch hier jeder an diesem Linux herumbasteln, wenn er wollte. (Nur war Linux für den HeimPC gedacht). Kombiniert mit etwas Feedback und einer Kontrollgruppe kann so die Kraft der Anwenderschaft genutzt werden, um die Fehler in der Software auszumerzen. Die Idee ist - um die Analogie von Eric Raymond noch mal auf zu greifen - dass viel User dabei nicht gemeinsam an einer Kathedrale bauen, sondern auf einem Bazaar interagieren.

Im OpenSource Modell kann sich der User mit der neuen Software versorgen, sobald die Programmierer die gemeldeten Fehler behoben haben, während im konventionellen geschlossenen Modell die Updates in bestenfalls periodischen Abständen präsentieren, während derer geschlossenen Entwicklerteams die Fehler ausmerzen.

In ihrer Studie schliessen Challet und Du, dass die Fehlerreporte seitens der User beim geschlossenen Modell stark abnehmen, nachdem ein Update verfügbar wurde. Dies lässt die Entwickler qusi in einem luftleeren Zustand, indem sie selbst Fehler suchen müssen, um sich Abeit zu beschaffen.

Je mehr Zeit zwischen den Updates vergeht, und je restriktiver die Firma mit ihrem "Eigentum" um geht, um so langsamer werden Bugs zerdrückt. So einfach ist das. Firmen wie Apple haben das gelernt: Öffentliche Betaversionen erhöhen die Qualität der finalen Version deutlich, drücken die eigenen Entwicklungskosten und sorgen gleichzeitig noch für Werbung. Es ist ganz klar, dass Safari u.A. genau deswegen in so kurzer Zeit so beachtliche Resultate zeigen konnte.

Kommentare

Open Source in anderen Bereichen?

Von: mickel | Datum: 27.06.2003 | #1
Wenn hier gerade das Thema angesprochen wird, gibt es Versuche diese "OSS-Philosophie" auf andere Bereiche zu übertragen, also nicht Software sondern auf andere "komplexe Entwicklungsbereiche" z.B. in anderen Wissenschaftsdisziplinen?

Wenn wer Links dazu hat, würde mich das sehr interessieren...

Grüße
mickel

Ich kann den Artikel nicht finden

Von: Alexander Nouak | Datum: 27.06.2003 | #2
Hallo Mr. Mike,

vielen dank für diesen interessanten Beitrag. Leider kann ich den zitierten Artikel in der Online-Ausgabe von Nature nicht finden. Könntest Du diese Quelle bitte näher spezifizieren? Idealerweise einen direkten Link auf diesen Artikel oder aus den Abstract, sollte er nur gegen Bezahlung zur Verfügung stehen.

Vielen Dank.


Servus

Alexander

Sorry, ich vergass!

Von: Mr. Mike | Datum: 27.06.2003 | #3
hier ist er:

[Link]

Das ist interessant

Von: Thyrfing | Datum: 27.06.2003 | #4
aber warum hat Apple dann die DevSeed Versionen von Safari angeblich "eingestellt"? Wollten die nur das Gesicht waren, verderben viele Betas den Brei?

Waren die späteren "Auswürfe" von Safari durch Apple gesteuert, um mehr Feedback aus den User Reihen zu kriegen (ich erinnere hier mal an den "MISTAKE" vor der Keynote).

Wollte Apple nicht zu viel ihres neuen Browsers bekannt geben, damit andere Entwickler nicht abschauen können (Camino, Mozilla, Omni)?

Fragen über Fragen

Thyr

Safari

Von: Mr.Mike (MacGuardians) | Datum: 28.06.2003 | #5
Hm also ich weiss dass.. - wie soll ich sagen - es bis zum Schluss Safari Builds gab.

Eine beta kann u.U. einem Erfahrenen "Forscher" hinweise geben, nicht nur was an Produkten kommen mag, auch was an Features eingebaut werden wird. Nicht immer ist eine Beta nach kurzer Zeit eine Vollversion, manchmal dauert es ja auch. Aber da sehe ich denke ich auch zuwenig hinter die Kulissen...