Wie mache ich eigentlich Open Source?

Was ist Open Source?

Open Source bedeutet quelloffen, der Programmcode ist also für Jedermann lesbar. Üblicherweise ist Open-Source-Software kostenlos nutzbar.

Jeder von uns nutzt täglich, ohne es zu wissen, mindestens eine Open Source Applikation. Viele Web- und Mailserver laufen auf Linux, dem freien Betriebssystem von Linus Torvalds. Der Apache Webserver, der unsere Webseiten ausliefert, ist ebenso Open Source wie Postfix, ein SMTP-Server, der unsere E-Mails überträgt. Mozilla Firefox und Google Chrome erlauben uns das Surfen im Internet, auch sie sind Open Source. MySQL und PostGreSQL, die erfolgreichsten Datenbanken für Web-Applikationen, sind genauso Open Source wie auch PHP, Ruby und Python, die Sprachen, mit denen wir Web-Applikationen verwirklichen. Ebenso quelloffen und kostenlos einsetzbar sind die JavaScript-Frameworks jQuery, ExtJS, MooTools, Dojo und YUI. Auch V8, Googles JavaScript Engine, und das darauf aufsetzende Node.js stehen uns open source zur Verfügung.

Open Source und JavaScript

JavaScript ist grundsätzlich quelloffen. Die in Webseiten eingebundenen Scripte lassen sich in aller Regel ohne Mühe betrachten. So hat man jederzeit die Möglichkeit nachzuvollziehen, wie eine bestimmte Funktion auf einer Webseite implementiert wurde.

GitHub, eine der derzeit populärsten Open Source Plattformen, stellt Statistiken über die bei ihnen gelagerten Projekte zur Verfügung. Aktuell entfallen 20% aller Projekte auf die Sprache JavaScript, 16% auf Ruby, 9% auf Python und nur 7% auf PHP. Unter den beliebtesten GitHub-Projekten finden sich Node.js, Bootstrap von Twitter, jQuery, jQuery UI und jQuery mobile, Backbone.js, modernizr.js, das jQuery-Plugin chosen und viele weiteren JavaScript-Projekte.

Selbst JavaScript als Sprache selbst, wird öffentlich auf ecmascript.org und in Mailinglisten bei Mozilla entwickelt und von ECMA standardisiert.

Open Source Lizenzen

Lesbarer Programmcode ist nicht mit grundsätzlich kostenlosem Einsatz zu verwechseln. Das ist vergleichbar mit Büchern, die zwar im Buchhandel jeder einsehen kann, aber nicht kopieren und weiterverbreiten darf. So versteht man unter Open Source also auch die Lizensierung frei benutzbarer Programme. Eine Lizenz beschreibt in welchem Umfang und mit welchen Bedingungen eine Software (meist kostenfrei) eingesetzt werden darf.

Es gibt zwar eine ganze Menge verfügbarer Lizenzmodelle, aber nur wenige sind für uns JavaScript-Entwickler wirklich interessant. Die drei meist genutzten Lizenzen in der JavaScript Open Source Welt stellen wir kurz vor. Die GPL (General Public License) erlaubt den kostenlosen Einsatz der Software. Wird ein GPL-lizensiertes Programmstück in einer anderen Software eingesetzt, muss diese ebenfalls unter der GPL freigegeben werden. Die LGPL (Lesser General Public License) erlaubt hingegen den Einsatz von LGPL-Programmstücken in nicht-LGPL Software. Beide Lizenzen fordern, dass Änderungen an der L/GPL Software an das Projekt zurückgeführt werden müssen. Die MIT-Lizenz (Massachusets Institute of Technology) erlaubt jeden erdenklichen Einsatz ohne Einschränkung.

Alle drei Modelle dienen außerdem dem Schutz der Entwickler vor möglichen rechtlichen Schritten gegen sie. Sollte ein Open Source Projekt mal für Datenverluste verantwortlich sein, können deren Entwickler also nicht vor Gericht gezerrt werden. Es sei angemerkt, dass diese Lizenzen nur die Autoren der Open Source Software schützen – sie sind die Lieferanten. Konsument, aus Sicht der Lizenz, ist der Entwickler, der die Open Source Komponente in sein Projekt einsetzt. Er übernimmt also seinen Kunden gegenüber die Verantwortung für die eingesetzte Open Source Komponente. Natürlich lässt sich diese Verantwortung vertraglich auf den Kunden übertragen, um selbst aus der Haftung zu kommen.

