Még csupán az elején járunk, de jól látható jelek már arra utalnak, hogy 2014 az áttörések éve lesz az informatikában. Előző cikkünkben az ipari internet szárba szökkenésével foglalkoztunk, most itt az alkalom, hogy egy újabb fontos mérföldkő, a nyílt (open source) és a zárt forráskódú szoftver (proprietary technology) közötti verseny várható kimenetelét tegyük vizsgálódásunk tárgyává.
A nagy megmérettetés ugyanis eredményhirdetés, győztes és vesztes nélkül érhet véget, miután napjainkra értelmetlenné vált a szembenállás, és a két koncepció közötti határ megszűnni látszik. A Gartner szerint 2015-től kezdve a világ kétezer legnagyobb vállalatánál az üzletileg kritikus alkalmazások 99 százalékában lesznek nyílt forráskódú komponensek is.
Manapság a zárt forráskódú szoftverek gyártói is olyan fejlesztési modelleket használnak, amelyek azelőtt csupán az opensource-közösséget jellemezték, míg ez utóbbi a nagyvállalati üzleti modell adoptálásával igyekszik kiaknázni a nyílt forráskódú technológiában rejlő lehetőségeket. Hogy csupán néhány példát említsünk, az IBM, az Oracle és a Microsoft mára nagyon széles termékportfóliót alakított ki az opensource-modell alapjain.
A jövő új „adatgazdái” is élenjárnak a nyílt forráskódú szoftverek használata és fejlesztése terén: a Linkedin az Apache Kafka projektjén keresztül, a Google az Android és a Chrome fejlesztésével, a Facebook az Open Compute és a Foly publikálásával a világ legnagyobb opensource-vállalatai közé került, és ugyanez elmondható a Bootstrap projektet támogató Twitterről, valamint a Netflixről is.
Jellemző, hogy az Amazont például számos bírálat éri, mert Jeff Bezos vezérigazgató irányítása alatt a kereskedő szemléletű cég nem vesz részt az opensource-közösségek munkájában, és csak minimális mennyiségű forráskódot nyit meg hozzájárulásképp – a megosztástól való vonakodás okainak feltárása egyébként egy külön tanulmányt is megérne.
Az Egyesült Államokban külön a kimondottan erre a célra létrehozott OpenSource.gov portál az államigazgatás nyílt forráskódú szoftverek használatára történő átállását könnyítené meg. Az ottani honvédelmi minisztérium kutatási projektjeit felügyelő hivatal, a DARPA (Defense Advanced Research Projects Agency) több mint 70 opensource-projektet finanszíroz, többnyire az adatkezelés és az analitika területén. Vállalkozó kedvű fejlesztők hozzáférhetnek a lehallgatási botrányba keveredett, amerikai nemzetbiztonsági hivatal, az NSA (National Security Agency) által 2011-ben publikált, nyílt forráskódú, BigTable NoSQL-alapú adatbázis-kezelőhöz, az Apache Accumulóhoz is.
Az eddigi tapasztalatok alapján körvonalazódott, hogy a nagy teljesítményű adatközpontok és számítási klaszterek építése, valamint a mobilalkalmazások készítése lesz a három legfontosabb terület, amelyen az opensource-alapú fejlesztések különösen fontos szerepet fognak betölteni. Ebből következik, hogy a nyílt forráskódú megoldások elterjedése a nagyvállalati informatikai környezetben olyan trend, amelynek megfelelő kezelésére a jövő CIO-jának mindenképp fel kell készülnie.
Érvek és ellenérvek
De milyen érvek hatására dönthet egy IT-vezető opensource-megoldás használata mellett? A Black Duck Software és a North Bridge Venture Partners felmérése (Future Open Source Survey 2013) szerint a beruházást előkészítő CIO-k elsősorban olyan szempontok alapján mérlegelnek, mint a jobb minőség (mind felhasználói élmény, mind funkcionalitás tekintetében), az információbiztonság, a választás és migráció szabadsága, valamint a megfizethető birtoklási összköltség.
Az opensource-megoldások nagyvállalati elterjedését ugyanakkor több tényező is hátráltathatja. Az idézett felmérés szerint ilyen körülmény lehet mindenekelőtt a felhasználók tapasztalatlansága az opensource-megoldások használata terén, a bevezetés bonyolultságától való félelem, illetve a nyílt forráskódú szoftverek licencelése körüli, vélt vagy valós bizonytalanság.
Cikksorozatunk szempontjából a felmérés egyik legfontosabb eredménye az volt, hogy a válaszadók 2013-ban az információbiztonságot a második legfontosabbnak nevezték az opensource-megoldások mellett szóló érvek sorában.
A nyílt forráskódú szoftverek használatát ellenző IT-vezetők leggyakrabban a fejlesztő közösség kiterjedtségét és a forráskód nyitottságát hozták fel ellenérvként, mivel mindkettőben biztonsági kockázatot látnak. Az igazság ezzel szemben az – és ezt a gyakorlat már megannyiszor alátámasztotta –, hogy egy opensource-megoldás ugyanolyan biztonságos vagy kockázatos lehet, mint egy zárt forráskódú szoftver.
Az opensource-megoldások támogatói például gyakran érvelnek azzal, hogy a több száz vagy ezer fejlesztőt felölelő közösség felügyelete, ellenőrzése mellett a kód egyetlen hibája vagy sérülékenysége sem maradhat rejtve – mindig akad valaki, aki észreveszi és orvosolja a problémát, ezáltal a rendszer öngyógyítóvá válik.
Nos, ez sincs teljes egészében így. Készültek olyan tanulmányok, amelyek szerint az érett opensource-projektek által gondozott kód kevesebb sérülékenységet tartalmaz, mint a zárt forráskódú szoftverek, de a különbség nem számottevő. A helyzet valójában az, hogy az open source szoftverfejlesztési paradigma szerint egymásból építkező szoftverkomponensek esetében egy fel nem fedezett sérülékenység – például egy Linux disztribúcióban vagy Spring MVC, Struts, Hibernate keretrendszerben – a központi repositorykból letöltve és integrálva sokkal több vállalatnál jelenhet meg és gyorsabban terjedhet, mint egy zárt forráskódú szoftver esetében.
Fejlesztés házilag
Ez egy valós veszély, ami leginkább a saját fejlesztésű opensource-komponensekből építkező vállalati alkalmazások esetében okozhatja a legnagyobb kárt. Egy 2012-s felmérés szerint, amelyet a Sonatype végzett, a felhasználók a Sonatype Central Repositoryból 46 millió alkalommal töltötték le a legnépszerűbb biztonsági platformok nem biztonságos (feltárt sérülékenységekkel rendelkező) verzióját. További 18 ezer letöltő a Struts2 keretrendszer egy nagyon sérülékeny verzióját választotta.
Az ilyen, nem biztonságos komponensek használatát még kockázatosabbá teszi, hogy az opensource-közösségnek nincs egy egységesen elfogadott monitoring és riasztási rendszere. Ennek hiányában nem egyértelmű, hogy a több, különböző forrásból származó komponensekben felfedezett, legújabb sérülékenységekről milyen forrásból lehet teljes körűen tájékozódni, illetve milyen csatornán lehet ellenőrizni az új javítások, frissítések megjelenését. Tovább rontja a helyzetet, hogy a komponensek felhasználása a fejlesztési ciklusok lerövidítését célozza, állandó ellenőrzésük és frissítésük viszont lassítaná a fejlesztés folyamatát. A probléma komolyságát érzékelteti, hogy az Open Web Application Security Project (OWASP) tíz legveszélyesebb sérülékenységet felsoroló listáján a kilencedik helyen az ismert sérülékenységeket tartalmazó komponensek használata szerepel.
A veszélyek és kockázatok elhárítására javasolt folyamat és módszertan szerint a szoftverfejlesztési projektek esetében ezért tanácsos a következő lépések beiktatása:
1. Minden felhasznált komponens azonosítása (adatbázis készítése)
2. A komponensek biztonságosságának állandó monitorozása a weben nyilvánosan elérhető információk alapján
3. Szabályok (például licenctípus-megkötések), belső ellenőrzési tesztek bevezetése és végrehajtása
4. Ahol lehetséges, további védelmi funkcionalitások kifejlesztése, nem használt modulfunkciók tiltása stb.
Látható tehát, hogy a jövő CIO-ja számára az opensource-megoldások használata nem csupán a csökkenő szoftverköltségekről és a beruházások gyors megtérüléséről fog szólni, hanem kellően komplex kihívásokat is tartogat.
