Mitarbeit am ZendFramework

… über die Mitarbeit an Open-Source-Projekten

Wer hat nicht schon einmal damit angefangen sein eigenes CMS/Framework zu konzipieren? Mittlerweile wird es ja schon aus Lerngründen als "best practice" angesehen, jedoch den ganzen Sicherheitskram von vorne durcharbeiten zu müssen kann genauso stressig wie langweilig sein. Das ist der Punkt wo die meisten Entwickler anfangen zu großen Open-Source-Projekten wie dem ZF oder Typo3 beizutragen. Vielleicht haben sie ja schon einmal damit gearbeitet, und noch ein weiteres CMS/Framework auf dem Markt durchzusetzen, oder gar Entwickler zum beisteuern zu bringen, scheint einem fast nicht machbar. Anstatt sich wieder mit einer eigenen ACL-Implementierung zu beschäftigen, hilft der Entwickler der Software besser zu werden, egal ob er nun Bugs meldet / löst, Erweiterungen oder Dokumentation entwirft (ein weiterer, oft unterschätzter Teil der Mitarbeit). Ebenfalls möchte ich darauf hinweisen, dass jeder einzelne Blog-Eintrag sowie jedes HowTo im Web ebenfalls ein Beitrag an der Software ist. Anfänger-Tutorials im Netz sind wichtig, da jeder von uns in ein neues System erst einmal reinkommen muss, und anhand vieler Tutorials Software für diverse Projekte auch beurteilt wird. Wie man nun vielleicht lesen kann, soll dieser Artikel nicht nur das Beitragen zum ZF zum Thema haben, ich möchte genauso jeden Entwickler dazu ermuntern es einfach einmal auszuprobieren.

… über das Zend Framework

