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”.[1]
A szabad, illetve nyílt forrású 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.
Az angol nyelvű „fork” kifejezést (ágakra osztás, különválás értelemben) már a 14. században használták.[2] 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.[3][4]
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.[5]
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.[6]
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.[7] A „fork” szót már bizonyosan a jelenlegi értelemben használták 1995-ben az XEmacs szakadásának leírására,[8] és a GNU projektben 1996-ra elfogadott használattá vált.[9]
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:[10]
- „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.[10] 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[11] 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.[12][13]
David A. Wheeler a szoftverfejlesztés elágaztatásának négy lehetséges kimenetelét jegyzi fel,[10] példákkal illusztrálva:
- 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.
- A forkok újraegyesítése, összeolvasztása (pl. az egcs jóváhagyása, mint a gcc új verziója).
- Az eredeti változat elhalása (pl. az X.Org Server sikere és az XFree86 halála).
- 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,[14] vagy a LibreOffice és az OpenOffice.org kapcsolata.
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.[15] 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[16]), a Supported PostgreSQL, tulajdonosi ESM tárolórendszerével[17] és a Netezza,[18] 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.
- Szoftverforkok listája
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
