Az OpenOffice.org a nyílt forráskódú szoftverek zászlóshajója: a projekt több száz millió letöltést ért el, és valós alternatívát nyújt a kereskedelmi szoftverekkel szemben. Azonban a felszín alatt, egy ideje az elégedetlen fejlesztők moraja hallatszik, akik meg is fogalmazták aggályaikat a nem válaszolók/vezetés hiánya wikibejegyzésben is. Az elhangzó érvek nem arról szólnak, hogy maga a projekt rossz, hanem arról, hogy az OpenOffice.org projekt a jelenleg felmutatott eredményeinél sokkal több kellene, hogy legyen; hogy a projekt irányítása nem felülről lefele hozott döntéseken kellene, hogy alapuljon, valamint, hogy a fejlesztőknek nagyobb szabadságot kellene adni.

Habár az OpenOffice.org szabad licenc alatt jelenik meg, a szerzői jogok, amelyek a belső és külső hozzájárulókat illetné, mind az Oracle/Sun cégre tulajdonába kerülnek és az OpenOffice.org fejlesztési ütemét és irányait az Oracle/Sun diktálja.

Ennek a folyamatnak az egyik legnagyobb kritikusa a Novell alkalmazásában álló GNOME és OpenOffice.org fejlesztő, Michael Meeks. Meeks azt állítja, hogy a szerzői jog átruházása visszafogja a külső hozzájárulók munkakedvét, és a több mint buzgónak mondható projekt feletti ellenőrzés gátolja a fejlesztői kezdeményezéseket.

Meeks véleménye szerint, az OpenOffice.org projekt a nem igazán nyílt és átláthatatlan projektvezetés miatt nem képes magához vonzani és megtartani az egyéni és a cégek által finanszírozott fejlesztőket. Ez az ami gátolja az OpenOffice.org növekedését.

Vajon miért?

“Egy egészséges projektnél elvárható lenne a nagyszámú önkéntes fejlesztő” – írta Meeks. “Ezenkívül sok céget is szívesen látnánk, akik ugyanabból a kódbázisból dolgoznak, és ugyanahhoz a fejlesztői fához járulnak hozzá. De nem ezt látjuk. Sőt, éppen az ellenkezője történik: az aktív egyéni fejlesztők száma a projekt életútja során most a legalacsonyabb.”

“A Sunhoz kötött fejlesztési folyamat gátolta mindazt a fejlesztési kreativitást, ami a nyílt forrású projektek egyik meghatározó ismérve. A fejlesztők nem szívesen járulnak hozzá a projekthez, mert az ösztönzés teljesen hiányzik. A sikeres nyílt forrású projektek általános jellemzője, hogy a fejlesztők vezetik őket, nyitottak, zajosak, okoskodók, megosztók, kaotikusak… és produktívak. És ez így működik.”

A Meeks által felvetett problémák egyszerűek: az OpenOffice.org projektnek felül kellene vizsgálnia a tulajdonjogi és licencelési struktúráját. “Sokkal jobb lenne, ha csak hagynánk az embereket közösen dolgozni, hogy összpontosítani tudjanak a műszaki problémákra, ahelyett, hogy alapvető dolgokon menne a marakodás.”

Ez az Oracle számára érdekesnek ígérkezik mutat rá Meeks: “Nem véletlenül említettem a Sun nevét, hiszen a szervezet még mindig nem egyesült az Oracle-lel, ezért várni kell, hogy mit tesz majd az Oracle.”

Összefogás

