Fork (szoftverfejlesztés)

A szoftverfejlesztés területén a fork, azaz a szoftverfejlesztési projekt elágaztatása során a fejlesztők veszik a szoftvercsomag forráskódját és megkezdik annak az eredeti fejlesztéstől független továbbfejlesztését, egy új szoftverterméket hozva létre. A fork leggyakrabban nem csak a termék új fejlesztési elágazására utal, hanem a fejlesztői közösségben történő szakadásra, „skizmára”.

A szabad, illetve open source szoftverek definíció szerint az eredeti fejlesztői csapat külön engedélye nélkül forkolhatók anélkül, hogy a szerzői jog sérülne. Mindazonáltal előfordul a tulajdonosi szoftverek (pl. Unix) esetében is a szoftverfejlesztési projekt licencelt elágaztatása.

A Linux-disztribúciók elágazásainak kronológiája

A szó eredete

Az angol nyelvű „fork” kifejezést (ágakra osztás, különválás értelemben) már a 14. században használták. Számítógépes kontextusban a „fork” 1969 körül jelent meg a zsargonban, a Unixnak arra a mechanizmusára utalva, melynek során egy folyamat (processz) kettéhasad, saját magával megegyező mását létrehozva.

A szoftverfejlesztésben a „fork” első dokumentált, „fejlesztési projekt elágaztatása” értelemben történő használata 1980-ban történt, Eric Allman részéről, aki az SCCS rendszerben az elágazások létrehozását írta le vele:

Creating a branch "forks off" a version of the program.

A kifejezést 1983-ban már használták a Useneten egyes témák egy hírcsoporton belül létrehozott alcsoport alá mozgatására.

1991-ben, a Lucid Emacs (jelenleg XEmacs) elindításának idején a „fork” szónak nem volt olyan jelentésárnyalata, ami közösségi szakadásra utalt volna, sem a BSD-k szétválásának idején, 1993–1994-ben; Russ Nelson 1993-ban a „shattering” (megrázó) kifejezést használta az ilyesfajta forkolásra, a kifejezést John Gilmore-nak tulajdonítva. A „fork” szót már bizonyosan a jelenlegi értelemben használták 1995-ben az XEmacs szakadásának leírására, és a GNU projektben 1996-ra elfogadott használattá vált.

Szabad vagy nyílt forrású szoftverek forkolása

A szabad és/vagy nyílt forrású szoftverek fejlesztése jogszerűen elágaztatható a projekt aktuális vezetőjének vagy a szoftver terjesztőjének jóváhagyása nélkül is, ahogy az a szabad szoftver és az open source szoftverek önmeghatározásaiban is szerepel:

• „3. A jogot arra, hogy tökéletesítsék a programot, és a tökéletesített változatot közzétegyék, hogy az egész közösség élvezhesse annak előnyeit.”
• „3. Származtatott művek létrehozásának engedélyezése: A licencnek lehetővé kell tennie a módosításokat és a származtatott művek előállítását, valamint ezek terjesztését az eredeti program licencével megegyező feltételek mellett.”

A szabad szoftverek elágaztatása sok esetben a résztvevők eltérő célkitűzései vagy személyiségek ütközése miatt következnek be. A szakadás után mindkét fél azonos vagy közel azonos kódbázisból indul ki, de általában csak a nagyobb (vagy a weboldalt birtokoló) csoport tartja meg a projekt eredeti nevét és az ahhoz kapcsolódó felhasználói közösséget. Ezért a forkolással együtt jár a hírnévben, ismertségben elszenvedett veszteség is. A fejlesztőcsapatok közötti kapcsolat milyensége a szívélyestől az elkeseredett viszálykodásig terjedhet.

Eric S. Raymond A nooszféra kisajátítása c. esszéjében kijelenti, hogy „a fork legfontosabb jellemző sajátossága, hogy olyan egymással versenyző projekteket hoz létre, amik között később nem lehetséges kódcsere, kettéosztva a lehetséges fejlesztői közösséget”. A Jargon File-ban megjegyzi:

A forkolást Rossz Dolognak tekintjük – nem csupán azért, mert rengeteg jövőbeli elvesztegett erőfeszítést vetít előre, hanem mert a forkokat jellemzően sok viszály és keserűség veszi körül, az utódcsapatok között legitimitási, utódlási és fejlesztési irányválasztási kérdésekben. Komoly társadalmi nyomás hat a forkolással szemben. Ennek eredményeként a nagyobb forkok (mint a GNU Emacs/XEmacs szétválás, a 386BSD csoport szétrobbanása három utódprojektre és a rövid életű GCC/EGCS szakadás) kellően ritkák ahhoz, hogy a hacker folklór egyenként emlékezzen valamennyire közülük.

