Dembelo als Open-Source-Software

Dembelo Entwicklungsumgebung Dembelo Entwicklungsumgebung

Darüber, wie Freiheit und Gemeinschaft Projekte umsetzt.

Ein Vorwort

von Tina Giesler

Wieso Open Source? Weil nur als Open Source die Entwicklung der Software zum Selbstzweck wird.

Üblicherweise werden Webapplikationen, Portale und Software von jemandem beauftragt, der keine Ahnung von Technik hat und nur weiß, wie es „aussehen“ soll. Die Beauftragung geht dann an eine Agentur, die nie mit dem fertigen Produkt wird arbeiten müssen aber daran interessiert ist Folgebeauftragungen zu erhalten. Die Arbeit dieser Agentur kann in der Regel nicht von Externen überprüft werden, so dass der Auftraggeber nie erfährt, für was für einen Mist er da Geld bezahlt hat, wobei er in der Regel auch ganz offiziell den Mist bekommt, den er in seiner Unkenntnis der Technik beauftragt hat.

Open Source hat diese Probleme nicht, es ist Software die sich sozusagen selbst beauftragt, baut der eine Mist, kann der andere feststellen, dass es Mist ist und nicht nur meckern, sondern es direkt besser machen. Es ist wie mit dem Gang zur Kirche, im eigenen Hof läuft man rum wie Sau, aber sobald man unter Leute geht, kämmt man sich die Haare, putzt die Schuhe und zieht eine Hose ohne Löcher an. Paradoxerweise bezahlen die meisten Leute dafür, dass Techniker den Code hinter verschlossenen Türen in Turnhosen rumgammeln lassen, statt zu verlangen, dass er vorzeigbar ist.

Dembelo hat nicht die Ressourcen um irgendwelchen Agenturen hinterher zu rennen, daher entwickeln wir Open Source, Nutzen das Wissen und die geleistete Arbeit ungezählt vieler anderer Entwickler und lassen das Projekt sich selbst verwalten, den es sind eben die Techniker die Ahnung von Technik haben. Gute Software sieht nicht nur an der Oberfläche gut aus, sie braucht auch sauberen Code und eine gutes Konzept und den bekommt man nur, wenn man den auch sehen kann. Wir fordern das Ego und die Findigkeit von Programmieren heraus und können so eine Entwicklung stemmen, die sonst unbezahlbar gewesen wäre.

Der folgende Bericht  ist ein Abriss unserer Gedankengänge und Entscheidungen, die wir bisher für die Software getroffen haben und ein Ausblick auf das, was wir noch machen wollen und wie Dembelo funktionieren soll.

Der Aufbau eines nachhaltigen Open-Source-Projekts

Ein Bericht von Chefentwickler Michael Giesler

Wenn man heutzutage ein Open-Source-Projekt starten will, bleiben einem im Grunde nicht allzu viele Gestaltungsmöglichkeiten. Webbasiert soll es sein, damit es plattformunabhängig auf allen Systemen von Desktop-PC über Mac bis hin zu Tablet-Rechnern und Smartphones läuft. Und ja auch irgendwie auf E-Readern, die haben ja alle Browser integriert.

Dann fragt man sich, welcher Programmiersprache man den Zuschlag gibt. JavaScript und Node.js? Nah, es ist zwar irgendwie cool, in serverseitigem JavaScript mit einem Zweizeiler einen Webserver starten zu können, aber das ganze Ökosystem wirkt auf mich derzeit noch viel zu neu und viel zu sehr im Fluss, als dass man damit nachhaltige Software entwickeln möchte. Java? Python? Zu träge, zu kleine Community. Bleiben wir beim meistverbreiteten im Webumfeld: PHP. Da stören dann auch meine 15 Jahre Erfahrung mit PHP nicht – Nur weil man vorbelastet ist, heißt das nicht, das man nicht Recht hätte. Das Argument, dass PHP sehr stark verbreitet ist, spielt bei Open Source eine wichtige Rolle, ich will es ja nicht selbst programmieren, ich will Leute finden, die mitmachen. Außerdem sollte der Projektleiter den Code der Mitstreiter beurteilen können, es ist also nicht nur eine Bauchentscheidung PHP zu nehmen.

Die Verwendung von git ist unumgänglich, github ist de-facto-Standard, das Repository dort auch schnell eingerichtet. Und schon kommt Dembelo der Open Source Gedanke zugute: Die offene Frage nach der Lizenz, wird von Stephan Kreutzer kompetent mit AGPL beantwortet, als proprietäre Software hätten wir kostenpflichtig einen Anwalt konsultieren müssen.

Als IDE ist seit geraumer Zeit PHPStorm das Maß der Dinge, nachdem Eclipse erst seinen Vorsprung und dann einiges an Boden verloren hat.

Nach all diesen Dingen sitzt man dann vor einem leeren Editorfenster. Was fehlt? Ach, ja – der Quellcode. Aber bevor man sich dann doch mal zum Programmieren herablässt, erinnert man sich, dass sich in der PHP-Welt ja mittlerweile eine Paketverwaltung namens Composer etabliert hat. Auch die Frage nach dem Framework tut sich auf.

