Apache CMS retrospektiv

[VERIFIERAD] Senast uppdaterad av Joe Schaefer på Sun, 26 Apr 2026    källa

 

Den Apache CMS — uppfanns i oktober 2010 av utvalda medlemmar i Apache Infrastructure Team (Paul Querna (VP), Daniel Shahaf, Ph.D. (SVN dev), och jag själv), formellt föråldrad i juni 2015och slutligen avvecklad i januari 2022 — Alltid före sin tid. Vid sin höjdpunkt förlitade sig över 100 Apache-projekt på toppnivå och över 4K-användare på det, men ingen mer än Apache OpenOffice. Aldrig var dess nuvarande prestandateknik tydligare bevisad än i dess funktioner för hantering av innehållsberoende under de första åren av Oracle-donationen av OpenOffice till Apache i juni 2011.

För att vara tydlig: när andra talar om beroendehantering, är de främst intresserade av programberoenden, inte innehållsberoenden. Allt kokar ner till välreglerat innehåll “inkluderar” i templating+build-systemet, vilket inte alls är samma sak som mjukvarudeps.

Denna funktion var helt avgörande för att stödja Apache massiva https://OpenOffice.org (OOo) webbplats. RDBMS CMS Sun som ursprungligen tillhandahölls till OOo skulle falla över och dö även om du bara ville fixa ett stavfel. Däremot körde Apache CMS på en FreeBSD fängelse på baldr.apache.org: en måttligt tilldelad, Dell 1950-låda som kördes på 8 CPU och 24 GB RAM med ett par speglade hårddiskar på 96 GB över flera fängelser, och flög genom arbetsflödet med relativ lätthet.

Utan några limning CMS som tjänst som kan få en bidragsgivare i en redigeringssession för sidan de vill reparera i en enda klick, är den kognitiva energin alldeles för stor för att fixa ett stavfel på en webbsida idag:

1. Gå fisk den sidan ut ur en github repo,
2. gaffel för repo,
3. redigera sidan,
4. Genomför förändringen,
5. Tryck på den,
6. Skapa ett PR
7. vänta tills en beställare godkänner och slår samman PR.
8. vänta 10-15 minuter för att mellanlagringsversionen ska slutföras medan den slipar igenom alla 40K+ byggbara tillgångar (~4 GB total storlek),
9. vänta för en beställare att hitta och granska det publicerade ändrade innehållet någonstans på mellanlagringsplats,
10. vänta så att beställaren flyttar upp den hela platsen till produktion
11. vänta ytterligare 5-10 minuter för att publiceringsversionen ska slutföras,
12. vänta så att gitpubsub pushar ut det nya innehållet till Apache:s edge-webbservrar.

Med Apache CMS (webgui), dela en committable “patch/diff.” över e-post var en enkelklicksoperation för någon person på jorden, samt en enkelklicksoperation för att bekräfta + bygga + publicera för en beställare att tillämpa på projektet. Det hela kretsade kring delning av funktions-URL:er i kontexten av en live Markdown-redigerare med samtidiga HTML-förhandsgranskningar med dubbla rutor. De tillät en Apache committer på projektet att “klon” baldr-jail-hosted zfs-filsystemet för en bidragsgivares (icke-engagerade) utcheckning; och inspektera, ändra och bekräfta sedan den klonade utcheckningen av Apache-åtagaren själva som uppdragsgivare och inte bidragsgivare. När den bekräftelsen inträffar byggde CMS inte bara den på sekunder (eftersom det bara bygger de ändrade filerna och deras handfull beroende filer), men det tillhandahöll också länkar till bygget och till den levande återgivningen av innehållet på mellanlagringsplatsen för granskning före befordran till produktion.

Hela **One-Click **Amazon Patent var avgörande för kundnöjdhet för dem. Samma sak här; men Apache CMS var helt ensam i detta utrymme.

Apache CMS (webgui) var den nödvändiga samordningsväxeln mellan all frivillig energi som tyvärr har lämnat org bakom sig.

