Po třech letech se na projektu podíleli vývojáři, dobrovolníci z podpůrného fóra, dokumentaristé a další. Mnozí z nich byli u projektu od jeho počátků, a přestože se projekt a software vyvíjely a měnily, někteří měli pocit, že struktura řízení se nezměnila. Projekt svobodného softwaru lze řídit mnoha různými způsoby. WordPress měl vždy strukturu Benevolentního doživotního diktátora (BDFL): konečné rozhodnutí často spočívalo na Mattovi, i když to byl Ryan Boren, kdo přijímal a realizoval většinu technických rozhodnutí. Někteří přispěvatelé však měli pocit, že by projektu prospěla struktura výboru, kdy by směr projektu a rozhodování řídil tým lidí. Jiní nebyli spokojeni s tím, jak Matt projekt vedl, a odešli. První velké rozvětvení WordPressu se netýkalo softwaru, ale komunity.
Někteří z nešťastných přispěvatelů se setkali v září 2006 na festivalu Ohio Linux Fest v Columbusu. Společně poobědvali v restauraci Buca di Beppo. Mezi strávníky byli čtyři vývojáři WordPressu – Owen Winkler (ringmaster), Rich Bowen (drbacchus), Scott Merrill (Skippy) a Chris Davis (chrisjdavis). Během oběda si povídali o svých stížnostech. Stále se opakovala stejná historka – patche byly odmítány, protože neodpovídaly vizi projektu. Rozhovor se stále vracel k možnosti založit nový projekt s otevřeným zdrojovým kódem (free-and-open-source, FOSS). Než jídlo skončilo, vývojáři se rozhodli přestat mluvit a začít jednat: vytvoří nový blogovací nástroj. O několik týdnů později na konferenci ApacheCon zvolili název: Habari, což ve svahilštině znamená “Jak je?” nebo “Jaké jsou novinky?”. Vytvořili strukturu řízení a vývojový étos projektu a začali na něm vážně pracovat.
Habari byl spuštěn v lednu 2007 a mnoho jeho základních principů je v přímém rozporu s principy projektu WordPress. Stránka Habari Motivations se zabývá otázkami, proti kterým zakladatelé projektu WordPress protestovali – a vysvětluje jejich odlišný přístup k vedení projektu svobodného softwaru. Upozorňuje také na některé problémy, které se v projektu WordPress objevily tři roky po jeho spuštění. Každý projekt svobodného softwaru – a vlastně každá skupina nebo komunita – má své problémy, zejména když se etabluje. Napětí, které bylo v počátečním zápalu nadšení přehlíženo, se zakoření, a jakmile nadšení opadne, vyplave na povrch.
Jedním z hlavních problémů byl styl řízení. Mnozí nebyli spokojeni s modelem BDFL, přestože je v projektech svobodného softwaru rozšířen, od Linuse Torvaldse z Linuxu po Guida van Rossuma z Pythonu. BDFL má obvykle konečné slovo ohledně směřování a vize projektu, ale jak projekt roste, je zde mnoho lidí, kteří mají vliv a rozhodují.
Rich Bowen, jeden z vývojářů, který nebyl spokojen s tím, jak je WordPress provozován, přišel z projektu Apache. Apache má model výboru. Výbor se skládá z vývojářů i nevývojářů, kteří mají možnost ovlivňovat chod projektu. Na rozdíl od WordPressu, který vyžaduje, aby revize byly schváleny revizorem a/nebo revizorem oprav, revize v Apache vyžadují konsenzus. Habari bylo spuštěno se strukturou výboru, podobně jako Apache.
Designér Michael Heilemann byl jedním z těch, které Habari zlákalo. Navrhl téma pro Kubricka a hledal novou výzvu poté, co projekt Shuttle selhal ještě před realizací.
Michael přepracoval rozhraní Habari – což podle něj byla dobrá i špatná zkušenost. Bavilo ho navrhovat a implementovat, méně už proces schvalování. Vzhledem ke struktuře výboru Habari strávil hodně času diskusemi o novém administrátorském rozhraní. Své názory zvažovali i lidé bez designérského vzdělání a všichni měli stejnou váhu. Michael měl proto pocit, že nemůže svou práci dokončit, a nakonec Habari opustil. Na otázku, zda dává přednost modelu ve stylu BDFL nebo Apache, odpovídá:
Pokud mají všichni stejné postavení, snadno se dostanou do velmi dlouhých diskusí. A to vytváří skvělou demokracii, ale je to také velmi hippie, 60. léta, každý si může sednout a podělit se o svůj názor, ale ne vždy je to něco, co má skutečný smysl. Ve skutečnosti tím nutně nezískáte lepší produkt. A tak často potřebujete někoho s vizí, nebo alespoň někoho s názorem s názorem, aby se k tomu vyjádřil.
Přístup pomocí commitu byl další důležitým bodem. U Apache projektu existovala jasná cesta, jak získat přístup k revizím v repozitáři. To nebyl případ WordPressu z počátku roku 2006. Matt a Ryan fungovali jako trychtýř, kterým procházel veškerý kód. Nakonec byli přidáni další revizoři, ale byl to pomalý proces, který vedl k frustraci, zejména u plodných přispěvatelů.
Rich Bowen přišel z Apache a přinesl jiný pohled na věc – který sdílel s ostatními nespokojenými vývojáři. Podle Riche WordPress nepředstavoval skutečnou meritokracii – pro ty, kteří měli schopnosti, neexistovala příležitost získat moc a odpovědnost. Konečné rozhodnutí o tom, kdo získá a nezíská pravomoci, leželo na vedoucím projektu – záleželo pouze na Mattově uvážení. Když Matt v jednom diskusním vlákně řekl, že WordPress je meritokracie, protože přístup k revizím je poskytován “těm nejlepším z nejlepších přispěvatelů, kteří v průběhu času prokáží svou hodnotu kvalitním kódem, vstřícností vůči komunitě a spolehlivostí v krizových časech”, Rich poukázal na to, že protože konečné rozhodnutí leží na BDFL, komunita se nikdy nemůže stát meritokratickou.
Jádrem diskuse byl zásadní spor o to, jak by měl být projekt svobodného softwaru strukturován. Eric Raymond se v knize Homesteading the Noosphere zabývá strukturami projektů a jejich vlastnictvím a sleduje, jak se tyto struktury v průběhu času vyvíjejí. WordPress se řídí Raymondovou osnovou: projekt měl jediného vlastníka/správce (nebo spíše dva – Mike Little a Matt Mullenweg). Postupem času převzal Matt vedení projektu. V případě WordPressu s sebou přístup k revizím nesl implicitní úroveň autority. Ti, kdo mají přístup k revizím, jsou rozhodčími kódu, který skončí v jádře. Matt dal při několika příležitostech jasně najevo, že “nechce, aby to byla statusová záležitost”, ale přesto se jí stala.
Matt v roce 2005 napsal do poštovní konference: “Committing != community status. Je to prostě způsob, jak zajistit, aby veškerý kód, který se dostane do jádra, byl před distribucí do světa zkontrolován.” Členové komunity však přirozeně přisuzují větší autoritu a důvěryhodnost těm, kteří mají přístup k revizím. Nebylo jasné, co je potřeba k tomu, aby se člověk stal committerem nebo vedoucím vývojářem. Místo toho se tyto role vyvíjely organicky. Pro komunitu autorita přirozeně vyplývala z přístupu k úložišti a přístup k revizím z kvalitního odevzdávání kódu spolu s porozuměním a závazkem k etice projektu. Commit je symbolem důvěry; s pouhými dvěma commitery se zdálo, že vedoucí projektu nedůvěřují ostatním členům komunity.
To mělo další důsledek: nekódové příspěvky nebyly uznány. Přístup k commitům se sice uděloval střídmě, ale autoritu a vedoucí postavení mohl teoreticky získat každý, kdo uměl psát kód. Pro ty, kteří tvrdě pracovali na fórech podpory, psali dokumentaci nebo zajišťovali překlady (kromě jiných podpůrných činností), neexistoval žádný formální způsob, jak postupovat, získat status nebo být uznán. Kodéři dostávali za kód přijatý do jádra podpory, ale pro ty, kteří pracovali nebo přispívali jinde, neexistoval žádný ekvivalentní systém. Když se ozývaly hlasy nespokojenosti, nestěžovali si jen kodéři.
Habariho přístup byl radikálně odlišný. Přístup k závazkům mohl získat kdokoli. Na motivační stránce Habari se píše: “Náš model přispívání je meritokracie. Pokud pravidelně přispíváte do kódu, získáte oprávnění k přímému přispívání (commit access).” Projekt jde v tomto přístupu ještě dál – přístup k revizím nezískali jen programátoři. Owen Winkler, jeden ze zakladatelů projektu Habari, říká: ,,Všichni, kdo se podílejí na tvorbě kódu, mají přístup ke kódování:
Existují lidé, kteří jsou členy revizní komise, kteří jsou součástí primárního řídicího výboru v Habari, a kteří by se nikdy nechtěli dotknout kódu, protože se ve skutečnosti nezabývají vývojem. Ale my jim k němu dáváme přístup, protože prokázali, že jsou součástí komunity a aktivně se snaží Habari jako projekt rozvíjet.
V Habari je přístup k závazkům výslovným projevem důvěry a odpovědnosti. Pokud vytváříte projekt, ve kterém tyto dvě věci nejdou ruku v ruce, má smysl ponechat přístup k revizi pouze jako kontrolní mechanismus. Problém? Pokud lidem v projektu není jasné, co představuje autoritu, stává se přístup k revizím jedním z mála jejích ukazatelů.
Společnost WordPress se vždy zaměřovala na uživatele a na to, aby pro ně zajistila dobré prostředí. Jednou z hnacích myšlenek projektu Habari bylo naopak vytvořit nástroj, který by lidi učil o vývoji, osvědčených postupech vývoje a o tom, že jsou součástí projektu svobodného softwaru. Rich Bowen, který toho o PHP moc nevěděl, řekl, že doufá, že ho to nový projekt naučí. Habari se vyhnul nízké vstupní bariéře WordPressu ve prospěch přístupu, který by kultivoval menší počet, ale silnějších vývojářů.
Habari bylo napsáno v jazyce PHP 5.1, které vývojářům umožnilo přístup k datovým objektům PHP. To poskytovalo úroveň nezávislosti na databázi, kterou WordPress postrádal. Vývojáři systému Habari shledávali vinu na systému WordPress, že nepoužívá nejnovější postupy kódování, zatímco vývojáři systému WordPress měli pocit, že přístup systému Habari staví uživatele na druhé místo. Jak uvedl Ryan Boren:
Kašlat na uživatele, protože si vývojáři chtějí hrát, není v pořádku. Je to dobrý způsob, jak se stát bezvýznamným. Velkým důvodem, proč je WordPress tak populární, je to, že není poblouzněn nejnovějšími, největšími objekty chtíče vývojářů, které vyžadují, aby uživatelé upgradovali svou platformu.
V únoru 2007, kdy Ryan napsal tento komentář, běželo PHP 4 stále na 88,44 % webových stránek. Přijetí PHP 5 bylo pomalé a mnoho webových hostitelů jej nepodporovalo. Kdyby WordPress přešel na PHP 5, stal by se náhle nedostupným na obrovském množství hostitelů, což by narušilo weby uživatelů po celém světě.
Habariho volba licence také znamenala zásadní rozdíly v názorech na FOSS. WordPress používá licenci GPL, jejímž cílem je zajistit svobodu uživatelů. Habari naproti tomu používá licenci Apache, permisivní licenci, která umožňuje vývojářům používat kód jakýmkoli způsobem – dokonce i v proprietárním produktu. Owen Winkler nastínil důvody, proč projekt Habari nepoužívá licenci GPL:
Je tu myšlenka vývojářské svobody. Pokud software poskytujete, měli byste mít možnost jej poskytovat bez jakýchkoli požadavků. Pokud ho chcete vzít a vytvořit software, který budete prodávat, pak to klidně udělejte. Doufejme, že to neuděláte. Doufejme, že budete přispívat. Nebo pokud ano, tak to, co vyrobíte, nějak vrátíte komunitě.
Všechny tyto rozdíly byly nakonec neřešitelné, protože vývojáři se cítili stále více znevýhodněni, přestože se WordPress pomalu měnil. Mark Jaquith, který získal přístup k revizím, zatímco ostatní vývojáři v tichosti pracovali na Habari, vzpomíná: “Cítil jsem se jako […] Matt byl přímo na pokraji uvolnění otěží, měl jsem pocit, že se věci začínají opravdu dařit, a oni odešli. A já jsem si říkal, ach, kdybys tak vydržel.”
Ale nevydrželi. Než otěže povolily, založili si vlastní projekt s vlastními ideály a zaměřením. Když v rámci projektu FOSS existuje kritická masa lidí, kteří nesouhlasí s jeho základním étosem, vždy existuje možnost vytvoření forku. To nemusí být nutně špatně. Než se potýkat s neustálými debatami a bojem, který vyplývá ze střetu přesvědčení, je někdy lepší, když se dvě skupiny oddělí. Každý projekt se pak může laserově soustředit na věci, které jsou pro jeho přispěvatele důležité, a na software a projekt, který chtějí vytvořit.
Zdroj: Github.com – 24. Habari
