Az FSF.hu Alapítvány 2009-ben kiírt Szabad Szoftver Pályázat 2009 pályázatán 7 pályaművet támogatott mintegy 3 millió forint összeggel, köztük a „Hasznos OpenOffice.org kiterjesztések fejlesztése” elnevezésű pályázatot is. A pályázat célja olyan kiterjesztések megírása, amely az OpenOffice.org közösség által régen hiányolt funkciókat valósít meg.

A kiterjesztésekről
A „Munkafüzet-dokumentumok lehetséges hibáinak felkutatása” kiterjesztés fejlesztése; Az ellenőrzés többek között ezekre a területekre terjed ki: Azon szövegként tárolt számok jelzése, amelyek képletekben kerültek felhasználásra; Számot tartalmazó cellák, amelyeket egyetlen képlet sem használ fel; Üres cellák, amelyet referenciaként használtak fel.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/validator

Figyelőablak (Watch Window) fejlesztése Calc programhoz; A figyelőablak segítségével a kiválasztott cellák értékei és az értékek változásai egy külön megjelenő, mindig látható ablak segítségével a felhasználó számára is jól követhetővé válik.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/watchwindow

Diagram készítő (szervezeti, gyűrű, venn és piramis diagramok támogatásával) kiterjesztés fejlesztése.
A kiterjesztés elérhető az OpenOffice.org Extension webhelyről:
http://extensions.services.openoffice.org/en/project/diagram

A pályázat keretén belül készült kiterjesztések forráskódja elérhető lesz ezen a helyen:
https://ooop.svn.sourceforge.net/svnroot/ooop/

Hibajelentést igénylése a következő linken lehet tenni:
https://sourceforge.net/apps/trac/ooop/wiki ]]> http://www.openoffice.hu/2010/09/palyazat-2009-hasznos-openoffice-org-kiterjesztesek-fejlesztese/feed/ 0 http://www.openoffice.hu/2010/08/openoffice-org-konferencia-2010/ http://www.openoffice.hu/2010/08/openoffice-org-konferencia-2010/#comments Fri, 27 Aug 2010 14:36:34 +0000 KAMI http://www.openoffice.hu/?p=1198

Már csak öt nap és kezdődik az egyik legérdekesebb informatikai témájú konferencia. Az OpenOffice.org Konferencia a népszerű szabad szoftver, az OpenOffice.org irodai programcsomag éves közösségi seregszemléje, ahol kiváló lehetőség kínálkozik arra, hogy a fejlesztők és a felhasználók, tehát közösség tagjai, találkozzanak egymással. Természetesen az érdekes előadásokra és közösségi programokra a szervezők várnak minden leendő felhasználót is és érdeklődőt is, akik számára teljesen ismeretlen még az OpenOffice.org.

A OpenOffice.org Konferencia 2010. augusztus 31-től szeptember 3-ig tart, amelynek helyszíne a Közép-Európai Egyetem lesz. A konferenciára a regisztráció a regisztrációs oldalon vagy a helyszínen történik. A konferencia teljes idejére szóló belépő ára 3000 forint, a kedvezményes belépő (diákoknak, válságban lévőknek) 600 forintba kerül.

Az OpenOffice.org teljesen ingyenes, tetszőleges célra felhasználható irodai programcsomag, amely szövegszerkesztésre, táblázatkezelésre, bemutatókészítésre, rajzolásra és adatbázis-kezelésre alkalmas. Legyen az magán, oktatási, a kormányzati, a közigazgatási vagy üzleti célú felhasználás az OpenOffice.org azonos feltételek mellett és ingyenesen vehető igénybe. Ezenfelül szabadon terjeszthető családtagoknak, barátoknak, diákoknak és alkalmazottaknak is.

Németország, Franciaország, Szlovénia, Spanyolország, Kína és Olaszország után Magyarországra érkező konferencia különlegessége, hogy idén 10 éves a programcsomag, ennek megfelelően a szervezők a szokásosnál is színesebb közösségi programokkal várják a résztvevőket. Mindenki számára szórakoztató lesz a kiállítással és koncertekkel egybekötött ingyenes születésnapi buli a Gödör Klubban, amelyre szeptember 1-én kerül sor. A további programokról itt lehet olvasni. Az eseményről friss információk a honlapon, a wiki oldalon és a Facebookon olvasható. ]]> http://www.openoffice.hu/2010/08/openoffice-org-konferencia-2010/feed/ 0 http://www.openoffice.hu/2010/08/szabad-szoftver-konferencia-2010-szeged/ http://www.openoffice.hu/2010/08/szabad-szoftver-konferencia-2010-szeged/#comments Thu, 19 Aug 2010 12:15:41 +0000 timar http://www.openoffice.hu/?p=1195

Ebben a változatban alig történt változás, ennek egyik oka a fejlesztők száma megfeleződött, egy főre csökkent és így csak a hibák javítására maradt idő és energia.

