Schlüsse aus der Open-Source-Software-Entwicklung

13.07.1999
Open Source ist ein Begriff, auf den man sich in jüngster Zeit geeinigt hat, um eine Tradition offener Standards, öffentlich geteilter Quellcodes und kollaborativer Entwicklung von Software zu beschreiben. Beispiele wären hierfür die Betriebssysteme Linux und FreeBSD, der Apache Web Server, die Sprachen Perl, Tcl und Python, ein Großteil der Internet-Infrastruktur inklusive Bind (die Berkeley Internet Name Server, auf denen das Domain Name System läuft), der Sendmail Mailserver und viele andere Programme. Die Kampagne für Open Source wurde 1998 international wahrgenommen, als Netscape ankündigten, mit Mozilla, der nächsten Version ihres Browsers, ein Open Source Produkt anzubieten. Gleichzeitig machten IBM den Apache Web Server zum Kern ihrer WebSphere-Produktlinie.

Offiziell bedeutet Open Source (als Trademark der Open Source Initiative) mehr als die Tatsache, daß der Source Code frei zugänglich ist: Der Quellcode muß auch zur Weiterverbreitung ohne Restriktionen oder Gebühren offen stehen. Die Lizenz muß also die Erstellung von Modifikationen erlauben, sowie die Herstellung von Produkten, die aus dem ursprünglichen Code abgeleitet wurden. So entstandene Derivate müssen unter den selben Bedingungen wie das ursprüngliche Werk weiterverbreitet werden dürfen. Lizenzen, die mit dieser Definition von Open Source übereinstimmen, sind unter anderem die GNU Public License (GPL), die BSD-Lizenz zusammen mit Berkeley Unix-Derivaten, die X Consortium-Lizenz für das X Window System und die Mozilla Public License.

Open Source ist aber auch mehr als eine bloße Lizenzfrage.

Open Source ist aber auch mehr als eine bloße Lizenzfrage. Einige der bedeutendsten Fortschritte in der Computertechnik, die signifikant unsere Ökonomie und unsere Zukunft bestimmen, sind das Produkt einer noch kaum verstandenen "Hackerkultur". Es ist also fundamental wichtig, diese Kultur zu verstehen, und damit die Art und Weise, in der sie solch innovative und qualitativ hochwertige Software produziert. Darüber hinaus versuchen kleine wie große Firmen zu verstehen, inwiefern die Ethik der freien Distribution von Source Code die ökonomischen Modelle beeinflußt, die gegenwärtig ihre Geschäftspolitik bestimmen.

Der folgende Text versucht Perspektiven zu eröffnen, wie Open Source nicht nur von denjenigen, die sich ohnehin bereits diesem Modell verschrieben haben, genutzt werden kann, sondern prinzipiell von jedem, der Software entwickelt.

Man darf die Debatte um Open Source nicht auf die Frage NT versus Linux, oder gar Microsoft gegen den Rest der Welt verkürzen. Es gilt vielmehr herauszufinden, welche Schlüsse aus Open Source man auch generell auf das ganze Spektrum der Softwareentwicklung übertragen kann. Können Hersteller bessere Produkte schaffen, indem sie ihren Nutzern mehr Einfluß in Hinblick auf die Produktentwicklung geben? Können Nutzer davon profitieren, wenn sie ihre selbstgemachte oder zurechtgeschneiderte Software mit anderen teilen und im Gegenzug die Arbeiten anderer bekommen? Und während das Internet im Gegensatz zum Desktop immer mehr zum Schauplatz der Entwicklung wird: Können aktuelle Open-Source-Projekte über generelle Prinzipien einer kollaborativen Arbeit in großem Stil Auskunft geben, um sie auch für Unternehmungen nutzbar zu machen, die sich nicht mit der Entwicklung von Software beschäftigen?