Nach fast einem Jahr im IRC-Support-Kanal kann ich sagen, dass die Jungs wirklich gut drauf sind. Natürlich hat sich das Framework nach einiger Zeit in eine gute Software entwickelt. Ich möchte hier nicht die Vor- wie Nachteile eines Baukasten-Frameworks erörtern, noch möchte seine Benutzung vor {dein bevorzugtes Framework} empfehlen. Doch worüber ich berichten kann ist eine kleine Zusammenfassung der Chatlogs des Kanals. Der weit bekannte Kanal (#zftalk im Freenode-Netz) beinhaltet alle möglichen Arten von Anliegen. Der eine Nutzer findet Bugs, ein anderer hat richtig clevere Ideen zu Verbesserungen von Komponenten, doch wenn man sie um etwas Mitarbeit bittet ist es immer das gleiche: Sie denken entweder, dass es Jahre dauert hier einzusteigen, oder dass sie "nicht gut genug" wären um etwas zu leisten. Selbstverständlich zwingen wir hier niemanden zur Mitarbeit, doch lasst mich den Vorgang etwas entmystifizieren sodass am Ende klar wird: es sind wirklich nur ein paar Minuten. Doch bevor es losgeht, noch ein paar Worte zu letztgenannter Sorte der Entwicklern: Man kann nichts kaputt machen, und jede einzelne eurer Ideen kann zu einer hervorragenden Verbesserung leiten, ob nun bezüglich eures eigentlichen Anliegens oder auf einem ganz anderen Bahnhof. Wir sind froh, dass ihr euch die Zeit nehmt, selbst wenn ihr komplett neu im Bereich ZF seid. Einige Anliegen von Anfängern hat Entwickler dazu gebracht Themen relevante Blog-Einträge zu schreiben, die auch nach einiger Zeit noch im Support-Kanal verlinkt werden.

… am ZF mitarbeiten

Die Mitarbeit in Form von jeglichem Code erfordert das Unterschreiben der CLA, in welcher man offenlegt, dass man jeglichen beigetragenen Code teilen kann, und nicht patentieren darf. Das dient der Geschäftsfreundlichkeit der Codebase bei, und kommuniziert, dass es jeder frei benutzen darf. Genaugenommen muss man einen Vertrag unterschreiben, welchen man später druckt und entweder faxt oder mailt. Dies ist ein wichtiger Schritt, und keinerlei Code wird von unsignierten Entwicklern in offiziellen Paketen verwendet. Als nächstes sollte man sich die Coding- wie Subversion-Standards durchlesen. Wer schon den Code von ZF Komponenten gesehen und sie grob überflogen hat (man wird sich all das nicht das nicht alles auf einmal merken können), kann man das offizielle SVN-Repository aus checken. Bemerkung: Auch nach dem Unterschreiben der CLA hat man noch keine beschränkten Commit-Rechte, aus denen später der Code "zusammen-gemergt" wird. Wo wird denn dann nun gearbeitet? Die ganze Magie hinter dem Bugfixing, um welches es hier gehen soll, findet im Bugtracker statt, ZF´s offizielles Jira. Alle gelösten Bugs wie Erweiterungen werden hier als Tickets behandelt. Wer also einen Bug findet, registriert sich hier um ihn in einem Eingabeformular auszuformulieren. Ein wenig später wird hier, sofern notwendig, in Form von Kommentaren die Notwendigkeit sowie das Vorgehen diesbezüglich diskutiert.

So ziemlich alle hier namentlich gelisteten Personen sind auch unter diversen Synonymen im IRC wiederzufinden, wo ebenfalls Ticket bezogen diskutiert werden darf. Der Code um das Problem zu lösen wird später als eine Patch-File ins Ticket hochgeladen (svn diff > patchFile). Das kann auch von Leuten mit Commit-Rechten passieren, weil man sich vielleicht bei der Vorgehensweise nicht ganz klar ist oder noch Fragen offen sind. Diese Methode des Code-Managements lässt dem ursprünglichen Autor einer Komponente die Möglichkeit zu Entscheiden ob eine Änderung nun vorgenommen werden soll, oder ob Fragen noch zu klären sind (es könnte mit anderen Komponenten kollidieren oder ähnliches).

Der letzte und wichtige Punkt sind unit-tests. ZF macht hier sehr großen Nutzen, was auch der Entwickler tun sollte. Die besten Bugs werden als fehlschlagende Tests mit einer kurzen Fehlerbeschreibung formuliert, und mit einem kurzen Code-Diff und zugleich wieder funktionierenden Tests gelöst.

… Schlussendlich

Wie man vielleicht sehen kann, sobald alle kontaminierten Bereiche sichtbar sind, kann man den Insektenschutz auspacken und die Bugs innerhalb von Minuten ausmerzen. Das Beitragen von neuen Komponenten findet im Wiki in Form von "Proposals" statt, welche später vom Community-Review (Kern-Entwickler des ZF´s) beurteilt werden. Dieser Vorgang ist nicht trivial und umfassender, weshalb ich hier vielleicht einen Folgeartikel nachreichen werde. Wer immer einen Bug löst oder eine Erweiterung abliefert wird im Jira bzw. dessen Übersichtsseite gelistet. Kannst du es dort hin schaffen? Der Platz um dies herauszufinden sind ZF´s offizielle Bug-Hunting-Days, bei denen es jeden Monat ein Shirt zu gewinnen gibt. Als eine Fußnote möchte ich hinzufügen, dass sich die aktive Mitarbeit an einem Open-Source-Projekt in jeder CV gut macht.

Nachdem ich nichts mehr zu sagen habe, möchte ich noch einmal alle Entwickler da draußen aufrufen es auszuprobieren. Ein kurzes Zitat von Ben Scholzen (Kernentwickler des ZF): "I code whenever I feel like it": Schlussendlich zwingt einen weder die CLA noch der Jira-Account zu irgendwas. Sucht euch das Level oder die Komponente aus, auf welcher es sich für euch am besten arbeiten lässt.