Interview mit Johannes Schlüter (Release Manager PHP 5.3)

Hallo Johannes, vielen Dank, dass du dir ein wenig Zeit für uns genommen hast. Ich habe dich das erste Mal auf der Froscon als Redner, in einem Vortrag über PHP 5.3, erlebt. Wer könnte so einen Vortrag besser halten, als der Release Manager dieser PHP Version, der du ja bist. Und genau aus diesem Grund interviewen wir dich heute auch ein wenig. Natürlich wollen wir sich nicht auf deinen Job als Release Manager reduzieren, deswegen erzähl doch einfach erstmal ein paar Sätze über dich.

Ich wurde eines schönen Dezembertages in München geboren, wo ich immer noch lebe, da bin ich auch in die „Computerei“ hereingewachsen, als Teenager, so um 1996 hatte ich meine erste in HTML entwickelte Homepage – nur mit dem kleinen Problem, dass ich nicht wusste wie man die aus dem Internet abruft. Um die Zeit bin ich auch von meinem Bruder zu Basic verleitet worden, später erfreute ich mich an Windows-Oberflächen mit Delphi und kam dann über zunächst Perl und später, 1999, PHP zum Web zurück.

Momentan arbeite ich, neben einem Studium in München, als Engineer im MySQL Connectors and Client Connectivity Team von Sun Microsystems. Das ist die Gruppe, die Programmier-Interfaces für MySQL und verschiedene Programmiersprachen/Platformen, wie ODBC, JDBC, .Net, … und eben auch PHP entwickelt.

Wie lange arbeitest du schon am PHP Projekt mit und wie kommt man dazu der Release Manager einer so wichtigen Version zu werden?

In die PHP „Core“ Entwicklung bin ich mehr oder weniger hineingerutscht, eine große Priese Interesse „Wie funktioniert das eigentlich?“ gepaart mit einem fördernden Umfeld bei Mayflower, für die ich damals arbeitete, so wie Unterstützung durch aktive PHP Core Entwickler, wie vor allem Marcus Börger , führte für mich Schritt für Schritt tiefer rein. Wirklich bekannt wurde ich in Entwicklerkreisen wohl durch meinen Patch der Operator-Überladung für PHP implementierte, das war 2004.

… und wie kommt man dann dazu der Release Manager einer so wichtigen, die ja bereits einige Features bietet, mit denen wir erst mit PHP 6 gerechnet haben, Version zu werden?

Im Sommer letzten Jahres zeichnete sich ab, dass wir vor PHP 6 noch eine 5.3 Serie entwickeln werden. Ilia Alshanetsky, der Release Manager für 5.2 hatte aber, arbeitsbedingt, weniger Zeit sich darum zu kümmern. So suchten die PHP Entwickler jemanden der genug Überblick über die wesentlichen Aspekte von PHP hat und der genug Zeit hat, ich hatte zuvor entschieden arbeitsmäßig etwas kürzer zu treten und wieder zu studieren und erfüllte somit die Kriterien und merkte erst später, das mein Bruder wirklich recht hatte mit der Aussage, dass das „Release Management“ die dümmste Position in einem Open Source Projekt ist: Man hat viel zu tun und nach dem Release ist man an den Fehlern schuld.

Inzwischen haben wir die Arbeit auf mich und Lukas Smith verteilt, wobei Lukas mehr Organisation und ich mich mehr um die „technischen“ Dinge kümmere.

Wie viel Mitspracherecht hat mein bei einem solchen Release und gibt es Features für die und gegen die du gekämpft hast?

Das ist eine interessante Frage, im Zweifel habe ich das Veto-Recht, zumindest in der Theorie, in der Praxis hieße ein echtes Veto, dass das gut begründet sein muss sonst werde ich abgesetzt und/oder wir verlieren einen Entwickler und da PHP im wesentlichen von Leuten privat oder zumindest in großen Teilen privat entwickelt wird sind wir über jeden Entwickler und jedes Feature froh. In der Praxis heißt es die RM-Aufgabe ist es Kompromisse auszuloten und bei unklaren Entscheidungen eine zu treffen. Das bringt jedoch alles nichts, wenn die, die es am besten umsetzen können , wenn der Entwickler mit einer Entscheidung nicht einverstanden ist habe ich als einziges „Druckmittel“ dass ich sagen kann „Du bist blöd“, was aber auch zu nichts führt.

Wenn man an PHP mitentwickelt, hat man dann überhaupt Zeit noch zusätzlich in PHP zu entwickeln? Würdest du deine Webprojekte denn überhaupt in PHP realisieren?

In letzter Zeit habe ich kaum aktiv an Projekten mitentwickelt, ich verwende mehr Zeit darauf mir verschiedene OpenSource PHP-Projekte anzusehen und (still) zu beobachten oder mit verschiedenen Entwicklern zu reden um zu sehen wie PHP denn so allgemein verwendet wird, was da so die Trends im „Userland“ sind, selber habe ich nur ein paar hundert Zeilen PHP Code im laufe des Jahres geschrieben, und das meiste davon auch nur Zwei- oder Dreizeiler um Features zu testen oder Bugs zu verifizieren.

Mein letztes nicht komplett triviales Web-Projekt habe ich mit Java implementiert – im wesentlichen, da ich der Überzeugung bin, dass man den Blick über den Tellerrand wagen soll, momentan suche ich Motivation für ein Testprojekt mit RoR aber da baucht man immer ein Projekt für – und Zeit.

Ich habe leider noch nie einen Blick auf die Sourcen von PHP geworfen. Würdest du sagen der Code ist vorzeigbar oder sollte man ihn lieber, wie auch so viele PHP Projekte ,verstecken und hoffen, dass es nie soweit kommt, das der Code in sich zusammenbricht?

Ich würde den Code als typischen gewachsenen C-Code beschreiben, relativ Makro-Verseucht, dies mit dem Ziel da möglichst modular und flexibel zu bleiben. Und ich denke es geht jedem so: Den perfekten Code gibt es nicht, ich habe kein Projekt über mehre Monate oder gar Jahre begleitet ohne am Ende zu sagen, hm, sollte man doch noch mal von vorne machen, was sich natürlich nie lohnt und nur wieder zur selben Erkenntnis führt.

Was sich über den Code jedenfalls sagen lässt ist, dass PHP, „berühmt“ für eine Vielzahl von Sicherheitsproblemen, als eines der ersten Open Source Projekte den vom U.S. Department for Homeland Security gesponsorten Coverity Scan ohne Schwachstelle bestanden hat.

Eigentlich gibt es als Standardfrage in unseren Interviews die Frage wann man sich das letzte mal so richtig über PHP aufgeregt hat. Für dich passen wir die Frage natürlich an: Wann hast du dich das letzte mal so richtig über den PHP Source Code aufgeregt?

Heute. Jeden Tag, wie es halt so ist, ich habe nun mal primär mit Bugs zu tun und Bugs sind immer ärgerlich, so lange sie nicht gefixt sind und bei einem trivialem Bugfix ist es ärgerlich dass der Bug dort war und bei einem komplexen ärgert man sich über Architekturentscheidungen, die einen Edge-Case nicht beachtet haben.