Rávettem magam Eric S. Raymond népszerű pamfletjének elolvasására (ez így 10 év után azért nem semmi).
A következőkben ebből fogok szemezgetni:
"Sokan gondolják azt, hogy a hagyományos módszer előnye, hogy a törvény előtt is felelőssé tesz valakit, akitől lehetőség van kárpótlást követelni, ha a projekt elvéti az irányt. Ez azonban illúzió, a legtöbb szoftverlicenc úgy van megírva, hogy kizárja még az eladhatósági garanciát is, a teljesítményről már nem is szólva, és a szoftverek hibás működése miatti sikeres kárpótlási ügyek száma elenyészően csekély. De ha gyakoriak is lennének, az érzés, hogy valaki perelhető, nem oldana meg semmit. Működő szoftvert szeretnénk, nem pereskedést.
Akkor tehát mi haszna a hagyományos vezetési rendszernek?
Hogy ezt megértsük, meg kell ismernünk, hogy mit gondolnak a szoftverfejlesztési vezetők a munkájukról. Egy munkájában sikeresnek tűnő ismerős hölgy elmondta, hogy a 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.
Nyilvánvalóan kiváló cél mindegyik, de a nyílt forráskódú modellben és az azt körülvevő szociális környezetben különösen jelentéktelennek tűnhetnek. Lássuk őket fordított sorrendben.
Az ismerősöm szerint az erőforrások megszerzése gyakran védekezés. Ha egyszer rendelkezésre állnak az emberek, a gépek és az irodahelyiség, akkor ezeket meg kell védeni az ugyanezekért az erőforrásokért versengő társvezetőktől és a magas beosztású vezetőktől, akik a korlátozott erőforrásokat lehető leghatékonyabban próbálják elosztani.
A nyílt forráskódú világ fejlesztői önkéntesek, érdeklődésük és képességeik alapján járulnak hozzá projektjeik munkájához (és ez általában akkor is igaz marad, ha fizetést kapnak a nyílt forráskódú programozásért). Az önkéntes szellemiség feleslegessé teszi az erőforrásszerzést, az emberek a saját erőforrásaikat teszik az asztalra. Így nincs szükség védekező vezetőre a hagyományos értelemben.
Egyébként az olcsó PC-k és a gyors internetkapcsolatok világában az egyetlen korlátozott erőforrás a szakértői figyelem. A nyílt forráskódú projektek felbomlása alapvetően sosem számítógépek, hálózati kapcsolatok vagy irodahelyiségek miatt történik, csak akkor múlnak ki, amikor a fejlesztők maguk vesztik el az érdeklődésüket.
Ha így áll a helyzet, akkor duplán fontos, hogy a nyílt forráskódú hackerek az önkiválasztás által a maximális teljesítmény elérésére szerveződjenek. Az ilyen közösségek szociális környezete a kompetencia alapján kíméletlenül válogat. Az ismerősöm szerint, aki egyaránt ismeri a nyílt forráskódú világot és a nagy, zárt projekteket, a nyílt forráskód részben azért sikeres, mert kultúrája csupán a programozással foglalkozó populáció legtehetségesebb 5 százalékát fogadja el. Ő az idejének nagyobb részében a maradék 95 százalékból valókat szervezi, így első kézből tapasztalta meg a legjobb programozók és a pusztán kompetensek termelékenysége közötti százszoros eltérést.
Az ilyen mértékű eltérés mindig fölveti a kínos kérdést, hogy a zárt kódú projektek a hátterükkel együtt, nem lennének-e jobb helyzetben a kevésbé tehetségesek több mint 50 százaléka nélkül? A komoly vezetők régóta tudják, hogy ha a konvencionális szoftver-menedzsment egyetlen funkciója a kevésbé rátermettekből származó nettó veszteség csekély nyereséggé alakítása lenne, az egész játék nem érné meg a fáradságot.
A nyílt forráskódú közösség sikere meglehetősen súlyossá teszi a kérdést, azt bizonyítva, hogy gyakran olcsóbb és hatékonyabb önjelölt önkéntesek toborzása az internetről, mint olyan felépítmények irányítása, amelyek tele vannak valami mással szívesebben foglalkozó emberekkel."
