Search the Catalog
Open Source - kurz & gut

Open Source kurz & gut


1.Auflage Mai 1999
3-89721-222-6, Bestellnummer: 30222
72 Seiten, DM 5,-


Über dieses Buch


Seit Bestehen des Verlags hat O'Reilly Bücher zu allen wichtigen Open Source-Technologien und -Themen wie beispielsweise Unix, Linux, Sendmail, DNS & Bind bis hin zu Perl veröffentlicht - lange bevor der Begriff Open Source geprägt wurde.

Im April 1998 organisierte O'Reilly das erste internationale Open Source-Gipfeltreffen in Palo Alto, Kalifornien. Hier diskutierten namhafte Entwickler freier Software wie Linus Torvalds, John Ousterhout und Larry Wall die Zukunft offener Entwicklungsmodelle und beschlossen, den Begriff Open Source an Stelle von freier Software zu fördern. Ein zweites Treffen fand im März 1999 statt. An ihm nahmen nun auch Vertreter großer Firmen wie Sun Microsystems, IBM oder Oracle teil. Vor dem Hintergrund des spektakulären Booms von Linux und der Tendenzen in der Softwareindustrie, sich Open Source-Technologien zu öffnen, standen die Möglichkeiten einer Zusammenarbeit von freien Entwicklern und kommerziellen Softwareherstellern und die Suche nach geeigneten Business-Modellen im Mittelpunkt.

Ziel dieses Buches ist es, Interessierten und Sympathisanten der Open Source-Initiative einen Überblick über den Stand der Diskussion zu geben und dabei wichtige Aspekte und die durchaus kontroversen Positionen innerhalb dieser Bewegung zusammenzufassen.

Ein einleitender Beitrag von Martin Müller skizziert die Wurzeln der Open Source-Initiative und die Gründe und Motivationen für das Prägen des neuen Begriffs Open Source. Es folgen knappe Beschreibungen von Open Source-Projekten, die beeindruckend die Bandbreite und Bedeutung der freien Software belegen. Darüber hinaus dokumentieren Interviews die Positionen von zentralen Persönlichkeiten wie Linus Torvalds, Eric Raymond oder Brian Behlendorf.[1]


Open Source - Standortbestimmung


von Martin Müller

Vorwort

Freedom is just another word for nothing left to lose,
Nothing don't mean nothing honey if it ain't free, now now.
And feeling good was easy, Lord, when Bobby sang the blues,
You know feeling good was good enough for me,
Good enough for me and my Bobby McGee.

(Janis Joplin)

Die Freiheit beschäftigt die Menschheit seit ihrer Entwicklung von der Rotte zum staatsbildenden Individuum. Beschäftigten sich in der Vergangenheit vorwiegend Philosophen, Staatstheoretiker und Politiker mit dem Thema, hat nun die IT-Branche dessen Relevanz für sich entdeckt. Die kleine Unzulänglichkeit (Buglet im Hacker-Jargon) der englischen Sprache, kein eigenes Wort für kostenlos zur Verfügung zu stellen, führt zu dem verbreiteten Mißverständnis, kostenlos sei das wichtigste Charakteristikum freier Software. Sowohl die Freiheit im eigentlichen Sinne als auch die Freiheit von Kosten im Sinne von gratis wird im Englischen mit dem Adjektiv free charakterisiert. Sicher ist die Freiheit von Kosten ein sehr wichtiger Aspekt freier Software, und insbesondere in wirtschaftlich schwachen Ländern kann diese Eigenschaft geradezu einen Segen bedeuten. Um aber die Entwicklungsdynamik, das hohe Qualitätsniveau und die Bedeutung freier Software für die Computerindustrie zu verstehen, muß man seinen Blick auf die andere Bedeutung des Wörtchens free, die Freiheit im Sinne der Freiheit des Geistes und der Wissenschaft, richten.

Kostenlose Software gibt es schon lange. Fast jeder, der sich in den letzten Jahren mit Computern beschäftigt hat, wurde mit ihr durch CDs oder Disketten in Zeitschriften oder durch die Möglichkeit, Programme aus dem Internet herunterzuladen, konfrontiert.

Freie Software ist ein noch viel älterer Hut und jeder, der im Internet surft oder E-Mails schreibt, benutzt sie, wenn auch vielleicht unbewußt. Wie so oft im Bereich der Informationstechnologie, taucht ein altes Konzept unter einem neuen Begriff, Open Source in unserem Fall, auf und wird stürmisch begrüßt.

Maßgeblich zu dieser Entwicklung beigetragen hat Netscapes Entscheidung, den Quellcode ihres Browsers allgemein zugänglich zu machen. Im Wettbewerb mit Microsoft um Marktanteile hat Netscape am eigenen Leib erfahren, daß es einen wichtigen Unterschied zwischen frei und kostenlos gibt.

Im folgenden werden Personen und Projekten, die die Vergangenheit, Gegenwart und Zukunft der freien Software und Open Source-Bewegung verkörpern, vorgestellt. Mit gewissen Vereinfachungen wird außerdem versucht, einen Überblick über das Lizenzwirrwarr der freien Software zu geben.

Warum Open Source?

Die Neuschöpfung eines Namens für ein Phänomen, das fast so alt ist wie die Computerindustrie, ist im Falle Open Source kein Marketinggag, sondern der Versuch, einen Begriff zu etablieren, der die Entwickler und Verfechter freier Software der Notwendigkeit enthebt, ständig sowohl zwischen kostenloser Software und freier Software als auch zwischen den verschiedenen Lizenzen freier Software differenzieren zu müssen.

Lizenzbedingungen gibt es sowohl bei kommerzieller Software als auch im Bereich der freien Software fast so viele verschiedene, wie es Programme gibt. Der Begriff Open Source wurde geprägt, um einen gemeinsamen Namen für die Lizenzen benutzen zu können, die Freiheit im Sinne der Wissenschaft verkörpern.

Der Begriff Software kann nahezu alles bezeichnen, was auf einem Computer ausgeführt wird, sowohl das fertige, nur auf einer Architektur ausführbare Programm (Binary) als auch den vom Programmierer geschriebenen, menschenlesbaren Programmtext (Source).

Die Verteilung von Software in Form von ausführbaren Programmen ist sicher die häufigste Distributionsweise. Da diese Form jedoch keine Veränderungen an einem Programm oder die Portierung auf andere Hardwareplattformen ermöglicht, erfordert die Entwicklung freier Software die Verteilung des Sourcecodes.

Frei wurde durch open ersetzt, um zu erreichen, daß nicht mehr umsonst sondern offen für alles assoziiert wird.

Verschiedene Open Source-Lizenzen

Viele Programmierer haben in der Vergangenheit zum heute verfügbaren Fundus freier Software beigetragen. Einige haben nicht nur programmiert, sondern sich auch mit den gesellschaftlichen und sozialen Konsequenzen ihres Schaffens befaßt. Wie so oft, wenn ein Thema den wissenschaftlich beweisbaren Rahmen verläßt, gewinnen persönliche Ansichten und Erfahrungen an Bedeutung. Auch bei der Diskussion um freie Software ist dieses Phänomen zu beobachten. Das Resultat sind verschiedene Lizenzen, die alle das Ziel haben, Programmierern wie Anwendern (die Grenze ist oft fließend) Software mit möglichst wenigen Einschränkungen zur Verfügung zu stellen und gleichzeitig ihren Fortbestand und ihre Weiterentwicklung zu sichern oder zumindest zu vereinfachen. Aus den unterschiedlichen Vorstellungen entstanden verschiedene Lizenzen.

Public Domain

stellt im Sinne von Open Source keine Lizenz dar. Es bedeutet im wesentlichen, daß der Autor auf jeglichen Einfluß auf sein Werk verzichtet. Der im Deutschen am ehesten vergleichbare Begriff ist der der Gemeinfreiheit, sie bedeutet, daß jeder alles damit machen kann.

Die BSD License

ist eine der ältesten Lizenzen und schränkt sowohl Programmierer als auch Anwender nur insofern ein, daß die ursprünglichen Autoren genannt werden müssen. Hauptpunkt der Lizenz ist der Ausschluß von Haftungsansprüchen gegenüber den Programmierern. Sourcecode, der der BSD-Lizenz unterliegt, kann in eigenen Entwicklungen benutzt werden, ohne daß diese wiederum freie Software sein müssen. Die BSD-Lizenz stammt von der Universität von Berkeley. BSD steht für Berkeley Software Distribution.

Die GNU General Public License (GPL)

hat sozusagen politische Ziele, da sie neben den schon bekannten Haftungsausschlüssen auch noch die Forderung enthält, daß alle Weiterentwicklungen und alle Programme, die in irgendeiner Form unter der GPL lizensierten Code enthalten, wiederum unter der GPL veröffentlicht werden müssen. Diese Eigenschaft hat ihr den Spitznamen GNU Public Virus eingetragen. Dahinter steht nicht nur der Nutzen für die freier Software, sondern auch eine politische Motivation im Umgang mit dem Copyright. Aus Sicht der GPL verhindert das Copyright den natürlichen Umgang mit anderen Computernutzern, da es einigen Privilegien einräumt (denjenigen, die eine Software lizensiert haben). Ferner verbietet die GPL auch das Hinzufügen weiterer Einschränkungen, die in irgendeiner Form auf unter der GPL stehendem Quellcode basieren. Diese Einschränkung macht GNU-Software, insbesondere Bibliotheken, im wesentlichen für eine Verwendung im kommerziellen Umfeld unbrauchbar. GNU ist ein rekursives Akronym und steht für GNU is not Unix.

Die GNU Library General Public License (LGPL)

entspricht im wesentlichen der GPL, mit der Ausnahme, daß Programme, die lediglich mit einer der LGPL unterliegenden Bibliothek verbunden werden, nicht als abgeleitete Arbeit im Sinne der GPL betrachtet werden. So wird die Verwendung von durch LGPL geschützten Bibliotheken zur Entwicklung kommerzieller bzw. nicht der GPL unterliegender Software ermöglicht. Änderungen an der Bibliothek selbst müssen allerdings wieder der LGPL unterliegen. Software, die der LGPL unterliegt, bietet damit bessere Möglichkeiten für eine Verbindung zwischen freien und kommerziellen Entwicklungen.

Die QPL, NPL und andere

sind meistens Derivate der drei zuvor genannten Lizenzvereinbarungen. Sie folgen dem Geist der GPL mit der Ausnahme, daß sie den Lizenzgebern andere Bedingungen als allen anderen Nutzern gewähren.

Lizenz

Kann mit kommerzieller Software verwendet werden

Eigene Veränderungen müssen wieder frei sein

Kann unter anderen Bedingungen veröffentlicht werden

Enthält besondere Rechte für den Lizenzinhaber

GPL

Nein

Ja

Nein

Nein

LGPL

Ja

Ja

Nein

Nein

BSD

Ja

Nein

Nein

Nein

NPL

Ja

Nein

Nein

Ja

Public Domain

Ja

Nein

Ja

Nein

Die Vorzüge des Open Source-Modells

Das größte Gewicht liegt bei den unter dem Namen Open Source zusammengefaßten Lizenzen auf dem Recht, den Quellcode nicht nur zu lesen, sondern auch zu verändern, und diese Veränderungen zusammen mit dem originalen oder dem veränderten Quellcode wiederum Dritten zugänglich machen zu dürfen.

Erst diese Bedingung kann die synergetischen Effekte hervorbringen, die Eric S. Raymond in seinem Essay The Cathedral and the Bazaar (http://www.earthspace.net/~esr/writings/cathedral-bazaar/) als charakteristisch für die Entwicklung freier Software beschreibt.

Das von Raymond beschriebene Modell beruht vornehmlich darauf, die Nutzer eines Programms zu Mitentwicklern zu machen, indem von ihnen vorgeschlagene Änderungen und Korrekturen wiederum in das Programm integriert werden. Diese Idee an sich ist nicht neu. Neu ist allerdings, daß die Nutzer (die laut Raymond zum großen Teil nicht so dumm sind, wie gemeinhin angenommen) diese Korrekturen selbst am Programm durchführen und testen, bevor sie sie an den Entwickler des Programms zurückschicken. Im Gegensatz dazu steht die althergebrachte Methode, die Fehlerbeschreibungen der Nutzer nachzuvollziehen, den Fehler zu suchen, und die Korrektur wiederum vom Nutzer testen zu lassen. Schon aus dieser kurzen Beschreibung wird ersichtlich, welche der beiden Methoden die effizientere ist.

Der so beschleunigte Entwicklungsprozeß führt zu einer schnelleren Fehlerbehebung und damit zu besseren und stabileren Programmen. Ein solcher Prozeß kann aber nur stattfinden, wenn die Nutzer auch Zugang zum Sourcecode des Programms haben und es ihnen erlaubt ist, diesen zu ändern.

Die 10 Gebote von Open Source

In einer vom Begriff der Ökonomie der Aufmerksamkeit geprägten Zeit bedeutet die prägnante Berichterstattung in der Presse zwar nicht alles, aber fast alles für ein Projekt. Unmißverständlichkeit war bei der freien Software in ihrer Zersplitterung in unzählige Lizenzen ohne einen gemeinsamen, unmißverständlichen Nenner nicht gegeben. Das Resultat ist eine Reihe ungenauer bis falscher Berichte zum Thema.

Zur Beseitigung dieses Mankos fanden sich am 3. Februar 1998 Todd Anderson, Chris Peterson, John maddog Hall, Larry Augustin, Sam Ockman und Eric Raymond zusammen und hoben den Begriff Open Source aus der Taufe.

In der folgenden Woche beteiligten sich auch Linus Torvalds sowie Bruce Perens an der Definition des Begriffs. Das Ergebnis ist die Open Source Definition. Sie beruht auf den Debian Free Software Guidelines von Bruce Perens.

Damit sich eine Software Open Source nennen darf, muß die Lizenz, unter der sie veröffentlicht wird, alle Forderungen der Open Source Definition erfüllen.

Die folgende Übersetzung (http://www.opensource.org/de-osd.html) des englischen Originals (http://www.opensource.org/osd.html) wurde uns freundlicherweise von Jens D. Baumgartner (jdb@gmx.net) zur Verfügung gestellt.

1. Freie Weiterverbreitung

Die Lizenz darf niemanden im Verkauf oder in der Weitergabe der Software als Teil einer aus verschiedenen Quellen zusammengesetzten Softwaredistribution einschränken. Die Lizenz darf keinerlei Lizenzgebühren oder andersartige Beiträge verlangen.

Indem wir von der Lizenz verlangen, eine freie Weiterverbreitung zu ermöglichen, verhindern wir, daß der Langzeitnutzen zugunsten von Geldmacherei beeinträchtigt wird. Wenn wir dies nicht täten, würde Druck auf Mitwirkende ausgeübt, abtrünnig zu werden.

2. Quellcode

Das Programm muß den Quellcode beinhalten und sowohl die Verbreitung als Quellcode als auch in kompilierter Form gestatten. Wird ein Teil des Produkts nicht mit Quellcode verbreitet, so muß auf eine Möglichkeit, den Quellcode gebührenfrei aus dem Internet downzuloaden, ausdrücklich hingewiesen werden. Der Quellcode muß in einer Form zur Verfügung gestellt werden, in der ein Programmierer ihn verändern kann. Absichtlich verwirrend geschriebener Quellcode ist nicht erlaubt. Ebenso sind Zwischenformen, wie die Ausgabe eines Präprozessors oder eines Übersetzers, verboten.

Wir benötigen Zugriff auf verständlichen Quellcode, weil man Programme nicht weiterentwickeln kann, ohne sie zu verändern. Da wir die Entwicklung einfach machen wollen, müssen wir auch verlangen, daß die Veränderung des Codes einfach ist.

3. Auf dem Programm basierende Werke

Die Lizenz muß die Veränderung des Programms, auf dem Programm basierende Werke sowie deren Verbreitung unter den gleichen Lizenzbedingungen gestatten.

Allein nur die Möglichkeit zu haben, den Quellcode zu lesen, reicht nicht aus, um eine unabhängige Prüfung und eine schnelle evolutionsähnliche Auslese zu erreichen. Damit eine schnelle Entwicklung möglich ist, muß man mit der Software experimentieren können und Veränderungen weiterverbreiten dürfen.

4. Die Unversehrtheit des Originalcodes

Die Lizenz darf die Verbreitung von modifiziertem Quellcode nur dann einschränken, wenn sie die Verbreitung von sogenannten Patchdateien in Verbindung mit dem Originalcode gestattet, damit das Programm vor der Benutzung verändert werden kann. Die Lizenz muß ausdrücklich die Verbreitung von Software erlauben, die mit verändertem Quellcode erstellt wurde. Die Lizenz darf allerdings von auf dem Programm basierenden Werken verlangen, einen von der Originalsoftware verschiedenen Namen oder eine andere Versionsnummer zu tragen.

Es ist eine gute Sache, Verbesserungen zu unterstützen, aber die Benutzer der Software haben ein Recht darauf zu wissen, wer für das Produkt verantwortlich ist. Andererseits haben die Autoren und deren Unterstützer das Recht zu wissen, welche Software sie überhaupt unterstützen sollen, und sie haben das Recht, ihren guten Ruf zu schützen.

Folglich muß eine Open Source-Lizenz garantieren, daß der Quellcode frei verfügbar ist, kann aber gleichzeitig verlangen, daß die Quellcodes in der ursprünglichen Fassung zusammen mit den Patches verbreitet werden. Dadurch können inoffizielle Änderungen verfügbar gemacht und gleichzeitig vom Originalcode unterschieden werden.

5. Keine Diskriminierung von einzelnen Personen oder Gruppen

Die Lizenz darf keinerlei Personen oder Personengruppen diskriminieren.

Um das Maximum aus diesem Verfahren herauszuholen, müssen möglichst viele verschiedene Personen das gleiche Recht haben, zu Open Source-Software beizutragen. Deswegen verbieten wir jeder Open Source-Lizenz, jemanden aus dem Verfahren auszuschließen.

6. Keine Einschränkungen für bestimmte Anwendungsbereiche

Die Lizenz darf niemanden in der Benutzung des Programms in einem bestimmten Einsatzgebiet einschränken. Sie darf beispielsweise nicht die kommerzielle Nutzung oder die Benutzung in der Genforschung verbieten.

Der Hauptsinn dieses Paragraphs ist es, zu verhindern, daß irgendwelche Klauseln einer Lizenz die kommerzielle Nutzung des Programms verbieten. Wir wollen, daß auch Benutzer des kommerziellen Bereichs zu unserer Gemeinschaft gehören und sich nicht ausgeschlossen fühlen.

7. Verbreitung der Lizenz

Die zum Programm gehörigen Rechte müssen für jeden gelten, der das Programm erhalten hat, ohne daß eine weitere Lizenz beachtet werden muß.

Dieser Paragraph soll verhindern, daß durch indirekte Mittel, wie das Verlangen eines Einverständnisses, die Software nicht offen weiterzugeben, die Software nicht wirklich frei ist.

8. Die Lizenz darf nicht für ein bestimmtes Produkt gelten

Die zum Programm gehörigen Rechte dürfen nicht davon abhängen, daß das Programm Teil einer bestimmten Softwaredistribution ist. Wird das Programm außerhalb einer solchen Distribution genutzt oder verbreitet, so gelten für den Benutzer dieselben Rechte, die in der Originaldistribution gewährt werden.

Dieser Paragraph beugt einer anderen Art Lizenzfalle vor.

9. Die Lizenz darf andere Software nicht beeinträchtigen

Die Lizenz darf keine andere Software einschränken, die zusammen mit der lizensierten Software verbreitet wird. Die Lizenz darf beispielsweise nicht verlangen, daß jegliche Software, die auf demselben Datenträger verbreitet wird, Open Source-Software sein muß.

Jeder, der Open Source-Software benutzen oder weiterverbreiten möchte, hat das Recht, sich seine eigene Software auszusuchen.

Beispiellizenzen

Beispiele für zur Open Source-Definition konforme Lizenzen sind:

Die Wurzeln freier Software

Die Anfänge freier Software sind eng mit den Anfängen der Computerindustrie verknüpft. In einem Kartellrechtsprozeß zwischen dem amerikanischen Departement of Justice und AT&T, der sich von 1949 bis 1956 hinzog, wurde AT&T verpflichtet, seine Geschäftstätigkeit auf den Bereich Telekommunikation zu beschränken und seine Patente gegen nominelle Gebühren an seine Konkurrenten zu lizensieren. Zu dieser Zeit bestand das Computergeschäft fast ausschließlich aus dem Verkauf und der Wartung von Hardware. Software war ein Nebenprodukt, da die meisten Anwender ihre Software selbst entwickelten. Erst mit der Entstehung der Timesharing-Systeme begann die Softwareentwicklung in der Form, wie wir sie heute kennen. Durch die Entwicklung von Festplatten und Magnetbändern war es erstmals möglich, Programme auf den Computern selbst zu speichern, zu modifizieren und wiederzuverwenden. Diese neue Form der Computernutzung förderte die enge Kooperation der einzelnen Benutzer und den regen Austausch von Programmen.

1969 entwickelten Ken Thompson und Dennis Ritchie in den AT&T Bell Telephone Laboratories die erste Version von Unix. AT&T, an der kommerziellen Verwertung gehindert, lizensierte Unix für einen nominellen Betrag an Universitäten und gegen astronomische Summen an kommerzielle Nutzer, um einen möglichen Verstoß gegen den Vergleich von 1956 von vornherein auszuschließen. Dazu kamen ausgesprochen vorteilhafte Rahmenbedingungen: kein Support, keine Bugfixes, Lieferung nur gegen Vorkasse.

Das Ergebnis war eine rege Entwicklungstätigkeit im universitären Umfeld. Ein Austausch der Programme war problemlos möglich, da nahezu alle Universitäten über eine Unix-Lizenz verfügten. Durch das Fehlen jeglichen Supports entwickelte sich das Usenet zu einem schnellen und leistungsfähigen Supportnetzwerk der Universitäten untereinander. Als Koordinationsstelle fungierte die Universität von Berkeley, Kalifornien, die einen eigenen Zweig von Unix, die Berkeley Software Distribution (BSD), entwickelte und an andere Universitäten vertrieb. Die erste BSD-Version wurde von Bill Joy, dem späteren Gründer von Sun Microsystems, im Jahr 1978 herausgegeben. Im selben Jahr entstand auch das Internet, damals noch Arpanet genannt, auf der Basis von Unix-Systemen.

Das Jahr 1982 ist das Geburtsjahr des kommerziellen Unix. IBM, HP und DEC veröffentlichen Unix-Versionen unter neuen Namen für ihre eigene Hardware. Bill Joy verläßt die Universität von Berkeley und gründet Sun Microsystems. Das erste Betriebssystem für die neuen Workstations basiert auf BSD 4.2. AT&T kündigt offiziellen Support für Unix an und veröffentlicht die erste kommerzielle Version.

Nach einem weiteren Kartellprozeß trennte sich AT&T 1984 von 26 Firmen der Bell-Gruppe und durfte fortan als Wettbewerber im Computergeschäft auftreten. Damit nahm die Ära der liberalen Unix-Lizenzierung, des Zugriffs auf den Quellcode sowie des Austauschs von Programmen und Verbesserungen ein Ende. Die Lizenzgebühren für Unix wurden drastisch angehoben.

Die Philosophie des GNU und die Pragmatik des Open Source

Im Schatten dieser Veränderungen gründete Richard Stallman das GNU-Projekt (GNU is not Unix) mit dem Ziel, ein freies Unix zu schaffen. Als Koordinationsstelle und zur Erwirtschaftung von Einnahmen durch den Versand der im Rahmen des GNU-Projektes erstellten Software und Dokumentation wurde 1984 die Free Software Foundation gegründet.

Stallman betrachtete es als sein natürliches Recht, seine Programme mit seinen Freunden und Kollegen zu teilen, insbesondere vor dem Hintergrund, daß das Verteilen von Software im Gegensatz zu echten Gütern nahezu ohne jeglichen Aufwand und mit nur marginalen Kosten zu erreichen ist. Durch die zu dieser Zeit immer restriktiver werdenden Lizenzen der kommerziellen Softwareanbieter, sah sich Stallman in diesem bis dahin üblichen Umgang mit Software gehindert.

Mit der GPL entwickelte Stallman den Begriff des Copyleft, als Wortspiel auf das ihm so unbequeme Copyright. Hauptaufgabe des Copyleft ist sicherzustellen, daß Software, die ihm unterliegt, frei bleibt, d. h., jeder, der sie benutzt und weiterentwickelt, hat die gleichen Rechte wie der ursprüngliche Autor. Dieses Ziel stellt die GPL durch die Forderung sicher, daß jedes Programm, das auch nur eine Zeile Code enthält, der der GPL unterliegt, wieder der GPL unterliegen muß.

Genau diese Eigenschaft macht die GPL denkbar ungeeignet für die Entwicklung kommerzieller Software, da sie mit jeder anderen Lizenz, die mehr Einschränkungen enthält, inkompatibel ist. Die Akzeptanz freier Software beschränkte sich daher über 10 Jahre lang fast ausschließlich auf den privaten und universitären Bereich. Die sozialistische Grundhaltung und Stallmans ideologische Beharrlichkeit gegenüber Versuchen, die GPL kommerzverträglicher zu gestalten, dürfte weiter zur Ablehnung der GPL von weiten Teilen der Softwareindustrie beigetragen haben.

Als mit dem Erscheinen von Linux das letzte fehlende Element, der Kernel, für das GNU-System verfügbar wurde, stand erstmals in der Geschichte der Datenverarbeitung ein komplett freies Betriebssystem zur Verfügung. Stallmans Ziel war erreicht.

Allerdings fing mit der Verwirklichung dieses Ziels der Ärger erst an. Linux erreichte in kürzester Zeit eine Beliebtheit und Verbreitung, wie sie bei freier Software bis dahin unbekannt war. Viele Benutzer kamen hinzu, die Linux wegen seiner Stabilität und seiner Vorzüge verwendeten, nicht wegen seiner Freiheit.

Mit Linux rückte die freie Software auch in das Blickfeld der kommerziellen Welt. Mehr und mehr kommerzielle Software wurde auf Linux portiert, die Grenzen zwischen freier und nichtfreier Software wurden fließend.

Eric Raymonds Analyse der Entwicklungsmethode der Linux-Kernel-Gemeinde beleuchtete die Effizienz und Wirtschaftlichkeit der offenen Softwareentwicklung. Schwerpunkt Raymonds ist nicht der ideologische Hintergrund, sondern das beindruckende Entwicklungsmodell, mit dem eine Handvoll Programmierer geschafft hatte, was Stallman und die FSF seit Jahren vergebens versuchten: Die Entwicklung eines stabilen und schnellen Unix-Kernels, ohne auf fremden Code zurückzugreifen.

Kein Wunder, daß Raymond schnell die Aufmerksamkeit der Industrie auf sich zog. Raymond war maßgeblich an der Definition der Netscape Public License und der Apple Public License beteiligt. Die freie Software-Gemeinde wurde in zwei Teile gespalten. Die Fraktion der Pragmatiker, die der Ansicht folgt, das Wichtigste sei stabile Software, die an die individuellen Bedürfnisse der Benutzer angepaßt und frei verteilt werden darf, steht den Anhängern der reinen Lehre freier Software gegenüber, die Schwächen und Einschränkungen der neuen Lizenzen lautstark anprangern.

Sicherlich bringt die Lizenzinflation neue Probleme mit sich. Welchen Status nimmt Software ein, die Code unter verschiedenen Lizenzen enthält - ein Programm, das beispielsweise durch die Zusammenführung von Code aus Apples MacOS X Server und Mozilla, dem freien Netscape, entsteht? Verwendet die Benutzeroberfläche dieses neuen fiktiven Programms auch noch die Qt-Bibliothek von Troll Tech, so kommt noch eine dritte Lizenz hinzu. Alle drei Lizenzen bedingen unterschiedliche Einschränkungen.

Wie und ob die Nutzer freier Software dieses Problem lösen, hängt letztlich auch von dem Kooperationswillen der Lizenzgeber, der Softwareindustrie, ab. Zur Zeit gibt es hierzu heftige Diskussionen. Ein Anhänger Stallmans schrieb: Das Schlimmste, das der freien Software passieren kann, ist eine riesige Menge fast freier Software.

Wichtig ist, mit welcher Absicht die Welt der kommerziellen Softwarehersteller in das Open Source-Entwicklungsmodell einsteigt. Will sie nur schnelle Bugfixes und Verbesserungen, oder schafft sie es, ihre Orientierung von dem kurzfristigen materiellen Vorteil auf langfristig stabile und qualitativ hochwertige Software zu verlagern? Nutzt sie das Know-how der freien Software-Gemeinde nur aus oder steuert sie selbst ihren Teil bei?

Die Antwort auf diese Fragen kann nur die Zukunft bringen und sie hängt stark davon ab, wie bewußt sich die Benutzer und Entwickler freier Software dieses Problems sind. Stallmans Position würde die freie Software wieder in ihre Nische zurückführen. Unter Raymond ist die feindliche Übernahme freier Software durch die Industrie wahrscheinlich. Wie so oft, kann man keiner der Positionen uneingeschränkt zustimmen. Da bei freier Software die Macht aber bei ihren Nutzern und Entwicklern liegt, wird es von dem Verhalten der einzelnen abhängen, welchen Weg die freie Software nehmen wird.


Open Source-Projekte


GNU

Als AT&T 1983 anfing, in Bezug auf Lizenzen für UNIX restriktiver zu werden, begann Richard Stallman vom MIT mit einem umfassenden Projekt eine komplett freie Alternative namens GNU zu schaffen. Stallman gründete dafür auch die sogenannte Free Software Foundation, um die Idee zu unterstützen, daß Quellcodes für alle Programme immer frei verfügbar sein sollten. Er entwickelte dazu eine Lizenz namens GNU Public License (GPL), die festlegt, unter welchen Bedingungen Quellcodes verfügbar sein sollen, und daß jedes Programm, das GPL-Code beinhaltet, der GPL unterliegt.

Hunderte von Programmierer entwickelten neue Open Source-Versionen der meisten UNIX-Utilities. Allerdings schlug der Versuch fehl, einen UNIX-Kernel zu entwickeln.

Einige der GNU-Utilities waren so leistungsfähig, daß sie de facto Standards auf fast allen UNIX-Systemen geworden sind. Besonders der GNU C-Compiler gcc wurde der dominierende C-Compiler und GNU Emacs der führende Editor.

Die GPL erlaubt es sogar, die Software zu verkaufen, solange die Quellcodes verfügbar sind. Allerdings können Vertreiber in der Praxis nur geringe Gebühren für Vervielfältigungskosten berechnen. Zudem führte der Zusatz, daß jedes Programm, das GPL-Code enthält (inkl. Libraries), ebenfalls im Quellcode verfügbar sein muß, zu dem Ergebnis, daß der gcc Compiler nicht eingesetzt werden durfte, um kommerzielle Applikationen zu erstellen. Es gab daraufhin eine modifizierte GPL (die LGPL), die dieses Problem löste, aber der zu dogmatische Ansatz der FSF führte dazu, daß immer mehr Entwickler freier Software liberalere Lizenzen entwarfen, um eine kommerzielle Verwertung zu vereinfachen.

Die Firma Cygnus Support verkauft kommerzielle Support-Dienstleistungen für GNU-Software. GNU-Utilities sind integraler Bestandteil aller Linux-Distributionen.

Von vielen wird Richard Stallman als der Vater der Freien Software betrachtet. Er ist Präsident der Free Software Foundation, er gründetet 1984 das GNU-Projekt und war der Hauptentwickler von GNU Emacs, dem GNU C-Compiler, dem GNU Debugger und Teilen anderer Software-Pakete. Er ist weiterhin für GNU Emacs verantwortlich.

Andere, wie zum Beispiel Eric S. Raymond, haben sich auch am GNU-Projekt beteiligt.

Informationen zum GNU-Projekt gibt es im Internet unter folgender URL: http://www.fsf.org

FreeBSD

FreeBSD stammt ab von der Berkeley Software Distribution UNIX. Es begann im Jahr 1993 als eine Portierung des BSD 4.3-Lite Release auf eine Intel-Plattform. Das FreeBSD-Projekt war dazu gezwungen, jedes Aufsetzen auf das 4.3BSD Lite (Net/2 Release) zu umgehen und vollständig das letzte BSD-Release (4.4 Lite2) zu benutzen. Dies wurde mit dem FreeBSD 2.0 Release erreicht.

Das Projekt wurde von der Firma Walnut Creek CD-ROM massiv unterstützt, weil sie großes Interesse daran hatten, die neue Version zu vertreiben. Ohne Walnut Creek CD-ROM und ihre absolute Treue zu einem damals noch vollkommen undefinierten Projekt, wäre FreeBSD nie soweit gekommen, wie es jetzt ist, sagt Jordan K. Hubbard. Bis zum heutigen Tag unterstützt Walnut Creek das Projekt finanziell, zusammen mit einer wachsenden Anzahl von Benutzern, die Spenden schicken.

Das FreeBSD-Projekt besteht aus einem harten Kern von 16 Entwicklern, die den Vorstand bilden. Es gibt mehr als 120 Entwickler, die an dem Projekt arbeiten, die meisten davon unentgeltlich. Einige werden von ihren Arbeitgebern, die ein eigenes Interesse an FreeBSD haben, bezuschußt.

Das Ziel von FreeBSD ist es, Quellcodes mit den geringstmöglichen Restriktionen zu verteilen. Der Großteil des Systems wird unter der Original-BSD-Lizenz vertrieben, die sowohl den kommerziellen und als auch den freien Einsatz der Software erlaubt. Die verbleibenden Teile sind unter der GNU Public License, der Artistic License und anderen Lizenzen erhältlich.

Hubbard ist der Ansicht, daß es die größte Herausforderung für FreeBSD ist, langsam zu wachsen, ohne die Infrastruktur des Projekts zu überlasten, und mehr auf die Bedürfnisse der Kunden einzugehen, so wie es eine kommerzielle Firma machen würde. Er sagt: Wir wollten immer kommerzieller sein als die richtig kommerziellen Betriebssysteme, ohne allerdings Geld ins Spiel zu bringen. Das ist eine sehr interessante Herausforderung.

Hubbard schätzt konservativ, daß FreeBSD mindestens 1,5 Millionen Benutzer hat. Japan ist mit großem Abstand der größte Markt.

Mehr Informationen zum FreeBSD-Projekt bzw. dessen Geschichte (A Brief History of FreeBSD) gibt es unter http://www.freebsd.org/handbook/handbook3.html#3 von Jordan K. Hubbard. Die gesamte Web-Site http://www.freebsd.org enthält so ziemlich alles über das FreeBSD-Projekt.

Linux

Die Zeitschrift Wired bezeichnete Linux als The Greatest Operating System That (N)Ever Was, eine Beschreibung, die gleichzeitig die Bedeutung von Linux und seinen Aufstieg als freies Sofware-Projekt aus dem Nichts anspricht. Das Betriebssystem wurde von Linus Torvalds entwickelt, auch um anderen Programmierern zu beweisen, daß es durchaus sinnvoll ist, ein Betriebssystem von Grund auf neu zu schreiben und daß manchmal der eigene Weg der einzig richtige Weg ist.

Linux ist so bemerkenswert, weil seine Entwicklergemeinde international zusammengesetzt ist und trotzdem ein sehr hohes Niveau der Kooperation aufweist. Im Mittelpunkt steht Linus Torvalds, vormals aus Helsinki, Finnland. Während sich UNIX schnell in mehrere Dutzend Versionen aufteilte, was zu Verwirrung bei Managern und Programmierern führte, hat es Linux geschafft, als ein einheitliches System auf mehreren Architekturen zu bestehen. Es bietet eine UNIX-ähnliche Plattform, die es den Programmierern erlaubt, die beste Maschine auszusuchen, um produktiver zu arbeiten.

Die kommerzielle Reichweite von Linux ist schwer einzuschätzen, aber man kann zweifellos feststellen, daß viele, die früher auf UNIX setzten, nun Linux einsetzen. Viele sind der Ansicht, daß Linux die einzige Alternative zu Microsofts NT darstellt. In der Tat fangen immer mehr Hersteller von Multi-User Software an, ihre Software auf Linux zu portieren, wie z. B. Oracle, Informix, SAP R/3, Corel, Netscape etc. Lasermoon Ltd. hat Linux in ein voll POSIX-kompatibles UNIX gewandelt (nach POSIX.1 und POSIX.2 Standards). Es wird zur Zeit von den X/OPEN-Gremien verifiziert, was Linux bei öffentlichen Ausschreibungen sehr helfen sollte.

Einige Hardware-Hersteller, wie z. B. SUN und IBM, liefern ihre Maschinen auf Wunsch mit Linux aus. Für SUN gibt es bei den billigsten Maschinen gar keine Portierung ihres eigenen Solaris-Betriebssystems mehr.

Die Firmen Red Hat (http://www.redhat.com) und Caldera (http://www.calderasystems.com) vertreiben verschiedene Versionen von Linux, in Deutschland ist die S. u.S.E.-Distribution (http://www.suse.de) sehr populär. Diese Distributionen enthalten teilweise auch kommerzielle Programme, die nicht frei sind. Die Debian Linux-Distribution (http://www.debian.org) enthält ausschließlich Programme, die unter einer Open Source-Lizenz veröffentlicht werden.

Informationen zu Linux sind unter den Adressen http://www.linux.de und http://www.linux.org verfügbar. Interessante Zusätze zu Linux sind auf http://www.linuxresources.com zu finden, ein Zeitdiagramm der Linux-Entwicklung unter http://lwn.net/1999/features/1998timeline/.

Linus Torvalds ist nicht mehr ausschließlich mit Linux beschäftigt. Er arbeitet in der Halbleiterindustrie, weil er beschlossen hat, seinen Lebensunterhalt nicht mit Linux zu verdienen.

DNS und BIND

Der BIND Daemon (Berkeley Internet Name Daemon) ist außerhalb der Technikerelite fast völlig unbekannt, aber jeder kennt die Dienstleistung, die er zur Verfügung stellt: das Domain Name System (DNS). Der Verbund von Name-Servern ermöglicht die Umsetzung von Adressen wie 207.25.98.191 in eine Form, die jeder versteht, wie beispielsweis ibm.com, harvard.edu oder whitehouse.gov. Ursprünglich von Paul Mockapetris im Jahr 1984 entwickelt, wird die Entwicklung von DNS zur Zeit von Paul Vixie vom ISC (Internet Software Consortium) gesteuert. Das ISC wurde 1993 von Rick Adams gegründet, als er die Firma UUNET von einer non-profit-Organisation in eine kommerzielle Firma umwandelte.

Das ISC ist ein gutes Beispiel dafür, was mit ausgereifter freier Software passiert: Sie trägt dann einen non-profit-Mantel - den gleichen Effekt kann man bei HTML und HTTP erkennen.

DNS und der Rest der Berkeley TCP/IP Software Suite ist die Grundlage für die gesamte Internet-Industrie, einschließlich aller Internet Service-Provider, Produzenten von Web Sites und vieler Softwarefirmen. Die erste Geschäftsidee in Bezug auf das Internet entstand in Form von Firmen wie UUnet, den ersten kommerziellen Internet Service Providern. UUnet wurde 1997 an WorldCom in einer Multimilliarden-Dollar-Transaktion verkauft. BIND ist fester Bestandteil aller UNIX-Systeme und auch Microsoft liefert eine NT-Version von BIND aus.

Es gibt zur Zeit 29 Millionen registrierte Sites in DNS. Zwar hat nicht jede Site einen Domain Name-Server, aber es gibt sicherlich mehrere Millionen aktive Hosts im Internet.

Paul Vixie ist Leiter der Vixie Enterprises, einer Consulting-Firma in Redwood City, Kalifornien. Der URL hierzu ist http://www.isc.org

Sendmail

Sendmail wurde ursprünglich 1981 von Eric Allman entwickelt und ist mit ca. 75-80% Marktanteil der dominierende Mail Transport Agent (MTA) im Internet. Unabhängig davon, welches Programm genutzt wird, um die Mail zu erstellen, wird fast jede Mail, die außerhalb der Firma zugestellt werden muß, mit Hilfe von sendmail weitergeleitet.

Im November 1997 gründeten Eric Allman und Greg Olson mit einigen privaten Geldgebern Sendmail Inc., um eine kommerzielle Version von sendmail herzustellen. Die Firma wird weiterhin den kostenlosen Freeware MTA herstellen. Die kommerziellen Teile werden eine Web-basierte Administrationsoberfläche und andere Management-Tools sein. Sendmail 8.9 beinhaltet ein umfassendes Tool, um Spam-Mails zu kontrollieren.

Eric Allman selbst ist überrascht vom Erfolg von sendmail: Ich muß gestehen, daß es mich erstaunt, daß sendmail so erfolgreich ist. Die Ursache ist nicht eine massive Marketingorganisation oder ein großes Budget. Ich glaube, es gibt drei Gründe:

Erstens: sendmail ist immer davon ausgegangen, daß es auch Mail-Nachrichten akzeptieren, bereinigen und zustellen sollte, die in Bezug auf die Einhaltung der Protokolle nicht ganz einwandfrei sind. Ich hielt dies für wichtig, weil ich UUCP Mail ins ARPANET bringen wollte. Zu der Zeit war das ARPANET klein, das Usenet war die totale Anarchie (manche sagen, daß dies heute noch so ist ...) und UNIX Mail-Programme verstanden noch nicht einmal Mail Header. Auf diese Weise war es zwar schwieriger, aber das Ziel war Kommunikation, nicht Pedanterie.

Zweitens habe ich mich auf die Routing-Funktion beschränkt. Ich wollte keine Zustellungsagenten oder Front-Ends schreiben. Dies war eine Abweichung vom damals gängigen Modell, wo das Mail Routing, die Zustellung und auch oft der Netzwerkcode im gleichen Benutzeragenten implementiert waren. Natürlich war auch entscheidend, daß es sendmail unentgeltlich gab, daß es zur richtigen Zeit erhältlich war, und daß es so funktionierte, wie es sollte.

Drittens war die sendmail-Konfigurationsdatei flexibel genug, um sich an eine rapide verändernde Welt anzupassen. Sie ist dynamisch, weil die Welt dynamisch ist. Eines Tages wird sendmail wie X11 sterben, aber ich werde nicht den Atem anhalten, während ich darauf warte.

Die umfangreichsten Informationen zu sendmail gibt es zum einen unter http://www.sendmail.org und für die kommerzielle Version unter http://www.sendmail.com

Apache

Apache ist eines der überraschendsten und erfolgreichsten freien Software-Projekte. Als die Produktpläne von Netscape und Microsoft die industriellen Schlagzeilen beherrschten, wurde Apache durch simple Mundpropaganda und durch die Verbreitung über das Internet zu dem am weitesten verbreiteten Webserver. Als bescheidenes Unternehmen ohne einen zentralen Visionär bricht Apache mit den Regeln, die für normale Projekte freier Software gelten. Das Apache-Projekt entstand aus der Einsicht, daß die Kontrolle über die Quellcodes für Web-Server-Software entscheidend ist, um mit den schnellen Änderungen im Web Schritt zu halten.

Während kommerzielle Firmen heutzutage immer wieder ihre Richtung ändern und ihre Prioritäten neu bestimmen, hat das Apache-Projekt bemerkenswerte Stabilität gezeigt und treu die Bedürfnisse der Benutzer erfüllt; deshalb hält es nach wie vor die Spitzenposition als der meist benutzte Web-Server.

Im Juni 1998 hat IBM ihre offizielle Unterstützung für die Apache-Gruppe angekündigt. IBM liefert Apache im Rahmen ihres Web Sphere-Produktes aus. Die Ankündigung von IBM war ein wichtiger Schritt, mit dem die freie Software-Bewegung viel an Akzeptanz in der kommerziellen Entwicklungsumgebung gewonnen hat.

Brian Behlendorf ist der Pressesprecher der Apache-Gruppe, und obwohl er nie eine einzige Zeile Code geschrieben hat, gilt er als einer der führenden Köpfe des Projektes. Schon weniger als ein Jahr nach dem ersten Apache-Release im Jahr 1995 hatte Apache den NCSA-httpd-Server vom ersten Platz verdrängt.

Mehr Informationen zu Apache gibt es unter http://www.apache.org

Samba

Ein erstes Release von Samba war 1993 verfügbar. Samba ermöglicht es einer UNIX-Maschine, als File- und Druck-Server für Windows NT- und Windows 95/98-Clients auf einem Netz tätig zu werden. Es ersetzt somit einen NT-Server und macht PC-NFS auf den Clients überflüssig. Samba wurde von Andrew Tridgell an der Australian National University entwickelt, und es stießen andere Entwickler dazu, als er den Code auf dem Internet verfügbar machte. Zur Zeit ist Jeremy Allison, der bei SGI arbeitet, das einzige bezahlte Mitglied im Team der Samba-Entwickler.

Ähnlich wie Linux wird Samba zur Zeit von der sogenannten Samba-Gruppe weiterentwickelt. Samba wird unter der GNU GPL vertrieben und es gibt immer zwei Releases: ein stabiles Release und eine Alpha-Version. Zur Zeit gibt es das Samba-Release 2.03 - in der Tat zeigte dieses Release, wie schnell die Entwicklergemeinde auf Probleme reagieren kann. Samba 2.0 wurde nämlich mit einem schlimmen Bug im Signal-Handling ausgeliefert. Innerhalb von drei Tagen konnte dieser Bug und dazu noch einige andere repariert werden. Auf diese Weise machte Samba innerhalb von drei Tagen den Sprung von 2.0 auf 2.02. Diese schnelle Reaktionszeit wird im Netz als massiver Vorsprung gegenüber Firmen wie Microsoft oder Netscape gewertet, die sicherlich kaum innerhalb so kurzer Zeit auf das Problem hätten reagieren können.

Das 2.02er Release von Samba unterstützt erstmalig Samba in der Rolle als Microsoft Primary Domain Controller: Diese undokumentierten Protokolle werden von Microsoft bewußt zurückgehalten. Somit gibt es keinen Grund mehr, für solche Dienste einen NT-Server zu beschaffen.

Samba wird von vielen Firmen eingesetzt, siehe dazu die Statistiken unter http://samba.anu.edu.au/pub/samba/survey/ssstats.html/

SGI unterstützt Samba durch einen bezahlten Entwickler - und zur Zeit stellen SGI-Server mit Samba die schnellsten NT File-Server dar.

Weitere Infos zu Samba, auch über den wichtigsten Kopf, Andrew Tridgell, der gerne in Pizza-Coupons bezahlt wird, gibt es unter folgender URL: http://samba.anu. edu.au/samba/

Perl

Perl (Practical Extraction and Report Language, im Scherz auch Pathologically Eclectic Rubbish Lister) wurde 1986 von Larry Wall entwickelt und ist ein wichtiges Werkzeug für System- und Netzwerk-Administratoren sowie zur CGI-Programmierung. Perl wird oft als das Klebeband des Internets bezeichnet, weil es sozusagen als Klebstoff mehrere Prozesse zusammenfügt. Große Sites wie Yahoo, Netscape, CNET, Amazon und Excite benutzen Perl, um ihre Web Sites zu managen und interaktive Dienste zur Verfügung zu stellen.

Perl wird von einer Gruppe von ca. 100 Programmierern weiterentwickelt, die über die perl5porters Mailing-Liste miteinander kommunizieren.

Perl wird mit vielen UNIX-Systemen ausgeliefert, zudem ist es Teil des Microsoft NT Resource Kit. Perl ist die am häufigsten benutzte Sprache zur Entwicklung von Internet-Diensten und interaktiven Datenbankabfragen. O'Reilly publiziert eine Vielzahl von Perl-Büchern und veranstaltet jährlich eine große Perl-Konferenz. ActiveState Tool Corp. vertreibt die Standarddistribution sowie Profi-Tools für Perl für Win32-Systeme.

Es gibt etwa 500.000 Perl-Programmierer und viele Millionen Perl-Anwender. Aufgrund der Buchverkäufe geht O'Reilly davon aus, daß Perl mindestens ebenso oft genutzt wird wie Java. Die wichtigsten Perl Web Sites sind http://www.perl.com und http:www.perl.org. Larry Wall hat eine persönliche Web Site (http://www.wall.org), wo er z. B. das Tagebuch seiner kürzlich überstandenen Hornhaut-Transplantation veröffentlichte.

Python

Python ist eine interpretierte, objektorientierte Sprache, die ein weiteres Beispiel der typischen Open Source-Entwicklung ist: Python fing als ein kleines Tool an und wurde recht schnell zu einem universellen Werkzeug. Guido von Rossum, der Chefentwickler von Python, sieht es als eine verbesserte Perl-Version.

Vor kurzem wurde Jpython 1.0, eine vollständige Integration von Python mit Java, herausgebracht. Mit Jpython können Python-Programme überall dort verwendet werden, wo ein Java-Interpreter läuft.

Die Python Home Page ist unter http://www.python.org zu finden.

Tcl/Tk

John Ousterhout begann seine Arbeit an Tcl/Tk, als er Professor an der University of California in Berkeley war. Er wechselte dann zu Sun Microsystems, die ein Interesse an Sun Script, einer kommerziellen Scripting-Sprache, hatten. Zur Zeit hat Ousterhout seine eigene Firma namens Scriptics, um ähnlich wie Sendmail Inc. die Entwicklung der Sprache voranzutreiben, während er auch kommerzielle Aspekte abdecken will.

Wie Perl und Python ist Tcl eine Script-Sprache - die Tool Command Language. Von Anfang an wurde Tcl mit Tk verbunden, um die Programmierung graphischer Oberflächen zu erleichtern. Ursprünglich kommt Tk aus der X-Windows-Welt (X11), aber in der Zwischenzeit wird auch das Windows- und Macintosh-Interface unterstützt.

1997 gewann Tcl/Tk den Software Systems Award, der von der Association for Computing Machinery (ACM) vergeben wird.

Es gibt zur Zeit zwischen 500.000 und einer Million Tcl/Tk-Entwickler. Pro Woche finden ca. 12.000 Downloads von Tcl/Tk vom Scriptics FTP-Rechner statt, wobei die Plattform-Verteilung wie folgt aussieht: 65% Windows, 30% UNIX und 5% Macintosh.

Von den drei Skript-Sprachen scheint Tcl/Tk der designierte Nachfolger der Windows-Entwicklungsumgebungen zu werden. Die hervorragende Unterstützung von graphischen Benutzeroberflächen könnte auch Visual Basic-Anhänger ansprechen.

Zudem bietet eine solche Sprache viele nützliche Erweiterungen, die jedem Entwickler enorm viel Arbeit und Zeit sparen können.

Mehr Informationen unter http://www.tclconsortium.org, dort findet man die Software und Standards. http://www.scriptics.com ist die Web Site von John Ousterhouts Firma. Unter http://www.NeoSoft.com/tcl findet man viele Shareware-Module zu Tcl.

Andere Projekte

Das K Desktop System

http://www.kde.org ist die Web Site des KDE (K Desktop Environment) für UNIX Workstations. Es verbindet einfache Benutzung und hervorragendes graphisches Design mit der technologischen Überlegenheit des UNIX-Systems und wird inzwischen mit fast allen Linux-Distributionen ausgeliefert.

GNOME: GNU Network Object Model Environment

Unter http://www.gnome.org findet man das GNU-Projekt, das das Ziel hat, einen Desktop zu entwickeln, der ausschließlich auf freier Software basiert. GNOME benutzt das GTK (GNU GUI Toolkit) für alle GNOME-kompatiblen Programme. Dieser Desktop wird von Red Hat unterstützt.

GIMP: Das GNU Image Manipulation-Programm

The Gimp (GNU Image Manipulation Program) wird häufig als das freie Photoshop bezeichnet. Es ist Bestandteil der meisten Linux-Distributionen. Das leistungsfähige Werkzeug zur Bildbearbeitung kann für die Fotoretouche, Bildkomposition und Bildmanipulation eingesetzt werden. Es wurde unter der GNU General Public License (GPL) veröffentlicht. Informationen unter http://gimp.org.

Project Mnemonic

Dieses Projekt hat nichts mit dem Protagonisten eines Science Fiction-Romanes zu tun (Bonuspunkte des Übersetzers Snoopy in Form von Hanutas winken den LeserInnen, die den Roman und Autor nennen.), sondern ist vielmehr der Versuch, einen freien, modular erweiterbaren Web Browser zu entwickeln. Die ersten Versionen laufen auf UNIX-Betriebssystemen unter dem X11 Windows-System. http://www.mnemonic.org bietet mehr Informationen.

PGP

PGP (Pretty Good Privacy) ist de facto der Standard in Sachen Verschlüsselungssoftware. Der Autor, Phil Zimmermann, wählte das Modell der freien Software, um eine weite Verbreitung seiner Software sicherzustellen. Er hielt dies für wichtig, um Regierungskontrolleure daran zu hindern, diese Software einzuschränken. Er gründete die Firma PGP Inc., um kommerzielle PGP-Versionen zu vermarkten. McAfee, Network General, PGP und Helix fusionierten dann zu Network Associates.

Die Web-Seiten sind unter http://www.nai.com/default_pgp.asp zu finden.

Groff, SP und Jade

James Clark hat eine beeindruckende Sammlung von Werkzeugen zur Textverarbeitung und Formatierung zusammengestellt, wobei er mit groff begonnen hat. Innerhalb der SGML-Gemeinde hat er kostenlose Parser-Programme wie sgmls und sp zusammen mit der DSSSL-Formatierungsmaschine Jade entwickelt. In letzter Zeit hat er sich mehr um zwei XML-Parser gekümmert, einer davon in Java geschrieben, der andere in C. Obwohl er die Software selbst entwickelt hat, arbeitet er mit diversen Standardisierungsgruppen zusammen, um ihre Spezifikationen zu standardisieren. Seine Web Site ist: http://www.jclark.com


Interviews


Linus Torvalds (Linux):
Der Pragmatiker der freien Software

Von Hiro Yamagata

Dies Interview aus dem Jahre 1997 wurde ursprünglich für die Tokyo Linux Users Group mit Linus Torvalds geführt. Diese überarbeitete Version wird mit Erlaubnis des Autors abgedruckt.

Linus Torvalds versucht nicht, die Welt mit Hilfe der freien Software zu verbessern (obwohl es ihm durchaus gelingen könnte). Wie man in dem folgenden Interview erkennen kann, ist ihm die klare Trennung zwischen kommerzieller und proprietärer Software ziemlich gleichgültig, anders als RMS (Richard Stallman vom GNU Project), der, was diesen Punkt angeht, empfindlich ist. Linus unterstützt im Gegenteil sogar die Entwicklung proprietärer Software auf Linux, worüber RMS wohl die Stirn runzeln würde. [Anm. d. Ü.: In der Tat läuft das SAP R/3 System, sowie große Datenbanken wie IBMs DB/2, Oracle und Informix, auf Linux-Plattformen.]

Diese Freiheit oder Offenheit ist die Kraftquelle für Linux und seine Popularität. Lege keine engen Rahmenbedingungen oder Richtungen fest, laß die Dinge einfach passieren und nimm das Beste in Linux auf. Linus ist von technologischen Trends und Modeerscheinungen nicht beeindruckt, sein Widerstand gegen die Benutzung eines Mikro-Kernels ist dafür ein gutes Beispiel. Wenn das allerdings jemand anders handhabt als er, so ist es kein Problem, dagegen hat er nichts einzuwenden. Generell gilt: Was immer die Leute mit Linux machen, ist deren Sache. Besser, es wird schlecht genutzt, als gar nicht.

Diese Freiheit und die Verfügbarkeit verschiedener Linux-Pakete macht es sehr viel einfacher, Linux einzuführen und einzusetzen. Es ist eine andere Freiheit als die des RMS, obwohl beide viel gemeinsam haben. Allerdings war dieser Pragmatismus in Bezug auf Linux essentiell, um den Horizont für freie Software zu erweitern.

HY: Du bist einer der führenden Verfechter freier Software geworden. Anders allerdings als Richard Stallman kommentierst Du nicht so oft, was freie Software sein soll und was sie uns allen bedeutet. Bist Du überhaupt interessiert an der Förderung der freien Software oder interessiert Dich nur die Software an sich?
Linus: Ich bin im allgemeinen ein sehr pragmatischer Mensch: Was funktioniert, funktioniert. Wenn es um Software geht, bevorzuge ich freie Software, weil ich noch nie ein Programm gesehen habe, daß von sich aus meinen Bedürfnissen entsprach. Die Quellcodes zur Verfügung zu haben, kann Dir das Leben retten.

In diesem Sinne bin ich ein Förderer der freien Software und der unter GPL freigegebenen Software. Insbesondere deshalb, weil, wenn Software einmal unter GPL lizensiert ist, dann bleibt sie frei und ich muß mir um weitere Releases keine Sorgen mehr machen.

Allerdings heißt es auch nicht, daß ich gegen kommerzielle Software bin. Kommerzielle Software-Entwicklung hat auch einige Vorteile - die geldbringenden Aspekte geben einige neue Anreize, die es für freie Software nicht gibt. Und diese Anreize sorgen oft für ein polierteres Produkt.

Zum Beispiel bin ich wirklich sehr glücklich über die kommerziellen Linux CD-ROM-Verkäufer wie Red Hat. Die Kommerzialisierung hat für Linux den Anreiz geschaffen, eine gute Version zu produzieren, die man einfach installieren und benutzen kann, und bei der das Thema des Packaging geklärt wurde. Einfach alles ist problemlos erhältlich.

Vor diesen kommerziellen Unternehmungen war es nicht ganz einfach, Linux einzurichten, weil die meisten Entwickler vor allem von ihren eigenen Bedürfnissen motiviert werden und sich wenig um die Einfachheit der Installation und der Benutzung kümmern. Und bei Linux hat man trotz der Kommerzialisierung Zugang zu den Quellcodes, also bekommt man das Beste aus beiden Welten.

Und dann gibt es natürlich noch Software, die kommerziell ist, aber ohne Quellcodes ausgeliefert wird - dies ist die traditionelle kommerzielle Software im Gegensatz zu der Red Hat Linux-Distribution. Dagegen versuche ich auch nicht zu predigen. Ich hasse die Tatsache, daß ich keine Bugs beheben kann, aber manchmal führt kein Weg an dieser Software vorbei.

HY: Wann und warum hast Du Linux der GPL unterstellt? Hast Du es jemals bereut, daß Linux keine Shareware ist?
Linus: Ich habe niemals bereut, daß Linux keine Shareware ist. Ich mag diese pay for use Binär-Shareware-Programme, die in der MS-DOS-Welt so verbreitet sind, überhaupt nicht.

In meinen Augen vereint Shareware die schlimmsten Nachteile von kommerzieller Software (keine Quellcodes) mit dem Schlechtesten der freien Software (es fehlt der letzte Schliff). Ich glaube überhaupt nicht an den Shareware-Markt.

Am Anfang habe ich Linux unter einem Nicht-GPL-Copyright herausgegeben, das in der Tat noch viel restriktiver als die GPL war. Es setzte voraus, daß die Quellcodes immer verfügbar sind und erlaubte nicht, daß mit Linux in irgendeiner Form Geld verdient würde. Mit anderen Worten, nicht nur ich wollte mit Linux kein Geld verdienen, auch niemand anderes sollte dies tun.

Die erste Copyright-Version war eigentlich eine Reaktion auf das Betriebssystem, das ich versuchte zu benutzen, bevor ich Linux entwickelte: Minix. Minix war als Betriebssystem für die Ausbildung gedacht, aber es war viel zu limitiert und zu teuer. Es war auch sehr schwer zu bekommen.

Als ich also Linux entwickelte, wollte ich, daß es einfach mit den gesamten Quellcodes per FTP erhältlich ist. Und ich wollte nicht, daß es für irgend jemanden zu teuer ist.

Nach ungefähr einem halben Jahr habe ich das Copyright zur GPL geändert. Es wurde schnell klar, daß das ursprüngliche Copyright viel zu restriktiv war und einige ganz legitime Dinge verbot, wie z. B. Floppy-Kopierdienste - dies war die Zeit, bevor CD-ROMS wirklich populär wurden. Zuerst war ich in Bezug auf die GPL sehr nervös, aber ich wollte auch dem gcc (auf dem Linux basierte) eine Ehre erweisen, der bekanntlich der GPL unterlag.

Linux unter die GPL zu nehmen, war das beste, was ich je getan habe.

HY: Offensichtlich arbeitest Du an Linux, weil es Dir auf die eine oder andere Art Spaß macht. Wenn Dir jetzt jemand Geld bieten würde, damit Du Dich auf die Linux-Entwicklung konzentrierst, glaubst Du, es wäre anders gelaufen? Hat dies mit der Wahl Deines augenblicklichen Arbeitgebers zu tun? So wie ich gehört habe, waren viele Leute sehr erstaunt, daß Du nicht zu einer Firma gegangen bist, die direkt mit Linux zu tun hat.
Linus: Ich bin nicht zu einer kommerziellen Linux-Firma gegangen, weil ich nie gezwungen sein wollte, etwas zu tun, was ich nicht tun will.

Eigentlich wollte ich nie, daß meine Arbeit zu 100% mit Linux zu tun hat, weil ich die Befürchtung hatte, daß ich mich langweilen würde, wenn Linux alles wäre, was ich tun würde. Also war der Job hier bei Transmeta genau das Richtige für mich. Ich mache etwas Interessantes, das nichts mit Linux zu tun hat, und ich habe trotzdem Zeit, an Linux zu arbeiten. Und ich bin in Bezug auf Linux zu nichts verpflichtet, mein Chef kann mich also nicht bitten, etwas mit Linux zu tun, was ich nicht tun will.

HY: Was sind Deine Ansichten in Bezug auf Richard Stallmans Idee von Freier Software? In Deinem Vortrag am MIT vor ein paar Jahren klang es nicht so, als wärst Du gegen proprietäre Software. Bist Du dagegen? Welche Applikationen siehst Du eher im Bereich der freien Software und welche in der proprietären Welt?
Linus: Ich sehe die Dinge nicht so schwarz-weiß wie RMS. Ich bin der Meinung, die Leute können tun und lassen, was sie wollen, aber, wie leicht zu erkennen ist, bevorzuge ich freie Software. Ich bevorzuge freie Software nicht aus religiösen Gründen oder so etwas ähnlichem. Nur habe ich viele verschiedene Maschinen, und ich möchte an allen arbeiten können. Wenn ich freie Software habe, kann ich sie auf meinen Alphas und PCs kompilieren.

Auf der anderen Seite neige ich dazu zu glauben, daß einige Dinge bei kommerzieller Software besser funktionieren, weil ein wesentlicher Aspekt des Endprodukts der letzte Schliff ist - und kommerzielle Software hierin wirklich gut ist.

Zum Beispiel sind die Benutzeroberflächen oftmals bei kommerzieller Software besser. Dies ist sicher nicht immer wahr, aber in den meisten Fällen ist die Benutzeroberfläche für eine kommerzielle Firma der wichtigste Teil eines Programms. Ob die Software funktioniert oder nicht ist sekundär, wie die vielen bug-durchsetzten Programme von Microsoft beweisen (nicht daß Microsoft hier der einzige Übeltäter ist).

Also sind Textverarbeitungsprogramme in der kommerziellen Version meist besser, weil ihr wichtigster Teil die Benutzeroberfläche ist.

Auf der anderen Seite ist die freie Software sehr erfolgreich in Bereichen mit technischem Fokus. Dies schließt natürlich den Linux-Kernel ein, aber auch Dinge wie den GNU C-Compiler und andere Entwicklungs-Tools.

HY: Wir haben schon Linux-Distributionen gesehen, die es dem Benutzer erlauben, Linux zu installieren, ohne zu wissen, wie es innen aussieht. Dies hat eine Menge neuer Benutzer zu Linux gebracht, aber es gibt Leute, die behaupten, dies untergrabe den Geist der freien Software, weil niemand mehr gezwungen wird, unter die Motorhaube zu blicken und zu verstehen, wie es darunter aussieht. Beunruhigt Dich das?
Linus: Nein - ich glaube das ist so am besten. Ich glaube nicht, daß sich jeder dafür interessieren muß, wie ein Betriebsystem funktioniert. Es ist das, was mich interessiert, aber ich glaube, ein Programm ist nur so gut wie seine Nützlichkeit.

Ein nutzloses Programm ist niemals gut, egal wie gut es implementiert ist. Die Tatsache, daß es eine Menge Leute gibt, die Linux nur benutzen wollen und sich nicht darum kümmern, wie der Kernel funktioniert, ist nicht nur eine Ehrung für Linux, sondern bringt auch neue Entwicklungen mit sich, an die ich vorher nie gedacht habe.

Diese Benutzer nutzen die Software anders als ich, und daher sind ihre Bedürfnisse eben auch andere. Und in vielen Fällen zeigten diese Bedürfnisse Dinge auf, die in Linux fehlten oder schlecht gelöst waren. Also haben diese Benutzer Linux entscheidend weitergebracht, obwohl sie sich für das Innenleben nicht interessierten.

HY: Ich weiß, Du wurdest das sicherlich schon tausendmal gefragt, aber warum wurde Linux so ein Erfolg? Einige Leute meinen, es liegt an Dir. Andere behaupten, es war eine Kombination aus gutem Timing und einer Menge Glück. Was meinst Du?
Linus: Es gibt viele Gründe. Gutes Timing und viel Glück sind die offensichtlichen. Aber ich glaube, ich war auch ein guter Manager und wohl auch ein guter Programmierer, und dies war sicherlich auch wichtig, um Linux zu einem erfolgreichen Produkt zu machen.

Ich glaube auch, daß das Linux-Entwicklungsmodell ein gutes Modell ist. Linux hat viel weniger Regeln als andere Entwicklungen und jeder kann beitragen, was er will. Ich bin nur ein allgemeiner Filter für die Patches, aber ansonsten ist es ein sehr freies Entwicklungsmodell.

HY: Jetzt wo Linux so groß geworden ist, spürst Du viel Druck, Linux auf dem richtigen Kurs zu halten? Was ist Deine größte Sorge in Bezug auf die Zukunft von Linux?
Linus: Ich hatte immer den Druck, Linux auf dem rechten Weg zu halten, aber es war immer technischer Druck und daher hat er mir nicht viel ausgemacht. Das Gute an technischen Fragen ist, daß sie eine gute technische Antwort haben. Es sind die nicht-technischen Fragen, die oftmals gar keine Antwort haben. Für die technischen Probleme findet man eine Lösung, solange nur gute Leute daran arbeiten. Und Linux hat die Allerbesten.

Also mach ich mir um die Zukunft von Linux keine Sorgen. Technisch wird Linux besser und besser werden und die nicht-technische Seite macht mir persönlich keine Sorgen.

Larry Wall (Perl): Evolutionäre Veränderungen freier Software

von Larry Wall

Dies ist ein Auszug aus Larry Walls programmatischer Rede auf der Perl-Konferenz, die im August 1997 stattfand. Larry gilt als der Vater von Perl, einem der erfolgreichsten Projekte freier Software.

Vor vielen Jahren gab es eigentlich nur kommerzielle Software. Klar, wir schrieben auch unsere eigene Software, aber man hatte keinen Ort, wo man sie verfügbar machen konnte, und es war sicherlich unmöglich, seine Firma zu bitten, freie Software offiziell zu vertreiben.

Dann kam die Freie Software-Bewegung in Gang. Natürlich denken wir nun alle an Richard Stallman. Er war der wichtigste Blitzableiter der Bewegung, aber Tatsache ist, daß die Zeit einfach reif dafür war und viele von uns damals freie Software herausgebracht haben. Wir mußten es tun, allen kommerziellen Interessen zum Trotz, und wir waren gezwungen, unsere eigene Infrastruktur aufzubauen. So entstand natürlich ein Antagonismus zwischen der kommerziellen und freien Software-Welt. Das war eine natürliche Überreaktion, die bis zum heutigen Tag andauert, und einige von Euch, die hier vor mir sitzen, sind auf den gegnerischen Seiten in diesem Kampf.

Einige von Euch glauben, daß freie Software ihren Sinn darin hat, neue Ideen zu lancieren, daß aber Software nicht wirklich erfolgreich ist, solange sie nicht durch die Industrie kommerzialisiert wurde. Andere von Euch denken, daß man die Software vergessen kann, wenn sie erst mal kommerzialisiert ist, weil die Firmen sie nehmen, hamstern, auf sie pissen und sie ruinieren werden.

Beide Ideen sind gefährlich. Sie sind nicht gefährlich, weil sie unwahr sind, sondern weil sie beide ein bißchen wahr sind und man befürchtet, daß beide vollständig wahr sein könnten. Aber vor ca. eineinhalb Jahren hatte ich den Verdacht, daß vielleicht beide nicht wahr sein müssen. Heute bin ich mir dessen viel sicherer. Ich bin hier, um Euch davon zu überzeugen, daß wir zumindest daran denken sollten, einen Waffenstillstand zwischen der Welt der kommerziellen und der freien Software zu verhandeln.

Ich möchte Euch bitten, alle Eure Ängste und Vorurteile beiseite zu legen und uns zu helfen, etwas Neues zu tun. Ein neues Kooperationsmodell erblickt das Licht der Welt. Eine neue Generation von Unternehmern taucht auf, die die neue Dynamik der freien Software-Szene versteht.

Es muß ein neues Zwischenmodell geben, in dem die freie Software-Szene das tut, worin sie gut, ist und die kommerzielle Gemeinde das tut, was sie gut kann (außer die Leute übers Ohr zu hauen). Dann wird es beiden Gemeinschaften durch diese Zusammenarbeit besser gehen als vorher. Wenn Ihr glaubt, daß das unmöglich ist, dann geht bitte auf den Gang und fangt an, Euch die Köpfe einzuschlagen.

Wenn Ihr wie ich an evolutionäre Metaphern glaubt, dann könnt Ihr vielleicht erkennen, daß nicht alle Beziehungen nach dem Muster Jäger-Gejagter oder Parasit-Wirt funktionieren müssen. Warum probieren wir nicht eine Symbiose? Wir müssen lernen, uns aufeinander zu verlassen. Ob Ihr es glaubt oder nicht, aber es gibt Dinge, die die Entwickler von freier Software nicht gut können, und es gibt Dinge, die die Entwickler kommerzieller Software nicht gut können. Aber jeder kann diese Dinge für den anderen tun.

Bevor wir zur technologischen Metapher kommen, möchte ich zunächst festhalten, daß ich in Bezug auf freie Software grundsätzlich nicht besonders dogmatisch bin. Aus ethischen Gründen glaube ich dagegen, daß wenn jemand etwas verschenkt, niemand anders damit eine schnelle Mark machen sollte. Und wenn man glaubt, daß dies gerade mit einem passiert, dann hat man das Recht zu protestieren - und laut zu protestieren.

Ich glaube allerdings nicht grundsätzlich daran, daß Informationen kostenlos sein müssen. Vielmehr glaube ich, daß Informationen wertvoll sein sollten. Informationen kostenlos zur Verfügung zu stellen, erhöht zwar ihren Wert für den Konsumenten. Aber ich bin kein Kommunist, wenn es um Informationen geht, und wenn wir eine Informationswirtschaft aufbauen möchten, müssen die Informationen auch für mich, den Produzenten, einen Wert haben.

Die theologische Metapher, mit der ich schließen möchte, ist ganz einfach, daß es besser ist zu geben als zu nehmen. In der westlichen Kultur bewerten wir die Menschen nach dem, was sie besitzen. Statt dessen sollten wir den amerikanischen Indianern des pazifischen Nordwestens nacheifern, die den sogenannten Potlatch erfanden. In dieser Kultur wurde man nicht nach dem bewertet, was man hatte, sondern nach dem, was man verschenkt. Aber bedenkt bitte: Man muß erst etwas haben, um es verschenken zu können. Wir können Dinge verschenken, weil wir unsere Zeit und unser Geld investiert haben, oftmals auch Zeit und Geld unserer Arbeitgeber, und wertvolle Dinge produziert haben. Nur wenn wir grundsätzlich das Recht haben, Informationen zu besitzen, haben wir auch das Recht, diese Informationen frei und ohne Zwang zu verschenken. Ganz einfach, weil wir dies wollen, nicht weil wir müssen.

John Ousterhout (Tcl/Tk): Kommerzielle Interessen der freien Software-Bewegung

von Dale Dougherty

John Ousterhout ist der Entwickler von Tcl/Tk und er hat 1998 eine neue Firma namens Scriptics gegründet, um dieser Sprache neue Möglichkeiten zu eröffnen.

DD: Welche Entwicklungen gab es bei Tcl/Tk im letzten Jahr?
Ousterhout: Es gab mehrere interessante Entwicklungen:

Erstens wurde Tcl/Tk 8.0 im Sommer ausgeliefert. Dieses Release ist das erste, das das gleiche Look and Feel auf Windows- und auf Macintosh-Rechnern zur Verfügung stellt. Mit dem 8.0er Release kann man eine Tcl/Tk-Applikation schreiben, die auf jeder UNIX-, Windows- oder Macintosh-Plattform läuft und für jede Plattform das richtige Erscheinungsbild hat.

Zweitens hat der Einsatz von Tcl/Tk unter Windows drastisch zugenommen - vermutlich aufgrund der Version 8.0. Windows ist für Tcl/Tk-Downloads nunmehr die beliebteste Plattform.

Die dritte interessante Entwicklung ist die Gründung der Scriptics Corporation im Januar 1998. Firmen, die Tcl benutzen, brauchen Entwicklungs-Tools, Support, Training und Consulting-Leistungen - bis dato waren diese nicht erhältlich. Scriptics möchte diese Lücke schließen und alle anderen Dienstleistungen für Firmen, die Tcl/Tk in zentralen Applikationen benötigen, anbieten. Scriptics wird weiterhin die freien Releases von Tcl/Tk unterstützen, um die Tradition des Open Source weiterleben zu lassen.

Schließlich hat das letzte Jahr eine rapide Zunahme des Einsatzes von großen Tcl/Tk-Applikationen in großen Firmen mit sich gebracht. Zum Beispiel kontrolliert Tcl die Generierung von Web-Inhalten bei großen Anbietern wie CINET, America Online und Travelocity. Tcl steuert Hardware- und Software-Tests bei Firmen wie Cisco und Sybase. Tcl wird von Merril Lynch, Lehman Bros., Bridge Informantion Systems, Fidelity und dem New York Stock Exchange für Finanzapplikationen benutzt. Tcl ist bei vielen Firmen der Elektronic Design Automations-Branche in Produkte integriert. Tcl ist das Herz des Sendekontrollzentrums der NBC. Dieser Akzeptanzprozeß ist seit ein paar Jahren im Gange, aber erst im letzten Jahr wurde deutlich, daß viele Firmen sich in zentralen Applikationen auf Tcl/Tk verlassen.

DD: Es sieht für mich so aus, daß Du als der Entwickler von Tcl/Tk unabhängig, aber mit der Unterstützung von anderen, die Sprache weiterentwickelt hast. Hat Deine Beziehung zu Sun dieses Modell verändert? Und falls ja, gestaltest Du es durch die Gründung von Scriptics wieder neu?
Ousterhout: Als ich in Berkeley Professor war, befaßte ich mich selbst mit der Entwicklung von Tcl und Tk. Viele Leute der Tcl/Tk-Gemeinde haben Code beigesteuert, aber alle Codeteile wurden im Verlauf der Tcl/Tk-Releases von mir persönlich modifiziert. Als Tcl/Tk immer komplexer wurde, wurde mir klar, daß einer allein nicht mit dem Bedarf an neuen Features Schritt halten kann. Als ich zu Sun ging, begann ich daher, mehrere Leute in die Entwicklung von Tcl/Tk einzubinden. Als ich dann Sun verließ, um Scriptics zu gründen, arbeiteten ca. zwölf Leute an Tcl/Tk. Bei Scriptics werden wir diesem Trend folgen und sowohl die Kernsoftware verbessern als auch mit Tools und Erweiterungen ausbauen.

Natürlich spielte die Tcl/Tk-Gemeinde bei diesem Prozeß eine unersetzbare Rolle. Sie dienten als Beta-Tester, haben Bugs gemeldet und repariert, machten viele Vorschläge zur Verbesserung des Systems und haben viele Erweiterungen geschrieben, die oftmals so nützlich waren, daß wir sie in das Kern-Release mit übernommen haben.

DD: Kannst Du Zahlen nennen, die das Wachstum der Tcl/Tk-Benutzung untermauern?
Ousterhout: Mir fallen mindestens drei Indikatoren ein, die ein starkes Wachstum der Tcl/Tk-Einsätze anzeigen.

Erstens haben wir gemessen, wie oft Tcl/Tk von der Sun Web Site heruntergeladen wurde. Vor drei Jahren maßen wir ca. 2.000 Downloads pro Woche. Im letzten Jahr ging die Rate auf 6.000 Downloads pro Woche hoch. Heutzutage messen wir mehr als 12.000 Downloads pro Woche - das ist innerhalb von drei Jahren eine Zunahme um den Faktor sechs.

Zweitens haben wir gemessen, wie der Mix der Downloads ist. Vor drei Jahren gab es Tcl/Tk nur für UNIX-Plattformen. Als letztes Jahr die ersten Windows- und Macintosh-Versionen erhältlich waren, verschoben sich die Downloads auf ca. 50% UNIX, 45% Windows und 5% Macintosh. Im letzten Jahr nahm die Windows-Benutzung dramatisch zu und wir haben 65% der Downloads für Windows, 30% für UNIX und 5% für Macintosh gemessen. Das zeigt uns, daß Tcl/Tk nun wirklich eine Cross-Plattform Lösung ist.

Schließlich haben wir ein enormes Interesse an Scriptics bemerkt. Seit wir im Februar die Gründung von Scriptics bekannt gemacht haben, haben mehr als 500 Firmen mit uns Kontakt aufgenommen, um Informationen über unsere Produkte zu bekommen. Diese Anfragen kamen von neu gegründeten Firmen mit nur wenigen Tcl/Tk-Programmierern bis hin zu Unternehmen der Fortune-500-Klasse mit Hunderten von Tcl/Tk-Programmierern.

DD: Kannst Du einige wichtige Richtungen oder Initiativen der freien Software-Szene nennen, die Tcl/Tk zugute kommen?
Ousterhout: Die freie Software-Szene hat traditionell vier wichtige Rollen für Tcl/Tk gespielt:

1. Experten der Tcl/Tk-Gemeinde haben anderen Support gegeben, normalerweise durch die Beantwortung von Fragen in der Newsgruppe comp.lang.tcl.

2. Die Benutzer haben Bugs gemeldet und repariert.

3. Die Gemeinde hat die Evolution von Tcl/Tk gesteuert, indem sie Schwächen identifiziert, Verbesserungsvorschläge gemacht und offene neue Features mitdiskutiert hat.

4. Tcl war immer ein erweiterbares System und die Benutzergemeinde hat dies genutzt, indem sie viele interessante Erweiterungen geschrieben hat. Einige davon, wie File I/O in der TclX-Erweiterung, die Socket-Unterstützung in der DP-Erweiterung und die Namensräume aus der incr tcl-Erweiterung, erwiesen sich als so wesentlich, daß wir sie in den Tcl-Kern mit übernommen haben.

Ich hoffe, daß die Benutzergemeinde weiterhin diese Rolle spielen wird. Bei Scriptics untersuchen wir verschiedene Wege, wie wir diese Leute mehr einbinden können und es ihnen erleichtern, zusammenzuarbeiten.

DD: Eines der Themen, auf das ich aufmerksam wurde, als ich das Gespräch mit Larry führte oder das Interview mit Linus las, war, daß beide Pragmatiker sind und nicht unbedingt diese große Kluft zwischen kommerzieller und freier Software sehen. Wie siehst Du dieses Zusammenspiel zwischen freier Software und kommerziellen Entwicklungen?
Ousterhout: Wir haben auch so eine pragmatische Sicht der Beziehung zwischen freier Software und kommerziellen Entwicklungen. Jede Gemeinschaft kann viel beisteuern und jede Gemeinde hat spezifische Bedürfnisse. Die kommerzielle Gemeinde zum Beispiel benötigt mehr Hilfe in Form von Training und Support. Anhänger der freien Software brauchen die Quellcodes, um ihre Probleme selbst zu lösen. Unsere Pläne für Scriptics spiegeln einiges von diesen beiden Welten wider.

Wir werden mit der Tcl-Gemeinde zusammenarbeiten und weiterhin die freien Tcl- und Tk-Releases unterstützen. Zur gleichen Zeit werden wir Training und Support anbieten und Tools entwickeln, die mehr proprietär sind. Auf diese Weise glauben wir, das Beste aus beiden Welten zu kombinieren. Das Echo auf die Gründung von Scriptics war überwältigend positiv. Viele Leute haben uns geschrieben, wie begeistert sie davon sind, daß es nun eine Firma gibt, die sich mit Tcl und Tk beschäftigt. Beide, Vertreter der freien Software wie kommerzielle Benutzer, sehen dies als großen Gewinn.

Brian Behlendorf (Apache):
Wir müssen ein Geschäftsproblem lösen

Von Dale Dougherty

Brian Behlendorf ist einer der Hauptakteure, die Anfang 1995 Apache auf den Weg brachten.

DD: Apache ist unter den freien Software-Projekten in der Hinsicht einzigartig, daß es keine starke zentrale Leitfigur, keinen Diktator oder Visionär hat. Apache ist mehr wie eine Kommune. Kannst Du mir etwas darüber erzählen, wie der rasante Start von Apache aussah?
Behlendorf: Es begann im Januar 1995, als einige Mitglieder der Web-bezogenen IETF Mailing-Liste (oder vielleicht war es www-talk/, ich bin nicht mehr sicher) Trübsal bliesen, weil so viele NCSA-Entwickler zu Netscape gingen und die NCSA nicht mehr so gut auf unsere Bug Fixes und Patches reagierte, die wir einschickten. Da andere Leute jene Patches hatten, die ich haben wollte, und ich wiederum Patches hatte, die sie haben wollten, lag es nahe, uns zusammenzutun.

Wer hatte die Idee? Ich glaube, da gibt es keine klare Antwort, obwohl ich derjenige war, der vorschlug, eine Mailing-Liste einzurichten und die Web-Site aufzusetzen, und von da an ging es bergauf. Wir waren eine Gruppe von Gleichgesinnten mit ungefähr gleichen Vorstellungen von Änderungen, die wir austauschen wollten. Mittlerweile haben sich einige von uns spezialisiert. Einige konzentrieren sich auf verschiedene Teile des Codes, andere schreiben die Doku, wieder andere wie ich sind bereit, mit der Presse zu sprechen. Aber aus naheliegenden Gründen möchte niemand als Hauptautor bezeichnet werden. Alles, was die Tatsache fördert, daß wir eine Gruppe sind, ist besser. Um wie Eric Raymond eine Analogie zu finden: Wir sind am ehesten mit dem Supreme Court [Anmerk. des Übers.: das amerikanische Bundesverfassungsgericht] zu vergleichen.

DD: Welche wichtigen Entwicklungen haben im letzten Jahr in der Apache-Gemeinde stattgefunden?
Behlendorf: Wir haben begonnen, Apache auf NT zu portieren und zu unterstützen. Wir haben sehr gute Performance-Verbesserungen implementiert, unser Marktanteil hat deutlich zugenommen. Spin-off-Projekte wie mod_perl, mod_iserv und mod_php sind ausgereifte Middleware geworden, die mit teuren kommerziellen Paketen vergleichbar sind.
DD: Viele Leute meinen, die freie Software-Szene würde von einem gemeinsamen Idealismus angetrieben. Aber wenn ich höre, was Linus und Larry zu sagen haben, dann werden sie doch eher von Pragmatismus geleitet. Die Software versucht, praktische Probleme zu lösen, die einige Leute gemeinsam haben. Kannst Du mir erklären, wie das Apache-Projekt diesen pragmatischen Ansatz umsetzt?
Behlendorf: Fast alle Initiatoren kamen zu dem Projekt, weil wir geschäftliche Gründe hatten, anstatt Netscape den NCSA-Server zu benutzen. Wir brauchten einen besseren Server, als NCSA ihn uns bieten konnte, und wir brauchten Quellcodes, weil der Stand der Technik damals weit davon entfernt war, ideal oder akzeptabel zu sein. Und selbst heute noch würde ich sagen, daß 80% der Entwickler involviert sind, weil sie ein geschäftliches Problem zu bewältigen haben, wobei ihnen Apache hilft. Oder sie haben mit Hilfe von Apache Sofware-Firmen oder Consulting-Firmen aufgebaut.

Guido van Rossum (Python):
Wie freie Software ein Eigenleben entwickelt

von Dale Dougherty

Guido van Rossum ist der Entwickler von Python, einer hochentwickelten Skript-Sprache, die zuerst 1991 veröffentlicht wurde. Van Rossum ist gebürtiger Amsterdamer und lebt zur Zeit in Washington, D.C. Er arbeitet bei der Corporation for National Research Initiatives (CNRI).

DD: Was für Entwicklungen gab es bei Python im letzten Jahr? [Anm. des Übersetzers: Langsam kann ich mich der Magie von Dales charismatischem Interviewstil nicht mehr entziehen...:-)]
Van Rossum: Ich glaube, die wichtigste Entwicklung war JPython (http://www.python.org/jpython/), eine Python-Implementierung in reinem Java von Jim Hugunin. Das andere große Ereignis war das Release von Python 1.5 mit der Unterstützung für PERL-ähnliche reguläre Ausdrücke sowie einem verschachtelten Modul-Namensraum.
DD: Was war für Dich als der Entwickler von Python erforderlich, um genug Substanz für die Benutzung und Entwicklung zu bekommen?
Van Rossum: Ich glaube, der Schlüssel waren weit verbreitete und regelmäßige, solide Releases. Ich habe Python 1992 (vielleicht auch etwas früher) per anonymen FTP zugänglich gemacht. Es war auch sehr wichtig, eine Mailing-Liste und eine Newsgruppe zu haben, damit Einsteiger schnell merkten, daß sie nicht allein sind.
DD: Gab es einen Moment, wo Du wußtest, daß Python wie ein Teenager begann, ein eigenes Leben zu führen?
Van Rossum: Das ist nach und nach passiert, so daß ich es fast nicht bemerkt habe, erst rückblickend. Das erste deutliche Zeichen war eine Diskussion in der Python-Newsgruppe: Was passiert eigentlich, wenn Guido von einem Bus überfahren wird? Daraufhin folgte die Einladung vom NIST, dort einen Python-Workshop zu organisieren.
DD: Die Python Software Association wird vom CNRI unterstützt. Kannst Du den Ursprung und die Ziele der PSA erläutern?
Van Rossum: Dies wird sehr detailliert im PSA FAQ [Anmerk. d. Ü.: Frequently Asked Questions: eine Sammlung häufig gestellter Fragen zu einem Thema zusammen mit den entsprechenden Antworten] unter http://www.python.org/psa/FAQ.html/ erläutert. (Nicht zu verwechseln mit den Python FAQ). Kurz zusammengefaßt, wurde die PSA gegründet, weil einige Nutzer sich zusammentaten und eine Support-Gruppe gründen wollten, um Python zu fördern, zu unterstützen und um seine Glaubwürdigkeit zu verbessern. Die CNRI kam erst später ins Spiel, als die Organisatoren eine Heimat für die PSA suchten. CNRI ist eine non-profit-Organisation und hat viel Erfahrung darin, Organisationen wie die PSA bei sich unterzubringen und zu unterstützen.
DD: Glaubst Du, daß dies ein Modell für die Organisation und für das Management eines ausgereiften Projektes freier Software ist?
Van Rossum: Das PSA-Modell hat gute und schlechte Seiten. Ich glaube, der Hauptentwickler unterscheidet sehr genau, welches Modell am besten funktioniert. Finanziell wäre die PSA schon längst ruiniert, wenn es die CNRI nicht gäbe. Wir versuchen, ein Industriekonsortium aufzubauen, ähnlich wie das X11 oder W3C, um für zukünftige Python-Entwicklungen mehr Unterstützung zu haben.
DD: Kannst Du irgendwelche Zahlen nennen, die das Wachstum des Python-Einsatzes untermauern?
Van Rossum: Wirf doch mal einen Blick darauf, wie viele Postings es jeden Monat in der Python-Mailing-Liste und -Newsgroup gibt: http://www. egroups.com/list/python-list. Das gibt es auch grafisch aufbereitet unter http://starship.skyport.net/~just/FindMailStats/.

Wir haben die Web-Zugriffe und FTP-Downloads nicht regelmäßig gezählt, aber soweit ich mich erinnere, haben sie ein ähnliches Wachstum.

DD: Kannst Du einige wichtige Zielrichtungen und Initiativen der freien Software-Bewegung nennen, die Python zugute kommen könnten?
Van Rossum: Hmm, soweit ich es sehe, gibt es keine homogene Szene freier Software. Es gibt die Python-Gemeinde, die Tcl-Gemeinde, die Perl-Gemeinde, eine für Emacs und noch ein paar mehr, aber die Verbindungen zwischen ihnen sind nicht sehr stark. Wie bei den drei oder vier freien Skript-Sprachen, gibt es eine mehr oder weniger freundliche Rivalität und auch mal gegenseitige Beschimpfungen. Die Leute sehen freie Software aus unterschiedlichen Blickwinkeln - einige, wie zum Beispiel GNU und die FSF, haben politische Ziele, andere nicht.

Wenn natürlich alle der Meinung sein sollten, daß Python die ideale Skript-Sprache ist, dann würde Python davon profitieren :-). Aber das ist eine ziemliche blöde Idee und wird nicht passieren.

DD: Eines der Themen, die mir in den Gesprächen mit Larry und dem Interview mit Linus auffielen, war, daß sie beide Pragmatiker sind und nicht unbedingt diese große Kluft zwischen kommerzieller und freier Software sehen. Wie siehst Du dieses Zusammenspiel zwischen freier Software und kommerziellen Entwicklungen?
Van Rossum: Genauso. Die erste Gruppe von Leuten, die an freier Software Geld verdienen (außer den eigentlichen Benutzern), sind die Verleger (meist mehr als die ersten Buchautoren [Anm. d. Verlags: Naja, geht so]). Die zweite Gruppe sind die Consultants. Es gibt eine Gruppe von angehenden Python-Consultants (PPSI - ihre Web Site ist http://www.pythonpros.com/). Die eigentlichen Entwickler kommen als letztes - die machen die ganze Arbeit in ihrer großzügig bemessenen Freizeit, wie Larry Wall es einmal sagte, während sie versuchen, gleichzeitig ihre bezahlte Arbeit erledigt zu bekommen. Ich habe einfach Glück, daß ich bei CNRI soviel an Python machen darf, obwohl es eigentlich mein richtiger Job ist, mobile Agenten und verteilte Systeme zu erforschen.

Es gibt auch Modelle, parallel kommerzielle und freie Versionen einer Software zu entwickeln, aber ich muß erst sehen, wie das funktioniert. Für Python könnte dies in ein bis zwei Jahren möglich sein - oder vielleicht auch nie.

Paul Vixie (DNS/BIND): DNS/BIND und das Internet Software Consortium

Von Dale Dougherty

DD: Wann wurde das ISC gegründet? Wie lange kümmerst Du Dich schon um BIND?
Vixie: Das ISC wurde 1993 gegründet. Ich betreue BIND seit 1989.
DD: Betrachtest Du die Entwicklung von BIND als kollektive Leistung, die andere Entwickler mit einbezieht?
Vixie: Ja. Wir haben eine Mailing-Liste für BIND-Entwickler und richten allmählich einen gemeinsamen CVS-Zugang zu unserem Quellcode-Pool ein.
DD: Kannst Du mir etwas über die wichtigsten Entwicklungen in Bezug auf BIND im Laufe des letzten Jahres erzählen?
Vixie: Wir haben die obere Hälfte effektiv neu geschrieben und daher die Versionsnummer von 4.* auf 8.* gehievt. Dies war die wohl arbeitsintensivste Periode, die BIND je erlebt hat.
DD: DNS und BIND sind offenkundig die entscheidenden Dienste, die das Internet erst möglich machen. Gibt es irgendwelche Zahlen, die Du mir nennen kannst, die die Bedeutung dieser Software dokumentieren? Sicherlich ist die Anzahl der weltweiten Domain-Server ein Maßstab.
Vixie: Alle UNIX-Hersteller und die meisten NT-Verkäufer bieten BIND an. Alle Root-Name-Server benutzen ein aus den Quellcodes kompiliertes BIND.
DD: Einen gemeinnützigen Verein zu gründen, um eine heranreifende Quellcode-Basis eines freien Software-Projektes zu unterhalten, ist nur ein mögliches Szenario in der Fortentwicklung der freien Software. Wie ist es ISC bisher gelungen, in ihrem Hause die Entwicklung von BIND zu unterstützen? Meinst Du, daß dies auch für andere Projekte ein gutes Modell ist?
Vixie: Die Jury tagt noch. Wir bekommen nicht so viele Spenden von Firmen, wie wir gehofft haben. Daher bewegen wir uns mehr in Richtung bezahltem Support, wie etwa bei dem frühen Cygnus-Modell. Ich beobachte aber auch Sendmail Inc. als mögliches zukünftiges Modell, falls wir die Gelder, die wir brauchen, weiterhin nicht zusammenbekommen.
DD: Würdest Du auch ein anderes Konsortium wie zum Beispiel das W3C in Betracht ziehen und ein ähnliches Modell auf Web-Standards und Software übertragen?
Vixie: Ja, das W3C und das X-Consortium sind beide auch reizvoll. Ich denke, wir haben uns noch nicht auf ein Finanzierungsmodell festgelegt, weil wir immer noch eher bezahlte Projektarbeit machen, als die Tue Gutes-Einstellung von W3C und XC zu übernehmen.
DD: Kannst Du Richtungen oder Initiativen innerhalb der freien Software-Szene nennen, die DNS und BIND helfen würden?
Vixie: Nein, nicht wirklich. Ich fürchte, das ist nicht mein Fachgebiet. Ich habe aber dem Executive Director des ISC, Jerry Scharf, eine Kopie Deiner Mail geschickt. Er hat zum Thema Finanzierung viel mehr Ideen.

Open Source-Evangelist: Eric S. Raymond

Von Dale Dougherty

Durch die Ankündigung von Netscape, die Quellcodes für ihren Browser zur Open Source zu machen, haben Eric Raymond und andere in der freien Software-Bewegung begonnen, Open Source in Begriffen zu definieren, die die kommerzielle Gemeinde verstehen kann. Die Web-Site www.opensource.org soll diesen neuen Begriff publik machen. Siehe dazu auch History of the Open Source Effort und die Open Source Definiton auf der Web-Site.

DD: Deiner Veröffentlichung The Cathedral and the Bazaar wird zugeschrieben, daß sie das Mozilla-Release inspiriert habe. Wieso hast Du sie geschrieben?
ESR: Auslöser war der Schock über die Entdeckung von Linux. Als ich Linux 1993 das erste Mal benutzte, war ich bereits 15 Jahre lang Programmierer (davon 10 Jahre UNIX-Hacker), und ich dachte, ich wüßte wie der Hase läuft. Nach dem, was ich über Software-Entwicklung wußte, hätte es für einen lockeren Haufen von Amateuren niemals möglich sein dürfen, etwas so großes und komplexes wie ein Betriebssystem zu entwickeln, das sogar funktioniert. Aber innerhalb der ersten 20 Minuten, nachdem ich es gebootet hatte, war ich überzeugt, daß es wesentlich besser war als jedes kommerzielle Betriebssystem, das ich kenne (und dabei war dies die 0.99 Version!).

Ich war vollkommen überrascht und habe sofort entschieden:

- da will ich mitmachen und

- ich will herausfinden, wie es die Linux-Gemeinde geschafft hat, alle Regeln auf den Kopf zu stellen.

Darüber habe ich drei Jahre nachgedacht und dann habe ich den Artikel veröffentlicht.

DD: Wie lange warst Du vorher in der Open Source-Gemeinde engagiert?
ESR: Eigentlich solange ich programmiere. Ich kannte Richard Stallman schon, bevor er lange Haare hatte und den Jesus-Komplex bekam, und wir sind immer noch befreundet, auch wenn wir uns in den vergangenen Jahren oft gestritten haben. Ich war einer der ersten, denen er von seinen FSF-Plänen erzählt hat, und ich war der erste, der ihm vorschlug, als Flaggschiff der FSF-Bewegung eine Version von Emacs zu schreiben. Viele meiner frühen Projekte waren Emacs-Projekte - auf diese Art und Weise habe ich Jamie Zawinski (einer der Mitgründer von Mozilla) kennengelernt, der ein ernstzunehmender Emacs-Hacker war, bevor Netscape ihn einstellte.
DD: Als Du Dich hier bei dem Gipfeltreffen selbst vorgestellt hast [Anmerk. des Übers.: 1998 auf dem ersten Open Source-Gipfeltreffen in Palo Alto, Kalifornien], hast Du Dich als beobachtender Teilnehmer und Anthropologe bezeichnet. Was bedeutet das?
ESR: Ich hatte schon immer die Neigung, menschliches Verhalten zu beobachten, als wäre ich ein außerirdischer Anthropologe, selbst wenn ich daran teilnehme. Als ich somit über die Jahre an der Hacker-Kultur teilnahm, habe ich ihre Mechanismen analysiert, als wäre sie ein Urvolk aus dem Amazonas oder dem Kongo.

Das erste greifbare Resultat dieser Studien war die Wiedergeburt der Jargon File im Jahre 1990 (veröffentlicht als The New Hacker Dictionary im Jahre 1991). Das zweite war das How to Become a Hacker-FAQ. Der Artikel The Cathedral and the Bazaar war das dritte Resultat, und ich habe gerade einen Artikel fertiggestellt, Homesteading the Noosphere, das die Riten und Traditionen der Open Source anthropologisch untersucht.

DD: An welchen Projekten arbeitest Du zur Zeit?
ESR: Ich arbeite immer noch an fetchmail - einer populären Utility, um Mails per POP3/IMAP abzuholen. Und ich arbeite am 6.0 Release von Xlife mit. Ich habe das Linux Undercover-Kompendium von Red Hat redigiert, dabei habe ich eine neue Just in Time Publishing-Technologie entwickelt, die innerhalb der nächsten Wochen in den Läden verfügbar ist. Und in letzter Zeit habe ich intensiv über Open Source gesprochen und Aufklärung betrieben - in den letzten eineinhalb Wochen habe ich, glaube ich, neun Interviews gegeben.

Ich glaube, ich werde jetzt auch einen dritten Artikel mit dem Titel The Magic Stone über die Ökonomie von Open Source schreiben. Außerdem arbeite ich an mehreren Büchern, wovon das interessanteste The Art of UNIX Programming - über die Traditionen und Philosophien von UNIX ist.

Open Source auf dem Desktop:
Eric W. Sink von AbiSource

Von Dale Dougherty

Eric W. Sink, einst Chefentwickler von Mosaic bei Spyglass, hat eine Firma gegründet, um Open Source-Applikationen für den Desktop zu entwickeln. Seine Firma AbiSource hat eine Textverarbeitungssoftware in Aussicht gestellt, die einschließlich Quellcodes frei verfügbar sein wird.

DD: Erzähl mir etwas von Dir, zum Beispiel wie Du an der Mosaic-Entwicklung bei Spyglass mitgearbeitet hast.
Sink: Ich war sehr früh bei Spyglass, noch bevor es eine Internet-Firma war. Im Frühjahr 1994, nachdem Spyglass die Mosaic-Lizenz vom NCSA erhalten hat, arbeitete ich daran mit, das Web Browser-Projekt in die Wege zu leiten, zunächst als Chefingenieur, später als Projektleiter. Wie dem auch sei, Mosaic erwies sich als eine Kette von technischen Erfolgen gepaart mit Marketingmißerfolgen. Beides waren aber exzellente Erfahrungen für mich, durch die ich viel gelernt habe.
DD: Erzähl mir doch etwas über Deine neue Firma.
Sink: Wir begannen im Januar 1997 als Projektfirma, ohne daß wir einen detaillierten Plan hatten. Solche Projekte sind sehr lukrativ und es ist einfach, eine solche Firma zu führen, aber es wurde uns dann klar, daß wir eigentlich eine Produktfirma werden wollten. Aber wir hatten nichts in der Hand, worauf wir die Firma stützen konnten, bis die Open Software-Bewegung Anfang des Jahres an Fahrt gewann. Innerhalb von zwei Monaten haben wir einen Plan für Open Source-Produkte entwickelt, fünf neue Leute eingestellt und unseren Namen auf AbiSource geändert.
DD: Was hat Dein Interesse an Open Source geweckt?
Sink: Ich bin seit zehn Jahren ein Fan von Open Source-Software, aber ich muß gestehen, daß ich bisher nie daran gedacht hatte, daß freie Software ein derartiges Mainstream-Phänomen werden könnte. Das Mozilla-Release von Netscape hat wirklich meine Aufmerksamkeit geweckt. Ich habe angefangen, darüber nachzudenken, auf welche Weise sich verschiedene Geschäftsmodelle aus dem Verkauf von Dienstleistungen anstelle von Software-Lizenzen ergeben könnten. Obwohl ich meine Ansichten nicht so extrem finde, wie die von Richard Stallman, war mir klar, daß die Open Source-Philosophie eine große Zukunft hat.
DD: Warum sieht die Zukunft so rosig aus?
Sink: Es ist wichtig, die Schlüsselrolle des Internet als Verteilungsmechanismus für Open Source-Software zu erkennen. Das Problem der Distribution ist einer der Hauptgründe dafür, daß Softwarefirmen scheitern. Proprietäre Software-Modelle führen zu einem Zwiespalt: Hersteller verbringen viel Zeit damit, herausfinden, wie sie ihre Software vertreiben sollen, während sie gleichzeitig zu ergründen versuchen, wie sie andere an der Distribution ihrer Software hindern können. Open Source-Modelle unterbinden diesen Widerspruch und erlauben es dem Hersteller, seine Energie dort zu bündeln, wo es wirklich wichtig ist. Der Grund ist, daß das Internet nun verbreitet genug ist, um als Distributionsmedium für wirklich große Märkte zu dienen.
DD: Welche Art von Open Source-Produkten entwickelt Ihr zur Zeit?
Sink: Wir konzentrieren uns auf Desktop Produktiviäts-Tools, einschließlich Textverarbeitungssysteme, Spreadsheets, Endbenutzer-Datenbanken und ähnliches. Unser erstes Produkt ist ein Textverarbeitungssystem namens AbiWord. Die Quellcodes einer ersten Version werden am 21. August 1998 zur Verfügung gestellt. Dieses Release ist an Softwareentwickler gerichtet. Wenn AbiWord gegen Ende des Jahres (1998) für den Endbenutzer fertiggestellt ist, werden wir dies in einem wesentlich größeren Rahmen ankündigen.
DD: Da Ihr Endbenutzer-Produkte anbietet, ist doch die Frage, welchen Reiz Open Source-Produkte für diese Benutzer haben? Sind sie daran überhaupt interessiert?
Sink: Ich glaube schon. Die Benutzer haben genug davon, mit diesen verrückten Upgrade-Zyklen, die für die meisten Desktop-Applikationen die Regel sind, mitzuhalten. Der gesamte Prozeß ist nicht effektiv. Wir finden uns nur damit ab, weil wir keine Alternativen haben. Warum bezahlen wir jedes Jahr horrende Upgrade-Gebühren, wenn diese Upgrades keine neuen Features enthalten, die wir brauchen können? Weil wir immer öfter die Upgrades kaufen, um ein Problem wie eine Inkompatibilität oder einen Bug zu lösen.

Warum akzeptieren wir die schlechte Qualität der Software? Weil Features die Upgrades verkäuflich machen und nicht das Entfernen von Bugs. Der Hersteller hat keinen finanziellen Anreiz, qualitativ gute Software zu produzieren, und der Konsument hat keine Kontrolle darüber. Wir alle wissen, daß der augenblickliche Zustand unbefriedigend ist, aber wir tun nichts. Sieh Dir mal die drei wichtigsten Office-Pakete an: Sie sind doch alle mehr oder weniger gleich, oder? Warum leiten wir unsere Einkünfte als Industrie denn eigentlich weiterhin aus dem geistigen Eigentumsrecht ab, wenn proprietäre Technologie nicht mehr den Unterschied ausmacht? Daß die großen Hersteller Geld für das Falsche verlangen, ist ein sicheres Zeichen dafür, daß sie deutlich zuviel verlangen. Vom reinen Technologie-Standpunkt aus sind diese Applikationen langweilig, und dies schon seit Jahren. Es ist an der Zeit, daß sie Gebrauchsgüter werden. Die Mainstream-PC-Hardware hat bereits diese Wandlung durchgemacht, die Hersteller konkurrieren nun auf der Preisebene und mit zusätzlichen Dienstleistungen. Die normale Desktop-Software wird exakt den gleichen Weg nehmen.

Interessieren sich Endbenutzer für Quellcodes? Natürlich nicht. Aber bei Open Source geht es nicht nur um Quellcodes, es geht um einen besseren Weg, Software zu entwickeln, und um einen Weg, bessere Software zu entwickeln. Das interessiert die Benutzer wiederum sehr.

DD: Warum dachtest Du, daß dies eine Gelegenheit sei, etwas zu versuchen, was traditionelle Softwarefirmen schon aufgegeben haben, nämlich Microsoft im Bereich Desktop herauszufordern?
Sink: Wir fordern Microsoft heraus? Wirklich? Wann haben sie denn eine Mehrfach-Plattform Open Source Office Suite angekündigt? :-)

Aber im Ernst: Jeder fragt mich nach Microsoft, weil es gerade sehr in Mode ist, mit ihnen zu konkurrieren. Ehrlich gesagt sehe ich Microsoft nicht als Konkurrenten. Wir bringen nicht ein weiteres proprietäres Textverarbeitungssystem auf den Markt - das wäre Selbstmord. Wir spielen nach anderen Regeln. Wir geben zu, daß eine Menge Leute noch nach den alten Regeln spielen werden, und daß Microsoft immer noch enorme Gewinne aus dem Markt ziehen kann. Am Anfang haben wir uns bewußt dazu entschlossen, mit unseren Produkten auf die Nische von Benutzern zu zielen, die mit den führenden proprietären Lösungen von Microsoft und anderen nicht zufrieden sind.

Um sich der Terminologie von Geoffrey Moore zu bedienen: Damit Open Source die Kluft überwinden kann, müssen wir unsere Produkte zunächst an die leidgeprüften Pragmatiker richten.

DD: Wieso denkst Du, daß Du eine Firma auf der Basis von freier Software gründen kannst? Ihr seit keine Entwickler, die in ihrer Freizeit umsonst arbeiten. Glaubst Du, daß Ihr als Firma Geld verdienen werdet?
Sink: Aber sicher: Wir haben sehr genau finanziell geplant und unsere Zahlen sind stimmig. Die potentielle Nutzerzahl für Desktop-Tools ist riesig. Wir glauben, daß Millionen von Leuten unsere Produkte nutzen möchten und wir damit eine lebensfähige, wachsende Firma erhalten können, selbst wenn nur ein geringer Prozentsatz der Benutzer unsere kostenpflichtigen Dienstleistungen in Anspruch nimmt.
DD: Wie wirst Du das Team finanzieren, das an der Software weiterarbeiten soll?
Sink: Unsere Firma ist gerade im Umbruch, und zu einem gewissen Grad werden die Profite unseres alten Geschäftes helfen, das neue zu finanzieren. So ist die richtige Antwort eher die, daß wir eine ganz normale Software-Neugründung sind. Wir brauchen eine Anschubfinanzierung, um unsere Firma zu etablieren, bis wir profitabel sind. Wir haben einige Fremdinvestoren und wir suchen weitere Geldgeber.
DD: Wie werdet Ihr merken, daß Eure Produkte Anklang finden? Nach welchen Zeichen für den Erfolg werdet Ihr suchen?
Sink: Es gibt eine Menge Signale, auf die ich mich freue. Ich spreche hier vor allem über AbiWord, weil dies auch unser erstes Produkt sein wird.

AbiWord wird schon einen kleinen Teilerfolg errungen haben, wenn meine Mutter anfängt, es zu benutzen. Es wird mich dann sehr ermutigen, eine Rezension in einem Magazin zu finden, von der wir vorher nichts gewußt haben. Später würde ich mich freuen, wenn ich eines Tages in einem Buchladen stehe und fünf Bücher über AbiWord im Regal stehen sehe. Und vor allen freue ich mich auf den Tag, an dem ich auf einer Party mit einem wildfremdem Menschen Small Talk mache, der gar nicht weiß, wer ich bin, und der anfängt mir zu erzählen, wie großartig AbiWord ist. Ich glaube, ich werde dann einfach nur zuhören.


Literaturverzeichnis


Deutschsprachige O'Reilly-Titel

DNS und BIND, von Paul Albitz & Cricket Liu, 1997, ISBN 3-930673-54-1, DM 69,-
Einführung in Perl, von Randal L. Schwartz & Tom Christiansen, 2. Aufl. 1998, ISBN 3-89721-105-X, DM 59,-
Einführung in Perl für Win32-Systeme, von Randal L. Schwartz, Erik Olson & Tom Christiansen, 1998, ISBN 3-89721-106-8, DM 59,-
Fortgeschrittene Perl-Programmierung, von Siriam Srinivasan, 1998, ISBN 3-89721-107-6, DM 79,-
Gimp - kurz & gut, von Sven Neumann, 1999, ISBN 3-89721-215-3, DM 12,80
GNU Emacs - kurz & gut, von Debra Cameron, 1999, ISBN 3-89721-211-0, DM 12,80
GNU-Tools zur Programmierung - kurz & gut, von Matthias Kalle Dalheimer, 1998, ISBN 3-89721-209-9, DM 12,80
KDE - Das umfassende Referenzwerk, von Matthias Kalle Dalheimer, erscheint Mai 1999, ISBN 3-89721-131-9, DM 59,-
Linux-Gerätetreiber, von Alessandro Rubini, 1998, ISBN 3-89721-122-X, DM 69,-
Linux in a Nutshell, von Jessica P. Hekman, 1997, ISBN 3-930673-57-6, DM 49,-
Linux - Wegweiser zur Installation & Konfiguration, von Matt Welsh & Lar Kaufman, 2. Aufl. 1998, ISBN 3-930673-58-4, DM 59,-
Perl 5 - kurz & gut, von Johan Vromans, 2. Aufl. 1999, ISBN 3-89721-201-3, DM 12,80
Perl/Tk - kurz & gut, von Stephen O. Lidie, 1998, ISBN 3-89721-200-5, DM 12,80
Programmieren mit Perl, von Larry Wall, Randal L. Schwartz & Tom Christiansen, 1997, ISBN 3-930673-48-7, DM 89,-
Programmieren mit Perl-Modulen, von Nate Patwardhan u.a, 1998, ISBN 3-89721-108-4, incl. CD-ROM, DM 74,-
Reguläre Ausdrücke, von Jeffrey E. F. Friedl, 1998, ISBN 3-930673-62-2, DM 59,-
sendmail - kurz & gut, von Bryan Costales & Eric Allman, 1998, ISBN 3-89721-202-1, DM 12,80

Englischsprachige O'Reilly-Titel

Advanced Perl Programming, by Siriam Srinivasan, 1997, ISBN 1-56592-220-4 DM 70,-
Apache: The Definitive Guide, by Ben Laurie & Peter Laurie, 2nd Edition 1999, ISBN 1-56592-528-9, incl. CD-ROM, DM 70,-
DNS and BIND, by Paul Albitz & Cricket Liu, 3rd Editon 1998, ISBN 1-56592-512-2, DM 66,-
Exploring Expect, by Don Libes, 1994, ISBN 1-56592-090-2, DM 66,-
GNU Emacs Pocket Reference, by Debra Cameron, 1998, ISBN 1-56592-496-7, DM 14,-
Learning Perl, by Randal L. Schwartz & Tom Christiansen, 2nd Edition 1997, ISBN 1-56592-284-0, DM 60,-
Learning Perl on Win32 Systems, by Randal L. Schwartz, Erik Olson & Tom Christiansen, 1997, ISBN 1-56592-324-3, DM 60,-
Learning Perl/TK, by Nancy Walsh, 1999, ISBN 1-56592-314-6, DM 66,-
Linux Device Drivers, by Alessandro Rubini, 1998, ISBN 1-56592-292-1, DM 60,-
Linux in a Nutshell, by Ellen Sievers & the Staff of O'Reilly & Associates, 2nd Edition 1999, ISBN 1-56592-585-8, DM 50,-
Mastering Regular Expressions, by Jeffrey E. F. Friedl, 1997, ISBN 1-56592-257-3, DM 60,-
Open Sources: Voices from the Open Source Revolution, by Chris DiBona, Sam Ockman & Mark Stone, 1999, ISBN 1-56592-582-3, DM 50,-
Perl Cookbook, by Tom Christiansen & Nathan Torkington, 1998, ISBN 1-56592-243-3, DM 80,-
Perl in a Nutshell, by Stephen Spainhour, Ellen Siever & Nathan Patwardhan, 1998, ISBN 1-56592-286-7, DM 50,-
Perl 5 Pocket Reference, by Johan Vromans, 2nd Edition 1998, ISBN 1-56592-495-9, DM 14,-
Perl/Tk Pocket Reference, by Stephen O. Lidie, 1998, ISBN 1-56592-517-3, DM 14,-
Programming Perl, by Larry Wall, Randal L. Schwartz & Tom Christiansen, 2nd Edition 1996, ISBN 1-56592-149-6, DM 80,-
Programming Python, by Mark Lutz, 1996, ISBN 1-56592-197-6, incl. CD-ROM, DM 90,-
Programming Web Graphics with Perl & GNU Software, by Shawn P.Wallace, 1999, ISBN 1-56592-478-9, DM 60,-
Programming with Qt, by Matthias Kalle Dalheimer, 1999, ISBN 1-56592-588-2, DM 60,-
Running Linux, by Matt Welsh & Lar Kaufman, 2nd Edition 1996, ISBN 1-56592-151-8, DM 60,-
sendmail, by Bryan Costales & Eric Allman, 2nd Edition 1997, ISBN 1-56592-222-0, DM 80,-
sendmail Desktop Reference, by Bryan Costales & Eric Allman, 1997, ISBN 1-56592-278-6, DM 14,-
Tcl/Tk in a Nutshell, by Paul Raines & Jeff Tranter, 1999, ISBN 1-56592-433-9, DM 50,-
Writing Apache Modules with Perl and C, by Lincoln Stein & Doug MacEachern, 1999, ISBN 1-56592-567-X, DM 70,-


[1] Die Projektbeschreibungen wie die Interviews gehen auf eine Dokumentation zurück, die im Anschluß an das ersten Open Source-Gipfeltreffen zusammengestellt wurden.

O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen | Kontaktieren Sie uns
International | Über O'Reilly | Tochterfirmen

© 1998, O'Reilly Verlag