Allen, die sich für Open Source interessieren, sei in diesem Zusammenhang Eric Raymonds Text "The Cathedral and the Bazaar" empfohlen, der Netscapes Entscheidung mitbeeinflußt hat, ihren Browser als Open-Source-Software zu veröffentlichen. Werfen Sie außerdem einen Blick in Mark Stones "Science of the New Renaissance", das die Argumentation verfolgt, daß Open Source eine natürliche Fortsetzung der wissenschaftlichen Tradition des Westens ist.

Software: Produkt oder Dienstleistung?

Mit dem Aufstieg von Microsoft zur dominanten Kraft der Software-Industrie kann man leicht den Eindruck gewinnen, daß es sich bei Software um ein Produkt handelt, das konzipiert, hergestellt, verpackt und dann verkauft werden kann. Tatsächlich aber repräsentieren folienverschweißte PC-Applikationen lediglich einen kleinen Teil der Gesamtheit von benutzter Software.

Die meisten Anwendungen, die große Firmen benutzen, werden entweder intern entwickelt oder so heftig verändert und auf die eigenen Bedürfnisse zugeschnitten, daß man sie auch gleich selbst entwickeln könnte. Die meisten wissenschaftlichen Anwendungen sind entweder 'Einzelstücke' oder zum größten Teil von den Nutzern individualisiert worden, wenn sie auf fertigen Produkten beruhen. Die Administrierung von Netzwerken, großen Computersystemen oder einer Website erfordert die konstante Entwicklung von kleinen Anwendungen, Scripts und sogenannten "glue applications", die dafür sorgen, daß die einzelnen Komponenten zusammen funktionieren. Sogar auf der Ebene des einfachen Desktops entwickeln Power User Makros und andere "Programme", um wiederkehrende Aufgaben zu automatisieren.

Ob Open Source eine überlegene Methodologie für die Entwicklung von fertig verpackten Softwareprodukten für den Endverbraucher ist, oder vielleicht auch nicht, wird derzeit auf dem Markt getestet. Dagegen ist aber längst offensichtlich, daß Open Source die überlegene Methodologie für die Entwicklung der oben genannten, auf spezifische Bedürfnisse zugeschittene Software ist. Indem Nutzern eines Produkts der Zugriff auf den Quellcode ermöglicht und das Recht auf die Entwicklung von Derivaten eingeräumt wird, erlaubt man ihnen, sich selbst zu helfen. Darüber hinaus fördert man die natürliche Evolution eines Produktes in gleichem Maße wie durch vorgeplantes Produktdesign.

Egal, ob Open-Source-Technologien als fertig vepackte Produkte Erfolg haben, oder nicht: Ihre größte ökonomische Kraft liegt unter Umständen in den neuen Dienstleistungen, die sie ermöglichen. Das Internet ist das beeindruckendste Beispiel eines Marktplatzes voller ökonomischer Möglichkeiten, der seine Existenz der Open Source Community verdankt. Das Internet (und die verschiedenen Netzwerke, die irgendwann zum Internet zusammenwuchsen) war gleichzeitig Mechanismus für und Produkt von einer enormen Explosion kollaborativer Entwicklung. Auch heute noch machen Open Source Programme wie Bind, Sendmail und Apache sowie kommerzielle Programme, deren Funktionalität ursprünglich von der Open-Source-Community entwickelt worden waren (Browser, Internet E-Mail), das Herz des Internet aus. Firmen, die von Uunet (und dem gesamten ISP Markt) über Yahoo (und dem ganzen kommerziellen Web), die Zulieferer von Hardwarefirmen bis hin zu Werbeagenturen reichen, haben von der Open-Source-Revolution profitiert. Kommerziell drückt sich dies heute schon in Umsätzen aus, die im Milliarden-Dollar-Bereich liegen.

Vielleicht noch wichtiger ist die Tatsache, daß der Open Source Prozeß einen mächtigen globalen Trend der zunehmenden Zusammenarbeit von Menschen über Netzwerke reflektiert.