Az alapvető probléma Meeks és a többi fejlesztő számára a fejlesztés és a hibajavítás lassúsága. Valahogy ösztönözni kellene az Oracle/Sun-t, hogy visszajelzéseket adjon, innovatívabb legyen és felgyorsítsa a fejlesztés ütemét, hiszen ezek mind a sikeres nyílt projekteknek jellemzői. Néhány fejlesztő szerint egy független alapítvány lenne a megoldás, mint amilyen a Mozilla, KDE vagy a Gnome esetében is megvalósult. Meeks azonban ambivalens érzéseket táplál ezen megoldás kapcsán: “Egy független alapítvány számos kérdést vet fel, hiszen lehetsz egy Mozilla-szerű alapítvány. Ők nagyon sok jó dolgot csinálnak, de van egy szerencsétlen instabilitás abban, ahogy egyetlen nagy szervezet csinál mindent. És ott vannak a finanszírozási kérdések is. A Mozilla finanszírozási modellje nem működne az OpenOffice.org esetében, így meg kellene kérdezni a cégeket, hogy hajlandók lennének-e fejlesztőket foglalkoztatni. Ez egy elegáns megoldása lenne a problémának. Sokkal jobb lenne, ha minden cég fejlesztőket alkalmazna és ezek az emberek közösen dolgoznának, ahogy az a Linux, Gnome, vagy a KDE esetén is szemmel láthatóan működik. A függetlenség jó dolog, de elvenni az Oracle tulajdonát meglehetősen nehézkesnek tűnik. Személy szerint csupán lehetőséget biztosítanék az emberek számára, hogy együtt dolgozzanak, olyan ésszerű kompromisszumokat kötnék, amelyek azt sugallják, hogy érdemes együtt dolgozni.”

“Az lenne az ideális, ha az upstream projektet kevésbé erős kézzel szabályoznák. Nincs igazából üzleti oka a szétválásnak, sőt a közös munka éppen üzleti okokból lenne jelentős, hiszen nem kellene ugyanazt a munkát többször elvégezni és kifizetni, amit már valaki valamely liberális licence alatt már megírt. Teljesen nonszensz, hogy két cégnél pontosan ugyanazon a funkción dolgoznak. Nem igazán lehet szavakkal kifejezni, hogy ez mennyire értelmetlen. Mindenki számára a közös munka lenne az ideális. A kérdés csak az, hogy akkor miért nem ez történik?”

Minden hiba egy funkció

Az OpenOffice-t eredetileg a StarDivision fejlesztette StarOffice néven, amelyet a Sun Microsystems 1999-ben megvásárolt. Simon Phipps, volt Sun alkalmazott szerint “a legfontosabb oka a StarDivision felvásárlásnak az volt, hogy abban az időben a Sun alkalmazottainak száma elérte a 42 ezret és minden munkatárs rendelkezett egy Unix-munkaállomással és egy windowsos laptoppal. Olcsóbb volt megvenni egy céget, amely irodai alkalmazást fejlesztett Solaris és Linux operációs rendszerre, mint 42 ezer Microsoft Office licencet venni a Microsofttól.” Hasonló érvek mentén vásárolta fel annak idején az IBM a Lotust, akik akkoriban levelezőrendszert kívántak bevezetni.

A Sun megnyitotta a StarOffice forráskódját a közösség számára, ugyanakkor a folytonosság biztosítása érdekében megtartotta a tulajdonjogokat és a fejlesztés feletti felügyeletet, mind a StarDivision, mind a korábbi fejlesztők felett. Ennek eredményeképpen a StarOffice nyílt forrású fejlesztése rengeteg védett, zárt forrású szoftverekre jellemző fejlesztési folyamatot örökölt meg a StarDivision-től, amelyre a merev vízesés fejlesztési modell, és a saját fejlesztési eszközök használata volt jellemző.

“Számtalan komoly probléma van a Sun-on belül” – mondta Meeks. “Először is a minőségbiztosítási osztályon. Például, azt mondták, hogy nem értik hogy a Gyorsindító hogyan működik Unix-on a teljes specifikáció, a képernyőképek, a funkcióleírások, valamint a Sun felhasználói élmény és dokumentációs csapat jóváhagyása nélkül. Mindenkit be kellett volna vonni a specifikációba, majd megírni a kódot…”

