A következő lista ezeket a csapdákat taglalja. Az alaplistát Drew Ladner készítette, aki a JBoss kormányzati üzletágának vezetője. A JBoss licencmentes, nyílt forráskódú köztesréteg (middleware) architektúrát terjeszt, mint például a J2EE alkalmazásszerver és a webportál-technológia. A vállalat konzultációs és támogatási szolgáltatásokat is nyújt. A Ladner által összeállított listára más, nyílt forráskódot használók és szaktanácsadók, mint például John McManus, a NASA CIO helyettese és Monson-Haefel, a Burton Group fő elemzője is reagáltak. Az alábbiakban az ő felvetéseiket és véleményeiket foglaltuk öt alapvető pontba:

1. Ha nem vesszük figyelembe a teljes életciklus költségeket

Az emberek gyakran megfeledkeznek a szoftverek teljes életciklus költéségének figyelembevételéről, beleértve a nyílt forráskódot is. A csapda abban rejlik, hogy az emberek, mivel nem fizetnek licencdíjat, hajlamosak azt gondolni, hogy pénzt takarítanak meg. De valójában az egész életciklust kell figyelembe venni, ami üzleti nézőpontból különösen fontos. A beszerzés utáni életciklus költség magában foglalja a szoftver implementáció fejlesztési, alkalmazási és menedzsment fázisának pénzügyi eseményeit.

A nyílt forráskód nem ingyenes. Talán nem kell fizetni a kódért, de ez nem mentesít az alól, hogy a szükséges integrációt magunk kell, hogy elvégezzük. Ha nem gondolkodunk fenntartási, működési és integrációs költségeken, akkor akár nullás költségvetéssel is nekivághatunk egy nyílt forráskódú projektnek és csodálkozunk, hogy pénz nélkül nem tudunk egy adott ponton továbbjutni.

2. Ha nem tervezzük meg a nyílt forráskódú projektjeinket teljeskörűen

Nyílt forráskódú projektek tervezésénél hosszútávú működésre és fenntartásra kell gondolni. A nyílt forráskódot használók talán nem gondolják át a működést és fenntartást, így nem bizonyosodnak meg arról, hogy a megfelelő támogatási szolgáltatást veszik-e igénybe. Ki kell emelnünk, hogy vállalati szintű szoftverimplementációkról beszélünk. Minden jó CIO megakar arról bizonyosodni, hogy az általuk használt szoftverhez igény esetén megfelelő támogatási szolgáltatás társul, akár nyílt forráskódról, akár kereskedelmi kódról beszélünk. Emellett, különösen küldetéskritikus alkalmazások esetén a felhasználóknak szükségük van olyan segítségre, amely bármikor rendelkezésre áll probléma esetén.

Az egyik legnagyobb hiba, amit a nyílt forráskódot alkalmazók elkövethetnek az az, hogy azt gondolják, mivel hozzáférnek a kódhoz, a vállalaton belüli számítástechnikai szakemberek is elvégezhetik a karbantartási feladatokat, mint például kódrevízió, frissítés menedzsment, hibajavítás. Ezen feladatok elveszik az időt a többi, szokványos IT feladattól. Ha elvárjuk, hogy a vállalaton belüli fejlesztők ellássák a támogatási feladatokat is, akkor hatalmas rejtett költség keletkezik. Hagyjuk tehát a fejlesztési feladatokat a fejlesztőkre, és biztosítsuk azt, hogy a támogatással foglalkozó szakemberek lássák el a kritikus alkalmazások támogatását.

A felhasználók számára karbantartási szerződések kötése sok esetben előnyös lenne. Ugyanakkor látnunk kell, hogy a különböző támogatási szolgáltatást nyújtó vállalatok szerződési ajánlatai mögött eltérő szándékok húzódnak meg, amik nem feltétlenül egyeznek meg az állami szektor igényeivel, különös tekintettel például a közbeszerzésre. Az elfogadott és tisztelendő, hogy néhány vállalat mások szakértői tudásának hiányából kiindulva, abban lát lehetőséget, hogy segíteni próbál és ezáltal bevételhez jut. De számos más vállalat csak plusz bevételi forráshoz kíván jutni a nyílt forráskódon keresztül, és ez általában véve hátráltatja a nyílt forráskód fejlődését. Ha valaki tehát a szoftverét üzleti alapokra kívánja helyezni, akkor mindig átlátható üzleti modellt kell kommunikálnia a felhasználói felé, amiből egyértelművé válik, hogy hol történik az értékteremtés.

3. Ha úgy kezeljük a nyílt forráskódú szoftvert, mint bármely más szoftvert

Ha az IT vezetők nem dokumentálják és teszik közzé azokat a megtakarításokat és más előnyöket, melyekre a nyílt forráskódú projektek során tettek szert, a legfelsőbb vezetés talán vonakodhat ezen technológiától, és attól, hogy életképes alternatívaként kezelje. Az IT vezetőknek meg kell osztani tapasztalataikat, így az állami ügynökségek is fejlődhetnek az éppen kialakulóban lévő IT stratégiájukban és eljárásaikban. A szegényes kommunikáció félreértésekhez és téves feltételezésekhez vezet a nyílt forráskóddal kapcsolatban. Az információmegosztásnak túl kell lépnie a szervezeten belüli kommunikáción. A legnagyobb csapda abban rejlik, ha az emberek nem tudják hogyan kötelezzék le megfelelő módon a nyílt forráskódú közösséget, így nem kapják meg a nyílt forráskódból kinyerhető érték teljes egészét.