So, wie die Druckerpresse in der Renaissance die Verbreitung von Wissen ermöglichte, ermöglicht das Internet heute in großem Stil Versuche kooperativer Entwicklung. Die Geschwindigkeit, in der sich Information heute verbreitet, hat sich signifikant erhöht. Darüber hinaus erhalten die Prinzipien der freien Meinungsäußerung und des freien Informationsaustauschs eine neue Bedeutung im Kontext unserer Interaktion mit Computern. Was ist ein Programm schließlich anderes als eine Form des Sprechens mit einem Computer? Und was ist Open Source dann anderes als der offene und öffentliche Diskurs, der immer schon dem Fortschritt menschlichen Wissens diente?

Mit der Verbreitung des World Wide Web schließlich, das von Menschen lesbaren Text (HTML) mit programmierter Funktionalität in Form von CGI-Skripten, inline JavaScript, Java auf Server-Seite oder ASP mixt, verschwimmen die Grenzen zwischen Mensch-Computer-Kommunikation und Mensch-Mensch-Kommunikation zusehends. Man könnte also die Dynamik der Computerindustrie als eine Reflektion der Dynamik unserer Kommunikation verstehen.

Innovation und Evolution

Eines der Probleme bei der Entwicklung kommerzieller Produkte ist die Tatsache, daß der Fokus dabei auf der Herstellung von Produkten liegt, die ihren Produzenten einen Profit einbringt. Sehr viele Produkte sind zwar auf reale Bedürfnisse zugeschnitten, trotzdem aber zu spezialisiert. Oder sie treffen auf eine Situation, die ein erfolgreiches Marketing noch nicht erlaubt, um die vorgestreckten Investitionen auch wieder einspielen zu können. Letzteres aber ist die Grundvoraussetzung sowohl für große Firmen als auch für Neugründungen von Firmen mit Hilfe von Risikokapital.

Tatsächlich wurden viele Open Source Projekte in Angriff genommen, um ein spezifisches Problem eines Nutzers zu lösen. Die Lösung des Problems ist in diesem Fall der Ertrag der Investition. Frühe Open-Source-Entwickler haben aber verstanden, daß die Weitergabe ihrer Arbeit an die als Netzwerk organisierte Gemeinschaft von Entwicklern ihnen eine zusätzliche Dividende in Form von Funktionalität einbringen kann, die andere Nutzer als 'Ertrag' beisteuern.

Es war die gleichzeitig stattfindende Evolution immer größerer Computernetze, die der Idee von Open Source erst den wirklichen Impetus gab. Vorher waren Nutzergemeinschaften um kommerzielle Hersteller und ihre Produkte zentriert. Die Möglichkeit aber, Software über FTP, E-Mail und Usenet zu vertreiben, brachte unabhängigen Entwicklern unbeabsichtigt Gewinne ein, indem Software im Sinne einer "stillen Post" herumgereicht wurde. Das führte oft zu unverständlichem Gebrabbel, noch viel öfter aber zu evolutionären Fortschritten.

Ein kurzer Blick in die frühe Geschichte vieler Open Source Projekte illustriert in Kürze die Art und Weise, wie eine Anwendung, die einem eher belanglosen Problem geschuldet war, später als signifikante Neuerung erschien.

Eric Allman schrieb ursprünglich einen Vorgänger von Sendmail, weil es einfacher war, die E-Mails anderer Wissenschaftler der Universität Berkeley weiterzuleiten, als ihnen ein Login auf seinem Rechner zu geben. Keiner konnte sich damals vorstellen, daß das Forwarden von E-Mail über heterogene Netzwerke und Systeme 20 Jahre später eine kritische Internetanwendung sein würde. Larry Wall schrieb Perl, um einige nervtötende Probleme in der Systemadministration zu lösen. Tim Berners-Lee erschuf das World Wide Web, damit Physiker, die mit Teilchen-Beschleunigern arbeiteten (ein unter allen Umständen kleiner Markt), zusammenarbeiten und ihre Erkenntnisse teilen konnten. Dies geschah in der Tradition des größten Teils grundlegender Internetsoftware, die entwickelt wurde, um einen akademischen Informationsaustausch zu ermöglichen. Richard Stallman hat den Weg zur Free Software Foundation, zum GNU-Projekt und am Ende auch zu großen Teilen von Linux angeblich eingeschlagen, weil ein Händler ihn nicht mehr mit Source Code für einen schlecht funktionierenden Druckertreiber versorgen konnte. Keines dieser außerordentlich einflußreichen Projekte wäre in einem traditionellen Markt begonnen worden, und jedes davon brauchte Jahre, um seine Transformationseffekte zu entwickeln. Genau aus diesem Grund kann Open Source unerwartete Innovationen auslösen: Weil es Individuen die Möglichkeiten eröffnet, unscheinbare Probleme anzugehen.

Wie Peter Schwartz in seinem Buch "The Art of the Long View" (Doubleday, 1991) beschreibt, "organisieren Menschen und Organisationen ihr Wissen oft konzentrisch, so daß sich die am liebevollsten gehegten und vitalsten Glaubensinhalte im beschützten Inneren befinden. An der äußersten Grenze befinden sich die Ideen, die die Mehrheit ablehnt. Ein bißchen näher am Zentrum sind die Randzonen gelegen - Gebiete, die noch nicht legitimiert sind, aber auch nicht vollständig vom Zentrum abgelehnt werden. Innovation ist die Schwäche des Zentrums. Gemeinsam tendieren die Struktur, die Macht und die institutionelle Trägheit dazu, innovative Denker zu behindern und an den Rand zu drängen."

Selbstverständlich entstehen signifikante Innovationen auch, wenn bekannte Probleme konzertiert angegangen werden, um mit dem Ergebnis einen bereits vorhandenen Markt zu bedienen. Die Mechanismen solcher Entwicklungsprojekte sind gut eingeführt. Open Source aber ist ein kostengünstiger Weg, um die Wahrscheinlichkeit von Überraschungen zu erhöhen.

Open Source ist daher ein Way of Life, nicht ein besserer Weg, um potentielle Gewinner oder Verlierer herauszupicken. Open-Source-Programme wie Linux, Apache und Perl sind nicht länger Randprodukte - sie bewegen sich geradewegs aufs Zentrum zu. Um die nächste große Open Source Überraschung zu schaffen, muß man aber die Bedingungen für solche Innovationen schaffen: Offene Standards und Protokolle, die den Leuten erlauben, neue Software schnell und einfach an alte Software anzuschließen, gute Dokumentation und einen präzise definierten Mechanismus der Erweiterung, der Entwicklern die Erstellung eigener zusätzlicher Module ermöglicht, ohne dafür die Erlaubnis eines zentralen Architekten haben zu müssen. Und selbstverständlich braucht man Lizenzen, die einem Entwickler das Weiterbasteln auf der Grundlage der Arbeit anderer erlauben, ohne daß vorher die Erlaubnis eingeholt werden muß.

Kooperative Entwicklung

Viele der Annahmen in "The Cathedral and the Bazaar", inklusive der berühmt gewordenen Weisheit, mit genügend Augen werde jeder Bug sichtbar, basieren auf der Idee, daß man mit dem Internet mehr Entwickler auf ein Projekt ansetzen kann, als es das größte Unternehmen könnte.

Indem man Nutzer eines Produkts zu Ko-Entwicklern macht, beschleunigt man den Prozeß des Debuggens, verbessert die Qualität und gewinnt spezielle neue Features, die sich für eine große Anzahl von Nutzern eventuell als wichtig herausstellen. Indem man Nutzern erlaubt, selbst ihre ureigenen Probleme zu lösen, gewinnt man neue Programmcharakteristika bei niedrigen Unkosten, die sich dann auf einem Markt beweisen können, der fruchtbarer ist, als es selbst die fiebrige Hektik von Risikokapitalisten in Silicon Valley vermuten läßt (und größere Stückzahlen erlaubt, als sich die zentralisierte Produktplanung der großen Firmen vorstellen kann).

