A VE-GA és a Linux

Kategória: Írásaink Megjelent: 2005. július 05. kedd

Nem sokkal az írásom után egy olyan cikkre találtam, ami végképp bizonyossá tette számomra, hogy a VE-GÁ-nak foglalkoznia kell a Linuxszal: Eric S. Raymond: A katedrális és a bazár (2000. - ford.: Karsai Róbert, 2003/11/07 10:15:29) URL: http://magyar-irodalom.elte.hu/robert/szovegek/bazar/
Az írás a szoftvertervezés-fejlesztés egy újabb, a Linuxra jellemző modelljéről szól közérthető nyelven. Azoknak is ajánlom, akik nem érdekelődnek a programozás, a technikai részletek iránt, mert nem a programozást, hanem egy közösségi alkotó folyamatot elemez szociológiai, pedagógiai és vezetéselméleti szempontokból, és olyan következtetésekre jut, amely hasonlít a VE-GA gyakorlatának és elméletének eredményeihez.

Azok kedvéért, akik "önhibájukon kívül" nem tudják elolvasni, felvázolnám a lényegét:
Alapvetően két fejlesztési modellt állít szembe: a szakértők kis, logikus lépésekből egymásra épített centralizált rendszerét, és a Linuxos, un. szabad, "adj ki korán és gyakran, adj ki mindent, amit csak tudsz, a kuszaságig légy nyílt" jelmondatokkal jellemezhető módszerét.
Hogy történik egy ilyen fejlesztés?
A program futtatható, de még nem tesztelt, feltehetően hibás változatait korán és gyakran kiadják (általában tíznaponként, intenzív fejlesztések idején minden nap).
A tesztelés mindenki előtt nyitott, aki az ügyben érdeklődik.
"Bő lére eresztett" bejelentések jelennek meg a nyilvánosság előtt, a tesztelők listáján, így bátorítva a részvételt.
Figyelnek a tesztelőkre, tervezési kérdéseket tesznek fel nekik, "hízelegnek", amikor javításokat és visszajelzéseket küldenek - fenntartják, erősítik a motivációt.
A nyílt forráskód miatt a hibajelentések pontos helyének megjelölésével, esetleg már javításokkal érkezik, így jelentősen lerövidül a korrekció ideje, csökken a félreértések esélye.
Ezzel szemben a hagyományos szoftverprojekt-menedzsmentnek öt funkciója van:
Célok kitűzése, és a munkatársak azonos cél felé irányítása.
Megfigyelés, illetve annak biztosítása, hogy nem maradnak ki fontos részletek.
Az emberek motiválása az unalmas, de szükséges egyhangú feladatokra.
A produktivitást legjobban elősegítő felépítés megszervezése.
A projekt fenntartásához szükséges erőforrások megszerzése.
Ezek a feladatok igen nagy erőforrás-igényűek. A "bazár" modell ezen problémák jelentős részét nem is ismeri, vagy automatikusan a fejlesztő-tesztelő közösség kiválasztódásakor, kialakulásakor megoldja.

