Iconoclast
Home » Joe  

Apache CMS - Retrospektiv

[ÜBERPRÜFT] Zuletzt aktualisiert von Joe Schaefer am So., 22 März 2026    Quelle

 

geteert und gefedert.

Die Apache-CMS — im Oktober 2010 von ausgewählten Mitgliedern des Apache Infrastructure Teams (Paul Querna (Politiker), Daniel Shahaf, Ph.D. (SVN dev), und ich, im Juni 2015 offiziell eingestelltund schließlich im Januar 2022 außer Betrieb genommen — war seiner Zeit immer voraus. Zu seinem Höhepunkt verließen sich über 100 Apache Top-Level-Projekte und über 4K-Benutzer darauf, aber nicht mehr als Apache OpenOffice. Nie war seine vorausschauende Leistungstechnologie deutlicher belegt als in der Content Dependency Management-Funktionalität in den Anfangsjahren der Oracle-Spende von OpenOffice an Apache im Juni 2011.

Um klar zu sein: Wenn andere von Abhängigkeitsmanagement sprechen, sind sie überwiegend mit Softwareabhängigkeiten beschäftigt, nicht Inhaltsabhängigkeiten. Alles kocht auf gut regulierten Inhalt “enthält” im templating+build SystemDas ist nicht das Gleiche wie Software deps.

Diese Funktion war absolut entscheidend für die Unterstützung von Apache’s massiv https://OpenOffice.org (OOo) Webseite. Das RDBMS CMS Sun, das ursprünglich OOo zur Verfügung gestellt wurde, würde umfallen und sterben, auch wenn Sie nur einen Tippfehler beheben wollten. Im Gegensatz dazu lief das Apache CMS in einem FreeBSD Gefängnis auf baldr.apache.org: ein mäßig bereitgestelltes, Dell 1950-Box, die mit 8 CPU und 24 GB RAM mit einem Paar 96 GB gespiegelten Festplatten lief über mehrere Gefängnisse und flog relativ einfach durch den Workflow.

Ohne einen Klebe-CMS-ähnlichen Service, der einen Mitwirkenden IN eine Bearbeitungssitzung für die Seite bringen kann, die er IN einem einzigen Klick reparieren möchte, ist die kognitive Energie viel zu groß, um einen Tippfehler auf einer Webseite heute zu beheben:

  1. gehen Sie Fische, die Seite aus einem github repo,
  2. Gabelung des Repo,
  3. die Seite bearbeiten,
  4. die Änderung festschreiben,
  5. drücken Sie es,
  6. PR erstellen,
  7. Warten, bis ein Committer die PR genehmigt und zusammenführt,
  8. Warten 10-15 Minuten bis zum Abschluss des Staging Builds während es alle 40K+ von baubaren Assets durchschleift (~4 GB Gesamtgröße),
  9. Warten auf einen Committer, um die veröffentlichten geänderten Inhalte irgendwo auf der Staging Site,
  10. Warten auf diesen Committer, um den gesamten Standort in die Produktion zu befördern,
  11. Warten Sie weitere 5-10 Minuten, bis der Veröffentlichungsaufbau abgeschlossen ist,
  12. Warten auf gitpubsub, um den neuen Inhalt an Apache zu übertragen’S Edge Webserver.

Mit dem Apache CMS (Webgui) ein Committable teilen “Patch/Diff” over E-Mail war eine Ein-Klick-Operation für jede Person auf der Erde, sowie eine Ein-Klick-Operation zum Festschreiben + Erstellen + Veröffentlichen für einen Committer, der auf das Projekt angewendet werden soll. Die ganze Sache drehte sich um das Teilen von Funktions-URLs im Kontext eines Live-Markdown-Editors mit sofortigen HTML-Vorschauen mit zwei Fensterbereichen. Sie erlaubten einem Apache-Committer im Projekt, “Klonen” das von kahlr-jail gehostete zfs-Dateisystem eines Mitwirkenden’s (nicht festgeschrieben) Checkout; und anschließend prüfen, ändern und festschreiben, dass der geklonte Checkout vom Apache-Committer selbst als Committer und nicht als Contributor geklont wurde. Sobald dieser Commit erfolgt ist, hat das CMS es nicht nur in Sekunden erstellt (da es’s nur die geänderten Dateien und ihre Handvoll abhängiger Dateien erstellen), aber es stellte auch Links zum Build und zum Live-Rendering des Inhalts auf der Staging-Site zur Überprüfung vor der Promotion zur Produktion bereit.

Das gesamte One-Click Amazon Patent war für die Kundenzufriedenheit von entscheidender Bedeutung. Gleiches hier, aber das apache CMS war ganz allein in diesem raum.

Das Apache CMS (Webgui) war das wesentliche Koordinations-Switchboard zwischen all der freiwilligen Energie, die leider die Org hinter sich gelassen hat.

Es gibt mehrere Ausreden Apache’Die Infrastruktur-Führung hat erklärt, warum sie gestrichen wurde:

  1. ein Busfaktor von 1 (me),

  2. Auslaufen von FreeBSD (OpenZFS läuft auf Ubuntu),

  3. mod_perl, nicht python, aber scheinbar mod_lua ist koscher),

  4. Buggy (unzuverlässige zfs Klone aus einem winzigen FreeBSD Gefängnis),

  5. hässlich (danke, reich!),

  6. git ist besser (danke Greg!).