Dieser Aspekt gemeinschaftlichen Entwickelns bedeutet nichts anderes, als daß Nutzergemeinschaften, nicht die Produkte selbst, die eigentlichen Schlüsselfaktoren für den Erfolg von Produkten sind. Als Unternehmer werde ich immer wieder von Entwicklern angesprochen, die ein marginales Produkt mit geringer Akzeptanz im Markt mit Hilfe des magischen Schlüssels Open Source zu einem Star machen wollen. So funktioniert es aber nicht. Das Produkt muß ein echtes Bedürfnis treffen, und damit einen passionierten Kern von Nutzern anziehen, die noch mehr von ihm wollen, als der ursprüngliche Entwickler hineingelegt hat. Umgekehrt kann eine Firma mit einem etablierten Produkt nicht darauf hoffen, daß eine bereits existierende Open Source Community daran arbeitet, nur weil das Produkt zu Open Source erklärt wurde. Stattdessen muß ein Produkt seine Codes der Gemeinschaft seiner Nutzer offenlegen.

Das führt zu einer Idee, die mancher Fürsprecher von Open Source nicht interessieren wird, weil sie nicht der Open-Source-Definition entspricht, eine Idee, die großen Unternehmen aber durchaus Vorteile bringen könnte. Vor allem, wenn ein Unternehmen die Hebelwirkung einiger Prinzipien von Open Source nutzen möchte, ohne sich zu einer vollen, freien Redistribution von Software verpflichten zu wollen, die auch von potentiellen Mitbewerbern genutzt werden könnte. Es geht um ein Phänomen, das man spöttisch (wie es kürzlich ein Teilnehmer eines Managermeetings zum Thema Open Source getan hat) als "beschränkte Open Source Gemeinschaft" bezeichnen könnte.

Ein Unternehmen mit einer großen Nutzerbasis könnte mit der Einschränkung auf zahlende Kunden die strikte Kontrolle darüber behalten, wer Zugang zum Source Code erhält, trotzdem aber dafür sorgen, daß der volle Quellcode offengelegt wird, daß eine komplette Dokumentation vorhanden ist, und daß über Mechanismen für die Erstellung von Erweiterungen die Modifikationen der Nutzer in den Kern des Codes zurückfließen können. Das Unternehmen könnte studieren, wie Open-Source-Projekte wie Apache kollaborative Entwicklung organisieren, und diese Prinzipien auf die Interaktion mit ihren Kunden anwenden, ohne deshalb die Software generell freizugeben. Auf diese Art und Weise wurde tatsächlich in den frühen Tagen von Mainframe-Rechnern mit Software umgegangen: Software wurde gratis der Hardware beigefügt. IBM-Produkte wie CICS wurden ursprünglich von Kunden entwickelt, und dann an IBM zur Wartung und Weiterentwicklung übergeben.

Die Lektionen aus dem Apache-Projekt, wie sie von Roy Fielding dargelegt wurden, sind diesbezüglich äußerst relevant. Eine Gemeinschaft muß Prozesse entwickeln, in denen über neue Charakteristika abgestimmt werden kann. Sie muß entscheiden, wer Zugang zum Source Tree bekommt. Und sie muß so kommunizieren, daß die frei fließende Entwicklung, die für Open Source so wichtig ist, nicht gehemmt wird.

Natürlich stellt sich bei so einem Projekt die Schlüsselfrage, wie groß denn die Gemeinschaft der Entwicklergemeinschaft sein muß, um den Netzwerkeffekt von Open Source zu garantieren. Viele proprietäre Entwicklergemeinschaften könnten dafür einfach zu klein sein. Um die gesamte via Internet verfügbare Entwicklergemeinschaft anzusprechen, ohne ihren Laden gleich verschenken zu müssen, fangen immer mehr Unternehmen an, mit neuen Lizenzformen zu experimentieren. Ein Ansatz ist die Distribution des Source Code und die Erlaubnis unbegrenzter Modifikation und Redistribution für nicht-kommerzielle Zwecke, während kommerzielle Anwendungen hingegen anderer Lizenzen bedürfen.