Für welche Lizenz man sich entscheidet, kommt ganz auf das Projekt an. Für ein kleines jQuery-Plugin, das von möglichst vielen Entwicklern eingesetzt werden soll, ist die MIT-Lizenz die optimale Wahl. Bei etwas umfangreicheren Bibliotheken möchte man vielleicht verhindern, dass ein dritter den Programmcode kopiert, umbenennt und als sein eigenes verkauft. Hier wäre man mit der LGPL besser bedient, da diese zwar die Benutzung der Bibliothek in einer Software mit einer anderen Lizenz gestattet, aber sämtliche Änderungen an der Bibliothek selbst wieder an das Projekt zurückgegeben oder als neues LGPL-Projekt veröffentlicht werden müssen.

GPL ist der Kommunist unter den Open Source Lizenzen.

Wer GPL-lizensierte Komponenten in seinen Projekte verwenden möchte, muss seine Software ebenfalls unter der GPL freigeben. Das bedeutet, dass es nicht gestattet ist, eine GPL-lizensierte Komponente in sein kommerzielles Produkt zu integrieren. Würde man die GPL-lizenzierte JavaScript-Bibliothek X in seiner Webseite Y benutzen, müsste man also deren gesamten Quellcode und Ressourcen (wie Bilder) offenlegen. Dadurch dürfte ein Dritter die gesamte Webseite kopieren und für sich selbst nutzen. Kunden bezahlen einen Entwickler aber in aller Regel nur für Produkte, die in ihrer Gesamtheit nur der Kunde einsetzen darf. Wer mit dem Handwerk Webentwicklung Geld verdienen möchte, macht also besser einen großen Bogen um GPL-lizensierte Komponenten.

Erfreulicherweise kann man Programme auch mit mehreren Lizenzen gleichzeitig freigeben. So ist jQuery beispielsweise in der MIT-Lizenz und GPL verfügbar. Auf den ersten Blick macht das vielleicht wenig Sinn, da die MIT-Lizenz ja bereits alles erlaubt. Veröffentlicht man aber selbst GPL-lizensierte Programme, muss man sicherstellen, dass auch nur GPL-lizensierte Komponenten benutzt werden. Hier macht sich jQuery also einfach GPL-kompatibel.

ExtJS ist ebenfalls in mehreren Lizenzmodellen zu haben. Für die Open Source Welt stellt Sencha seine JavaScript-Bibliothek in einer erweiterten GPL-Lizenz zu Verfügung und erlaubt das eigene Werk in einer Reihe von Lizenzen zu veröffentlichen. Wer ExtJS in einem nicht-quelloffenen Projekt einsetzen möchte, kann sich von Sencha eine kommerzielle Lizenz ausstellen lassen – natürlich gegen Bezahlung. Sencha nutzt die duale Lizensierung also dazu, für die kommerzielle Nutzung ihres Open Source Produkts ExtJS eine Gebühr erheben zu können. So unterstützt Sencha die Open Source Gemeinde, hält sich das Projekt aber auch als Einnahmequelle offen.

Am besten stellen wir unsere Werke also Dual-Licensed in MIT-Lizenz und GPL zur Verfügung.

Openwashing – „Open“ versus „Open Source“

Zwischenzeitlich gibt es viele Unternehmen, die ihre Produkte als open bezeichnen. Der sorgfältige Leser hat bestimmt das fehlende „Source“ bemerkt. Open ohne Source ist nämlich meistens etwas ganz anderes. Produkte als open zu bezeichnen ist eine kleine Trickserei, ein kommerzielles Produkt in ein besseres Licht zu rücken. Marketingabteilungen versprechen sich davon ein positiveres Image ihrer Produkte.

Softwareprodukte werden gerne mal als open bezeichnet, wenn der Quellcode zwar zur Verfügung steht, lizenzrechtlich aber so gebunden ist, dass niemand wirklich etwas damit anfangen kann. Es kann beispielsweise passieren, dass die Quellen eines Produkts offengelegt werden, aber Änderungen von Dritten schlicht ignoriert werden. Man möchte also die absolute Kontrolle über das Produkt behalten. Diese Unternehmen verzichten (bewusst?) auf das Potential der Open-Source-Gemeine am Produkt mitzuarbeiten, um beispielsweise gefundene Fehler im Programmcode selbst zu beheben und (kostenlos) an das Unternehmen zurückzuführen.

Auch der Einsatz von Standard-getreuen APIs (Application Programming Interface; Schnittstelle zum Programm) wird als Rechtfertigung missbraucht, ein Produkt als open zu bezeichnen. Standardkompatibel wäre vermutlich die bessere Wahl gewesen, aber vermutlich weniger hilfreich für das Marketing.