A számunkra fontos (nem technikai jellegű) pontok, és a vegalógia párhuzamai:
1. "Minden jó szoftver egy fejlesztő személyes vágyainak kielégítésével kezdődik."
Belső igények és motivációk.
2. "A jó programozók tudják mit írjanak. A nagyok azt is tudják, mit írjanak (és használjanak) újra. (Kódújrahasznosítás.)"
Interiorizált, de inkább önalkotó tudás, a meglévő ismeretek a feladat célja szerinti átrendezése.
3. „Tervezd be, hogy egyet el fogsz dobni, úgyis el fogod.”
A tevékenység "puffer" jellege - a lényeg a fejlődés, a közösség fejlődése.
4. "Megfelelő attitűd mellett az érdekes problémák megtalálnak."
A legfejlettebb rendszer az, amelynek legfejlettebb a problémarendszere, és innen már "csak" egy lépés, hogy a világtörténelmi sorsra jutott felnőtt egyének és közösségeik megtalálják a megfelelő megoldásokat.
5. "Ha már nem érdekel egy program, az utolsó kötelességed átadni azt egy kompetens utód számára."
Az önkéntesség és a felelősség kérdése.
6. "A gyors kódfejlesztés és a hatékony hibakeresés felé vezető legkönnyebb út a felhasználók társfejlesztőként való kezelésén át vezet."
A problémák megoldásába a lehető legszélesebb kört be kell vonni, figyelembe véve igényeiket.
8. "Elegendően sok bétateszter és társfejlesztő mellett majdnem minden probléma gyorsan felismerhető, és a javítás is nyilvánvaló valaki számára... A sok szem csökkenti a komplexitást."
9. "A buta kód ügyes adatszerkezetekkel jobban működik, mint a fordítottja."
Talán egy kicsit erőltetett, de a 8-9. pont a civil társadalom, az alternatív mozgalmak lényegét írják körül: az érintettek gyorsan reagálni képes közege hamarabb képes felismerni a problémákat, és kialakítani a megoldásokat, a civilek sajátsága, hogy olyan tényezőkre is rámutatnak, amelyek a szakértők figyelmét elkerülik.
10. "Ha bétatesztelőidet a legértékesebb erőforrásodként kezeled, a legértékesebb erőforrásoddá válva reagálnak."
Az emberi rendszerek alapvető erőforrása a bennük résztvevő személyiségek, számukra folyamatosan biztosítani kell a megfelelő motivációs szintet, megbecsülést, igényeik kielégítésének és problémáik megoldásának lehetőségét.
11. "A saját jó ötletek utáni legjobb dolog a felhasználóidtól származó jó ötletek felismerése. Időnként ez utóbbi jobb."
A vezetőnek nem a feladatok megoldására kell koncentrálnia, hanem az emberi folyamatok kezelésére.
12. "A leginkább megdöbbentő és innovatív megoldások gyakran annak a felismeréséből származnak, hogy hibás volt a probléma felfogása."
Ha kívülről, más szemszögből is tudjuk nézni a dolgokat, az közelebb vihet a megoldásokhoz. A VE-Gá-nak sajátja a többszempontú megközelítés.
13. "A tökéletességet (a tervezésben) nem akkor érjük el, amikor már nincs mit hozzáadni, hanem amikor már nincs mit elvenni."
Egy rendszernek nem a bonyolultsága, összetettsége, részletekig menő kidolgozottsága, hanem a működőképessége, használhatósága, praktikussága az igazi mércéje.
14. "Akármilyen eszköznek az elvárt módon kell hasznosnak lennie, de az igazán jó eszköz ott is felhasználható, ahol soha nem számítottál volna rá."
Egy igazán hasznos módszer kitermeli a saját, helyzethez idomuló módosulásait, mint például a kreatív-tréning és annak un. "génmutáciői".
18. "Egy érdekes probléma megoldásához találj először egy olyan problémát, amely számodra érdekes."
Egy feladatot akkor tudunk eredményesen megoldani, ha a probléma motivál minket a megoldásra, ha a probléma sajátunk is, ha teljes személyiségünkkel tudunk részt venni a megoldásban.
19. "Több ember kétségtelenül jobb egynél, ha a fejlesztés koordinátorának legalább olyan jó kommunikációs közeg áll a rendelkezésére mint az Internet, és képes a kényszer nélküli vezetésre."
Egy közösség - megfelelő kommunikációval - önmaga összességén túlmutató minőséget tud létrehozni: ezt hívjuk addíciós közösségnek.

Végül néhány eredeti idézet, ami megerősít abban, hogy valóban közünk van ehhez:
"Az is kiderülhet, hogy a nyílt forráskód sikerének legfontosabb hatása az lesz, hogy megtanít mindnyájunkat a kreatív munka gazdaságilag leginkább hatékony módjára."
"A projektvezetőnek vagy koordinátornak jól kell tudnia kezelni az embereket, és jó kommunikációs készséggel kell bírnia.
Ennek nyilvánvalónak kellene lennie. Ahhoz, hogy egy fejlesztői közösséget építs, fel kell keltened az emberek figyelmét, érdekessé kell tenned számukra a munkád, és elégedettségben kell őket tartanod, hogy az általuk végzett munka megfelelő. A műszaki érdekességek sokat segítenek ennek elérésében, de ez messze nem elegendő. Az általad kivetített személyiség is fontos.
Nem véletlen, hogy Linus[1] remek fickó, akit szeretnek, és akinek segíteni akarnak az emberek. Az sem véletlen, hogy erélyes, kifelé forduló ember vagyok[2], aki élvezi a társas munkát, van humorérzéke, és elő tudja magát adni. A bazár modell működését segíti, ha legalább egy kis jártasságod van az emberek elbűvölésében."

*   *   *

Úgy látom, hogy ebben a modellben, és a mi közösségeink működésében sok közös elem van, amiből akár következtetéseket is vonhatnánk le.
Ehelyett inkább hasznosítsuk a bazárban lévő tapasztalatokat, ötleteket, és gondoljuk végig, milyen haszna lehet ezeknek civil jellegű közösségekben, közösségi személyiség fejlesztésben, más tevékenységekre épülő hálózatokban.

[1] Linus Torvalds, a Linux "atyja".
[2] mármint A katedrális és a bazár esszé szerzője, Eric S. Raymond.