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.

Who hasn't ever started writing his own Framework/CMS? It is considered best practice for learning purposes, but going through all the security stuff can be stressful and boring at the same time. That's where most devs start to contribute to big Open Source-projects like Typo3 or the Zend Framework, because they are already experienced working with it and yet evolving another system on the market or even getting people to contribute seems like an unachievable task. Instead of wasting his time on yet another ACL implementation, the developer is taking part in making a software become even better, no matter if he delivers new features, reports / fixes bugs or works on documentation (another, yet an often underestimated part of contribution). It is also worth noting that every single Blog-entry and every HowTo thats put on the web also is a great deal of contribution that helps the software spreading. Beginners articles are important to put on the web since every one of us had it's beginnings and these are the sort of articles where many people decide to either use the software for a certain project or not.

As you might see, this article is not only a guide on contributing bugfixes, but also I want to motivate you to just give it a try.

... on Zend Framework

Having spent almost a year at the IRC support channel, I can tell they're really fun guys to hang around with. Of course, the Framework itself developed into a great piece of software. I do not want to discuss the up or downsides of a use-at-will framework, neither I want to recommend it over {put your favourite software here}. But what I can talk about is a little summary of the support channel's chatlogs. The widely annouced channel (which is #zftalk on Freenode) includes all kinds of concerns. One kind of people finds bugs, the other do have really clever ideas on improvements, but when you ask them to contribute its all the same: they either think it takes years to get into it, the others think they might be "not good enough for this". We sure won't force or threaten people to contribute, but what I can do is taking the fear out of it and demystify the thing, so later you might see that its actually just a few minutes to spend. Let me just loose a few words to the latter ones before we get into it: You can't destroy anything, and every idea of yours can also lead to a great improvement either realted to your concern or in a completely different area. We're glad that you take your time, even if you are completely new to ZF. Some beginners concerns already caused developers to write guides and articles that are still around and are linked at times in #zftalk...

... on contributing to Zend Framework

Contributing any code to ZF requires signing the CLA, which is an agreement that both you have the right to share any code you supply, and that you will not patent that code. This is to ensure that the frameworks codebase remains business friendly, and free to use for everyone. In fact you have to actually sign a paper, having done this you can just scan and mail or fax it. This is an important step, and none of your code will be used in any official package unless you did this.

The next step will be reading the coding & subversion standards. If you already had a look at actual ZF components code you should be familiar with the standards. Once you took a short insight (you probably wont be able to just remember all of this at once), you can check out the official SVN repository. Notice, that you, even having signed the CLA and being confirmed, do not have commit rights. So you might now ask yourself how to contribute then? All magic is taking place in the bugtracker, ZF's official Jira. All bug tickets, additions and improvements are filed as tickets here. So if you find a bug, report it here, and soon there will be a discussion in the comments section of a ticket.

Mostly all of these people, being listed by their reallife names, are also to be found on different names in the support channel, so feel free to ask them any ticket-related stuff.

The code itself will be submitted as a patch file (svn diff > patchFile), and uploaded in the Jira-Ticket. This might also be done by people who do have commit rights, but one might not be sure how to fix a problem, or any question might be left. This method of code management then leaves it to the original package developer to decide whether a change should be made or it should be thought over again (might have side effects on other packages and so on).

The last yet very important point is unit tests. ZF makes heavy use of them and so should you. The best you can do is report bugs as failing tests with a short description, fix them with the code diff and then deliver them with working tests.

... in closing

As you might now see, once the problems and the contaminated areas are visible, you can pull out your armory and kill the bugs within minutes. The contribution of new packages for the ZF are made in the Wiki, filed as proposals that later get discussed by the community review team, but I might do another article about that one as its a not so trivial workflow. Whenever you fix a bug or deliver an improvement you will be listed on the official Jira´s Overview page of top contributors. Can you make it to the top? ZF´s bug hunting days are the place for many contributors to join the battle on a shirt, but you might also see that being an active contributor on an open source project might be a good point of interest on your CV.

Having run out of things to say, I want to call all the devs out there to give it a try. A short quote of Ben Scholzen (ZF Core developer): "I code whenever I feel like it": In closing, remember that neither having an account on JIRA nor Signing the CLA ties you in to any minimum commitment, and you can do as much or as little as you are comfortable with. Just pick the level which feels right for you.

As an example, I will use PHProjekt 6. The project is particularly suitable for demonstration purposes as it has a logging infrastructure for function calls, but does not log SQL statements.

It features a neat interface that let you find errors even quicker, a clear commandline interface and much better performance, it's almost seven times faster than the 0.1.x release.

You can get it via pear, just do

pear channel-discover pear.phpunit.de

pear config-set preferred_state beta

pear install phpunit/PHP_CodeBrowser

or you can check out the from github, just visit http://github.com/mayflowergmbh/PHP_CodeBrowser or just try

git clone git://github.com/mayflowergmbh/PHP_CodeBrowser.git

 Here are some pictures to give you an impression of what it looks like

This is the overview page

And this is how the real code browser looks like.