Ziemlich zu Beginn meiner beruflichen Laufbahn als PHP-Entwickler war es das damals neue Zend Framework 1, das mich vom Script Kiddy zu einem ernsthaften Entwickler hat werden lassen. Zend Framework 2 jedoch konnte mich nie überzeugen. Man kommt dort aus dem Schreiben von Dummy-Klassen und Konfiguration kaum heraus, bevor es an den eigentlichen Code geht – und während Version 1 noch in vielen Projekten lebt, sind die Entwickler schon auf dem Weg zu Version 3. Bis die aber fertig ist kann Dembelo nicht warten, also wird es Zeit, sich mal nach etwas anderem umzuschauen: Symfony 2 sticht da ins Auge. Allerorten liest man, das dieses Framework quasi State of the Art ist. Gut. Machen wir.

Als nächstes kam uns die Idee, dass das Projekt zur Entwicklung auf Vagrant basieren sollte. Das abstrahiert ein wenig die Serveradministration. Mit dem git-Repository, ein wenig Konfiguration, die über Puppet geregelt wird und dem Befehl „vagrant up“ hat man auf einem beliebigen Rechner das Projekt fix und fertig in einer virtuellen Machine laufen. Und schon kommt einem ein anderes offenes Projekt sehr gelegen: irmantas‘ symfony2-vagrant. Und schon hat man die Symfony2-Defaultseite im Browser. Das im Entstehen befindliche Webportal ist also fast fertig.

Eigenen Quellcode hat man immer noch nicht geschrieben. Aber erstmal wird mittels Composer-Paket Twitter Bootstrap integriert. Das Anlegen einiger Controller und das Erstellen einiger Twig-Templates bei der Umsetzung der Mockups geht zwar leicht von der Hand, die Eigenleistung hält sich aber immer noch in Grenzen. Selbst die Implementierung des Logins und der Authentifizierung ist nur ein wenig Konfiguration und eine Handvoll Codezeilen anhand der Symfony-Doku.

Als nächstes soll das Lorem Ipsum von den Templates in eine Datenbank verschoben werden. MySQL war neben PostgreSQL für mich die letzten 15 Jahre das Maß aller Dinge – Zeit für neues. NoSQL wollte ich mir ohnehin schon immer näher anschauen und scheint als Dokumentendatenbank für Dembelos Zwecke ohnehin besser zu passen: Die einzelnen Textknoten sind als Dokumente zu verstehen, an denen inhomogene Metadaten hängen können. Hier stand erstmals ein wenig Recherche an – nach kurzem Querlesen des Internets, entscheiden wir uns gegen Redis und für MongoDB, und freut sich über das Lorem-Ipsim-Composer-Paket.

Nun hat das Projekt die nächste Stufe des „fast fertig“-Seins erreicht – nach wie vor ohne ernsthaften selbstgeschriebenen Code. Da man auf das Schreiben eines hübschen Backends zur Verwaltung der Daten, nun auch keine Quellcode Zeit vergeuden will, geht es nochmal in die Recherche. ExtJS könnte ein Backend zwar quasi out-of-the-box zur Verfügung stellen, die undurchsichtige Lizenzierung war ein KO-Kriterium. Open Source scheint bei Sencha nicht ganz oben auf der Agenda zu stehen. Webix überzeugt da schon eher. Auch hier gibt es neben der GPL-Variante eine kostenpflichtige Version, doch ist dies im Gegensatz zu ExtJS klar kommuniziert, und beide Versionen unterscheiden sich nur in einigen Gimmicks. Mit einem großen Konfigurationsobjekt entsteht so ein schickes Backend. In den dazugehörigen PHP-Controllern entsteht erstmals ein wenig selbstgeschriebener Code. Die Sektkorken knallen.

Überwältigt von der unerwarteten Größe des Projektes muss jetzt aber eine Projektverwaltung und eine Dokumentation her. Am nächstliegenden sind hier sicherlich die Issues und das Wiki von github zu benutzen. Die Issues haben Schlagworte und können in Meilensteine strukturiert werden – das sollte bis auf weiteres reichen.

Auch ist jetzt der letzte Zeitpunkt, sich um die Code-Qualität zu kümmern, bevor das Konstrukt über den Entwickler zusammen bricht. Unittests werden mit PHPUnit umgesetzt, Codesniffer sorgt für die Einhaltung grundlegender Konventionen. Das faszinierende an Open Source sind die Möglichkeiten, die sich durch die Freiheit erschließen. Musste man früher noch selber einen Buildserver wie Hudson/Jenkins hosten und administrieren, sind heutzutage Services wie travis-ci.org gratis für Open Source-Projekte und direkt an github angebunden. Bis die Konfiguration stimmt, ist Build #12 erreicht.

Zu diesem Zeitpunkt, hat sich eine gewisse Routine entwickelt. Man plant agil in relativ kurzfristigen Meilensteinen die nächsten Schritte, implementiert in git-Branches, und mergt diese über Pull-Requests in den Master. Ein Projektforum nimmt langfristige Themen, Gedanken und Ziele auf, ein Burndown Chart motiviert zum Abarbeiten der Tickets, bei Slack wird alles mögliche Diskutiert.

Aus einer kruden Idee, ist ein wachsendes Projekt geworden, vernetzt mit vielen anderen, von der Gemeinschaft und Freiheit profitierend und im Bestreben, selber etwas zu dieser Gemeinschaft beizutragen, die einem den Start überhaupt erst ermöglicht hat.

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht.


*