Dieser Weg wurde vor kurzem für die Java Community Source License von Sun, sowie für die Aladdin Free Public License von Peter Deutsch gewählt, der das weitverbreitete GhostScript Paket entwickelt hat. Deutsch erklärte in einem Interview seine Vorstellungen von "community development":

Wenn man gewillt ist nach den Regeln zu spielen, die ich dieSechziger-Jahre-Regeln nennen würde, dann bekommt man mit der Aladdin-Lizenz die gleichen Nutzungsrechte wie bei der GPL

[Die Software kann] frei genutzt, frei kopiert und modifiziert werden. Verkürzt gesagt sehe ich die Sechziger-Jahre-Regeln, die man auch Kooperative Regeln nennen könnte, so

Auf vielfache Weise besteht der Kern vieler Open-Source-Communities aus einer sozialen Übereinkunft zwischen einem Software-Entwickler und seinen oder ihren Usern. Beide Seiten vereinbaren eine Kooperation, die für alle Beteiligten einen Vorteil bringt. Im besten Fall ist das auch für Entwicklergemeinschaften gültig, die um proprietäre Produkte herum entstehen. Der Schlüssel ist dabei, daß Open Source finanzielle Transaktionen - der Kitt, der Gemeinschaften sonst zusammenhält - durch Kooperationen ersetzt.

Die Relevanz von Erweiterbarkeit

Lizenzen, die Kooperationen vereinfachen, sind ein wichtiger Schlüssel zum Open-Source-Phänomen. Ein Teil des Erfolgs von Open-Source-Projekten ist aber auch technischen Entscheidungen geschuldet, die anderen das Beisteuern von Neuerungen erleichtert haben, wie sowohl Linus Torvalds als auch Larry Wall angemerkt haben. Laut Torvalds verdankt Linux seinen Erfolg zumindest teilweise der Tatsache, daß es den Prinzipien guten Designs folgte. Dies erlaubte die Ausweitung und Erweiterung in Richtungen, die Torvalds nicht vorausgeplant hatte, als er mit der Arbeit am Kernel begann. Ähnlich erklärt Larry Wall, wie er Perl so konzipierte, daß sein Set von Charakteristika natürlich wachsen konnte, so wie menschliche Sprachen sich im Dialog mit den Bedürfnissen ihrer Nutzer entwickeln.

Tatsächlich haben viele erfolgreiche Open-Source-Projekte eine modulare Architektur, die Nutzern erlaubt, die Funktionalität des Systems zu erweitern, ohne schon existierende Kernfunktionen ändern zu müssen. Dies erlaubt einem Open Source Projekt mit seiner Gemeinschaft zu wachsen, während ein ursprünglicher visionärer Entwickler (oder ein Team) die Kontrolle über das Kernprodukt behalten kann.

Offensichtlich eröffnet sich hier das noch zu studierende Problem, wo die ideale Grenze zwischen dem von einem Individuum oder einem kleinen Team kontrollierten Kernprodukt und dem Input der Nutzergemeinschaft liegt.

Kommerzielle Produktentwicklung auf der Basis von Open Source

Große Unternehmen sind nicht die einzigen, die sich für die Grenze zwischen kommerzieller Entwicklung und der kooperativen Entwicklung von Open Source interessieren.

Selbstverständlich ist es für Open Source eine große Herausforderung, den Beweis anzutreten, daß es Produkte herstellen kann, die auch von Nicht-Spezialisten benutzt werden können. Viele Open-Source-Entwickler versuchen den besten Weg herauszufinden, um die Kluft zwischen 'early adopters' und einem größeren Markt zu überwinden.