Aber das eigentliche Motiv war spite. Zwischen der Zeit, als es im März 2015 eingestellt wurde und der Zeit, als es im Januar 2022 endgültig außer Betrieb genommen wurde, lief es fast 7 Jahre lang auf Autopiloten in einem FreeBSD-Gefängnis auf baldr.apache.org. Die einzige erforderliche Wartung war (vierteljährlich?) ein Hostneustart aufgrund von Punkt 4 oben und jährliche SSL-Zertifikatserneuerungen. Das’IT.

Als der Push Ende 2021 kam, bot ich Dave Fisher an, die OpenOffice-Website auf Orion mit einem hohen Rabatt zu veranstalten. Zuerst bat Dave das Board und sie genehmigten die Kosten. Dave bot der ASF an, auf die Findungsgebühr zu verzichten, der ich zugestimmt hatte, ihn zu bezahlen, und sagte mir, dass ich das Geld für die Hosting-Kosten verwenden sollte.

Was als nächstes geschah, war wirklich bemerkenswert: Das Apache Infrastructure Team, sofort und beharrlich über einen Zeitraum von Wochen, brachte Dave in die unbestreitbare Position, seine jetzt exklusiven Loyalitäten zu erklären, nach ihnen: für mich und durch Erweiterung das Projekt’s Freiwilligengemeinschaft oder an ASF.

Dave war der Schlüsselinnovator und Mitarbeiter hinter den Skalierbarkeitserfolgen von The Apache CMS’s inkrementelle Build-Technologie. Er tat’t erfinden die Lösungen; aber er arbeitete produktiv mit mir daran, wie ich die Skalierbarkeitsfunktionen hinzugefügt habe, die er brauchte, um High-Performance-Builds von The Apache CMS zu gewährleisten, wie sie auf der Website OpenOffice angewendet wurden - die zu der Zeit nördlich von 25M anfordert einen Tag! Gemeinsam haben wir eine tiefgreifende Anwendung von SSI in seinen Bemühungen, die meines Erachtens auch heute noch im JBake-Templating-System durchgeführt werden.

Leider, wenn Sie sich die Contentbearbeitung mit OpenOffice ansehen’Auf der Website von GitHub in letzter Zeit können Sie deutlich einen massiven Rückgang der Aktivität sehen, als das Apache-Infrastrukturteam Dave gezwungen hat, sie vom Apache-CMS zu entfernen, und als Ergebnis alle Beitragsaktivitäten allein über GitHub kanalisiert hat.

Ich spende’T Schuld Dave für die hässliche Wahl, die er gezwungen war, zu machen, noch für das vorbestimmte Ergebnis, aber wir sind offensichtlich nicht mehr auf Begriffe seit diesem Tag zu sprechen.

Was an der ganzen Sache schockierend ist, war die absolute Kriegslust des Apache Infrastructure Teams über die gesamte Anstrengung. Ich persönlich hielt die Hand jedes Projekts, das wir an Bord des Apache CMS hatten; zu sehen, dass der gesamte Wohlwollen, der durch autokratisches Dekret zu Boden gebracht wurde, für mich als langjähriges Mitglied der Organisation einfach unergründlich war.

Alles, was sie jemals taten, war, den gestrandeten Apache-Projekten kallige Ultimaten zu stellen, und nie eine einzige Stunde der Anstrengung, die sich dafür einsetzt, sie persönlich für alles andere zu offboardingieren. Es war nicht anders mit OOo; sie missbrauchten einfach, hazed und zwangen Dave, ihr Angebot zu machen. Und so tat er es.

Ich bin 2018 zurückgetreten. Konnte nicht’Sie werden es weiter beobachten. Was ich 2020 gemacht habe, war gebaut Orion aus der Asche. Aber selbst dieser Weg wurde für Apache-Projekte vom Apache-Infrastrukturteam ausgeschlossen.

Alles für spite.

Traurig.