|
Die Ideologie der Internet-”Open Source”-Gemeinde ist sehr vielfältig. Generell sind alle Mitglieder einverstanden, dass “Open Source” (und als solches auch Software, die frei veränderbar und wiedervertreibbar ist) eine gute Sache ist, allerdings herrschen noch in den Stufen und Ausprägungen dieses Glaubens große Unterschiede.
Im Verlauf der Zeit gesehen war der prominenteste und auffälligste Teil der Hacker-Kultur sowohl stark antikommerziell als auch besonders eifrig im Verteidigen und Verfechten der „Freidenker“-Werte.
Allerdings ergaben sich in letzter Zeit, vor allem durch die Ausmasse, die “Open Source”-Softwareentwicklung angenommen hat, wo die kommerziell relevante Schwelle überschritten wurde, neue Implikationen für die Bewegung und die Teilnehmer, als auch eine ganze Reihe neuer Interessenten aus dem betrieblichen, ehemals verteufelten „Corporate Sector“.
Eric S. Raymond hat sich in seinem berühmten Essay >[Homesteading the Noosphere] im Detail mit den ethischen und moralischen Implikationen des Pioniertums im Bereich "Open Source" auseinandergesetzt.
|
|
Das Konzept der „freien Software“ tauchte bis 1997 noch als allgemein anerkannter Begriff in verschiedensten Definitionen auf, deren gemeinsame Elemente 1997 in die >[Debian Free Software Guidelines] konzentriert wurden, die sich später zu der >[“Open Source”-Definition] entwickelten.
Die Annahme, von der die OSD (und OSD-konforme Lizenzen) ausgehen, ist dass es jedermann freigestellt ist, alles zu hacken und zu verändern, was ihm gefällt. Jeder Hacker hat die Wahl, ein Programm, das er mag, umzuprogrammieren und umzuformen.
In der Praxis passieren solche radikalen Veränderungen allerdings eher selten. Die Abspaltun der Richtung einer Programmentwicklung, im Allgemeinen unter dem Begriff „Forking“ zusammengefasst, hat selten solche drastischen Charakteristika.
Obwohl die Freiheiten in der Theorie so gross sind, hat die open-source-Kultur doch einen ziemlich ausgereiften Satz an Besitzrechten und –bräuchen, welche die Umstände regulieren, unter denen Software verändert werden kann, wer das machen darf, und wer das Recht hat, die veränderten Versionen wieder an die Gemeinschaft zu releasen.
Der Begriff des „Besitzes“ hat im Kontext von “Open Source” weitreichende Implikationen und ist schwer zu definieren. Alle Parteien, die sich an der Programmentwicklung beteiligen, sind gleichgestellt. In der Praxis wird allerdings oft zwischen „offiziellen“, autorisierten Stellen, und Drittpartei-Entwicklern unterschieden. Eventuelle Drittpartei-Beiträge in Form von Patches sind eher unüblich und man begegnet ihnen oft mit Misstrauen.
|
|
Der Benutzer-Prozess
Das Ziel eines Benutzers ist primär die Erfüllung seiner Aufgaben. Er besorgt die für seine Ziele notwendigen Komponenten und integriert sie mit den Programmteilen, die er benötigt. Ist diese Aufgabe erledigt, findet sich der Benutzer im allgemeinen noch unzufrieden mit bestimmten Gegebenheiten, und hätte diese gerne geändert. Das kann ein Bug sein, ein Feature, eine kleine Erweiterung, oder eine andere Veränderung. Er sende eine Beschreibung seines Problems zum Projektteam/Verantwortlichen, und hofft, dass es positiv erledigt werden kann.
Oft passiert es, dass der Benutzer ein individuelles Problem mit der Komponente hat. Es wird daher meistens nichts passieren, bis der Benutzer nicht selbst handelt. Er hat grundsätzlich 2 Möglichkeiten: entweder eine andere Person, die das beheben kann, von der Notwendigkeit der Massnahme überzeugen, oder sich selbst die Kenntnisse, die zur Behebung des Problems notwendig sind, aneignen.
Der Forschungs-Prozess
Ein neues Projekt wird definiert und ein Team startet die Arbeit an einer Software-Komponente. Die Aufgaben, die daraus erwachsen, sind in der Regel in Form von Textdokumenten und Software-Prototypen. In regelmässigen Abständen wird das Ergebnis der Arbeit zusammengefasst und an die Öffentlichkeit in Form eines neuen Release freigegeben. Die Zeitintervalle zwischen den Releases sind unregelmässig, und können von Tagen bis hin zu mehreren Jahren reichen.
Im “Open Source” Bereich ist es üblich, interessierten Personen, die keine Mitglieder des Projektteams sind, Zugang zum Forschungsmaterial und zu anderen Ressourcen zu ermöglichen (z.B. Mailing Listen, Usenet-Gruppen etc.). Diese Offenheit ermöglicht es Nicht-Projektmitgliedern, mehr über die Arbeit der einzelnen Projektgruppen zu erfahren und reduziert den Aufwand für Fragen und Feedback.
Die Entwickler bekommen bei jeder Release Feedback und wichtige Hinweise zu Problemen, Bugs und Abhängigkeiten zu anderen Komponenten. Daher werden die Benutzer als Tester und QA-Mitarbeiter für “Open Source”-Projekte betrachtet, obwohl es eigentlich die Absicht der Benutzer es nur war, ihre Probleme zu lösen.
Die Entwickler verwenden spezifische Werkzeuge, die nicht exklusiv für den “Open Source”-Bereich zur Verfügung stehen, allerdings hier ihre größte Verbreitung und Akzeptanz erfahren haben, bzw. wo es in manchen Fällen erst durch die “Open Source”-Bewegung zu ihrer Entstehung kam: Versionierung, Editoren, FTP-Server/Archiven, Shared Workspaces. Berühmte Beispiele für solche Tools sind das >[Concurrent Version System], oder auch jenes Webportal, das am nähesten dem beschriebenen Bazaar-Modell kommt, das >[SourceForge-Projekt], welches "Open Source"-Entwicklern eine Internet-Plattform für ihre Tätigkeit bereitstellt
|
|
Obwohl vom qualitativen Standpunkt aus attraktiv, entsteht durch die “Open Source”-Philosophie ein fundamentaler Konflikt für Software-Hersteller: das wertvollste Kapital dieser Firmen, wird durch ihr geistiges Eigentum (Intellectual Property, IP) dargestellt, und genau dieses Kapital müßte man laut “Open Source” Richtlinien für die Öffentlichkeit frei zugänglich machen. Eine erfolgreiche kommerzielle Vermarktung dieser „Intellectual Property“ ist in solchen Szenarien eher unwahrscheinlich. Aus diesem Grunde wurden von verschiedenen kommerziellen Herstellern “Open Source”-Derivate im Laufe der vergangenen Jahre entwickelt. Als weitere Möglichkeit wurden auch Teile von Software-Paketen als “Open Source” zugänglich gemacht, während man die anwendungskritischen Teile weiterhin proprietär unter eigener Entwicklungshochheit behielt. Eine besondere Ausprägung dieser Ideologie stellen APIs (Application Programming Interface) dar.
Um die Vorteile von “Open Source” und die geschäftlich/ökonomischen Anforderungen von kommerziellen Softwareherstellern zu verbinden, entstand eine Entwicklungsphilosophie, die in den letzten Jahren unter dem Namen „Corporate Source“ immer beliebter wurde. Hewlett Packard zählt zu den Vorreitern in diesem Bereich, und hat sich in einem internen Forschungsprojekt sehr ernsthaft mit dem Thema “Open Source” im Corporate-Umfeld“ auseinandergesetzt.
|