“Eddigre már el is felejtetted, hogy mi volt az, amit el szerettél volna érni, elvesztetted az ösztönzést a változtatáshoz. Ez a merev fejlesztési modell pontosan ellentéte a nyílt forrású projektekben végzett munkának. Nyilvánvalóan lehet beszélni a végfelhasználói közösség marketingértékéről, de ha végül elveszítjük a fókuszt a fejlesztőkről, és a közreműködés az OpenOffice.org projektben nem működik tisztességesen és még csak nem is szórakoztató, akkor egyáltalán nem lesz vonzó a fejlesztők számára.”

Mindezek mellett Meeks más lényeges problémára is rámutatott. “Szeretném hangsúlyozni, hogy vannak emberek a Sunon belül, akik mindezt értik. Olyanok, akik nyitottak, segítőkészek és nagyon jó szakemberek. Ugyanakkor egy nagyon nagy részük, tradicionális módon és higgadtan végzik a munkájukat, különösen a minőségbiztosítási osztályon. Nem lehet velük vitatkozni, mert önigazoló világnézettel rendelkeznek. Azt mondják az előírások szükségesek a termék minősége miatt; azt mondják, hogy ez jó, de a minősége még nem elég jó. Szerintük több specifikáció kell, a válaszuk mindig ugyanaz, és nem lehet velük vitatkozni. Ez elavult termékhez vezet, vagy ahogy mondani szoktam a minőség elavultsághoz vezet. Anélkül, hogy a kódon módosítanának, minden hibát funkcióként specifikálnak és végül azt mondják, hogy “hé, ez hibamentes!”, ahelyett, hogy valóban módosítanánk, javítanánk és fejlesztenék a terméken.”

Miért nem teszik?

A projektnek Meeks szerint csak “vezetésre, néhány elképzelésre és a változásra való hajlandóságra” van szüksége. “Nagyon könnyű eltévedni számos különböző típusú probléma közt, különösen a fejlesztői oldalon, és nem válnak láthatóvá a nagyobb szerkezeti problémák, így azokat nem is lehet javítani.”

“Néhány problémát meglehetősen egyszerű javítani, de nem javítják őket. Nem hiszem, hogy ezen olyan bonyolult lenne változtatni. A jelenlegi tulajdonosi helyzet vezetett ehhez a működésképtelen csoportmunkához, és a lehetőségekhez képest sokkal kevesebb közreműködőhöz. A vezetők végső soron örülnek annak, hogy van egy kódjuk, ami az övék, sőt biztosak lehetnek benne, hogy senki nem férhet hozzá, vagy módosíthatja egyszerűen. A szerzői jog átruházása önmagában nem elháríthatatlan akadály, de a projekt licence és a teljes tulajdonjog között lévő szakadék igen. Természetesen mi az LGPLv3 licencet részesítjük előnyben mindenféle tulajdonosi jog nélkül, de a Sun ezt nem fogadta el. Talán van értelme a tulajdonosi jogokat átadni a Sun számára, de egy sokkal liberálisabb licenc alatt.”

“Van egy nagyszerű termékünk, ehhez nem fér semmi kétség. De ahhoz, hogy olyan sebességgel fejlődjön, ahogy szeretnénk, ahhoz, hogy bővítsük a funkcionalitást és hogy megnyerjük a versenytársakkal folytatott funkció- és teljesítményharcot, ahhoz együtt kell dolgoznunk. De nem látom, hogy a fejlesztői közösség létrehozása prioritás lenne, nem látom a döntéseket, amelyek efelé vezetnének.”

Felejtésre kárhoztatva

“A tulajdonjogok átadása logikus és viszonylag jelentéktelen a cégek számára, azonban nagyon fontos az egyéni és a cégek által foglalkoztatott fejlesztők számára. A tulajdonjog átadása azonban megnehezíti a kód máshol történő újrahasznosítását és a saját kód máshol történő újralicencelését. Például, a Sun arra használja az OpenOffice tulajdonjogát, hogy a Microsofttal szabadalomvédelmi egyezséget kössön, holott a licenc erre nem ad lehetőséget. Valójában a szellemi tulajdonjog megsértése merült fel a múltban az OpenOffice kapcsán.”

