Homepage » hogyan kell » A nyílt forráskódú szoftverek hátrányai

    A nyílt forráskódú szoftverek hátrányai

    CyanogenMod halott, az anyavállalat, a Cyanogen megölte. A közösség megpróbálja felvenni a darabokat, és létrehoz egy új projektet, a LineageOS-t a kód alapján. De ez egy emlékeztető, hogy a nyílt forráskódú szoftverek nem minden napsütés, szivárvány és stabilitás: sőt, gyakran nagyon rendetlen.

    Még akkor is, ha egy projekt nyílt forráskódú, nem feltétlenül reagál a közösségre, sokkal kevésbé megbízható szoftver, amitől függ. A projektek változóak: Néhányat egy vagy két fejlesztő hobbiként működtet, mások a nagy cégek által fizetett fejlesztőket, míg másokat egy anyavállalat vezeti. Minden helyzetnek saját problémája és dráma van.

    Szeretjük a nyílt forráskódú szoftvert, ne tévesszen el minket, de bizonyos számú kihívást jelent. Nézzük meg néhányat.

    A nyílt forráskód gyakran szenved késéseket és egy gleciális fejlődési ütemet

    Számos nyílt forráskódú projekt látszólag lassú fejlődési ütemben szenved, ahol az új verziók végtelenül késleltetve vannak, az új funkciók lassan jelentkeznek, ha valaha, és nehéz megnehezíteni a nehéz, de fontos funkciókat..

    Nézd csak meg az Ubuntu kísérleteit, hogy elindítsák az Unity 8 asztali és Mir megjelenítő kiszolgálóját, lehetővé téve a „konvergencia” látását. A Linux asztali új verziónak sok évvel ezelőtt stabilnak kellett lennie, és még mindig nem. A projekt glaciális ütemben mozog, annyira, hogy a Canonicalot a Microsoft ütötte meg, amely a Windows 10-es verziója előtt jelentette be a saját PC-meghajtású, okostelefonjait, és azt kézbesítette. A Canonical még mindig nem adta meg a régóta ígért látását. Talán néhány év alatt stabil lesz.

    A Mozilla-nak is nehézségei voltak a prioritások meghatározásában. Még mindig nem szállítottak többprocesszoros és homokozó funkciókat a Firefoxban. Ezek kritikusak ahhoz, hogy a böngésző biztonságos maradjon, megakadályozza az egész böngésző lefagyását, és jobban kihasználja a többprocesszoros CPU-kat. Az összes többi nagyobb böngésző ezeket a szolgáltatásokat, köztük az gyűlölt Internet Explorer-t is szolgáltatta. A Mozilla felsorolta az „Elektrolízis” projektet, hogy felvegye ezeket a funkciókat, de 2011-ben megállította, mert túl nehéz volt. A Mozilla-nak 2013-ban újra kellett indítania. Ez a funkció 2017-ben fog megjelenni, ami valóban késő. Időközben a Mozilla időt vesztett a Firefox operációs rendszeren, egy meghibásodott okostelefon operációs rendszeren.

    Amikor egy projekt olyan sok önkéntes fejlesztőt használ, nehézséget okozhat, hogy megtalálják az embereket, hogy megtegyék a kemény munkát, ami nem szórakoztató.

    Belső dráma kezd villák, villák és további villák

    A nyílt forráskódú projekt forráskódja bárki számára elérhető, hogy megváltoztassa. Ez a lényeg! Ha egy nyílt forráskódú projekt olyan módon változik, ahogy nem tetszik, akkor Ön vagy a közösség képes arra, hogy a régi forráskódot folytassa, és új projektként folytassa a munkát. Azonban a közösségi projektek gyakran olyan belső drámákba kerülnek, amelyek a dolgokat több projektre bontják, zavaró és elidegenedő felhasználókat.

    Például, amikor a GNOME 3 elindult, és sok GNOME 2 felhasználó nem volt elégedett, nem volt azonnal nyilvánvaló út. A fejlesztőknek a GNOME-kódot más projektekbe, például MATE-be és Cinnamon-ra kellett fordítaniuk. Az egyik asztali környezet háromra változott, és a fejlesztési források szétszóródtak a projektek között. Ennek eredményeként eltartott egy ideig, amíg a közösség ezeket az új projekteket megszerezte.

    Hasonlóképpen az OpenOffice közösség nem volt boldog, amikor az Oracle megszerzi a Sun-ot. Az Oracle még röviden átnevezte saját, nem nyílt forráskódú irodai csomagját, a StarOffice-t az „Oracle Open Office” -nak. A közösségnek egy új villát kellett létrehoznia, a LibreOffice, az OpenOffice kód alapján. Számos ember számára a de facto nyílt forráskódú irodai csomag lett, de mások még mindig használják az OpenOffice-t, mert nem tudják a jobb villát és az azt körülvevő drámát. Az OpenOffice-nak csak egy csomó felépített névfelismerése van.

    És persze, van CyanogenMod. A cianogén Inc egyszerűen kihúzta a CyanogenMod online szolgáltatásaihoz tartozó dugót, ami azt jelenti, hogy inkább megölik a legnépszerűbb harmadik fél Android ROM-ot, mint hogy átadják a közösségnek, és arra kényszerítik a közösséget, hogy hozzon létre egy új villát a CyanogenMod nevű LineageOS-nak. Miért nem adja át a cianogén a CyanogenMod projektet a közösségnek? Úgy tűnik, hogy a válasz belső dráma (látsz egy mintát itt?). A cianogén volt az a cég, akinek vezérigazgatója megígérte, hogy végül is „golyót vezetnek a Google fején”. Végül egy golyót vezetett CyanogenMod fejére.

    Ez mindössze a CyanogenMod felhasználóinak sérülését okozza, akik nagyon kevés értesítést kaptak a CyanogenMod szervereinek és szolgáltatásainak leállítása előtt. A telefonok továbbra is működnek, de a kényelmes frissítések és egyéb szolgáltatások majdnem egy éjszakán át füstölnek. A felhasználóknak csak remélniük kell, hogy a LineageOS projekt gyorsan válik helyettesítővé.

    Nem minden nyílt forráskódú projekt közösségi irányítású

    A nyílt forráskódú projekteket nem mindig a közösség hajtja. Egy program megnyitása nyílt forráskódú, csak azt jelenti, hogy a kód rendelkezésre áll, amit szeretne. A szoftvert fejlesztő cégnek nem feltétlenül kell közösségi projektként futtatnia, vagy érdekelhetik a projekt használatát más szoftverek reklámozására..

    CyanogenMod jó példa erre. Amint a Cyanogen Inc. jött létre, nem igazán érdekeltek a CyanogenMod. A cianogén új célja a Cyanogen Modular OS platform forgalmazása a gyártók számára, a CyanogenMod nagyszerű elismerése után a projekt megölése után. Talán éppen ott van a pénz.

    Az Oracle soha nem érdekelte az OpenOffice-t, de kezdetben a nevét használja a StarOffice szabadalmaztatott irodai csomag értékesítésének meghajtására, azáltal, hogy az „Open Office” névvel jelölte meg. Ezután az önkéntes fejlesztők többségét követően az Apache-nak adományozta a projektet.

    A Google sem igazán érdekli az Androidot, mint egy teljes nyílt forráskódú projektet, ezért egyre több és több része az „Android nyílt forráskódú projekt” (vagy „AOSP”) marad. A Google meg akarja tartani az Androidot, így a gyártók könnyen testre szabhatják, de a nyílt forráskódú alkalmazások, mint például a billentyűzet és a tárcsázó, egyre elavultabbak. Egy fogyasztói Android-eszközön a Google csak a saját zárt forráskódú billentyűzetét, tárcsázóját és más alkalmazásokat köt össze. Úgy tűnik, a Google elkötelezett az Android nyílt forráskódú magja iránt, de nem egy nyílt forráskódú operációs rendszer használhatja a Google szoftvereit és szolgáltatásait. Végül is, az Android nyílt forráskódú projektjének javítása csak segít az Amazon Fire OS-nek, a Google Android-eszközeinek versenytársának. Mi a lényege ennek?

    A nyílt forráskód hiányozhat komoly munkaerőt, annak ellenére, hogy milliókat használnak

    Ha egy projekt nyílt forráskódú, bárki használhatja azt anélkül, hogy hozzájárulna-még hatalmas vállalatokhoz is. Ez problémákhoz vezet, amikor egy fontos, széles körben használt projekt súlyos munkaerő- és pénzhiányt jelent.

    Ennek eredményeit 2014-ben a Heartbleed biztonsági lyukkal láttuk. A Heartbleed kihasználta az OpenSSL biztonsági rését. Az OpenSSL egy fontos titkosítási könyvtár, amelyet sok óriási technológiai vállalat és több százezer webszerver használ. De csak egy teljes munkaidőben foglalkoztatott alkalmazottja volt, külső foglalkoztatás nélkül, és évi 2000 dollárt adományoztak. A projekt további támogatást kapott a kereskedelmi támogatási szerződésekből és tanácsadásból, de csak egy teljes munkaidőben foglalkoztatott munkavállaló tűnik megdöbbentően alacsonynak a több milliárd dolláros vállalatok, mint a Google és a Facebook által használt kritikus infrastruktúra számára..

    A Heartbleed felhívta a figyelmet arra, hogy ez a kritikus szoftver mennyire alulfinanszírozott, olyan nagy technológiai cégek, amelyek minden évben pénzt szántak pénzre, hogy finanszírozzák az OpenSSL és más fontos projektek fejlesztését a „Core Infrastructure Initiative” részeként.

    Ez a történet jó eredményt mutat, de csak azért, mert annyi figyelmet fordítottunk rá. Amikor egy nyílt forráskódú projektre támaszkodik, hogy engedélyezze az infrastruktúrát, könnyen el lehet végezni, attól függően, hogy valaki más megfelelően tartja. Milyen más fontos nyílt forráskódú projektet kritikusan alultápláltak? Előfordulhat, hogy nem veszünk észre, amíg nem lesz egy másik nagy probléma.

    Képhitel: snoopsmaus