Mit wenig Aufwand lässt sich die open-Spreu vom Weizen trennen. Richtiges Open Source wird üblicherweise in einer der von OSI akzeptierten Lizenzen freigegeben. Auch die Entwicklergemeinde lässt sich in Bugtracker, Forum, Newsgroup und Co. begutachten.

Neben Open Source gibt es auch noch Open Core. Das sind Systeme, die auf Open Source basieren, aber eine Reihe von proprietären Erweiterungen aufweisen. Diese Erweiterungen werden gewinnbringend vermarktet. So kann man beispielsweise MySQL als Open Source Software einsetzen, wird für nützliche Tools zur Administration und Optimierung jedoch zur Kasse gebeten. Mit dieser Vorgehensweise lassen sich Open-Source-Gedanken und wirtschaftliche Bedürfnisse vereinen.

Wer macht Open Source?

Fast jedes bekannte Unternehmen ist in Open-Source-Projekten involviert – ob sie diese selbst entwickelt und freigegeben haben, oder das Potential eines Projekts erkannten und unterstützten. Facebook veröffentlichte unter anderem HipHop, den PHP-zu-C Compiler, Thrift, eine sprachunabhängige Kommunikationsinfrastruktur, und beteiligte sich an Projekten wie MySQL, Varnish und PHP. Google gab uns Android, Chrome Browser, Closure, Go, V8, WebM und vieles mehr. Oracle veröffentliche einige datenbankspezifische Projekte und ist, dank der Übernahme von SUN Microsystems, nun auch Halter von MySQL und Java. Microsoft unterstützt unter anderem PHP und Drupal.

Neben den eigenen Open-Source-Projekten und denen, denen sie sich angeschlossen haben, scheinen viele Unternehmen die Open-Source-Welt als Endlager für nicht so erfolgreiche Produkte zu betrachten. Was Adobe mit Flex und Google mit Wave vorgemacht haben, hat HP kürzlich mit webOS nachgemacht. Am Produkt bestand kein enormes Interesse, aber man hatte viel Zeit und Geld hineingesteckt. Es einfach wegzuwerfen wäre schlecht fürs Image – außerdem könnte ja doch noch jemand einen Einsatz dafür finden. Die Idee das Produkt der Allgemeinheit zu übergeben und zu überlassen, liegt da nicht mehr fern. So kann sich ein Unternehmen einigermaßen elegant aus der Affäre ziehen und den eigenen Verlust zum Gewinn für Alle drehen.

Warum Open Source?

Die Gründe für Open Source variieren. Die einen möchten andere Entwickler in ihre Projekte einbeziehen, um so schneller und effektiver arbeiten zu können. Andere möchten sich mit ihrer Arbeit profilieren und manche wollen der Welt einfach etwas zurückgeben.

Es existiert das Gerücht „Mit Open Source lässt sich kein Geld verdienen“. Das ist nur begrenzt korrekt. Man kann Programme durchaus als Open Source freigeben, aber für die kommerzielle Nutzung Lizenzgebühren verlangen. Auch die Dienstleistungen (Support, individuelle Anpassung und Integration, etc.) lassen sich prima in Rechnung stellen.

Open-Source-Programme sind außerdem ein gutes Mittel, seine Fähigkeiten zu demonstrieren. So bitten zwischenzeitlich immer mehr Unternehmen die Bewerber, ihren Unterlagen den Zugang zu den öffentlichen Profilen, wie beispielsweise GitHub, beizufügen.

Wo mache ich Open Source?

Möglichkeiten, eine Software zu veröffentlichen, gibt es viele. Die effizientesten heißen derzeit GitHub und Google Code. Diese Portale stellen eine breite Palette nützlicher Hilfsmittel zur Verfügung. Mit dem Bugtracker können andere Entwickler Fehler melden und Funktionswünsche äußern. Mit dem Wiki können Dokumentationen, Anleitungen, allgemeine Fragen und mehr auf einfache Art und Weise publiziert werden. Besonders hilfreich sind die Versionskontrollsysteme (VCS), auf denen beide Portale aufbauen. Google Code ermöglicht den Einsatz von Subversion (SVN), Git und Mercurial; GitHub beschränkt sich, wie der Name vermuten lässt, auf Git.

SVN und Git sind die am häufigsten genutzten Systeme. Gerade ältere und dadurch etablierte Projekte setzen gerne noch auf SVN. Für neue Projekte wird jedoch eher auf Git gesetzt. Einer der Gründe warum Git als überlegenes Versionskontrollsystem angesehen wird, ist dessen verteilte Natur. Bei SVN gibt es einen zentralen Speicherort und Versionsstand. Um eine Änderung registrieren (commit) zu können, muss man sich mit dem SVN-Server verbinden können. Git kennt diese Anforderung nicht. Jede Git Instanz kann vollständig unabhängig von anderen Instanzen genutzt werden. Durch das Abgleichen von Instanzen wir eine zentrale Datenhaltung ermöglicht.

Wer Software als Open Source zur Verfügung stellt, verfolgt grundsätzlich die Absicht, auch die Arbeit von Dritten, also nicht dem Projekt angehörigen Entwicklern, übernehmen zu können. Hier bietet GitHub viele angenehme Funktionen, die Google Code vermissen lässt. GitHub bietet außerdem kostenlosen Webspace, um beispielsweise Dokumentationen und Beispiele zu veröffentlichen.

Neben Portalen wie GitHub, Google Code, bitbucket, SourceForge, launchpad, Freecode und anderen, besteht die Möglichkeit, mit Applikationen wie beispielsweise Redmine oder Trac ein eigenes Projektmanagement zu betreiben. Wer jedoch gerade in Open Source einsteigt, sollte sich nicht mit der Administration dieser Systeme beschäftigen.

Open Source bedeutet Arbeiten im Team

An den meisten Open Source Projekten arbeiten mehrere Entwickler simultan. Damit diese sich nicht gegenseitig Code überschreiben, hat man vor Urzeiten den Gedanken der Versionskontrolle durch Programme unterstützt. Heute setzen wir überwiegend SVN und das noch mächtigere Git ein. Diese VCS protokollieren, welcher Entwickler wann welche Zeile Code geändert hat. Sie stellen sicher, dass Entwickler 1 nicht versehentlich etwas von Entwickler 2 überschreibt. Sie bieten eine zentrale, stets aktuelle Programmcodebasis.

Dank der Versionskontrolle kann man aber nicht nur feststellen, zu welchem Zeitpunkt ein defektes Stück Programmcode in die Basis eingespielt wurde, man kann diese Änderungen auch direkt rückgängig machen. Unterschiedliche Entwickler arbeiten an unterschiedlichen Versionen desselben Programmcodes. Diese können von Git und SVN meist vollkommen automatisiert zusammengeführt werden. Hat jemand versehentlich etwas gelöscht, kann es jederzeit wieder hergestellt werden.

Ein Versionskontrollsystem (VCS) ist unerlässlich für Projekte mit mehr als ein paar Zeilen Code oder mehr als einem Entwickler. SVN und Git sind des Entwicklers Freunde, nicht dessen Feinde. Wer sich noch nicht mit VCS auseinandergesetzt hat, möge dies zügig nachholen. Es vereinfacht die Zusammenarbeit und bietet Sicherheit, auch vor seiner eigenen Fahrlässigkeit. Wer sich einmal mit Git oder SVN angefreundet hat und die Vorteile erleben konnte, wird selbst in Solo-Projekten nie wieder ohne Versionskontrolle arbeiten wollen.

Open Source goes GitHub

In diesem Artikel werden Konzepte und Abläufe anhand von GitHub gezeigt, da es derzeit die leistungsstärkste und attraktivste Plattform für Open-Source-Projekte ist. GitHub meint seine Parole social coding (gemeinschaftliches Programmieren) ernst. Viele Hürden der Zusammenarbeit haben die Entwickler aus San Francisco ausgemerzt. Ein kleines Beispiel: Entwickler Frank hat einen Fehler in jQuery gefunden und vermag ihn zu beheben. Alles, was Frank tun muss, ist auf den „fork“ (gabeln, eine Kopie erstellen, die einen anderen Weg einschlagen kann) Knopf zu drücken, um in seinem Benutzerkonto eine eigene Kopie von jQuery zu finden. Diese kann Frank nun mit git clone URL auf seinen Rechner laden und den Programmcode in seinem Editor des Herzens öffnen. Frank macht ein paar Änderungen und „committet“ (auf etwas festlegen, den aktuellen Programmstand in der Versionskontrolle festhalten) sie mit einer kleinen Anmerkung, was er überhaupt getan hat. Frank ist mit seiner Fehlerbehebung fertig und schiebt seinen Stand nun mit git push zurück auf die Server von GitHub. In GitHubs Oberfläche klickt er nun noch auf den Knopf „Pull Request“, um das jQuery Team über seine Änderungen zu informieren. Ein Entwickler des jQuery Teams sieht diese Nachricht, begutachtet Franks Änderungen und entschließt sich, Franks Werk zu übernehmen. Der Klick auf den „Merge Pull Request“ Knopf ist alles, was der jQuery-Entwickler zu tun hat.

