Két hónapja finom testcsellel próbálta átjátszani a nyílt forráskód apostolait. Egy kutatással támasztotta alá, hogy milyen veszélyei vannak a nyílt forráskód burjánzásának. A kutatást egyik konklúziója, hogy egy vállalat rendszereiben a nyílt forráskód aránya nem haladhatja meg a 40 százalékot, ellenkező esetben...

Na de mi is lesz ellenkező esetben? Bár a SAS kutatása értelemszerűen az analitikai platformokra koncentrál – egyesek szerint az R nyelv terjedésének ellensúlyozására készült a felmérés is –, két általános megállapítás is kiolvasható az adatokból. Egyrészt a nyílt forráskódú eszközök nem hogy csökkentenék, hanem növelik a biztonsági kockázatokat (nehezítik a megfelelő szint biztosítását). Másodsorban problémák adódhatnak a nyílt forráskódú rendszerekhez szükség szakértelem megtalálásában (toborzás, átképzés, emberek cseréje). Mindez kiegészülve egyéb tényezőkkel olyan rejtett költségeket generál, amelyek miatt az "ingyenes" rendszer jóval drágább is lehet, mint a tulajdonosi (proprietary) eszközök.
 

A SAS megállapításaiban van is valami. Legfőképpen az, hogy a nyílt forráskód és a tulajdonosi szoftver között nem vagy-vagy reláció van. Mindkettőnek van helye, de az is egyre inkább nyilvánvaló, hogy a piac megállíthatatlanul halad a nyílt forráskód irányába.

Desktoptól a vállalati rendszereken át a felhőig

Amióta a felhőszolgáltatások a vállalati (és konzumer) informatika szerves részévé váltak, a nyílt forráskód minden szinten eluralta a világot. Ha okostelefonról beszélünk, ott az Android (és vele az összes biztonsági és frissítési probléma), ha adatközpontokról, a különböző Linuxok (Red Hat, SUSE), ha konténertechnológiáról, elkerülhetetlen a Docker vagy a Kubernetes, a fejlett analitikában a RapidMiner vagy a KNIME, big datánál a Hadoop vagy a Spark, a gépi tanulásnál a TensorFlow vagy a Mahout és így tovább.

Ha maradunk a SAS területénél, egy tavalyi amerikai felmérés jól mutatja, hogyan változnak az analitikai piacon a felhasználói preferenciák. A BurtchWorks, amely toborzó cég, elsősorban munkaerő-piaci szempontokból vizsgálta, hogy az analitikai szakemberek miloyen eszközöket kedvelnek. A SAS megoldásait, valamint két nyílt forráskódú eszközt, az R és a Python megítélését vizsgálták több szempontból.

Kezelhetőségben a válaszadók 39 százaléka tartotta a SAS-t a legjobbnak, 42 százalékuk az R-t, míg 20 százalékuk a Pythont. De nem is ez az érdekes – legalábbis a SAS szempontjából –, hanem az, hogy 2014-ben még a válaszadók mintegy 65 százaléka szavazott a SAS-ra. Persze az sem mindegy, milyen szektorban dolgoznak a válaszadók: míg a technológiai és a telekom szektorban dolgozók huszonegynéhány százaléka szavaz csak a SAS-ra, a pénzügyi szektorban dolgozók körében még a többség (kb. 51 százalék) azt találja jobbnak.
 

Az alkalmazási terület sem mindegy. Az adattudósok 53 százaléka a Pythont kedveli, 44 százaláka pedig az R-t, és csupán 3 százalékuk szavazott a SAS-ra, míg a prediktív analitikával fogalalkozók körében még mindig a SAS a legnépszerűbb 43 százalékkal.

Akkor befellegzett a tulajdonosi szoftvernek?

Ha egyszerűen extrapolálnák a BurtchWorks felmérését a jövőbe, illetve egyéb olyan területekre, melyeken éles a verseny a tulajdonosi és a nyílt forráskódú eszközök között, gyorsan levonhatnánk a következtetést, hogy az előbbit fejlesztő vállalatok hamarosan lehúzhatják a rolót. Ezzel szemben azt látjuk, hogy a Microsoft, az Oracle vagy az SAP – hogy csak a legnagyobbakat említsük a vállalati világból – él és virul.

És hogy miért? Mert ha valaki a nyílt forráskódra szavaz, számtalan addig viszonylag egyértelműen kezelhető problémát és kötelmet is a nyakába vesz.

1. Licencelési problémák. Komoly felkészültség kell ahhoz, hogy valaki ne vesszen el a nyílt forráskódú licencek sűrű erdejében. A jelentősebb licencelési típusokból is van öt-hat. Ez ráadásul halmozottan jelentkezik, hiszen elképzelhető az is, hogy a nyílt forráskóddal érkező egyes komponensek más licencelési szabály alá esnek. Ezeknek a függőségi rendszereknek az átlátásához komoly tudás kell.

2. Biztonság. A probléma súlyosságát jól mutatja az OpenSSL-ben felfedezett Heartbleed sérülékenység. Egy évvel a felfedezése után még a Frobes Global 2000-es listáján szereplő cégek háromnegyedénél még nem javították a súlyos hibát, de két évvel később is még az érintett rendszerek felében megvolt.

A Sonatype, amely ún. szoftver ellátási lánc szolgáltatást kínál nyílt forráskódú megoldásokhoz, és amelynek repository szolgáltatása is van, tavaly évre vonatkozó kutatásában azt állítja, hogy a letöltések több mint 6 százalékában van egy ismert biztonsági hiba. A cég szerint a nyílt forráskódú komponensek óriási energiaforrásai a vállalatok belső innovációjának, de csak akkor, ha ezeket a komponenseket megfelelő forrásból szerzik, és a követésükkel is foglalkoznak. Ellenkező esetben főleg a biztonsági réseket gyarapítják, licencelési problémákat, bugokhoz vezetnek.

A Sonatype adatai alapján a nyílt forráskódú fejlesztések elképesztő lendületet vettek. A fejlesztők a szolgáltató statisztikái szerint átlagosan naponta 1000 új projektet indítanak, és 10 ezer új verziót szállítanak. Ezeknek a követése és auditálása nem éppen egyszerű. Érdekes adat, hogy a két évnél frissebb komponensek – ezek teszik ki a fejlesztők által felhasznált nyílt forráskódú elemek 47 százalékát – átlagos hibaaránya 5 százalék alatt van, míg a két évnél idősebb komponensekból származott a kockázatook 80 százaléka.

Éppen ezért komoly ellátásilánc-menedzsmentre van szükség, amellyel meg lehet szűrni a komponensfejlesztőket, és le lehet követni minden komponenst, ami a belső rendszerekbe kerül.