Érdekes véleménycikkel indította az évet a The Register oldalán a lap APAC régióért felelős ausztrál szerkesztője, Simon Sharwood. Azt vizsgálta, hogy figyelembe tudja-e venni a nyílt forráskód a geopolitikai feszültségeket. Amikor Vlagyimir Putyin Oroszországa lerohanta Ukrajnát, sok állam megtiltotta a fejlett technológia exportját Oroszországba. Az USA pedig a nemzetbiztonsági megfontolások mellett az emberi jogok megsértésére is hivatkozik, amikor újra és újra szigorítja a Kínával szembeni technológiai embargót, amibe igyekszik szövetségeseit is bevonni.

Ezzel szemben a nyílt forráskód akadálytalanul áramlik a világban, és nem nézi, hogy gyilkos diktatúra vagy világjobbító demokrácia érdekében használják, bár az USA tett kísérletet a korlátozására. Sharwood az ellentmondás feloldásához kérte a Linux Alapítvány és az Apache Alapítvány segítségét is, de egyik szervezettől sem kapott választ. Idézi viszont az open source mozgalom egy jeles szószólóját, a chicagói Coraline Ada Ehmkét, aki a nyílt forráskódú fejlesztések etikai oldalával foglalkozva elkezdte kidolgozni az ún. Hippocratic License-t.

Ehmke egy 2020-as előadásában azzal érvel a Hippocratic License mellett, hogy a fejlesztőknek erkölcsi kötelességük megakadályozni, hogy munkájukat ártó szándékkal használják fel. Közben persze azt is elismeri, hogy az open source per definitionem a kód bármilyen célú felhasználását lehetővé teszi, beleértve a kifejezetten gonosz célokat is.

Hasonló véleményt mondott lapunknak egy nyílt forráskódú megoldásokkal foglalkozó hazai szakember is: a nyílt forráskódú licencek (mínusz az egyelőre meglehetősen homályos Hippocratic License) nem foglalkoznak etikai kérdésekkel, kizárólag a kód felhasználásának módjáról rendelkeznek (másokét felhasználod, sajátodat visszaadod). De nem is foglalkozhatnak, hiszen egy kódhoz a hozzájárulás bárhonnan jöhet, mintegy "fizetségként" a fejlesztői közösség többi tagja által végzett munkáért. Azaz egyfajta cserekereskedelemről van szó, annak minden előnyével és hátrányával.

Az open source fejlesztések elkötelezett képviselői persze azért igyekeznek az előnyökre helyezni a hangsúlyt. És ebben sok igazságuk is van: az utóbbi bő másfél évtizedben a felhő és a mobiltechnológia a mainstreambe emelte a nyílt forráskódot. (Az IBM például részben a nyílt forráskódra alapozott üzletével naggyá váló Red Hat felvásárlásával vált ismét fontos szereplőjévé az üzleti IT-világnak.)

Az open source sem eredményez tökéletes szoftvert

De pont mainstreammé válása hozta felszínre a hátrányait is. Az InfoWorld amerikai kiadása a közelmúltban ezeket próbálta összegezni egy összeállításában.

Maga a fejlesztési filozófia (több szem, többet lát, így sokoldalúbb a tesztelés, gyors lehet a hibajavítás stb.) nagyon eredményesnek tűnik, amit olyan szoftverek bizonyítanak, mint a Linux, az Android, a MySQL vagy a Docker. De pont a fejlesztési filozófiával függnek össze a problémák is, összegzi az InfoWorld a megkérdezett szakemberek véleményét. Az egy dolog, hogy a nyílt forráskódra intenzíven építő vendorok sokszor vajmi keveset adnak vissza a fejlesztéseikből, ami ellen a közösség egyelőre nem sokat tehet. Vannak ugyanis olyan problémák is, melyeknek technikai hatásai igencsak megnehezítik az open source termékek vállalati alkalmazását.

Itt van például a sokszínűség. Erre az open source közösségek szeretnek egyfajta erényként hivatkozni. De mit is jelent valójában? A közösség tagjai nem csak egymásért élő-haló zseniális fejlesztők. Lehetnek közöttük felületesek, szétszórtak, sőt akár gonoszak is. Hozzáállásuk, amely a kódban testesül meg, sokszor csak használat közben mutatkozik meg. A kódot ugyanis olyan közösség hozza létre, amely csak kvázi létezik, hiszen a projektekhez félig-meddig anonim módon, e-mailben vagy üzenőfalakon kommunikálva kapcsolódó közreműködők alkotják.

És ha már közösség: hiába csak virtuális, felépítése és fenntartása sok energiát emészt fel. Ez főleg akkor mutatkozik meg, amikor egy szoftvervendor próbál úgy új ötleteket (néha érdekes kódolási megoldásokat) gyűjteni, hogy kiadja terméke open source változatát. Ez csak akkor működik, ha energiát fordít a közösség fenntartására: pl. valaki megválaszolja a projektbe bekapcsolódó fejlesztők és felhasználók kérdéseit. Még egy élő közösség is gyorsan leépül, ha nincs olyan központja, amely energiát fektet a koordinálásába. (A nagyobb szoftvervendorok ezért jellemzően főállású fejlesztőket foglalkoztatnak, hogy ellássák ezt a szerepkört egy-egy fontosabb projektnél.)

A közösségekben nincs megfelelő fórum a tudásátadásra, ritka, hogy kialakul a közösségen belüli mentorálás. A megosztás egy pillanat, csupán hozzáférést kell adni egy reménybeli közreműködőnek a projekt Git-tárához, amelyben az új csatlakozó egyből szembesülhet egy figyelmeztetéssel a közreműködői megállapodás végén: nem kap támogatást, és nem garantálja semmi, hogy kérdéseire választ kap. Ahhoz pedig igencsak nagy elszántság kell, hogy ilyen feltételek között valaki elmélyedjen a csilliárd sornyi kódban, amiben ráadásul csak itt-ott vannak használható kommentek.

Csak a pék nem veszi boltban a kenyeret

Felhasználónak és fejlesztőnek egyaránt problémás terület: a nyílt forráskód ingyenessége. Először nézzük a fejlesztőket. Még a legelkötelezettebb open source fejlesztőknek is meg kell élniük valamiből. Többségük idealista ugyan, de ettől még nem lesz ebédjük és fedél a fejük fölött. Azaz a való világ működése részben ellentmond a nyílt forráskód eszméjének. Ezért inkább kisebb stackeknél, szerelemprojekteknél működik.

Nagyobb kódbázisokhoz jellemzően főállású programozókat is alkalmaznak, akiknek a munkáját viszont meg kell fizetni. Ha pedig nem fizetnek a termékért elegen, hanem csak az ingyenes verziót használják, a projekt kimúlik (elég, ha a Mozilla vergődésére és arra gondolunk, hogyan lett az egykor piacvezető Firefoxból marginális szereplő).

Merthogy semmi sincs ingyen. A felhasználóknak sem. A nyílt forráskódú szoftverek használat közben mutatják meg a korlátaikat, hiszen nincs presales mérnök, szakértő, tanácsadó stb., aki már a beszerzés tervezésekor eligazítana egy adott termék funkcionalitásában. Az ilyen szoftverek többsége 99 százalékban megfelel a célnak. A maradék egy százalék néha nem jelent gondot, elég kicsit belenyúlni itt-ott a forráskódba, hiszen ez lehetséges. És ki panaszkodna, hogy csak félig telt a pohár, amikor ingyen volt? De könnyen előfordulhat, hogy annak az 1 százalékos hiátusnak a kitöltése komoly összegeket – és időt – emészt fel.