John Ousterhout hat das Argument eingebracht, daß es zwischen Open Source und kommerzieller Entwicklung einen natürlichen Widerspruch gebe. Open Source sorgt sozusagen für das Rohmaterial, das später verfeinert und durch kommerzielle Entwicklung erweitert werden kann.

Dick Hardt von ActiveState, die Perl-Produkte für die Win32-Plattform entwickeln, führt ein ähnliches Argument an. Während einer Präsentation auf einer Perl-Konferenz benutzte Hardt die Metapher vom Baumstamm und der zurechtgesägten Latte. Open Source sei großartig, um rohes Bauholz zu gewinnen. Während aber viele Nutzer zufrieden damit seien, aus klobigen Stämmen Holzhütten zu bauen, oder diese Stämme selbst weiterzubearbeiten, könne man eine größere Zahl von Nutzern gewinnen, indem Unternehmen passend zurechtgesägte Latten in Form von fertigen Programmteilen, Interfaces, Dokumentationen und anderen Elemente kommerzieller Anwendungen anbieten.

Es gibt natürlich eine permanente Diskussion in der Open-Source-Community darüber, wie man am besten solche kommerziellen Produkte entwickeln könne. Die Firma Red Hat etwa, die Linux vertreibt, hat sich der GNU Public License auch für die von ihr erstellten Erweiterungen verpflichtet. Ihr Argument ist, daß die Verpackung, der Markenname und ihre Distributionswege ausreichend sind, um ihren Markt zu sichern und einen akzeptablen Gewinn zu gewährleisten.

Andere Firmen wie Ousterhouts Scriptics, Allmans Sendmail, Inc. und Hardts ActiveState Tool Corp. haben sich einem hybriden Ansatz verschrieben und liefern sowohl eine reiche Open-Source-Produktpalette als auch proprietäre, mit einem Mehrwert versehene Erweiterungen. Starke Verfechter der GPL und der strikten Open-Source-Definition mögen solche Versuche fragwürdig finden. Letztendlich aber werden uns Experimente auf dem Markt eher als philosophische Debatten darüber Auskunft geben, ob Open Source Lizenzen (oder ganz einfach eine offene Architektur), der Zugang zum Source Code (auch wenn auf der Basis einer bezahlten Lizenz) oder die Partizipation von Nutzern am Entwicklungsprozess die wichtigsten Elemente darstellen für den zukünftigen Erfolg von Open Source Projekten.

x
Fehler melden
Telepolis zitieren
Vielen Dank!
Kommentare lesen (2 Beiträge) mehr...
Anzeige
Weit weg mit Telepolis
Anzeige
Auf nach Brasilien
Leben im Regenwald, Nationalpark Iguacu, Rio de Janeiro
Cover

Leben im Gehäuse

Wohnen als Prozess der Zivilisation

Anzeige
Cover

Vergiftete Beziehungen

Männer oder Frauen: Wer hat recht?

Anzeige
Hellwach mit Telepolis
Anzeige
Cafe
Telepolis-Cafe

Angebot des Monats:
Kaffee und Espresso aus Guatemala in der Telepolis-Edition für unsere Leser

Cover

Aufbruch ins Ungewisse

Auf der Suche nach Alternativen zur kapitalistischen Dauerkrise

bilder

seen.by

Mit dem Schalter am linken Rand des Suchfelds lässt sich zwischen der klassischen Suche mit der Heise-Suchmaschine und einer voreingestellten Suche bei Google wählen.

Tastenkürzel:

ctrl-Taste:
Zum Wechseln zwischen Heise- und Google-Suche

esc-Taste:
Verlassen und Zurücksetzen des Eingabe-Felds

Buchstaben-Taste F
Direkt zur Suche springen

SUCHEN

Mit dem Schalter am linken Rand des Suchfelds lässt sich zwischen der klassischen Suche mit der Heise-Suchmaschine und einer voreingestellten Suche bei Google wählen.

SUCHEN

.
.