“A Sun egyik ellenérve a nem tulajdonolt kódok OpenOffice-ba történő beolvasztásával szemben az, hogy a kiterjesztésekkel bármit meg lehet csinálni és bármi megtalálható a kiterjesztések online gyűjtőhelyén. A szomorú valóság azonban az, hogy ezt a megközelítést alkalmazva néhány nagyon jó funkció található a bemutató programhoz, de senki sem tudja, hogy egyáltalán léteznek. Másrészről a kiterjesztések korlátozottan alkalmazhatók. Havonta 1 millió OpenOffice letöltésre 10 ezer kiterjesztésletöltés jut, vagyis a felhasználók 1%-ához jut el. Ez nem más, mint felejtésre kárhoztatni ezeket a funkciókat.”

Egy halom ellentmondásos és összeférhetetlen licenc létezik. A Sun a GPL alatt megjelenő MySQL kliens programkönyvtárat az OpenOffice részeként jelenteti meg LGPLv3 licenc alatt, annak ellenére, hogy a forráskód GPL. “Nemrég az FSF felhívta a figyelmet erre a problémára és bejelentett egy projektet, amely összegyűjti azokat a kiterjesztéseket, amelyek valóban szabad szoftverek.”

“Csak gondoljuk el, hogy egy vállalati felhasználó le akar tölteni egy programot valamely, aláírással nem rendelkező oldalról és futtatni akarja a hálózatán. Ez alapvetően szembemegy azzal az irányelvvel, hogy egy ilyen környezetben egy internetről letöltött programot nem szabad használni, vagy futtatni. Semmilyen minőség-ellenőrzés nincs a kiterjesztésekkel kapcsolatban. A Novell összeszedi ezeket a kiterjesztéseket és a program részeként telepíti azokat. Így a felhasználóknak nem kell ezeket összevadászniuk.”

A világ legbénább márkaneve

Ezekre a jelenségekre a Novell, Meeks vezetésével létrehozta a go-oo.org projektet, amelyről Meeks azt nyilatkozta, hogy “A go-oo első számú feladata az, hogy a világ legbénább márkaneve legyen. És tényleg a legszörnyűbb név, amit el lehet képzelni, azonban egy remek hely arra, hogy mindazt megtegyük, amit a Sun nem. Először csak a forráskódot tettük kereshetővé és ellenőrizhetővé. Ezzel egy hatalmas kódalapot hoztunk létre a Linux disztribúciók számára, amelyek rendszeresen saját javításaikkal látták el az OpenOffice verziókat a saját kiadásukhoz. Itt tartunk most. Rengeteg disztribúció táplálkozik a go-oo kódjából és készítik az OpenOffice buildeket a Debian, RedHat, Ubuntu, Mandriva és Frugalware disztribúciókhoz. Természetesen a Novell is ezt használja a SUSE alapú disztribúcióihoz. Ezáltal a kód olyan funkciókkal és javításokkal gazdagodott, amelyek valószínűleg sosem lesznek az upstream OpenOffice részei, hiszen ezek szerzői jogait a fejlesztők, vagy éppen a Novell egyszerűen nem akar átadni a Sun részére.”

Ebben az időben adta ki az IBM a Symphony új verzióját, amelynek alapját a Sun-féle OpenOffice adja. A Symphony korai verziói a SISSL licencelésű OpenOffice.org-on alapultak. “Én mindenkinek ajánlom a Symphonyt. Ez az OpenOffice egy szerencsétlen forkolásának az eredménye, de az új verzió már sokkal gyorsabban indul, mint korábban, sokkal jobban néz ki és most már sokkal frissebb OpenOffice.org kódon nyugszik. Néhány funkcióval kapcsolatban nagyon szoros az együttműködés az IBM fejlesztőivel. Nagyon jó termék, de az ördög a részletekben rejlik.”