Mit diesem und einigen anderen Verfahren bietet GitHub ein System, mit dem jeder schnell und einfach zu einem Projekt etwas beitragen kann. Man muss nicht erst Mitglied des Entwickler-Teams werden oder aufwändig Patches erzeugen und in irgendwelche Bugtracker hochladen.

GitHub macht nicht nur das Arbeiten einfacher, es ermöglicht auch eine gewisse Form der Selbstdarstellung. Wer an der JSConf.eu, der größten europäsche JavaScript-Konferenz in Berlin, vortragen wollte, wurde unter anderem auch anhand seiner Projekte auf GitHub bewertet. Dieses Verfahren, ähnlich dem bereits praktizierten Google- und Facebook-Stalking, setzen auch immer mehr Headhunter und Personalbüros. Sie können sehen, was der Bewerber schon entwickelt hat, und Fähigkeiten anhand von Code und nicht nur der Abitursnote von vor X Jahren beurteilen.

jQuery liebt GitHub

Kürzlich hat jQuery sein Plugin-Verzeichnis umgebaut. Die alte, auf den jQuery-eigenenenen Servern gepflegte Datenbank für die Verwaltung von Plugins (mit Versionen, Downloads, Bewertungen, etc.) wurde geschlossen. Statt der alten und umständlichen Oberfläche zur Pflege der Plugins, stellt man heute nur noch eine JSON-Datei in sein GitHub-Repository. Dort gibt man seine Metadaten wie Name, Autoren, Abhängigkeiten zu jQuery-Versionen und CSS-Dateien an. Danach ein Git Tag „v1.0“ anlegen, um den Stand der Version 1.0 zu fixieren. Und zum Schluss die URL des jQuery Plugin Archivs in den Hooks des GitHub-Repositorys speichern. Ab sofort wird jQuery über jede neue Version vollautomatisch informiert. Das lästige Aktualisieren des Plugin-Verzeichnisses nach der Veröffentlichung einer neuen Version ist hiermit ersatzlos gestrichen. GitHub macht es möglich, jQuery setzt es ein.

Wer jQuery-Plugins veröffentlichen will, kommt also an GitHub nicht vorbei. Es sei denn man verzichtet auf Nennung in jQuerys Plugin-Verzeichnis.

Welche Sprache spricht Open Source?

Grundsätzlich tickt das Open-Source-Netz auf Englisch. Wer die Sprache nicht beherrscht, kann seine Projekte auch auf Deutsch beschreiben. Man muss sich dabei jedoch der Tatsache bewusst sein, einen großen Teil der Entwicklergemeinde auszugrenzen. Die internationale Sprache ist nun mal Englisch. Open Source soll für alle sein, also idealerweise auch in der Sprache zur Verfügung gestellt werden, die vom Großteil der Menschen verstanden wird.

Google Translate und andere Programme sind zwar nett, führen aber oft zu sehr verwirrenden Übersetzungen. Wer Englisch nicht selbst beherrscht, sollte mit Deutsch beginnen und sich in seinem Umfeld nach einem Partner umschauen, der die Übersetzung übernehmen kann. Dies gilt übrigens nicht nur für Dokumentation und Webseite. Auch Variablen- und Funktionsnamen müssen Englisch sein.

Wie schreibe ich Code für die Allgemeinheit?

Für andere und mit anderen zu programmieren bedeutet, sich an Konventionen zu halten. Saubere Einrückung, Positionierung der geschweiften Klammern, Leerzeichen zwischen Operatoren und ähnliches wird als Coding Conventions bezeichnet. Für die meisten Programmiersprachen und viele Projekte wurden diese Konventionen niedergeschrieben. Es hilft sich an Dokumenten wie jQuery Core Style Guidelines zu orientieren.

„Intention-Revealing Code“ (Absicht deutlich machender Code) bezeichnet die Vorgehensweise, den Programmcode so selbsterklärend wie möglich zu gestalten. Beispielsweise kann man die Bedeutung von str2uc() bestenfalls erraten, wohingegen stringToUpperCase() klärt, dass ein Text in Großbuchstaben konvertiert werden soll. Ähnlich verhält sich das mit der Variablen var d = 200;, ein etwas ausführlicheres var duration = 200; erstickt jede Frage, jede Suche im Code im Keim. Obwohl ein

window.console && console.log("Hello");

Dasselbe bewirkt wie