Ha a következőképpen gondolkodunk: „letöltöttem a szoftvert, nem kell ezentúl foglalkoznom azokkal, akik a kódot fejlesztik és a támogatással foglalkoznak”, akkor a közösség részévé válás lehetőségét szalasztjuk el. Az együttműködés és a tapasztalatok egymással való megosztása a legnagyobb előnye és értéke a nyílt forráskódú közösségnek. Bizonyos esetekben az állami ügynökségek elvesztegetik az idejüket, ha olyan kódot és változtatásokat fejlesztenek ki, amelyek már elérhetők a termék fejlesztői közösségén belül.

Bizonyos felhasználók a nyílt forráskód alapfilozófiáját veszélyeztetik azáltal, hogy nem vesznek részt a közösségben új kódokkal való hozzájárulással vagy pedig hibabejelentéssel. Még az is segítség ha megosztjuk másokkal, ha valamilyen kód nekünk nem működött. A tapasztalatok megosztása az, ami a nyílt forráskódot olyan értékes modellé teszi. Amíg az emberek tevékenyen részt vesznek, a termékek továbbfejlődnek és alakulnak. Fontos, hogy felelősségteljesek legyünk, különösen szolgáltatás orientált architektúrák (SOA) szoftverfejlesztése során. Nem lehet csak elvenni, hanem valamit adni is kell. A nyílt forráskódot nem lehet ingyenesen "megúszni".

4. Ha tapasztalatlan partnereket választunk ki

Nagyon fontos a megfelelő partnerek kiválasztása egy nyílt forráskódú projekt során. A nyílt forráskód egy nagy ökoszisztéma kis és nagy rendszerintegrátorokkal, akik a szoftvereket és szolgáltatásokat új módon nyújtják. Bizonyos állami ügynökségek bizonyos partnereket részesítenek előnyben másokkal szemben, és ez csodálatos. Csak arról kell megbizonyosodni, hogy a partnerek megfelelő ismeretekkel és tapasztalatokkal rendelkeznek a nyílt forráskód területén.

A tapasztalatlanság hátránya a rossz technológiaválasztás és az implementációs késések. Ladner azt tanácsolta a kormányzati ügynökségeknek, hogy minden egyes integrátor nyílt forráskóddal kapcsolatos képzését és bizonyítványait vizsgálják meg. Ha nincs megbízható integrátor, akkor van értelme annak, hogy a meglévő partner mellé egy nagyobb nyílt forráskódú szakértelemmel rendelkezőt alkalmazzunk.

5. Ha túl kicsinek hisszük magunkat

Habár néhány állami ügynökség a nyílt forráskódot a projektjavaslatok elbírálása során már a kereskedelmi termékekkel együttesen, egyenlő súlyozással értékelik, néhányan azonban még mindig úgy tekintenek a nyílt forráskódra, mint egy szűk, speciális igényű piaccal rendelkező technológiára, vagy olyanra, amely leginkább kis ügynökségeknek felel meg. A valóság az, hogy a magánszektorban azonban a vállalatok formálisan ágyazzák IT architektúráikba és IT stratégiájukba a vállalati szintű nyílt forráskódot.

Az a tévhit, hogy a nyílt forráskód különleges szaktudást igényel, az állami ügynökségek vonakodását eredményezheti a nagyívű nyílt forráskódú projektekbe való belefogással kapcsolatban. Vannak akik azt mondják, hogy nagyon jól hangzik a nyílt forráskód, de nincs hozzá tehetségük. Ez egy érdekes hozzáállás azért is, mert a nyílt forráskódú technológiák épp olyan termékek, mint a tulajdonosiak. Az egyetlen különbség az, hogy ingyenesen megkapható és ha az embereknek segítségre van szükségük, fizetnek érte. Ez nem azt jelenti, hogy okosabb fejlesztőkre van szükség, csupán ugyanolyan jártasságra, mint a tulajdonosi szoftver esetén. Mások szerint ez csak egy bizonyos fokig igaz és a vállalaton belüli szakértelem is szükséges lehet ahhoz, hogy a közösségen belüli technikai támogatás nyílt forráskódú termékek által nyújtott lehetőségét teljes mértékben kiaknázzák. Az általános karbantartási csatornák igénybevétele a nyílt forráskód esetén csak akkor működik, ha a jó kérdéseket teszik fel. Azonban a levelezési listákon tapasztalható „pátyolgató stílus” nem mindig olyan, mint a kereskedelmi szintű támogatási szolgálatatás esetén, különösen akkor nem, ha valaki például olyan kérdést tesz fel, amit a tapasztaltabb felhasználók ostoba kérdésnek tartanak.