Det finns flera ursäkter Apache Infrastruktur Ledarskap gjort om varför det släpptes:

1. En bussfaktor på 1 (mig).

2. fasa ut FreeBSD (OpenZFS körs på ubuntu),

3. mod_perlinte python (men tydligen mod_lua är kosher),

4. buggy (otroliga zfs kloner från ett litet FreeBSD fängelse),

5. Fult (tack, rika!),

6. Git är bättre (tack Greg!)

Men det verkliga motivet var spett. Mellan den tid den avvecklades i mars 2015 och den tid den slutligen avvecklades i januari 2022 hade den kört på autopilot i ett FreeBSD-fängelse på baldr.apache.org i nästan 7 år. Det enda underhåll som krävdes var (kvartalsvis?) omstart av värd på grund av artikel 4 ovan, och årliga förnyelser av SSL-certifikat. Det är IT.

När push kom att skjuta i slutet av 2021 erbjöd jag Dave Fisher att vara värd för OpenOffice-webbplatsen på Orion med en brant rabatt. Först bad Dave styrelsen och de godkände kostnaden. Dave erbjöd ASF att avstå från fyndavgiften jag gick med på att betala honom och sa till mig att lägga pengarna mot värdkostnaderna.

Vad som hände sedan var verkligen anmärkningsvärt: Apache Infrastructure Team, omedelbart och ihärdigt under en period av veckor, satte Dave i den otacksamma positionen att förklara sina nu exklusiva lojaliteter, enligt dem: för mig och i förlängningen projektets volontär gemenskap, eller till The ASF.

Dave var den viktigaste innovatören och samarbetspartnern bakom skalbarhetsframgångarna för Apache CMS: s inkrementella byggteknik. Han uppfann inte lösningarna, men han arbetade produktivt med mig om hur jag lade till skalbarhetsfunktionerna han behövde för att säkerställa högpresterande byggen från The Apache CMS som tillämpas på OpenOffice-webbplatsen - som vid den tiden levererade norr om 25M begär en dag! Tillsammans upptäckte vi en djupgående tillämpning av SSI i hans ansträngningar, som jag tror fortfarande genomförs i det JBake-templateringssystem som används i dag.

Tyvärr, om du tittar på den innehållsredigering som pågår med OpenOffice webbplats på GitHub nyligen, kan du tydligt se en massiv avstängning i aktivitet när Apache Infrastructure Team tvingade Dave att flytta dem från Apache CMS, och som ett resultat kanaliserade all bidragsaktivitet genom GitHub ensam.

Jag klandrar inte Dave för det fula val han var tvungen att göra, inte heller för det förutbestämda resultatet, men vi är uppenbarligen inte längre på talande villkor sedan den dagen.

Vad som är chockerande med hela affären var den absoluta krigaren hos Apache Infrastructure Team om hela ansträngningen. Jag höll personligen hand om varje projekt som vi introducerade till Apache CMS; att se all den goodwill som skapade brännas till marken genom autokratiska dekret var helt enkelt outgrundlig för mig som en lång tid medlem av organisationen.

Allt de någonsin gjorde var att ge de strandsatta Apache-projekten kalla ultimatum, och aldrig en enda timmes ansträngning dedikerad till att personligen offboarding dem till allt annat. Det var inte annorlunda med OOo; de missbrukade, hotade och tvingade Dave att göra sin budgivning. Och det gjorde han.

Jag avgick 2018. Kunde inte fortsätta att bevittna det. Det jag gjorde 2020 var att bygga Orion från askan. Men även den avenyn stängdes för Apache-projekt av Apache Infrastructure Team.

Allt för spite.

Ledsen.

Men inte besegrad. Jag hällde all den energin i byggnaden Orion till en oöverträffad, säkerhetsinriktad, världsledande konstruktion KMS. Kolla in det om du tröttnar på att ha dina företagshemligheter stulna av script-kiddies; du kommer att älska det!