if (window.console) { console.log("Hello"); },

ist Letzteres selbst für einen Anfänger verständlich. Ebenso mag ~"hello".indexOf("z"); wie eine elegante Lösung aussehen, ein "hello".indexOf("z") > -1 verlangt aber nicht erst das Nachschlagen des Bit-Operators „Nicht“ und das Wissen um das Zweierkomplement.

Ist Programmcode denn schon alles?

Zur Veröffentlichung eines Projektes gehört mehr als nur der reine Code. Die wichtigsten zu liefernden Dinge sind Dokumentation und Beispiele.

Es gibt mehrere Ebenen von Dokumentation. Die unterste und einfachste Schicht stellen simple Kommentare im Quellcode dar. Mittels Kommentaren sollte erklärt werden, welche Variablen welchen Hintergrund haben, welche Methoden wozu dienen und warum man sich für eine bestimmte Implementierung entschieden hat. Hat man beispielsweise ein paar Zeilen eingebaut, um dem Internet Explorer 8 gerecht zu werden, darf der obligatorische Kommentar „damn IE8“ nicht fehlen. Auf dieser untersten Ebene helfen wir anderen Entwicklern, den Einstieg in die Fehlerbehebung und Weiterentwicklung unserer Programme zu erleichtern. Ausreichend dokumentierte Programme haben insgesamt gerne mal so viele Zeilen Kommentare wie Zeilen Code. Wichtig dabei ist aber, nur Konzepte und Probleme zu erläutern, die nicht bereits aus dem „Intention-Revealing Code“ hervor gehen. Also im besten Fall lediglich Hinweise auf Verfahrensweisen, für welchen Browser etwas bestimmtes gemacht wird, Links zu Spezifikationen und Dokumentationen.

Die API-Dokumentation stellt die nächste Stufe dar. API (Application Programming Interface) steht für Programmschnittstelle und beschreibt wie bestimmte Funktionen und Module benutzt werden können. „Was macht die Funktion?“, „Welche Parameter werden erwartet?“ und „Was gibt die Funktion zurück?“ sind Fragen, die in dieser Ebene der Dokumentation beantwortet werden. API-Dokumentation kann man aufwändig selbst bauen, oder von Hilfsmitteln wie JSDoc Toolkit automatisiert erstellen lassen.

Die dritte Stufe der Dokumentation, die Projekt-Dokumentation, beschreibt die Zusammenhänge und Hintergründe des gesamten Komplexes. Hier beschreibt man wie Modul alpha mit Modul bravo kommuniziert und in welchen Situationen der Einsatz von Modul charlie sinnvoller wäre. Hintergründe zum Werdegang des Projektes, Informationen über die Autoren, etc. lassen sich hier bestens unterbringen.

Mit der Projekt-Dokumentation geben wir also einen Überblick über das Ganze. Mit der API-Dokumentation beschreiben wir die Integration. Mit den Kommentaren beschreiben wir die Funktionalität im Detail. Keine der drei Dokumentationsstufen kann eine der anderen ersetzen. Das Verfassen der Dokumentation mag eine mühsame und unliebsame Arbeit sein, sie ist aber für den Erfolg eines Projektes absolut notwendig.

Eine Dokumentation sollte einen schnellen Überblick über das Projekt ermöglichen. Die Nutzung und Integration sollten so detailliert wie möglich erläutert werden, damit die Entwickler nicht unnötig viele Rückfragen beantworten müssen. Erst wenn ein dem Projekt fremder Entwickler den Einstieg in die Nutzung des Projekts findet, ist ein ausreichendes Maß an Dokumentation erreicht.

Wie präsentiere ich mein Werk im Web?

Das Auge isst mit – auch bei Webseiten für Software. Man braucht sich jedoch nicht verkünsteln. Ein schlichtes, modernes Design ist vollkommen ausreichend. Wichtiger als aufwändige Formen, Schatten und Hintergrundbilder ist die saubere Darstellung von Beispielcode. Der Einsatz einer monospace Schriftart und die Hervorhebung der Syntax sind hier die entscheidenden Dinge. Um Javscript, HTML und CSS syntaktisch hervorzuheben, bietet sich der Einsatz von prettify.js an.

GitHub bietet mit gh-pages ein kostenloses Hosting von statischen Dokumenten. HTML, CSS und JavaScript können so mühelos zur Verfügung gestellt werden. Wird die Seite etwas aufwändiger, bietet sich der Einsatz des in GitHub integrierten Templating Tools Jekyll an. Hiermit können komplexere Strukturen durch Vorlagen umgesetzt werden. Auch die Konvertierung von Markdown und Textile wird hiermit automatisiert. Für den schnellen Start bietet GitHub eine Oberfläche zur automatisierten Generierung einer solchen Dokumentationsseite. Diese automatisch im Netz abrufbaren Seiten werden in einem separaten Zweig (Git Branch) im selben Git-Repository wie das eigentliche Programm verwaltet. Wer sich die Arbeit sparen will, die beiden Git Branches zu synchronisieren, kann einfach den master entfernen und gh-pages als „master“ benutzen. So würden alle Freigaben sofort abrufbar. Mit gh-pages lassen sich also Dokumentation und Beispiele direkt über GitHub veröffentlichen.

Lauffähige Beispiele zum Experimentieren

Beim Programmieren wiederholt sich die Kindheit: Durch Spielen lernen wir am einfachsten.

Lauffähige Programmbeispiele zeigen die Funktionalität eines Projekts und spielen damit die Rolle der Appetithäppchen. Anhand dieser Demos kann ein Besucher schnell in Erfahrung bringen, ob ein Projekt für ihn einsetzbar ist. Außerdem kann man Beispiele einfach kopieren und anpassen, wodurch die Integration auf „Anpassung an eigene Bedürfnisse“ erleichtert wird. Das Gehirn funktioniert besser mit konkreten Beispielen, als mit abstrakten Erklärungen.

Lauffähige Demos lassen sich wunderbar über jsFiddle veröffentlichen. Hier hat der Benutzer sogar die Möglichkeit, direkt in den Beispielcode einzugreifen und mit dem Projekt zu experimentieren. Diesen Weg gingen beispielsweise die Entwickler von highcharts. Sie erlauben hierdurch das Erforschen der doch recht komplexen Diagramm-Thematik.

jsFiddle bietet eine Oberfläche, in der auf einen Blick HTML, CSS und JavaScript bearbeitet werden können. In einem vierten Fensterchen sieht man das Resultat der drei vorhergehenden. In der linken Seitenleiste kann man JavaScript-Bibliotheken wie jQuery oder MooTools hinzufügen, andere externe Scripts laden und ein paar weitere Einstellungen vornehmen. Die Texteditoren für HTML, CSS und JavaScript vereinfachen das Lesen des Codes durch Syntaxhervorhebung und rudimentäre Fehlerkennzeichnung. Alles in allem bietet das System eine nette Spielwiese, um schnell und einfach JavaScript und CSS auszuprobieren.

Wer mit jsFiddle nicht gleich warm wird, kann sich auch noch jsBin von Remy Sharp anschauen.

Wann darf ich veröffentlichen?

Open Source ist eine wunderbare Geschichte, um andere Entwickler für ein Projekt zu begeistern. Man sollte sich aber stets der Tatsache bewusst sein, dass Menschen lieber auf einen fahrenden Zug aufspringen möchten, als zuerst das Getriebe der Zugmaschine zu reparieren. Das bedeutet, dass das zu veröffentlichende Projekt funktionieren und über eine anfängliche Dokumentation verfügen sollte.

Das Projekt ist online, was nun?

Das Projekt ist jetzt zwar für jedermann zugänglich, aber niemand kennt es. Hat man ein jQuery-Plugin geschrieben, sollte man es in jQuerys Plugin-Verzeichnis einstellen. Hat man eine HTML5-Funktionalität für ältere Browser entwickelt, liegt das Nennen bei Modernizr nahe. Nahezu jede Software, die durch Plugins erweitert werden kann, verfügt über solche Verzeichnisse.

Im zweiten Schritt könnte man nach Fragen suchen, die mit dem neuen Projekt beantwortet werden können. Mit hoher Wahrscheinlichkeit wurde über das Thema bereits in irgendwelchen Blogs diskutiert oder Fragen auf beispielsweise Stackoverflow gestellt. Hier kann man sein neues Programm prima als Allheilmittel einstreuen. Aber keinesfalls zum Spammer werden! Es gilt nicht nur Links zum eigenen Projekt ins Netz zu streuen, sondern genau auf die einzelnen Fragen einzugehen.

Natürlich kann man auch seine bestehenden Kanäle wie Twitter, Google+ und das eigene Blog befüllen. Möglicherweise zeigt auch eine etwas größere Nummer der JavaScript-Szene Interesse am Werk und ist bereit ein paar Sätze in sein Blog zu stellen. Je nach Originalität des Werks, ist so eine Erwähnung durch JavaScript-Rockstars gar nicht mal abwegig. Egal zu welchen Mitteln zur Werbung man greift, man darf es nicht übertreiben. Gerade das Antworten auf Systemen wie StackOverflow muss im Rahmen bleiben, da Zugangskonten sonst gesperrt werden könnten.