A betervezett HSQLDB 2.0-ra való átállás a HSQLDB 2.0 késői megjelenése miatt (2010. június 7.), várhatóan a 3.4 változatra csúszik.

Elkészült két kiterjesztés, amelyek az OpenOffice.org Calc programjához nyújt – reményeink szerint – hasznos adalékot.

1) Watch Window
A Watch Window kiterjesztéssel megjeleníthető a figyelőablakban minden olyan cella, amelynek változásait követni szeretnénk függetlenül attól, hogy éppen melyik cellákat látjuk.

A kiterjesztés letölthető:
http://extensions.services.openoffice.org/en/project/watchwindow

A kiterjesztés telepítés után elérhető:
Calc: Eszköz – Detektív – Figyelőablak megjelenítése menüből.

2) Validator
A Validátor egy OpenOffice.org kiterjesztés, amely a kiválasztott szabályok alapján ellenőrzi a cellákat.

A kiterjesztés letölthető:
http://extensions.services.openoffice.org/en/project/validator

A kiterjesztés telepítés után elérhető:
Calc: Eszköz – Detektív – Validátor menüből.

Próbálja ki ezeket a kiterjesztéseket és visszajelzéseivel, új ötletekkel vagy bármilyen más módon járuljon hozzá a kiterjesztések továbbfejlesztéséhez.

A kiterjesztéseket Hornyák Tibor és Szalai Kálmán készítette együttműködésben a Szegedi Tudományegyetemmel és az OxygenOffice Professional Csapattal.

Támogatta a Free Software Foundation Hungary Alapítvány a Szabad Szoftverek Magyarországi
Népszerűsítéséért és Honosításáért, a Projekt 2009 keretein belül megítélt támogatással.

A munka még nincs kész, hiszen a meglévő kiterjesztések – felhasználói visszajelzések alapján történő – továbbfejlesztése mellett hamarosan jelentkezünk a vállalt feladatoknak megfelelően a Draw programhoz szánt kiterjesztéssel is.

Jó Calcolást!

A könyv pdf formátumban letölthető innen. A 2. kiadást az FSF.hu Alapítvány aktivistái, Tímár András és Zahemszky Gábor készítették el.

Az OxygenOffice Professional letöltése
http://ooo.itc.hu/oxygenoffice/download/
http://sourceforge.net/projects/ooop/files/

További információk
http://user.services.openoffice.org/hu/forum/viewtopic.php?t=514

Több száz nemzetközi fejlesztő, multinacionális döntéshozó, nagy nevű hazai és nemzetközi előadó érkezik Budapestre szeptember elején, hogy részt vegyen a világ talán legrangosabb nyílt szoftveres eseményén, az éves nemzetközi OpenOffice.org konferencián. A konferencia három napján az egész világ Budapestre figyel majd, hiszen a kis fejlesztő cégek és az OpenOffice.org mögött álló, nyílt szabványokat támogató multinacionális vállalatok – IBM, Oracle, Novell, Google – erre az alkalomra szokták időzíteni fontos bejelentéseiket. Ráadásul az idei jubileumi év rendkívül sikeres volt: a szoftver újabb változatait több, mint 157 millióan töltötték le.

Az eseményt a magyarországi Nyílt Dokumentumformátum Szövetség szervezi. A plenáris ülésnek a Parlament ad otthont – szimbolikus helyszín, hiszen számos civil szervezet, vállalat évek óta küzd azért, hogy a hazai közigazgatásban, az oktatásban, az állami szférában a nyílt ISO szabvány ODF, nyílt dokumentum formátum és általában a nyílt szabványok, valamint az ezekre épülő szoftverek a helyükre, az államigazgatási és intézményi felhasználók gépeire kerüljenek.

Az OpenOffice.org Konferencia 2010 rendezvény 2010. augusztus 31-től és szeptember 3-ig kerül megrendezésre, a konferencia fő helyszíne a Közép-európai Egyetem lesz.

Az OpenOffice.org Konferencia 2010 honlapja

Regisztráció a konferenciára

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.”

Eddig öt hibát jelentettem be az OpenOffice.org Issue Trackerébe, a feldolgozatlan hibák között még lehet több is. Ezeket a súgó fejlesztőinek kell javítaniuk a forrásban.

Ami a folytatást illeti, át kell gondolni, hogy hatékony-e a „hétvége” forma, esetleg rá lehet-e venni az embereket folyamatos munkára kötetlenebb időzítéssel. Tegnaptól fogva már az OpenOffice.org 3.3 fordításán kell dolgoznom, ezért a 3.2.1 súgójának bejelentett hibáit mielőbb javítani szeretném, és a következő ellenőrző körben már a 3.3 bétát kellene nézni. Természetesen az adminisztrációs oldal nincs befagyasztva, az ott kitűzött feladatot is be lehet fejezni, szerintem 95% a valószínűsége, hogy a bejelentett hibák a 3.3-ra is vonatkoznának.