Bizonyára a legtöbben voltunk már olyan szituációban, amikor valami nagyon jó és új alkalmazást gyorsan kifejlesztettünk a JBoss használatával, majd pedig azt az utasítást kaptuk a főnökünktől, hogy az eredményt egy másik gyártó „ősrégi” futtatókörnyezetébe kell portolnunk, mert az a vállalati szabvány.
Nem idegesítő, hogy ha egy vállalat IT részlege mondjuk hét évvel ezelőtt egy futtatókörnyezetre szabványosított, ami nagy, lassú és hiányzik belőle az az innováció, mely a JBoss-on keresztül szabadon és nyíltan elérhető? Az alábbiakban azokat az érveket olvashatjuk, melyek arra ösztönzik az IT döntéshozókat, hogy ezeket a döntéseiket bírálják felül és válasszanak jobban.
Egyre több szervezet építi fel IT infrastruktúráját nyílt forráskódú alapokon, habár néhány aggodalom továbbra is állandóan jelen van. Ezekről a mítoszokról rántjuk most le a leplet: Az első mítosz: a nyílt forráskód csak azoknak jó, akik hobbiból foglalkoznak vele, és még nem kész az üzletkritikus, vállalati felhasználásra.
Ez talán igaz volt 7-8 évvel ezelőtt, de még akkor is csak kis mértékben. Vegyük alapul a következő tényeket:
- A web, amely a Föld legnagyobb összefüggő IT infrastruktúrája, a sikerét a nyílt forráskódnak köszönheti. A nyílt forráskód nélkül a web nem létezne
- Egy nemrégi, Forrester jelentés nyilvánvalóvá tette, hogy a JBoss kimondottan jobb minőségű, mint néhány meglévő tulajdonosi, nagy gyártó terméke
- A legtöbb régóta használt, tulajdonosi szoftvertermék (különösen azok, melyek Javán alapulnak), jelentős mértékben tartalmaz nyílt forráskódú szoftverkomponenseket, ami a nyílt és zárt technológia keverékét, hibridjét állítja elő. (Ez nem feltétlenül előnyös, de egyértelműen mutatja a nyílt technológia betörését a tulajdonosi szoftverek területére.)
Kettesszámú mítosz: a nyílt forráskód nem nyújt professzionális, küldetéskritikus támogatást
Néhány tisztán nyílt forráskódú vállalat megpróbált olyan technológia köré támogatási tevékenységet építeni, melyet nem áll érdekükben ellenőrzésük alatt tartani, vagy pedig nem rendelkeznek elegendő szakértelemmel, hogy valóban támogassák azt. Mit jelent ez a gyakorlatban? A nyílt forráskód esetén egy hibajavítás, mely az ügyfél számára fontos, olyan fejlesztőket kíván, akik mélyen benne vannak a szóban forgó nyílt forráskódú közösségekben. A Red Hat nem csak a Linux legnagyobb hozzájárulója, hanem aktívan el is kötelezett számos nyílt forráskódú projekt iránt például a JBoss.org-on, a Hibernate.org-on, a Seam.org-on, az Apache-n és az OpenJDK-n keresztül.
A Red Hat és partnerei nem csak küldetéskritikus támogatást nyújtanak a nyílt forráskódhoz, hanem ki is emelkednek abban. Amikor a technikai támogatás a vállalat legfontosabb alapvető kompetenciája, és nem csupán egy adminisztratív költséghely, akkor a legjobb kell legyen az üzletben. Azokat a gyártókat, melyek kereskedelmi licenc-alapú üzleti modellel rendelkeznek semmi nem kényszeríti arra, hogy kiemelkedjenek a támogatásban.
A hármasszámú mítosz: a felhasználók számára túl kockázatos a nyílt forráskód használata annak licencelési problémái miatt
A nyílt forráskódú licencek összetettek, és tájékozottnak kell lennünk a témában ahhoz, hogy teljesen megértsük a hozzájuk kapcsolódó felelősséget és kockázatot. Ez nem csak a nyílt forráskód esetén igaz, hanem a végfelhasználói licencszerződést is el kell olvasnunk a hagyományos, „dobozos” szoftver esetén is. Ha nem vagyunk annyira jártasak a licenc értelmezésében, akkor szakértők segítenek nekünk.
A négyesszámú mítosz: sokan felteszik a kérdést, hogy mi történik akkor, ha a nyílt forráskódú technológiát választom, de azt senki sem fejleszti tovább?
Látnunk kell, hogy a tulajdonosi technológiákra ugyanez igaz, azok is az életciklusuk végére érnek valamikor. A probléma abban van, hogy a tulajdonosi technológia az életciklusa végén eltűnik, senki más nem tudja továbbvinni őket. A nyílt forráskódú modell azonban organikus és darwini szűrőként működik: az a rossz technológia, ami kevés gyakorlati haszonnal rendelkezik, elhal, méghozzá elég gyorsan. Mivel a nyílt forráskódot természetes átláthatóság jellemzi, van számos jelző, ami alapján ezt felismerhetjük. Ilyen például a kiadások üteme, a fejlesztői közösség összetétele, az elterjedtség, a támogatási ekorendszer, letöltési statisztikák stb.
Az ötösszámú mítosz: csak a hatalmas, jól megalapozott tulajdonosi vállalatok engedhetik meg maguknak a versenyhez szükséges innovációt
Az elmúlt 10 évben a nyílt forráskódú mozgalom folyamatosan megmutatta, hogy a nyílt forráskódú együttműködés a technológiai innováció elősegítésének legjobb módja. Nem véletlen, hogy számos olyan vállalat, melyet tipikusan az innovációval kapcsolatban említünk, nagy támogatója és felhasználója a nyílt forráskódnak. Ezen vállalatok közé tartozik például a Google, a Facebook, a You Tube, a Yahoo, a Twitter és mások. Gyakran olyan gyors az innováció üteme, ami a kereskedelmi vállalatoknak a szelektív innováció előnyét nyújtja, azaz csak a legjobb ötleteket kell elfogadniuk és egy adott probléma esetén gyakran több megoldás közül választhatnak.