OpenOffice.org és a GStreamer

Pár hónappal ezelőtt a StarDivision bejelentette, hogy titokban, cégen belül, a „nulláról” újraírta a GStreamer integrációját. Ezt a nagyszerű hírt a vállalati blogon hozták nyilvánosságra. Megjelent még néhány szórakoztatóan rosszul célzott marketing üzenet is, amelynek középpontjában az Ubuntu állt.

Azonban mit is jelent mindez a Linux-felhasználók számára? Semmit! Ha ez akkora mérföldkő a fejlesztésben, akkor vajon miért nem vesznek ebből semmit sem észre a Linux-felhasználók? Azért, mert a Linux-disztribúciók 2006 óta élvezhetik a GStreamer-támogatást, amelyet a Novell alkalmazásában dolgozó Radek Doulík készített, és amit később, a RedHat szupersztárja, Caolán McNamara látott el javításokkal.

Az igazi kérdés azonban az: miért hívja fel magára a StarDivision a figyelmet egy funkció elkészítésével kapcsolatban, amellyel több, mint 4 évet késett, miközben tovább folytatja a közösségi fejlesztők elidegenítését a projekttől?

Lekésni a bulit

A GStreamer a jelentős vállalati befektetések ellenére sok kézben van, és szemmel láthatóan a hagyományos nyílt forrású szoftverfejlesztési modellt követi.

Annak ellenére, hogy nyilvánvaló volt, hogy a GStreamer a megfelelő háttérrendszer, a StarDivision fogta magát, és elment mellette, és úgy döntött, hogy a JMF-et támogatja. Bár mára elismerik, hogy ez nem volt a megfelelő választás. De mégis, hogyan történt ez?

• 2004. augusztus: a StarDivision elkészítette a Java Media Framework (JMF) támogatást a Solarishoz és a Linuxoz. Ezzel egy időben bejelentették, hogy DirectX-támogatást is készítenek, ami nagyszerű, de ezzel a Linux másodrendű platformmá degradálódott.
• 2004. november: észrevették, hogy ez a megoldás nem lesz megfelelő a Linuxok számára, és figyelmen kívül hagyva Michael Meeks GStreamerre vonatkozó javaslatait, elkezdték a Xine támogatását előkészíteni. Ez valóban jó próbálkozás volt, azonban a Xine használata ütközött a GPL-licenceléssel. Ezidőtájt a StarDivisiont elkezdték bírálni, hogy nem a Javat választja, mivel annak használata házon belül technikailag nyilván egyszerűbb lett volna.
• 2005. február: világos lett, hogy nincs minden rendben. Ekkor születtek javaslatok a Xine és az MPlayer kapcsán, de GStreamer még mindig nem volt sehol.
• 2005. április: Ebben az időben a Helix fejlesztői küldtek be kódot, amit orvosolná ezt a problémát, de ez sosem került be a fejlesztői fába.
• 2006. Radek beküldte a GStreamer támogatás első részét, és hamarosan sikerült kiadni valamit, ami valóban működött is. A Linux-disztribúciók rendkívül gyorsan elkészítették az ooo-build (go-oo) fejlesztői ágból kivett GStreamer-támogatás implementációit. Ez azt jelentette, hogy lehetett egy prezentációban pl. ogg fájlokat lejátszani. Ekkor igazából egy beégetett GStreamer-implementáció készült el, nem pedig egy háttérrendszer kiválasztására alkalmas keretrendszer.
• 2006-2010. Négy éven keresztül a Novell fejlesztői azt javasolták a StarDivisionnek, hogy vegye át a GStreamer-támogatást a go-oo projekt által javasolt LGPLv3 licenc használatával, vagy átruházott szerző joggal (amit a go-oo projekt kevésbé szeretett volna).
• 2010. július:A StarDivision bejelentette, hogy újraírta a kódot.

Hibás érvelés minőséggel kapcsolatban

Egyesek úgy próbálnak érvelni ugyanannak a forráskódnak egy másik, többletfunkciókat tartalmazó ága ellen, hogy a nagybetűs Minőségre hivatkoznak. Nyilván ezt, a csak egy irányban alkalmazható érvelést kell alkalmazniuk, mert különben saját magukat is támadnák. Az ooo-build természetéből adódóan több funkcióval (és hibajavítással) rendelkezik, mint az eredeti fejlesztési ág. Az az érvelés azonban nem túl jó az olyan funkciók esetében, mint a médialejátszás, hiszen a GStreamer-integráció rendkívül stabil (legalábbis bejelentett hiba nincs vele kapcsolatban). De vajon valóban jobb lesz-e a termék minősége, ha nincs médialejátszás a termékben? Tényleg sokkal jobb, hogy nincs semmi, mintha lenne valami?

