Mi is a lényeg? Ha kívülről jövő résztvevőket akarunk az adott projekthez megnyerni, akkor a puszta transzparenciánál többet kell nyújtanunk: a fejlesztők meg kell, hogy tudják változtatni a projekt irányát, hogy az fennmaradhasson. A Sun és az OpenOffice jó példája annak, hogy a túlzott ellenőrzés hogyan tud egy közösséget elfojtani.

Ez mind nem meglepő, de ha egy kutatáson keresztül jobban elmerülünk a témában, feltárhatjuk, hogy ennek mi az oka, és hogy a vállalatok hogyan birkóznak meg vele. Míg a legtöbb nyílt forráskódú projekt kevés kívülről jövő fejlesztő érdeklődését kelti fel, vagy egyáltalán nem érdeklődnek kívülről, a vállalatok által támogatott nyílt forráskódú projektek egy magától értetődő hátránnyal indulnak, mivel a kezükben akarják tartani a projektjük sorsának irányítását.

Nézzük, hogy a fent említett tanulmány mit állapít meg ezzel kapcsolatban:

A projektek részvételi architektúráinak összehasonlításán keresztül, melyek a szponzorok tervezési döntéseinek eredményeképpen jöttek létre, kétféle nyíltságot állapítottunk meg: transzparencia és hozzáférhetőség. „A hozzáférhetőség lehetővé teszi a külső résztvevőknek, hogy közvetlenül befolyásolják a közösség irányítását annak érdekében, hogy igényeiknek megfeleljenek.”

Míg a transzparencia lehetővé teszi, hogy a potenciális hozzájárulók kövessék és megértsék a közösség fejlesztési erőfeszítéseit, a hozzáférhetőség bizonyos keretek közé szorítja ezt a képességet. Amikor a projekt szponzorai a közösséget létrehozták, inkább transzparenciát, nem pedig hozzáférhetőséget nyújtottak a külső közösségi tagok számára.

Azt is megállapítottuk, hogy a projektek szponzorainak az ellenőrzés és a növekedés közötti feszültséggel kell szembenézniük. A szponzorok annak érdekében, hogy élvezhessék azt az előnyt, hogy a közösségek a vállalataik eredményeihez a projekteken keresztül hozzájárulnak, a közösség stratégiai irányítása feletti ellenőrzést fent kívánták tartani. Azonban a szponzorok hamar felfedezték azt, hogy a közösségi folyamatokhoz való hozzáférés korlátozásával, a közösségeik azon képességét is korlátozzák, hogy az új tagokat vonzzon és növekedjen.

Egy dal szerint „oda akarunk menni, ahol mindenki ismer minket”. A nyílt forráskód esetén azonban a fejlesztők oda akarnak menni, ahol van ellenőrzésük a kódjuk felett. A kereskedelmi/vállalati nyílt forráskódú projektek kevesebb ilyen lehetőséget nyújtanak, hacsak a fejlesztő az ügyfél-fejlesztő kategóriájába esik. A tényleges kérdés a kereskedelmi nyílt forráskódú projektek esetén az, hogy a kereskedelmileg érdekelt résztvevők, például az ügyfelek és partnerek, motiválhatók-e a kódbeli hozzájárulásra?

Jim Whitehurst, a Red Hat vezérigazgatója nagyobb vállalati (vagyis ügyfél) részvételre szólított fel mindenkit a nyílt forráskódú közösségekben, és ezzel valószínűleg a lényegre tapintott. Ez kiaknázatlan piac a hozzájárulók számára a kereskedelmi nyílt forráskódú projektekhez. Nem csak az a jellemző, hogy a vállalati ügyfelek a nyílt forráskódot egyre nagyobb méretekben használják, hanem valószínű, hogy a kereskedelmi nyílt forráskódú projektek ellenőrzését és jogi védelmét is előnyben részesítik.

A következő kérdés az, hogy a kódhoz való hozzájárulás szabályrendszereit hogyan hozzuk létre annak érdekében, hogy az az ilyen fejlesztőknek is megfeleljen. Mivel a kereskedelmi nyílt forráskódú projektek esetén kevés a kódhoz való viszonylagos szerves hozzájárulás, még akkor is, amikor mindent megteszünk a hozzájárulás ösztönzése érdekében, új modellekkel kell kísérleteznünk. A régi modellek, melyek az Apache, Linux és más közösség által irányított nyílt forráskódú projekteket követik, nem működnek a kereskedelmi nyílt forráskódú projektek esetén. Találjunk ki új modelleket!