Wenn die sechste Ausgabe des PHP-Magazins in diesem Jahr erscheint, wird sie wohl die letzten PEAR-Kolumne und PEAR-News enthalten.
Wie begann es?
Beide Formate waren bereits kurz nach dem Start fester Bestandteil des PHP-Magazins. Vermutlich stand die erste Ausgabe im PHP-Magazin 1.2003, die im Dezember 2002 erschien. Das ist bereits so lange her, dass ich von den frühen Ausgaben schon längst die originalen Text nicht mehr habe. Die noch erhaltenen, älteste SWX-Datei mit Kolumnentexten stammen aus dem Jahr 2004.
Wozu?
Am Anfang der Kolumne stand natürlich die Promotion von PEAR selbst. Dazu muss aber klar sein, dass zum damaligen Zeitpunkt PEAR ein eher diffuses Gebilde war. Vieles von dem, was heute selbstverständlich scheint, war damals schlicht nicht existent oder noch sehr experimentell. Das beste Beispiel dafür ist das pear-Kommandozeilen-Programm. Dazu waren eine Vielzahl von Standards und Vorgehensweisen heiß umstritten. Ein normaler Nutzer hätte kaum die umfassenden Diskussion auf der Mailingliste und im IRC verfolgen wollen.
Die PEAR-Kolumne sollte hier zum einen Rückblick auf die Diskussionen rund um PEAR ermöglichen und ihm verständlich machen, warum bestimmte Entscheidungen getroffen wurden. Zum anderen sollten angewendete Muster im Umgang mit PEAR und die Arbeit mit Packages gezeigt werden (der Einblick). Und schließlich ging es auch um den Ausblick auf offene Punkte im Diskussionsprozess, der Leser zum einen Vorwarnen als auch ermutigen sollte selbst in PEAR-mitzuwirken. Dazu war die Dokumentation vieler Packages eher rudimentär gehalten.
Die PEAR-News sollten Nutzer gezielt auf interessante Packages und Funktionen lenken, durchaus auch nach dem Motto "Ich wusste gar nicht, dass ich sowas machen kann".
Was passierte in der Zeit?
Die Entwicklung von PEAR lässt sich in gewisse Phasen einteilen, die aber nicht klar von einander abgrenzbar sind, und ich werde hier auch keinen Versuch unternehmen konkrete Jahreszahlen zu nennen. Es handelt sich eher um gefühlte Entwicklungsabschnitte:
-
In der Wilden Zeit wurden Standards vorgeschlagen, verworfen und angenommen. Es entstanden Packages wie PEAR::DB, PEAR::Mail und HTML_Template_IT, die wesentlich für die Popularität von PEAR waren.
-
Darauf folgte die Flut. Packages kamen hinzu, bestehende Packages wurden ausgebaut. Das daraus resultierende Rauschen in der Community wurde schließlich durch die Bildung der PEAR-Group und Abstimmungswerkzeuge zu kanalisieren.
-
Mit PHP 5 begann das Nachdenken. PHP 5 ermöglichte die Umsetzung neuer Konzepte, bei gleichzeitigem Bruch der Rückwärtskompatibilität. Das erzwang klare Richtlinien bei der Versionierung und führte zu neuen Diskussionen über die Standards – daraus entstand auch der PEAR 2-Zweig (der keine Abspaltung ist!).
-
Schließlich sind wir in der Konsolidierung gelandet. Viele PEAR-Packages haben mittlerweile einen Stand erreicht, dass sie funktionsvollständig sind. Änderungen betreffen vor allem die Anpassung und die Korrektur von Fehlern. Neue Packages decken eher kleine Nischen ab. Durch Abstraktionskonzepte wird versucht, nischenübergreifende Arbeitsweisen beizubehalten.
Aus Autorensicht waren gerade die ersten drei Phasen ein reicher Steinbruch für Themen und abwechslungsreiche Inhalte.
Also ist PEAR tot?
Nein! Im Gegenteil, PEAR funktioniert einfach. Und genau das ist aber für mich als Autor ein Problem. Die Dokumentation vieler Packages ist umfassend, der durchschnittliche Programmierer ist längsten mit Entwicklungsmustern und Unittests vertraut. Die großen Diskussionen auf der Mailingliste sind vorbei. Vieles von dem, was PEAR ausmacht – und zu Anfang schwer macht - wurde längst von der gesamten PEAR-Community adoptiert.
Bei der PEAR-Kolumne ist das in den letzten Jahren bereits auffällig gewesen. Ursprünglich hatte ich noch die Devise: Abwechselnd eine Package-Vorstellung und dann wieder ein Blick auf Diskussionen und Standards. Das ließ sich aber bereits seit drei, vier Jahren nicht mehr umsetzen.
In den News war der Prozess schleichender. Wo ich früher ein Drittel neuer Packages aufzählen konnte und ich bei manchen Package entscheiden musste, welche der 20 neuen Funktionen ich hervorhebe, so bin ich heute froh, wenn ein Package überhaupt eine neue Funktion hat und nicht einfach nur einen neuen Parameter oder einfach ein Bugfix erschien.
Noch mal: Das ist für eine Entwicklerbibliothek etwas Positives (der Leser denke an POSIX), aber schlecht für den Autor, schlecht für mich.
Que Vadis Kolumne?
In Hinblick auf diese Gedanken halte ich es für sinnvoll, die News und die Kolumne in jetziger Form einzustellen, es besteht einfach die Gefahr, sich früher oder später Inhaltsleere schön zu reden und in Lächerlichkeiten abzugleiten.
Loslassen will mich das Thema aber nicht. Es gibt noch die eine oder andere unentdeckte Perle in PEAR, die gehoben werden will. Genauso wie immer wieder ein interessantes Package auftaucht – wie zum Beispiel Science::Astronomy, das gerade vorgeschlagen wurde.
Gerade dieses Package würde in den klassischen PEAR-News/Kolumne wohl untergehen – hier würde es mehr Spaß machen, das klassische Kolumnenformat zu sprengen.