A minőségre történő hivatkozás másik típusa hasonló célt szolgál, és azt sugallja, hogy az ooo-build hibajavításai borzalmas minőségűek. Ehhez többnyire hozzáfűzik, hogy mindez azért fordulhat elő, mert nincs egy megfelelően lassú és bonyolult minőség-ellenőrző folyamat. És természetesen ott van a hatalmas FUD, amit a programozni nem tudó közösségi emberek terjesztenek, miszerint a kód annyira bonyolult, hogy csak az eredeti fejlesztő tud hozzányúlni.

Természetesen érdekesek az érvelések, de vajon egy kód, ha valóban jó minőségű, akkor miért csak az eredeti programozó tud hozzányúlni? (Mellesleg a kód felülvizsgálata és gondozása hosszabb távon sokkal értékesebb, mint a fekete dobozos tesztelés.) A kód valóban bonyolult tud lenni, de közel sem módosíthatatlan. A FUD-háború közepette azonban sosem jelent még meg egyetlen olyan mérőszámokon alapuló, tényszerű elemzés, amely szerint a hibajavítások valóban rosszak, ez csupán feltételezés.

Természetesen a go-oo fejlesztői sokkal több hibát javítanak, mint amennyit beletesznek a rendszerbe és ezeket a javításokat rendszeresen el is küldik a fő fejlesztői ágba. Ugyanakkor nem mindig olyan könnyű felismerni, hogy mi számít jó kódnak. Úgy látszik ez attól függ, hogy melyik cég írja a kódot, hiszen ha StarDivision tulajdona a kód, akkor az jó minőségű, ha pedig nem, akkor ugyanaz a kód rossz minőségű.

Közösség növekedése

Természetesen ugyanazt a kódot titokban megírni, majd bejelenteni annak elkészültét, nem éppen a fejlesztési közösség épülését szolgálja. Milyen érzés lehet úgy dolgozni a egy fejlesztési projektben, hogy a valószínűleg az általam írt kódot újra fogják írni? Így talán mondani sem kell, hogy a GStreamer újraírása nem az a fajta reklám, amelyre szükség van ahhoz, hogy embereket csatlakozzanak a fejlesztői közösséghez. Ha egy kódon titokban dolgoznak, majd rádobják magasról a közösségre, akkor nem nagyon lehet arra számítani, hogy valaki belenéz, szakértő szemmel értékeli azt, vagy esetleg  a későbbiekben dolgozik rajta. Ez az irány nem egy nyílt és befogadó OpenOffice.org projekt fele vezet.

Sokkal szórakoztatóbb, hogy van egyfajta titkos szövetség a fejlesztésben részt nem vevő üzleti partnerek részvételével, akik stratégiai tanácsot adnak a StarDivision vezetőinek. Érdekes stratégia, hogy ezeket a cégeket ruházzák fel a döntéshozatalra, és nem azokat, akik részt vesznek a fejlesztésben. Ugyancsak érdekes, hogy az új GStreamer-támogatás egyetlen rejtett kódtömb, ahol a tíz forrásmodul fájlneve történetesen az ooo-build ágban lévőével megegyezik, miközben teljesen eltér a windowsos vagy a xine megoldástól. Valószínűleg mindez a véletlen játéka.

De kicsoda?

A többször StarDivision néven említett szervezet annak ellenére, hogy más és más cégek tulajdonolták, általában külön szervezeti egységként működött. Az Oracle felvásárlása azonban csak most záródott le teljes mértékben, mégis egyszerűbb StarDivisionként hivatkozni rájuk. Enyhén szólva szégyen, hogy azt a jó nyílt forrású fejlesztési gyakorlatot és tapasztalatot, ami Sun felvásárlása révén az Oracle háza tájára került, sosem tudták ebben a szervezeti egységben hatékonyan bevezetni.

Az OpenOffice.org magasra teszi a mércét a szoftverkorlátozások innovációjában: a StarDivision nem csak birtokolni akarja a beérkezett kódot, de azt kizárólagosan akarja birtokolni.

Üzleti modell

Nyílván komolyabb üzleti érdekek állhatnak az egész mögött, mint ami látszik. Nem is biztos, hogy üzleti szempontból, információ hiányában megfelelően értékelni lehet a helyzetet, de talán elemezhető, hogy mik az előnyei és hátrányai a belső fejlesztésnek a szabad licencű fejlesztéssel szemben:

A meglévő kód elfogadásának és használatának előnyei:

• nem kerül semmibe,
• a StarDivision fenn tudja tartani jelenlegi szerződéseit és el tud adni újakat,
• a közösség nem darabolódik szét,
• a fejlesztők a munkájukra tudnak koncentrálni,
• nincs az a látszat, hogy az erőforrások pazarlása folyik.

A kód újraírásának előnyei:

• Kizárólagos kódtulajdonlás: bárki, akinek szüksége van e kis kódrészlet jogaira, csak hozzánk fordulhat, nincs szabadon licencelt alternatíva.
• Macsó magatartás: verjük meg a szemüveges gyereket, hadd tudja, hol a helye!
• Más nem jut eszembe…

Ez nem azt jelenti, hogy a StarDivision vezetése aktívan rosszindulatú, sőt ők biztosan rendkívül értelmesek, ezért valószínű, hogy rengeteg előnye vannak annak, hogy a kódot újraírták. Léteznie kell értelmes oknak, de vajon mi az? Valóban megéri a fejlesztési előforrások szétforgácsolása és elfecsérlése, a meglévő, tesztelt és működő kód újraírása és a közreműködők elküldése csak azért, hogy biztosítva legyen a StarDivision tulajdonjoga? Ez valóban a nyíltságot jelenti? Mennyire valószínű, hogy a külső fejlesztők fogják újraírni és kijavítani az OpenOffice.org kódbázisának nagy részét a következő évtizedben csak azért, hogy hígítsák a StarDivision kizárólagos tulajdonrészét?

Ez nem egy kompetitív anyagnak készült, nem arról van szó, hogy mondjuk a Novell Edition évekkel a StarDivision fejlesztői előtt jár, de az bizonyos, hogy a legjobb szoftverek akkor készülnek, ha mindenki összefog, és a különböző cégeken belül dolgozó fejlesztők együttműködnek, hogy mindenki számára egy jobb OpenOffice.org készülhessen.

Összegzés

Igazából nem hír, hogy a StarDivision újraírt egy, a közösség által fejlesztett kódrészletet, amelyet majd 6 hónap múlva fog megjelentetni, az OOo 3.4-ben. A hír azonban rámutat egy zárt, titkos és haszontalan fejlesztési folyamatra. Természetesen ilyen jellegű, semmit mondó hírek továbbra is várhatók, ha a vezetés elveszti a hitét a közösségben, és inkább az erőforráspazarlást támogatja a közös munkával szemben. Ebben az esetben a következő lépés elég egyértelmű: még több erőforráspazarlás fog történni.

Sajnálatos módon ennek mellékhatása, hogy a fejlesztési tennivalók egyre sokasodnak és újabb falakat húz azok közé, akiknek érdeke a kódbázis jobbá tétele. Az OpenOffice.org csak erősödhet, ha az összes közreműködő együtt dolgozik. A közös munka alatt pedig az átlátható, tisztességes szabályok által meghatározott közreműködést kell érteni, nem pedig a hátsó szobákban zajló titkos megállapodások kuszaságát. Nehéz optimistának lenni a StarDivision jövőjével kapcsolatban, pedig éppen most kezdik komolyabban venni a Linux-integrációt, ami alapvetően igenis jó dolog.

Valamilyen szinten szomorú látni olyan 2500 sor kód újraírását, amelyet nem kellett volna újraírni. Jelenleg az ooo-build 673 ezer sornyi patchet tartalmaz, így ez a kódnak csupán 0,4%-át érinti.

Ez az írás többek között azért született, mert a bejelentés oldalán törölték számos Novell fejlesztő hozzászólását, akik reagálni próbáltak bizonyos ott elhangzott kijelentésekre. Később a hozzászólások ismét engedélyezve lettek, és az érvek között ismét felbukkant a minőségre való hivatkozás. Erre csak azt lehet mondani, hogy a teljesen cserélhető médiaalrendszer, ahol választani lehet a Xine, az MPlayer, a JMF és a GStreamer között, elhibázott ötlet. Ezért került kötött módon a GStreamer-támogatás  a kódba. Ámbátor igaz, hogy a patchként való kezelés miatt a go-oo-ban korlátozott volt a lehetőség a kód refaktorálására.

A hozzászólásokból látszik, hogy nem ez az első eset, hogy valamit a StaDivision újraírt. Erre a sorsra jutott a GStreamer mellett a 64 bites Linux verzió, a natív Mac verzió, a gyorsabb indítás, a solver, az egymás melletti lapmegjelenítés, az élsímítás, az SVG-támogatás. A gyors körlevélfunkció pedig még várat magára. Vajon mikor lesz mindebből elege a fejlesztői közösségnek?

Ez a bejegyzés Michael Meeks blogbejegzései alapján készült.