“Egyes komponenseknél visszakapjuk a fejlesztéseiket, látjuk, hogy miket módosítanak, de a Symphony más részei nem nyílt forrásúak és a kódok nem elérhetők el. Amennyire én tudom az IBM ezt egy termékbe ágyazva szállítja, tehát biztosan nem LGPLv3 alatt jelent meg. Sajnos az IBM nyilvánvalóan ellenszenvesen viszonyul a GPL-hez, így nagyon nehéz elképzelni, hogy milyen licenc alatt is terjeszti ezt az OpenOffice változatot, ráadásul rengeteg olyan kód van benne, amit én írtam, amit a Novell írt, amit más emberek írtak. Vajon hogyan lehetséges ez? Ez rendkívül sajnálatos dolog és ezeknek az anomáliáknak elő kellene segítenie a Sun által vezetett projekt átláthatóságát és a növelnie kellene a vele kapcsolatos bizalmat. A kód korábban a Sunhoz került és biztos vagyok benne, hogy itt jogi probléma van. Rengeteg fejlesztő jóhiszeműen átadta jogait a Sun számára, abban a hiszemben, hogy jól fog vele gazdálkodni. Ez talán így is van, de ezt lehetetlen megállapítani anélkül, hogy megtudnánk, hogy más, harmadik fél hogyan is szállíthatja az általuk írt kódot.”

Fenn és lent

Meeks szerint a fejlesztők közötti kommunikáció hiányát, a Sun projektvezetésének bürokratikus merevségét, a következetesen lassú fejlesztési és hibajavítási ütemet a Sun minőség-ellenőrzési osztálya okozza. Ennek ellenére érti a Sun hozzáállását is, hiszen “Ha csökkentjük a kódban végbemenő változások számát, akkor teoretikusan növekszik a kód minősége. Efelől semmi kétség. Azonban az igazán jó minőségű szoftver fejlesztéséhez több út is vezet.”

“A legnagyobb baj, hogy nem az elejéről fogunk hozzá a dolgoknak. Az OpenOffice.org-nak vannak minőségi problémái – talán kevesebb, mint korábban, ami biztató –, de minden esetre vannak. Ennek megfelelően, ha lassítják a fejlesztést, akkor javul a minőség… de mi alapján? Érdekes módon a Linux kernel minősége folyamatosan javul, miközben a kód változásának sebessége megdöbbentő módon gyorsul, tehát valószínűleg másképp dolgoznak. Lehet hogy lefele kell menni a hegyről, mielőtt találsz egy jobb utat felfelé. Lehet, hogyha kicsit pihenni hagyjuk a minőség-ellenőrzési osztályt, akkor a dolgok rosszabbra fordulnak. De ha radikálisan hagyjuk növekedni a módosítások számát, akkor a hibák valószínűleg gyorsabban javításra kerülnek.”

Ha a valaki a fejlesztési modell felett túlzott kontrollal rendelkezik, akkor az elveszti a nyílt szoftverek fejlesztési modellel járó előnyöket. A cégek igen önző okból vesznek részt egy nyílt forrású projektben: mert működik és fele akkora befektetéssel kétszer akkora eredményt hoz. De sokkal valószínűbb, hogy sikerül még önzőbb céljaikat is elérni, ha megengedőbben viszonyulnak a projekthez, és a fejlesztőket hagyják saját céljaikat elérni.

“Optimista vagyok, hogy amikor az Oracle befejezi a Sun német részlegének beolvasztását, akkor válaszokat kapunk bizonyos kérdésekre, hiszen mi nagyon egyszerű dolgokat kérünk, amelyek ráadásul nincsenek hatással az Oracle üzletmenetére. Nem ártunk az üzleti érdekeiknek, éppen ellenkezőleg. Egyszerre akarjuk növelni, mind az övükét, mind a sajátunkat.”