Fragen, Antworten, Ausblicke

PEARfekt?
Kommentare

Wir verfolgen mit großem Interesse die stetig steigende Zahl von Artikeln über PEAR in Magazinen und Onlineartikeln. In der letzten Ausgabe des PHP Magazins wurde ein Artikel von Kai Schröder veröffentlicht, der sich explizit mit der PEAR Group beschäftigt. Zum Ende des Artikels machte Kai die durchaus korrekte Feststellung, dass wir alle nicht unser Geld durch PEAR oder unsere Mitgliedschaft in der PEAR Group verdienen. Dennoch wollen wir dies nicht als Ausrede gelten lassen und wollen daher auf diesem Wege den von Kai vorgeschlagenen Dialog mit ihm und der Leserschaft des PHP Magazins eingehen.

In unserem ersten Announcement hat die PEAR Group festgeschrieben, wie sie plant, sich selbst zu regulieren. Kai merkte an, dass dort keine Möglichkeit festgeschrieben ist, wie die Community bindend auf die PEAR Group Einfluss nehmen kann. Wir haben uns da an das Vorpicture der PHP Group gehalten. Prinzipiell ist die Aufgabe der PHP Group auch mehr, als eine Gruppe von erfahrenen Entwicklern insbesondere in Streitfragen zu moderieren bzw. zu entscheiden. Die Group hat dabei keine Mittel oder Ressourcen, um die Community in irgendeine Richtung zu zwingen. Von daher ist Ihre Macht proportional zu dem Respekt und dem Vertrauen der Community. Generell wollen wir aber auch nicht allein verantwortlich für die zukünftige Gestaltung von PEAR sein. Das würde keinen Sinn machen, insbesondere da es sich hier um ein Open Source-Projekt handelt. Daher hat Alan Knowles, ein Mitglied der PEAR Group, auch einen Entwurf für einen Community-Prozess entwickelt, in dem jeder Verbesserungsvorschläge zur Abstimmung bringen kann. Dieser Entwurf wurde bereits zur öffentlichen Abstimmung in PEPr gebracht und ohne Gegenstimme angenommen [4]. Gerade auch weil die PEAR Group ihre Announcements und die resultierenden Aufgaben nicht selber umsetzen kann oder ihre Umsetzung erzwingen kann, haben wir auch davon Abstand genommen, Roadmaps zu definieren. Es muss sich auch jemand in der Community finden, der bereit ist, die entsprechende Aufgabe zu übernehmen. Gerade da PEAR von Freiwilligen entwickelt wird, kann dies schnell gehen oder auch mal etwas länger liegen bleiben. Allgemein sehen wir unsere Announcements stets als Ergänzung zu unserem Manual [1]. Daher erläutern unsere Announcements auch nur die Änderungen bzw. die konkreten Unklarheiten, die durch dieses Announcement behandelt werden. Beim Lesen eines unserer Announcements gehen wir also davon aus, dass der Leser bereits das Manual durchgelesen hat. Im Manual findet er auch eine Vielzahl von wirklich wichtigen Informationen, deren Fehlen Kai in unseren Announcements bemängelt hat, z.B. gibt es eine Seite im Manual, welche die Aufgabe und Funktion jeder der PEAR-Mailinglisten beschreibt. In einem weiteren Eintrag im Manual werden die erlaubten Lizenzen beschrieben. Das Thema Lizenzen haben wir in einem erst kürzlich veröffentlichten Announcement weiter präzisiert [5]. Jedoch ist die Anmerkung von Kai natürlich dennoch sinnvoll, die Lizenz bereits im Proposal angeben zu lassen. Dies wurde auch bereits umgesetzt. Wo wir gerade bei Verbesserungen Aufgrund von Anmerkungen von Kai sind, wollen wir auch die von Kai angemerkten Klarstellungen im ersten Group-Announcement, in dem wir die Regeln zur Abstimmung innerhalb der Group festgelegt haben, erwähnen. Dies wurde ebenfalls kürzlich in einem entsprechenden Announcement umgesetzt [6]. Ein ebenfalls angesprochener Kritikpunkt war das Fehlen eines Links auf der Seite des Login-Formulares zum Formular, in dem man einen Account beantragen kann. Jedoch fallen solche Anregungen eher in den Aufgabenbereich des PEAR Webmaster-Teams, welches auf entsprechende Bugreports in der Regel sehr schnell reagiert. Kai merkte auch an, dass es an einem Guide für neue Community-Mitglieder fehlt. Dies stimmt so nicht, da es im Manual verschiedene Bereiche gibt, die sich mit dem Thema beschäftigen, sowohl aus Anwender- als auch aus Entwicklersicht. Natürlich wird auch hier stets weiter gearbeitet. Im Folgenden wollen wir auf die noch offenen Kritikpunkte zum PEPr System eingehen. Kai äußerte die Befürchtung, dass die Möglichkeit, Proposals einreichen zu dürfen, ohne jeglichen Code vorhanden zu haben, dazu führen würde, dass es eine große Zahl von Projektleichen geben könnte. In der Vergangenheit hat sich aber gezeigt, dass viele Packages sich sehr erfolgreich aus eben solchen Proposals entwickelt haben. Wenn es jemand schafft, auch nur mit einem Konzept die Community zu überzeugen, dann spricht das eher für das Konzept. Den Autor dann zu zwingen, das Package erst außerhalb von PEAR umzusetzen und erst dann zur endgültigen Abstimmung zu bringen ist in sofern unlogisch, da er sich dann um eine alternative Entwicklungsinfrastruktur kümmern muss. Gerade in der PEAR Community selber finden sich oft mehrere Entwickler, um eine gemeinsame Idee umzusetzen. Diese Variante ist auch nicht der Regelfall. Ein weiterer Punkt war, in wie weit es Sinn macht, in einem Proposal .phps-Dateien anzubieten. Dies ist eine Entscheidung desjenigen der das Proposal einreicht. PEPr unterstützt diverse Formate, darunter phps, Archive und auch Livebeispiele. Abschließend wollen wir noch auf den Punkt eingehen, ob es nicht Sinn machen würde, Webspace für Packageproposals bereit zu stellen. Dies lässt sich leider nicht ohne größeren Aufwand machen, insbesondere um nicht eventuelle Sicherheitsrisiken in Kauf zu nehmen. Falls es nur darum geht, ein Zip-Archiv hochzuladen, sollte es jedem versierten Entwickler möglich sein bei Bedarf sich bei einem entsprechenden Freehoster anzumelden oder noch einfacher auf der Entwickler-Mailingliste um Hilfe zu bitten. Generell sehen wir das als den richtigen Lösungsweg für diverse Kritikpunkte, die Kai angesprochen hat: Einfach Fragen! Wir kennen wenige Open Source-Projekte, bei denen man so schnell Antworten zu seinen Fragen auf den Mailinglisten bekommt wie bei PEAR. Kai hatte auch diverse Anmerkungen zum Abstimmungsprozess selber. Zum einen kritisierte er die Möglichkeit, so genannte Conditional Votes abgeben zu dürfen. Sicherlich wäre der Idealfall, dass alle Fragen und Wünsche vor dem Call for Votes geklärt wären. Jedoch sieht die Realität anders aus. In der Realität haben nicht alle Entwickler vor dem Call for Votes Zeit, sich jedes Proposal anzuschauen. Statt diese dann von der Abstimmung auszuschließen, können sie Conditional Votes abgeben. Gelegentlich lassen sich aber einfach auch nicht alle Wünsche unter einen Hut bringen. In diesem Fall können die einzelnen Fraktionen in der Abstimmung klarstellen, welche Variante sie befürworten und der Proposer kann dann schauen, welche der Conditional Votes er ohne Konflikt umsetzen kann. Es ist nämlich so, dass Conditional Votes sehr wohl gelten, jedoch naturgemäß erst dann, wenn die Bedingung erfüllt wurde. Kai zeigte sich auch irritiert darüber, wie die PEAR Group auf die Zahl von +5 für ein angenommenes Proposal gekommen ist. Dies ist schlicht und ergreifend historisch bedingt. Seit je her war dies das nötige Ergebnis, um ein Package in PEAR einbringen zu dürfen. Wir haben uns also lediglich dazu entschieden den Status quo aufrecht zu erhalten. Wir haben natürlich verschiedene Alternativen durchdacht sind, aber zu dem Schluss gekommen, dass es durchaus Sinn macht zu sagen, dass ein Übergewicht von fünf Ja-Stimmen ausreichen soll. Schließlich bedeutet dies ja, dass ein Übergewicht von Entwicklern einen Nutzen für das Package sieht. Falls es entsprechende Gegenstimmen gab, können diese Entwickler zum einen das Package nicht nutzen bzw. einfach einen Vorschlag für ein Package unterbreiten, welches einen alternativen Ansatz verfolgt. Wir würden an dieser Stelle auch gerne die Gelegenheit nutzen, um den Mythos zu entkräften, dass in PEAR stets nur eine Lösung für ein Problem erlaubt ist: Dies stimmt nicht! Wir wollen auch im Interesse der Übersichtlichkeit und Wartbarkeit nur keine redundanten Packages in PEAR. Jedoch sehen wir ein Package, das einen klar anderen Ansatz verfolgt als ein anderes, nicht als redundant an, selbst wenn es sich mit derselben Aufgabe befasst. Abschließend wollen wir anmerken, dass viele Vorschläge des Autors zwar in unserem Kulturkreis großen Anklang finden, jedoch in einem internationalen Projekt wie PEAR keine Mehrheit finden. Gerade außerhalb Deutschlands und insbesondere außerhalb von Europa werden Regeln und straffe Roadmaps oft als unerwünschtes Korsett gesehen. Ausnahmen bestätigen da natürlich die Regel. Es gilt also stets, sinnvolle Kompromisse zu finden. Generell gilt jedoch für all unsere Regelungen, dass wir es vorziehen uns auf Vertrauen und gesunden Menschenverstand zu verlassen. Schließlich sind wir keine Anwälte, sondern Entwickler. Links

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -