k:blog

mostanság nem nagyon van időm írni. mondhatnám azt is, hogy ez jó, mert akkor biztos sok roppant fontos dolgot csináltam, de nem így van és ez nem jó… most megszámolva 23 félkész írásom áll a talonban, aminek fele, már aktualitását vesztette. ezért most úgy döntöttem, hogy folytatásokban adok le írásokat, amiket aztán ha kész vannak egyesítek. darabokban talán nem lesz megterhelő olvasni sem :) és nem érzem úgy, hogy mindent félbehagyok…

[erről jut eszembe, már arra is gondoltam, hogy a trójai háború történetét leírnám folytatásokban, tömören, mert nemrég újra elkezdtem bele-bele lapozgatni és rendkívül érdekes és izgalmas, és sokan hollywoodnak köszönhetően máshogy vélnek dolgokat és talán ez az oldal is érdekes lehet]

a “nyílt forráskód szomorú helyzete napjainkban” címmel megjelent nem kis terjedelmű írásra sokan felkapták a fejüket, és számomra valóban érdekes volt. újra elkapott az az érzés, hogy nem feltétlenül abba az irányba mennek a dolgok, ahogy és ahova néhányszor kellene és a fejekben nagy káosz van. a voice community értetlensége pedig további mélységeket mutat.

planéte béranger: the sorry state of the open source today

amikor először olvastam ezt a véleményt, teljes, világos, reflexszerű válaszaim és véleményeim születtek. ekkor azt gondoltam, hogy hiba lenne reflexből írni valamit, illetve egy ilyen méretű anyagnak ülepednie kell. eltelt egy hónap és újra elővettem. én nem egybefüggően szeretnék reflektálni az írásra, inkább a gondolataimat osztanám meg pár megjegyzéssel kapcsolatban, amelyek felmerültek bennem, és talán most egy leülepedett változat születik.

tehát az írásból kiemelek részeket, amik gondolatokat ébresztettek bennem…

Say, once the code is in the open, bugs can be easily noticed, and the necessary fixes and cleanup come at ease. Well, at least in theory, as nowadays’ code is complex.

annak ellenére, hogy a nyílt forrás nyújt egyfajta biztonságot, a források komplexitása nem teszi lehetővé, az egyszerű ellenőrzést. ha mondjuk az ooo-ban van egy olyan kis rész, ami eltárolja a dokumentumaimat és elküldi egy emailcímre, akkor ezt nem nagyon veszem észre, azonban akit érdekel, az észrevehetné. és itt jön a különbség. egy nyílt forráskódú projektbe öngyilkosság a nem megfelelően ellenőrzött forrás bevétele a verzióban, mert amennyiben az rosszindulatú, ártó stb., akkor a projekt szépen kinyírná magát és valószínűleg egy jó kis fork után hamvaiból és más néven éledne újjá. (más kérdés, hogyha ez egy nagy és hiteles projekt, akkor az egész nyílt forrású közösséget lejáratná és remélem most nem ötleteket adok ezzel valakiknek :( )

tehát mindenképpen az a jó megfogalmazás, ha azt mondjuk, hogy a nyílt forráskódnál a végfelhasználó szempontjából elvi lehetőséget nyújt a biztonság megítélésére.

ez az elvi megoldás azonban hatalmas biztosítékot is jelent, mert „ha van egy cracker thaiföldön, aki beszennyezi a kódot, mindig lesz egy finn egyetemista aki veszi a fáradtságot, hogy azt megtalálja és kijavítsa”.

erről jut eszembe egy másik érdekes cikk:

‘debunk mythology around open source’

és mielőtt beállnék a pfujolók népes kórusába azt hiszem néhány gondolatot innen is kiragadnék. a hangzatos mondat, amelyre a sajtó, (igen, megint a szeretett média) felfigyelt, az nem más, mint bill hilf, az ms linux laborjának vagy mijének vezetőjének szájából került elő:

the free software movement is dead.
linux doesn’t exist in 2007.

azt hiszem bill nagyon jól érzi, hogy mitől kerül top10-be egy hír: hogyha valami olyasmit mond, ami felforgatja a gyomornedveket. legyen az vér vagy oltári nagy abszurdum. számomra azonban fontosabb, hogy hogyan jutott el idáig:

they are full-time employees, with 401k stock options. some work for ibm or oracle. what does that mean? it means that linux doesn’t exist any more in 2007. there is no free software movement. if someone says linux is about love, peace and harmony, i would tell them to do their research. there is no free software movement any more. there is big commercial [firms] like ibm and there is small commercial [firms] like ubuntu.

a legszebb, hogy ez viszont igaz, illetve részben igaz. a gondolatmenet utolsó lépése szól csupán arról, hogy nem tud/akar/hagyják, hogy értelmes következtetéseket vonjon le valaki. na de nézzük ezt a részét.

itt sajnos emberünk összekeverte a dacból született linux kernel első lépéseit a mai fejlesztési modellel. a nagy cégek rájöttek, hogyha ellenpólust kívánnak adni az ms asztali/kiszolgáló operációs rendszer által szisztematikusan (és valljuk be üzletileg zseniálisan) felépített világba, akkor nem állhat egy ilyen méretű fejlesztés egyetlen cég mögött, illetve kezében, mert azt az ms eltiporja vagy az adott cég üzletmenet-, stratégiaváltás vagy egyéb okból saját kezüleg nyírja ki (talán nem kell mesélnem az os2 warpról).

ezek a cégek összeállva, üzleti és fejlesztési kapacitásuk csupán egy részét kockára téve öntik a kódot. a garancia pedig nem más, mint a nyílt forráskód. ez kilapítja a fejlesztési modellt a stratégiai tervezést és igyekszik minél kisebb deformációt adni a projekteknek, tehát, amit bill állít, az igaz… hiszen ez nem olyan szempontból love, peace and harmony, ahogy azt a flower power években megismerhette a társadalom. és valóban ma már nem fürdenek boldogan sárban max yasgur farmján hendrixet hallgatva és füvet szívva az emberek és ezt összemosni a nyílt forrású fejlesztéssel nem éppen megfelelő dolog.

a nyílt forráskód garancia, hogy senki nem pattan meg a kóddal, hogy senki nem teszi tönkre azt, hogy senki nem jut az alap infrastruktúra által kialakított leküzdhetetlen előnyökhöz. ez versenyt jelent, a verseny pedig innovációt teremt.

és hogy ezek az emberek hol dolgoznak? nézzük meg mit mond a szent grálnak tekintett kernel forrása. a cikkben rendkívül érdekes adatok vannak, amelyek azt tükrözik, hogy a fejlesztés valamivel több, mint 70%-át nagy cégek finanszírozzák így vagy úgy.

who wrote [the kernel] 2.6.20?

mi is akkor a modell? szerintem a nyílt forráson dolgozó fejlesztőknek is enniük kell, jön a villanyszámla és a barátnő is örül ha moziba viszik: vagyis dolgozni kell, mégpedig pénzért. igen, még rms-nek sem a legyek hordják össze.

a kezdeti lelkesedés, ami abból adódik, hogy milyen jó, hogy a nevem a readme-ben szerepel túl sokáig nem tartható fenn, és ekkor két út áll a fejlesztő előtt: vagy talál egy olyan munkát, ami hobbijának kellő intenzitást ad vagy egy olyan cégnél talál munkát, aki pont ezt a feladatot, amit szeret és jól csinál mint freelancer fejlesztő, azt a cég megbízásából folytatja. én azt hiszem ezek a szerencsések és az valóban nagyszerű, hogy sok olyan cég van aki tudja és képes ezt támogatni, mert üzleti modellje bizony erre épül.

ettől a fejlesztő nem lesz jobb vagy rosszabb, mert enni kell… és megnézhetjük pár top hacker pályafutást, mint amilyen jeremy allisoné, aki a hp | novell | google útvonalat bejárva végig a samba projekt vezetésén fáradozott és bárhol is dolgozott, vagy nagy csindradattával elveit, majd bankszámláját lobogtatva a google-nél foglalt helyet, ami valljuk be most meglehetősen nagy hype (mármint a google-nél dolgozni). néha én is elgondolkozom, hogy miért ragaszkodtam egy budapesti munkahelyhez a google-lel kapcsolatban…

de vehetjük robert love példáját aki a ximain | novell | google (mily furcsa) útvonalon nem hiszem, hogy kevesebbet fog a jövőben a kernel fejlesztésen dolgozni, mint ahogy ezt előtte tervezte volna. neki megtetszett, hogy a Google SoC szervezésében tevékenykedhet.

itt gond lehet, ha egy cég, mint a google felhalmozza ezeket a fejlesztőket, mert ugyan semmi jelét nem adja, mégis meglepően koncentrálja ezeket az erőit és kicsit arra emlékeztet, amikor a warcraft iii játékban a főhős az egyik kampány után véletlenül a sötét oldalra áll és azzal nyomhatjuk végig a hátralévő pályák kétharmadát, nem beszélve nyikoláj királyról, aki a heroes v-ben a gonosz markal hatására az élőhalott csapatok élére áll, hátat fordítva angyalainak és keresztes vitézeinek…

de én nagyon bízom abban, hogy a google ezt a lehetőségét inkább használni fogja, mint kihasználni… eddig legalábbis nincs okunk panaszra.

tehát a nyílt forrást ennyire félremagyarázni nem kell és nem kell félni az erre épülő üzleti modellektől sem, mert szabadságot biztosít, szabványokat teremt és innovációt gerjeszt. kell most nekünk ennél több? kell! de most ennyivel is beérjük…

így lábjegyzetben azért megjegyezhetjük azt is, hogy a szent grállon sem csillog úgy a fény. a nyílt forrás ugyanúgy lehetővéteszi, hogy számontartsuk nemcsak azt, hogy mennyire jó egy program, hanem azt is hogy mennyit fejlődött vissaz az előző kiadáshoz képest. ez lehet segítség, de lehet bármi más negatív folyamat kezdete vagy eredménye. a projektvezetés eldöntheti mennyire is használja fel ezeket a jelzéseket. a listából azonban úgy látszik, hogy az ingerküszöb nagyon különböző lehet.

known kernel regressions

de azért befejezném a fejlesztés témakört visszakanyarodva a kiinduló íráshoz és vegyük a következő idézetet:

let’s admit that a public bug tracking system leads to a better feedback, and to a better project management from the qa standpoint, with the side effect of having zillions of bugs reported, many of them duplicates or notabug. is this a good reason enough for not fixing some everlasting oo2 bugs such as not being able to have an easy way to change the default paper from letter to a4 in all the oo.org and to have it stick this way (bug #39733), or sticking with the design flaw that limits your paragraph to 65,534 characters, as if it were under windows 3.1 (bug #17171)?

na igen egy remek példa, amit ezer követhetne. de gondoljuk csak meg a nyílt forrású fejlesztés nem egy demokratikus folyamat. bizonyos szempontból nem az, hogy pontosak legyünk, hiszen olyan módon nem készülhet el egy program, hogy mindenki commitol a trunkbe, aztán a scheduler megnyomja a piros gombot és verzió lesz, ugye?

a demokráciáról arisztotelész óta tudjuk, hogy nagy hibaszázalékkal dolgozik. tehát vezetni kell a projektet, ami nem más, mint döntéshelyzetek sorozatában tartani a hajót, hogy a megfelelő irányban, megfelelő sebességgel menjen és az út során ne dőljön szét és lehetőleg a legénység se fluktuálódjon halomra vagy legalábbis a kritikusan minimális tömeget minden esetben megnyugtató módon biztosítsa.

ez nem egyszerű feladat. nagyon nem. gyakran inkább politikai, mint fejlesztési vénát igényel és fel kell tudni vállalni a döntéseket, még azokat is, amelyek népszerűtlenek. az ilyen az, hogy mit emelünk be a kódba és mit nem, mit javítunk a meglévő erőforrásokkal és mit nem.

elmondok két példát.

az egyik egy zárt forrású példa, vagyis a novell nprinter futtatása windows xp környezetben. ezt a témát kivesézte mélyen tisztelt “harcostársam”, maques, ezért ezt most nem fejtegetném tovább. de a lényeg az, hogy a a novellnél úgy döntöttek, hogy nem éri meg ezt a kékhalállal járó és állandóan a microsoft után rohanó, mellesleg a megoldást hivatalosan évek óta nem támogató kódot kijavítani. ekkor írtam mindenkinek a címjegyzékemben, akit úgy gondoltam, hogy köze lehet ehhez a komponenshez, és azt mondtam nekik, hogyha a kódot ideadják, akkor kijavítjuk a hibát, és egy nem hivatalos patchben megjelentethetik.

a zárt forrás és szabadalmak miatt erre nda hegyek aláírásával van remény. vagyis nincs remény. szembesülni kell azzal, hogy ez nem lesz meg. ez pénzügyi döntés és ezen ne reklamáljunk, mert a cégnek ez a saját pénze és ha erre nem ügyelne, az alkalmazottakat el kell bocsátani mind egy szálig az utolsó pedig leolthatja a villanyt, ha az áramot még nem kapcsolták ki előtte.

itt csendben megjegyzem, hogy sikerült úgy felkavarnom az állóvizet, hogy a lezárt ‘wontfix” státuszból „reopen”-re állították át ezt a hibát és azzal együtt, hogy bizonyosan képemmel és hajszálammal ellátott woodoobabákat áruló üzletlánc komoly sikereket érne el a novell fejlesztési részlegein üzemelő kantinokban, a fejlesztési hajlandóságot a esélytelenről a reményvesztettre sikerült feltornázni. és aki dolgozott zárt forrású multi környezetben az érti talán, hogy ez már valami.

na de nézzük az érem következő oldalát (nem a másikat, mert szerintem az éremnek sok oldala van, bármennyire is képzavar): a nyílt forrásnál sincs meg ez a garancia. nézzük csak meg a fentiekben vázolt nyitott incidenseket… a sun által fejlesztett projektben ezek az incidensek nem érték el az ingerküszöböt, és nem nagyon mozdulnak rá. látszólag a két helyzet nagyon hasonlatos, azonban, ha bármikor úgy érzem, hogy nekem ez fontos és megírom a patchet és beküldöm és működik (azt most hanyagoljuk el, hogy mekkora tortúra beküldeni egy patchet az ooo projektbe, és már le is mondtam arról, hogy a sunnal ezt el lehet intézni, ezért a novell fejlesztő proxyhálózatán keresztül passzírozzuk át amit lehet.), akkor meg is van oldva a probléma. a kapu, lehet javítani vagy ha egy cégnek ez fontos, akkor felbérelni programozót, hogy ezt javítsa ki, vagy tetesse bele, akár fordíttasson magának új ooo-t (na most megint egy rossz példa, mert ez sem leányálom, de nem is annyira rémálom, inkább a kettő között van).

azt hiszem a nyílt forrás szabadsága ezeken a helyeken tetten érhető.

ezzel kivesézettnek tekintem válaszomat a „nyílt forráskód szomorú helyzete napjainkban” írás 2. fejezetére a válaszaimat és gondolataimat. a rossz hír, hogy az említett írás 25 fejezetes, ezért is nem akartam egyetlen írásba sűríteni ezt…