A CyanogenMod halott , a Cyanogen anyavállalat ölte meg. A közösség megpróbálja felvenni a darabokat, és létrehozni egy új projektet, a LineageOS-t, a kód alapján. De emlékeztet arra, hogy a nyílt forráskódú szoftverek nem mind napsütés, szivárvány és stabilitás: valójában gyakran nagyon rendetlenek lehetnek.
Még ha egy projekt is nyílt forráskódú, még nem is feltétlenül reagál a közösségre, még kevésbé egy megbízható szoftverre, amelyre számíthat. A projektek változatosak: vannak, akiket hobbiként egy vagy két fejlesztő irányít, mások sok hatalmas vállalat által fizetett fejlesztőket hoznak össze, míg másokat egyetlen anyavállalat irányít. Minden helyzetnek megvannak a maga problémái és drámája.
Szeretjük a nyílt forráskódú szoftvereket - ne értsen félre minket -, de bizonyos számú kihívást jelent. Vessünk egy pillantást néhányra.
A nyílt forráskód gyakran szenved késéseket és egy jeges fejlődési tempót
Úgy tűnik, hogy sok nyílt forráskódú projekt lassú fejlesztési ütemben szenved, ahol az új verziók végtelenül késnek, az új funkciók lassan jönnek, ha valaha is, és nehéz a nehéz, de fontos funkciókat rangsorolni.
Csak nézze meg az Ubuntu kísérleteit az Unity 8 asztali és a Mir megjelenítő szerver elindítására, lehetővé téve a „konvergencia” vízióját. A Linux asztal ezen új verziójának állítólag sok évvel ezelőtt stabilnak kellett lennie, és még mindig nem az. A projekt jeges ütemben haladt, olyannyira, hogy a Canonicalt ütőerre verte a Microsoft, amely a Windows 10 előtt bejelentette saját jövőképét a PC-vel működő, okostelefonról - és továbbította azt. A Canonical még mindig nem nyújtotta be régóta ígért elképzelését. Talán még néhány év múlva stabil lesz.
ÖSSZEFÜGGŐ: A Firefox miért van még mindig a Google Chrome mögött
A Mozillának is nehézségekbe ütközött a prioritások meghatározása. Még mindig nem szállítottak többfolyamatos és sandbox funkciók a Firefoxban. Ezek kritikus fontosságúak a böngésző biztonságának megőrzése érdekében, megakadályozzák, hogy az összeomlások az egész böngészőt lerombolják, és jobban kihasználják a többfolyamatos CPU-kat. Az összes többi nagy böngésző biztosította ezeket a szolgáltatásokat, beleértve a a gyűlölt Internet böngésző. A Mozilla megkívánta az „Elektrolízis” projektet ezen funkciók hozzáadásához, de 2011-ben leállította, mert túl nehéz volt. Ezután a Mozillának újra kellett indítania 2013-ban. Úgy tűnik, hogy ez a funkció 2017-ben érkezik - ami nagyon-nagyon késő. Időközben a Mozilla időt pazarolt a meghibásodott okostelefon-operációs rendszer Firefox OS-jére.
Ha egy projektben ennyi önkéntes fejlesztő vesz részt, nehézségekbe ütközhet az emberek megtalálása azoknak a nehéz munkáknak, amelyek nem szórakoztatóak.
A belső dráma villákat, villákat és további villákat kezd
A nyílt forráskódú projekt forráskódja bárki számára elérhető. Ez a lényeg! Ha egy nyílt forráskódú projekt nem tetsző módon változik, akkor Ön - vagy a közösség - felveheti azt a régi forráskódot, és új projektként folytathatja a munkát. De a közösségi projektek gyakran annyira be vannak burkolva a belső drámákba, hogy a dolgok több projektre bomlanak, zavart és elidegenítik a 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 kellett terelniük, például a MATE és a Cinnamon. Egy asztali környezet háromra vált, és a fejlesztési erőforrások jobban szétszóródnak a projektek között. Ennek eredményeként egy kis időbe telt, mire a közösség elindította ezeket az új projekteket.
ÖSSZEFÜGGŐ: OpenOffice vs. LibreOffice: Mi a különbség, és melyiket érdemes használni?
Hasonlóképpen, az OpenOffice közösség nem volt boldog amikor az Oracle megszerezte a Sun-t. Az Oracle röviden átnevezte saját, nem nyílt forráskódú irodai csomagját a StarOffice-ot „Oracle Open Office” -ra. A közösségnek új villát kellett létrehoznia, LibreOffice , az OpenOffice kód alapján. De facto nyílt forráskódú irodai csomag lett sok ember számára, de mások még mindig használják az OpenOffice-ot, mert nincsenek tisztában a jobb villával és az azt körülvevő drámával. Az OpenOffice csak sok beépített névfelismeréssel rendelkezik.
És természetesen ott van a CyanogenMod. A Cyanogen Inc. csak kihúzta a dugót a CyanogenMod online szolgáltatásaiból - vagyis inkább megölik a legnépszerűbb, harmadik féltől származó Android ROM-ot, mint hogy átadják a közösségnek, ahelyett, hogy arra kényszerítenék a közösséget, hogy hozzon létre egy új, a LineageOS névre keresztelt CyanogenMod villát. Miért nem adja át a Cyanogen a CyanogenMod projektet a közösségnek? A válasz belső drámának tűnik (lát itt mintát?). A cianogén volt az a cég, amelynek Vezérigazgató megígérte végül is „golyót tennének a Google fejébe”. Végül egy golyót tett a CyanogenMods fejébe, ahelyett.
Mindez csak a CyanogenMod felhasználóinak árt, akik nagyon kevés értesítést kaptak, mielőtt a CyanogenMod szervereit és szolgáltatásait leállítják. A telefonok továbbra is működnek, de a kényelmes frissítések és egyéb szolgáltatások szinte egyik napról a másikra füstbe merülnek. A felhasználóknak csak abban kell reménykedniük, hogy a LineageOS projekt gyorsan helyettesítővé válik.
Nem minden nyílt forráskódú projekt közösségi alapú
A nyílt forráskódú projekteket nem mindig a közösség vezérli. Ha azt mondjuk, hogy egy program nyílt forráskódú, az csak azt jelenti, hogy a kód rendelkezésre áll ahhoz, hogy azt csináld, amivel szereted. A szoftvert fejlesztő vállalatnak nem feltétlenül kell közösségi projektként futtatnia, vagy érdekeltek lehetnek abban, hogy a projektet más szoftvereik népszerűsítésére használják.
A CyanogenMod jó példa erre. Miután a Cyanogen Inc. létrejött, nem igazán törődtek a CyanogenModdal. A Cyanogen új célja a Cyanogen Modular OS platform forgalmazása lett a gyártók számára, a CyanogenMod nagy névfelismerésével kereskedve a projekt megölése után. Talán csak itt van a pénz.
Az Oracle soha nem törődött az OpenOffice-szal, de eredetileg a nevével akarta ösztönözni a StarOffice saját irodai csomagjának eladásait azáltal, hogy azt „Open Office” névvel fémjelezte. Ezután a projektet az Apache-nak adományozta, miután az önkéntes fejlesztők többsége távozott.
A Google nem igazán érdekli Az Android, mint teljes nyílt forráskódú projekt , vagy éppen ezért az „Android Open Source Project” (vagy „AOSP”) egyre több része elmarad. A Google nyitva akarja tartani az Androidot, így a gyártók számára könnyű a testreszabás, de a nyílt forráskódú alkalmazások, például a billentyűzet és a tárcsázó, egyre elavultak. Fogyasztói Android-eszközön a Google csak saját zárt forráskódú billentyűzetet, tárcsázót és más alkalmazásokat tartalmaz. Úgy tűnik, hogy a Google elkötelezett az Android nyílt forráskódú magja mellett, de nem egy teljes nyílt forráskódú operációs rendszer, amelyet az emberek a Google szoftverei és szolgáltatásai nélkül használhatnak. Végül is az Android Open Source Project fejlesztése csak segít Amazon's Fire OS , a Google Android-eszközeinek versenytársa. Mi értelme van ennek?
A nyílt forráskódból hiányozhat komoly munkaerő, annak ellenére, hogy milliók használják
ÖSSZEFÜGGŐ: Szívvel magyarázva: Miért kell most megváltoztatnia a jelszavakat
Ha egy projekt nyílt forráskódú, akkor bárki felhasználhatja hozzájárulása nélkül - akár hatalmas cégek is. Ez problémákhoz vezet, amikor egy fontos, széles körben használt projektnek komoly munkaerő- és forráshiánya van.
Ennek eredményeit a a Heartbleed biztonsági lyuk A Heartbleed kihasználta az OpenSSL egyik 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ős alkalmazottja volt, külső foglalkoztatás nélkül, és Évi 2000 dollár adományként . A projekt többletköltségeket vett fel kereskedelmi támogatási szerződésekből és tanácsadásból, de csak egyetlen teljes munkaidőben foglalkoztatott alkalmazott tűnik megdöbbentően alacsonynak az olyan kritikus infrastruktúra-résznél, amelyet a sokmilliárd dolláros vállalatok, például a Google és a Facebook használnak.
A Heartbleed felhívta a figyelmet arra, hogy mennyire alulfinanszírozott ez a kritikus szoftver, ezért a nagy technológiai vállalatok elkötelezték magukat abban, hogy minden évben pénzt szánnak az OpenSSL és más fontos projektek fejlesztésének finanszírozására a „ Alapinfrastruktúra-kezdeményezés “.
Ennek a történetnek jó eredménye van, persze - de csak azért, mert olyan nagy figyelmet fordítottak rá. Ha egy nyílt forráskódú projektre támaszkodik az infrastruktúra engedélyezéséhez, akkor könnyen végződhet attól függően, és feltételezheti, hogy valaki elég jól karbantartja. Milyen fontos, nyílt forráskódú projektet finanszíroznak kritikusan alulfinanszírozottan? Lehet, hogy addig nem veszünk észre, amíg nincs egy másik nagy probléma.
Kép jóváírása: snoopsmaus
