2.5 Selbst etwas beisteuern 
Da es sich bei eZ Components um ein Open-Source-Projekt handelt, sind Sie natürlich herzlich eingeladen, ebenfalls einen Beitrag zu leisten. Dies ist auf verschiedenste Weisen möglich und immer gerne gesehen. Außerdem sind es Ihre Beiträge, von denen Open-Source-Software im Endeffekt lebt. Ob und wie viel Sie beisteuern wollen, bleibt natürlich Ihnen selbst überlassen. Die Möglichkeiten reichen vom einfachen Melden eines Fehlers über das Erweitern der Dokumentation bis hin zum Beisteuern kompletter Komponenten. Im Folgenden stellen wir einige Möglichkeiten vor und geben Ihnen Anhaltspunkte, wie zu verfahren ist.
2.5.1 Fehler melden 
Fehlerfreier Code existiert praktisch nicht; und selbst in der theoretischen Informatik ist der Nachweis von Fehlerfreiheit kompliziert. Obgleich alle eZ Components ausführlich getestet sind, kann es also immer wieder passieren, dass sich ein Fehler einschleicht und Ihnen über den Weg läuft. Sowohl um Ihnen möglichst schnell bei der Beseitigung Ihres Problems zu helfen, als auch um den eZ Components-Entwicklern zu helfen, das Projekt zu verbessern, ist es wichtig, gefundene Fehler zu melden.
Um einen Fehlerbericht (Bug-Report) einzureichen, müssen Sie sich vorab im eZ Components-Issue-Tracker (http://issues.ez.no/ProjectSelect.php?Id=1) registrieren. In diesem System, das übrigens auf eZ Components basiert, werden alle Fehlerberichte, Aufgaben und Erweiterungsanfragen verwaltet und verfolgt, sodass Sie sichergehen können, dass Ihr Fehlerbericht nicht untergeht. Außerdem können Sie hier eigene Ideen als Features-Request einstellen. Sie sollten diese aber vorher auf der eZ Components-Mailingliste (siehe Abschnitt 2.4.5, »Support«) mit den Entwicklern diskutieren.
Nachdem Sie sich erfolgreich für die Benutzung des Issue-Trackers registriert haben, sollten Sie zuerst mit Hilfe der Suchfunktion des Systems nachsehen, ob bereits jemand den gleichen oder einen ähnlichen Fehler gemeldet hat. Ist dies der Fall, teilen Sie bitte Ihre Erfahrungen als Kommentar zu diesem Fehlerbericht mit. Verfahren Sie dabei ebenso wie bei der Erstellung eines neuen Fehlerberichts, worauf wir in Kürze eingehen werden, bis auf die Änderung, dass Ihre Informationen komplett in das Kommentarfeld verpackt und nicht in einzelne Eingabefelder aufgeteilt werden.
Sollte es bisher keinen Bericht geben, der dem von Ihnen gefundenen Fehler entspricht, sollten Sie einen neuen Fehlerbericht eröffnen. Das Interface hierzu ist größtenteils selbsterklärend, Sie sollten aber so viele Informationen wie möglich über den Fehler und Ihre Umgebung bereitstellen. Besonders wichtig sind hierbei die folgenden Angaben:
- Die von Ihnen verwendete eZ Components-Versionsnummer, inklusive der Version der betreffenden Komponente
- Die PHP-Version, mit welcher der Fehler aufgetreten ist, sowie alle weiteren PHP-Versionen, mit denen Sie den Fehler reproduzieren können
- Bezeichnung und Versionsnummer Ihres Betriebssystems
- Falls ein Datenbanksystem involviert ist, dessen Namen und Versionsnummer
- Für jeden dieser Punkte existiert ein Eingabefeld im Formular zur Eröffnung eines Fehlerberichts. Des Weiteren ist es wichtig, einen sinnvollen Titel für Ihren Bug-Report zu wählen. Dieser sollte den Namen der Komponente und den Namen der betroffenen Klasse enthalten sowie eine stichwortartige Umschreibung des Fehlers. Wählen Sie also lieber »Database: ezcDbMysyqlHander, error on SELECT query without quoting«, statt »I get an error with my database«. Unter dem Feld für die ausführliche Beschreibung des Fehlers finden Sie eine Eingabe-Box »Steps to Reproduce«, in die Sie den Quellcode zur Reproduktion des Fehlers eintragen. Befindet sich dieser in einem größeren Codeabschnitt, ist es sinnvoll, dass Sie versuchen, ein möglichst kurzes und prägnantes Beispiel zu erstellen, mit dem sich der Fehler nachvollziehen lässt.
- Wenn Sie diese Tipps beachten, ist es höchst wahrscheinlich, dass Ihr Fehler schnell behoben wird. Insbesondere die Themen Testen und Fehlermeldungen sind wichtig. Hierbei sollte noch erwähnt werden, dass für jede neue Version von eZ Components mindestens eine Beta-Version erscheint und im Normalfall anschließend ein Release-Kandidat. Sie können eventuellem Ärger beim Update auf eine neue Version vorbeugen, indem Sie bereits diese Versionen in Ihrer Entwicklungsumgebung testen und auftretende Fehler melden. Dazu werden alle neuen Releases auf der Announcement-Mailingliste dev-ezcomponents-announce@lists.ez.no [http://ez.no/ezcomponents/mailinglists ] angekündigt.
2.5.2 Patches bereitstellen und Dokumentation verbessern
Ein weiterer Schritt nach der Meldung eines Fehlers über den Issue-Tracker ist das Suchen und Beheben des Problems in Eigenregie. Brauchen Sie dringend eine Lösung, ohne auf kommerziellen Support zurückgreifen zu wollen, oder haben Sie einfach Interesse daran, das Innenleben der eZ Components näher kennenzulernen, können Sie erwägen, das Problem selbst in die Hand zu nehmen.
Zunächst sollten Sie sich für Ihre Fehleranalyse einen Checkout des aktuellen Entwicklungsrepositories herunterladen. Wie Sie dazu vorgehen, erfahren Sie in Abschnitt 2.1.4, »SVN«. So stellen Sie sicher, dass die Kernentwickler Ihren »Fehlerflicken«, im Open-Source-Jargon Patch genannt, einwandfrei einpflegen können. Außerdem ist in Subversion bereits alles Wesentliche zum Erzeugen eines Patches enthalten, den die Entwickler nach Durchsicht in Ihren Checkout übernehmen können.
Zum eigentlichen Debugging empfehlen wir das von Derick Rethans, seines Zeichens ebenfalls eZ Components-Entwickler und aktiv an der Entwicklung von PHP beteiligt, entwickelte Programm Xdebug [http://xdebug.org/ ] ab Version 2. Xdebug integriert sich nahtlos in den PHP-Kern und stellt, im Gegensatz zu purem PHP, erweiterte Debugging-Features direkt im Quellcode bereit. Außerdem ist Support für Xdebug als Debugger bereits in verschiedenen PHP-Editoren integriert, die somit ein graphisches Debugging ermöglichen, und es existieren verschiedene spezialisierte Clients.
Haben Sie eine Lösung für den Fehler gefunden und in Ihrer Umgebung erfolgreich getestet, generieren Sie mit Hilfe von Subversion einen Patch und laden diesen als Anhang zu Ihrem Bug-Report in den eZ Components-Issue-Tracker hoch. Ihr Patch wird nun von den Kernentwicklern überprüft und gegebenenfalls auf der Mailingliste diskutiert. Sind alle Fragen geklärt, steht der Beseitigung des Fehlers so gut wie nichts mehr im Wege. Einen Patch erzeugen Sie mit SVN wie folgt:
$ svn diff > fix_something_in_MyComponent.patchDas Kommando diff veranlasst SVN, die Unterschiede zwischen der lokalen Version des Quellcodes und der letzten Version des Repositories anzuzeigen. Mittels > leiten Sie diese Ausgabe in eine Datei um, deren Name reflektieren sollte, was Ihr Patch tut. Vergessen Sie nicht, Ihre Änderungen vor dem Generieren eines Patches noch einmal zu überprüfen, indem Sie die Umleitung in eine Datei am Ende des Kommandos weglassen und sich die Änderungen auf dem Bildschirm ausgeben lassen. Das erzeugte Differenzformat ist recht verständlich.
Eines gilt es allerdings noch zu beachten: Sollte Ihr Patch mehr als ein paar Zeilen Code umfassen, müssen Sie sich bereiterklären, das Contributor-License-Agreement (CLA) von eZ Systems zu unterzeichnen, bevor Ihre Änderungen in eZ Components aufgenommen werden können. Den Grund dafür und weitere Informationen erfahren Sie in Abschnitt 2.5.4, »Contributor-License-Agreement«.
2.5.3 Eigene Komponenten beisteuern
Der wohl höchste Grad an Mitwirkung am eZ Components-Projekt ist das Beisteuern einer eigenen Komponente. Natürlich sind Sie jederzeit eingeladen, Ideen für eine neue Komponente auf der Entwickler-Mailingliste vorzuschlagen und zu diskutieren, doch sollten Sie sich im Klaren darüber sein, dass es ein weiter und manchmal steiniger Weg bis zur fertigen eigenen Komponente ist.
An dieser Stelle soll der definierte Entwicklungsprozess nur grob umrissen werden. Alle weiteren Informationen dazu finden Sie im eZ Components-SVN in der Datei docs/dev_process.txt sowie nähere Informationen zu den einzelnen Phasen im Verzeichnis docs/guidelines.
Zunächst sollten Sie, wie bereits erwähnt, Ihre Idee auf der Mailingliste diskutieren. Hier wird Ihnen die Community ein Feedback geben. Sie werden Ihre Idee verfeinern und erweitern oder einschränken. Kommt am Ende dieser Diskussion heraus, dass Ihre Komponente eine sinnvolle Erweiterung für eZ Components darstellt, gehen Sie zum nächsten Schritt über und entwickeln ein Anforderungsdokument, das zusammenfasst, was Ihre Komponente leisten soll, welche Probleme und potentiellen Erweiterungen beim Design der Komponente beachtet werden müssen und wie sich die Komponente in das bereits bestehende Paket integrieren soll, also ob Abhängigkeiten entstehen werden.
Nach erneuter Diskussion auf der Mailingliste gehen Sie dazu über, ein weiteres Dokument anzufertigen, welches das Design Ihrer Komponente beschreibt. Hier werden alle Features und Verhaltensweisen, die grobe Klassen- und Elementstruktur sowie Besonderheiten und ungelöste Probleme dokumentiert. Da dieses Dokument erneut Grundlage einer Diskussion auf der Mailingliste sein wird, werden Sie einige Zeit für die Fertigstellung benötigen. Unbedachte Fragen werden aufkommen und über die API werden weitere Diskussionen entstehen, bevor es zum nächsten Schritt gehen kann. Sind alle offenen Fragen geklärt, gehen Sie daran, Ihre Komponente zu implementieren.
Hierbei ist ebenfalls die Vorgehensweise festgelegt: Zunächst muss das API-Gerüst in PHP-Code umgesetzt und dokumentiert werden, allerdings wird hier noch keine Funktionalität implementiert. Im Anschluss daran entwickeln Sie sukzessive Testfälle für die Methoden Ihrer Klassen und implementieren anschließend die Methoden selbst, sodass die Testfälle erfüllt werden. Abschließend, vor dem ersten Release Ihrer Komponente, wird die Komponente erneut durch andere Entwickler getestet und überprüft. Ein wichtiger Schritt, bevor Ihre Komponente endgültig in eZ Components aufgenommen werden kann, ist hier in jedem Fall die Unterzeichnung des CLA, worüber Sie im nächsten Abschnitt 2.5.4, »Contributor-License-Agreement«, mehr erfahren.
Sie sehen, eine Komponente zu eZ Components beizusteuern, ist kein leichtes Unterfangen, aber die getroffenen Regularien sind notwendig, um den hoch angesetzten Qualitätsstandards zu genügen. Und haben Sie diesen Prozess überstanden, können Sie sicher sein, ein hochqualitatives Stück Code beigesteuert zu haben.
2.5.4 Contributor-License-Agreement
Open-Source-Software hat in den letzten Jahren enorm an Bedeutung gewonnen, was manchem traditionellen Software-Anbieter ein Dorn im Auge sein mag. Leider gehen einige Unternehmen sogar so weit, den Benutzern von Open-Source-Software Angst vor den Konsequenzen einzujagen, eine Strategie die weithin als FUD (Fear, Uncertainty and Doubt) [http://de.wikipedia.org/wiki/Fear%2C_Uncertainty_and_Doubt ] bekannt ist. Typischerweise wird hier vor Urheberrechts- und Patentverletzungen durch Open-Source-Software gewarnt. Das wohl bekannteste Beispiel der jüngsten Zeit ist die Klage des Software-Hauses SCO gegen den Konzern IBM wegen angeblicher Urheberrechtsverletzungen in dessen Beiträgen zum freien Betriebssystem Linux. Interessieren Sie sich für diesen Fall, so empfehlen wir Ihnen, die ausführliche Zusammenstellung des Heise-Verlags, in der alle Nachrichten der letzten Jahre zusammengefasst sind. [http://www.heise.de/ct/hintergrund/meldung/44492 ]
Wie dem auch sei, die Gefahr einer Urheberrechtsklage durch Beiträge an einem Open-Source-Projekt besteht zumindest theoretisch, und damit sind Open-Source-Anbieter in der Pflicht, ihre Kunden sowie Ihre Mitwirkenden vor dieser potentiellen Gefahr zu schützen. Aus diesem Grund wird es mehr und mehr üblich, Verträge zwischen Vendor und Kontributor abzuschließen, um eventuellen Urheberrechtsproblemen vorzubeugen.
Im CLA von eZ Systems werden daher ein paar grundlegende Regelungen getroffen, die unter anderem die Versicherung des Mitwirkenden enthalten, dass der beigesteuerte Quellcode selbst entwickelt wurde und nicht aus den Werken Dritter stammt. Zusätzlich erhält eZ Systems das (natürlich nicht exklusive) Recht, einmal beigesteuerten Code in seinen Projekten zu nutzen. So soll verhindert werden, dass einmal herausgebrachte Kontributionen wieder zurückgezogen werden. Natürlich wird in keiner Art und Weise das Urheberrecht des Autors für eine Erweiterung angetastet.
Schließlich dient der CLA nicht nur dem Schutz der Benutzer, sondern auch dem des Kontributors, da er seinen Code einem Projekt beisteuert, hinter dem eine Firma steht, welche ihm im Notfall beisteht.
Sollten Sie sich für den CLA zur Mitwirkung an einem eZ Systems-Projekt interessieren, verweisen wir Sie an dieser Stelle auf das entsprechende Dokument im Internet unter der Adresse http://ez.no/ezcomponents/contributing/cla.