Was erwartet mich nach der Veröffentlichung?

Sobald das Projekt an Fahrt gewinnt und Entwickler vom Einsatz überzeugt sind, rollen die ersten Fehlermeldungen (Bug Reports, Issues) herein. Auf den bei GitHub veröffentlichten Projekten wird mit der Meldung sehr häufig auch die Lösung mitgeliefert, da die Plattform echtes Social Development erlaubt. Bei Google Code bekommt man aber auch ab und an Lösungsvorschläge geliefert. Je mehr Entwickler das Projekt benutzen, desto mehr Funktionswünsche tauchen auf. Auch hier wird gerne mal die komplette neue Funktionalität mitgeliefert. Die häufigste Tätigkeit auf GitHub wird es sein, so genannte Pull Requests (Anfragen zur Übernahme von Änderungen) zu kontrollieren und (automatisiert) ins Projekt zu übernehmen.

Projekte müssen nicht im Wochentakt um neue Funktionen erweitert werden. Wenn ein Programm eine gewisse Reife bekommen hat, besteht die Hauptaufgabe darin, ab und an die Abhängigkeiten (z.B. jQuery) zu kontrollieren und zu aktualisieren. Es bricht also erst mal keine wirkliche Arbeitsflut auf den Autor des Projekts herein.

Man sollte die Projektpflege aber auch nicht unterschätzen. Gefragte Open-Source-Projekte werfen durchaus Fragen bei Entwicklern auf, die von selbigen gerne per E-Mail gestellt werden. Nehmen bestimmte Fragen überhand, ist das ein deutliches Zeichen, die Dokumentation zu erweitern. Auch Feature-Requests (Funktionswünsche) tauchen mal ohne fertigen Programmcode auf. Nicht jeder Wunsch kann oder muss erfüllt werden. Jeder muss selbst entscheiden, was Sinn für die Allgemeinheit macht. Manche Funktionswünsche sind als separate Erweiterung deutlich besser platziert, als alles in den Kern des Projekts zu integrieren.

Muss ich meine eigene Suppe kochen?

Die meisten Programmierer schreiben lieber neue Software, als sich um die Wartung und Erweiterung bestehender Projekte zu kümmern. In vielen Bereichen führte diese Vorliebe zu einer Fülle von gleichartigen Tools. Konkurrenz belebt das Geschäft ist aber nicht immer richtig. In vielen Fällen haben wir zwar nun die Wahl zwischen zehn Bibliotheken – jedoch ist das nur all zu oft die Wahl des kleineren Übels, denn jedes Projekt hat seine eigenen Schwächen und Probleme.

Oft gibt es für Problem X bereits Software Y. Warum also nicht einfach den Programmierern von Software Y unter die Arme greifen? Warum das Rad neu erfinden, wenn Software Y einfach nur Funktion Z nicht kann? Programmierer anderer Projekte sind auch nur Menschen und bauen (in aller Regel) auf die Hilfe aus der Community.

Der Entwicklerkreis eines bestehenden Projekts mag von außen gerne mal als geschlossene Gesellschaft wahrgenommen werden. Wer jedoch sein Können und Engagement unter Beweis stellt, findet sich selten vor geschlossenen Toren wieder. Schließt euch anderen an, um etwas bestehendes besser zu machen!

Korrekturgelesen von

• @tobiastom wegen Inhaltlichem (#selfhtml, iOS-Gedöns)
• Uwe Tews wegen Inhaltlichem (Smarty Entwickler)
• @quellebouille wegen Sprachlichem (#selfhtml, Computer-Linguistik)
• @kokopelliabq wegen Sprachlichem (Mutter, Sprachliches)

Rodney Rehm tummelt sich seit über zehn Jahren im Web Development. Als so genannter Full Stack Developer beherrscht er Frontend (HTML, CSS, JavaScript, UX), Backend (PHP, MySQL, PostGreSQL, …) und ein wenig Systemadministration. Durch gallestro.de arbeitet er hauptsächlich an Intranet Lösungen in den Bereichen Workflow und Business Intelligence. Als Freelancer kann er auch Ihr Projekt unterstützen. In der Open Source Liga spielt er bei Smarty PHP Template Engine mit, veröffentlichte unter anderem URI.js, jQuery Context Menu und Apples plist Format in PHP.
@rodneyrehm rodneyrehm.de