A Red Hat blogján ma jelent meg Mike McGrath, a Red Hat Core Platforms Engineering alelnökének bejegyzése. A bejegyzésben a „Red Hat nyílt forráskód iránti elkötelezettségéről” beszél, így:
A hétvégén sok időt töltöttem sétával, és sokat gondolkodtam az iparágunk reakcióján a legutóbbi blogbejegyzésemre. Gonosznak neveztek minket; engem egy IBM-vezetőnek neveztek, akit azért helyeztek a RedHat élére, hogy a Red Hatot zárt forráskódúvá tegye - és ez csak a „szép” dolgok. Szóval tisztázzuk a dolgokat.
A nevem Mike McGrath, és én vagyok a Red Hat Core Platforms Engineering alelnöke. Már 16 éve vagyok itt, és mielőtt elkezdtem volna itt dolgozni, önkéntes voltam a Fedora Projectben. A nyílt forráskód és minden, amit ez a kifejezés magában foglal, nagyon fontos számomra. Az elmúlt héten sok embertől láttam, hogy sok rosszindulatú és valótlan dolgot mondtak a keményen dolgozó Red Hatosokról, akik hozzám hasonlóan alapvetően értékelik ezt a munkát.
Annak ellenére, amit jelenleg a Red Hatról mondanak, mi a kemény munkánkat a nem ügyfelek számára is könnyen hozzáférhetővé tesszük. A Red Hat nyílt forráskódú fejlesztési modellt használ és mindig is használni fog. Ha hibát találunk vagy funkciót írunk, akkor a kódunkat az upstream felé elérhetővé tesszük. Ez a közösség minden tagjának hasznára válik, nem csak a Red Hat-nak és ügyfeleinknek.
Mi nem egyszerűen átvesszük az upstream csomagokat, és újraépítjük őket. A Red Hatnál emberek ezrei töltik az idejüket azzal, hogy kódot írnak az új funkciók lehetővé tételére, a hibák kijavítására, a különböző csomagok integrálására, majd hosszú ideig támogatják ezt a munkát - amire ügyfeleinknek és partnereinknek is szükségük van.
Itt azokról az órákról és késő éjszakákról van szó, amelyeket azzal töltünk, hogy egy-egy javítást visszaportálunk egy olyan kódhoz, amely már 5-10 éves vagy régebbi; bármikor 3-4 nagyobb kiadási folyamot támogatunk, miközben mindegyikhez alkalmazunk javításokat és visszaportokat. Emellett, amikor javításokat fejlesztünk a RHEL problémáihoz, nem csak a RHEL-re alkalmazzuk őket - először upstream projektekre, például a Fedora, CentOS Stream vagy magára a kernel projektre alkalmazzuk őket, majd visszaportáljuk őket. Egy operációs rendszer 10 évig tartó karbantartása és támogatása herkulesi feladat - az általunk végzett munka óriási értéket képvisel.
Mindig elküldjük a kódunkat upstream részére, és betartjuk a termékeink által használt nyílt forráskódú licenceket, amelyek közé tartozik a GPL is. Amikor azt mondom, hogy betartjuk a kódunkra vonatkozó különböző nyílt forráskódú licenceket, akkor ezt komolyan gondolom. Megdöbbentett és csalódott voltam, hogy milyen sokan tévedtek a nyílt forráskódú szoftverekkel és különösen a GPL-lel kapcsolatban - különösen az iparági megfigyelők és még a veteránok is, akiknek szerintem jobban kellene tudniuk. A részletek - beleértve a nyílt forráskódú licenceket és jogokat - számítanak, és ezek olyan dolgok, amelyek kialakításában, megőrzésében és fejlesztésében a Red Hat is segített.
Úgy érzem, hogy a közelmúltban hozott döntésünk miatti harag nagy része a továbbfejlesztett forrásokkal kapcsolatban vagy azoktól származik, akik nem akarnak fizetni a RHEL-be fektetett időért, erőfeszítésért és erőforrásokért, vagy azoktól, akik saját profitjuk érdekében át akarják csomagolni azt. Ez a RHEL-kód iránti igény álságos.
Meg kell fizetnünk azokat az embereket, akik ezt a munkát végzik - azokat a szenvedélyes közreműködőket, akik hosszú órákat és éjszakákat töltenek a nyílt forráskódú értékek mellett. Ha egyszerűen újracsomagoljuk az általuk készített kódot, és úgy adjuk el, ahogy van, hozzáadott érték nélkül, az fenntarthatatlanná teszi a nyílt forráskódú szoftverek előállítását. Ez magában foglalja a kritikus backporting munkát és a jövőbeli funkciókat és technológiákat, amelyek fejlesztés alatt állnak. Ha ez a munka fenntarthatatlanná válik, akkor leáll, és ez senkinek sem jó.
Külön szeretném megemlíteni az újraépítőket, eltérően a disztribúcióktól, amelyek például új architektúrát vagy fordítási zászlót adnak hozzá (teljes mértékben támogatjuk, hogy a Linux képességeit bővítsék, ahelyett, hogy utánozzák azokat).
Volt idő, nem is olyan régen, amikor a Red Hat értéket látott az olyan rebuilderek által végzett munkában, mint a CentOS. Az SRPM-jeinket a git.centos.org-ra raktuk ki egy csinos csomagban, ami megkönnyítette az újraépítést; még a márkát is lecseréltük nekik. Nemrégiben úgy döntöttünk, hogy nem jelent értéket egy downstream rebuilder.
Az általánosan elfogadott álláspont, miszerint ezek az ingyenes újjáépítések csak tölcsérek, amelyek RHEL-szakértőket űznek ki, és eladásokká alakulnak, egyszerűen nem felel meg a valóságnak. Bárcsak ebben a világban élnénk, de a valóságban nem így működik. Ehelyett találtunk egy olyan felhasználói csoportot, akik közül sokan nagy vagy nagyon nagy IT-szervezetekhez tartoznak, akik a RHEL stabilitását, életciklusát és hardveres ökoszisztémáját akarják anélkül, hogy ténylegesen támogatniuk kellene a karbantartókat, mérnököket, írókat és még sok más szerepet, akik ezt létrehozzák. Ezek a felhasználók szintén úgy döntöttek, hogy nem használják a sok más Linux-disztribúció egyikét sem.
Egy egészséges nyílt forráskódú ökoszisztémában a verseny és az innováció kéz a kézben jár. A Red Hat, a SUSE, a Canonical, az AWS és a Microsoft mind Linux-disztribúciókat hoz létre, amelyekhez kapcsolódó márkaépítési és ökoszisztéma-fejlesztési erőfeszítések társulnak. Ezek a változatok mind felhasználják és hozzájárulnak a Linux forráskódjához, de egyikük sem állítja, hogy "teljesen kompatibilis" lenne a többiekkel.
Végső soron nem találunk értéket a RHEL újjáépítésében, és nem vagyunk kötelesek megkönnyíteni az újjáépítők dolgát; ez a mi döntésünk. Ezzel eljutottam a CentOS Streamhez, amellyel kapcsolatban óriási a zűrzavar. Elismerem, hogy ez a változás egy olyan hosszú hagyományt változtat meg, ahol mi minden eddiginél többet tettünk, és az ilyen változtatások okozhatnak némi zavart. Ez a zűrzavar a zárt forráskódúvá válásunkkal és a GPL állítólagos megsértésével kapcsolatos vádaskodásokban nyilvánult meg. Van a CentOS Stream a bináris szállítható változat, és van a CentOS Stream a forráskód-tár. A CentOS Stream gitlab forrása az a hely, ahol a RHEL kiadásokat készítjük, nyíltan, mindenki számára láthatóan. A RHEL-t „zárt forráskódúnak” nevezni kategorikusan valótlan és pontatlan. A CentOS Stream gyorsabban halad, mint a RHEL, így lehet, hogy nem a HEAD-en van, de a kód ott van. Ha nem találod, az egy hiba - kérlek, jelezd nekünk.
Emellett ingyenes Red Hat Developer előfizetéseket és Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure is kínálunk. A fejlesztői előfizetés ingyenes RHEL-t biztosít a fejlesztők számára, és akár 16 rendszer használatát teszi lehetővé, szintén ingyenesen. Ezt magánszemélyek saját munkájukhoz, a RHEL-ügyfelek pedig alkalmazottaik munkájához használhatják. Az RHEL for Open Source Infrastructure célja, hogy a nyílt forráskódú projektek (függetlenül attól, hogy bármilyen módon kapcsolatban állnak-e a Red Hat-tal) ingyenesen hozzáférjenek a RHEL-hez az infrastrukturális és fejlesztési igényeikhez.
Végezetül szeretnék megszólítani minden nyílt forráskódú vállalatot, függetlenül attól, hogy a kódjuk ma nyílt, vagy a nyílt forráskódú modellre való áttérést fontolgatják. A Red Hat minden mércével mérve "megcsinálta", és remélem, hogy sok nyílt forráskódú vállalatnak sikerülhet úgy, ahogy nekünk sikerült. Ön maga döntheti el, hogy a downstream átépítések értékesek-e az Ön számára, és az Ön döntése, hogy megkönnyíti-e a dolgát, vagy sem.
A kód egyszerű újraépítése, anélkül, hogy hozzáadott értéket teremtene vagy bármilyen módon megváltoztatná azt, valódi fenyegetést jelent mindenhol a nyílt forráskódú vállalatokra nézve. Ez valódi veszélyt jelent a nyílt forráskódra, és magában hordozza a nyílt forráskód visszaváltozását egy kizárólag hobbi- és hackertevékenységgé.
Ezt mi nem akarjuk, és tudom, hogy a közösségünk tagjai, ügyfeleink és partnereink sem akarják ezt. Az innováció az upstreamben történik. A nyílt forráskód arról szól, hogy mások vállára építkezünk. Folytassuk az innovációt, támogassuk egymást és haladjunk előre.