David A. Wheeler a szoftverfejlesztés elágaztatásának négy lehetséges kimenetelét jegyzi fel, példákkal illusztrálva:

1. A fork elhalása. Ez a leggyakoribb eset. Könnyű bejelenteni az új, forkolt projekt beindítását, de sokkal jelentősebb erőforrásokat igényel a folyamatos fejlesztési és támogatási munka.
2. A forkok újraegyesítése, összeolvasztása (pl. az egcs jóváhagyása, mint a gcc új verziója).
3. Az eredeti változat elhalása (pl. az X.Org Server sikere és az XFree86 halála).
4. Sikeres fejlesztési elágaztatás, tipikusan megkülönböztetett névvel (pl. OpenBSD és NetBSD).

Az utóbbi időben az elosztott verziókezelő rendszerek (DVCS) népszerűvé tették a „fork” kevésbé emocionális használatát, összemosva a „branch” (elágaztatni) kifejezéssel. A DVCS-ekben, amilyen a Mercurial vagy a Git, a projekthez való hozzájárulás megszokott módja egy új elágazás létrehozása az adattárból (repository), később pedig a változtatások visszaintegrálása a fő adattárba. A Github, a Bitbucket vagy a Launchpad ingyenes DVCS-hosztinggal foglalkozó weboldalak kimondottan támogatják a független fejlesztési ágakat, így a forráskód-adattárak forkolásának technikai, közösségi és pénzügyi korlátai minimálisra csökkentek.

Az elforkolt projektek gyakran újraindítják a verziószámozást 0.1-től vagy 1.0-tól még akkor is, ha a kiindulási szoftver már a 3.0, 4.0 vagy 5.0 verziónál tartott. Kivétel a szabály alól, ha a forkolt szoftvert az eredeti projekt változtatás nélküli helyettesítőjének szánják, amilyen a MariaDB és a MySQL, vagy a LibreOffice és az OpenOffice.org kapcsolata.

Tulajdonosi szoftverek forkolása

A tulajdonosi szoftverek szerzői jogát általában a fejlesztőket alkalmazó entitás birtokolja, nem maguk a szoftverfejlesztők. A tulajdonosi szoftvert így általában akkor forkolják, ha a tulajdonos szükségét érzi két vagy több különálló verzió fejlesztésének, például egy GUI-s és egy parancssori verziónak, vagy különböző operációs rendszerekre készülő változatoknak, pl. egy szövegszerkesztő IBM PC-kompatibilis gépekre és Macintoshokra. Általában az ilyen házon belüli forkok törekednek a változatlan megjelenés és hangulat, adatformátum és viselkedés fenntartására minden platformon, hogy az egyik rendszerben járatos felhasználó megőrizhesse termelékenységét a másik rendszert futtatva is, és képes legyen dokumentumokat megosztani a másikkal. Ez csaknem mindig pénzügyi okokkal indokolható döntés, a nagyobb piaci részesedéssel (és az általa generált pluszbevétellel) indokolva az extra fejlesztési költségeket.

Nevezetes, az előbb említettől eltérő példája a tulajdonosi forknak a kereskedelmi Unix rendszerek számos válfaja – csaknem mindegyik visszavezethető az AT&T Unixra és Unixnak hívja magát, de növekvő mértékben és kölcsönösen inkompatibilisek. Lásd Unix-háborúk.

A BSD licencek megengedik a forkok tulajdonosi szoftverré válását, ezért egyes vélemények szerint a kereskedelmi ösztönzők csaknem elkerülhetetlenné teszik a szoftver tulajdonosivá válását. A példák között említhető a Mac OS X (alapja a tulajdonosi Nextstep és a nyílt forrású FreeBSD), a Cedega és a CrossOver (a WINE tulajdonosi forkja mindkettő, bár a CrossOver fejlesztői követik a Wine projektet és jelentősen hozzá is járulnak), az EnterpriseDB (a PostgreSQL forkja, Oracle-kompatibilitási funkciókkal), a Supported PostgreSQL, tulajdonosi ESM tárolórendszerével és a Netezza, ami a PostgreSQL magasan skálázható, tulajdonosi verziója. Az említett gyártók némelyike bedolgozik a közösségi projektbe is, mások megtartják maguknak a változtatásaikat, hogy a saját kompetitív előnyüket növeljék velük.

Kapcsolódó szócikkek

• Szoftverforkok listája

További információk

• Right to Fork a Meatball Wiki-n.