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”.[1]
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 szó eredete
[szerkesztés]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]
Szabad vagy nyílt forrású szoftverek forkolása
[szerkesztés]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.
Tulajdonosi szoftverek forkolása
[szerkesztés]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.
Kapcsolódó szócikkek
[szerkesztés]Jegyzetek
[szerkesztés]- ↑ A hitszakadás jelentésű „skizma” (schizm) kifejezés tényleges használatban van, pl. "the Lemacs/FSFmacs schism" Archiválva 2009. november 30-i dátummal a Wayback Machine-ben (Jamie Zawinski, 2000), "Behind the KOffice split" (Joe Brockmeier, Linux Weekly News, 2010-12-14), "Copyright assignment - once bitten, twice shy" (Richard Hillesley, H-Online, 2010-08-06), "Forking is a feature" Archiválva 2012. február 29-i dátummal a Wayback Machine-ben (Anil Dash, 2010-09-10), "The Great Software Schism" (Glyn Moody, Linux Journal, 2006-09-28), "To Fork Or Not To Fork: Lessons From Ubuntu and Debian" (Benjamin Mako Hill, 2005).
- ↑ Entry 'fork' in Online Etymology Dictionary
- ↑ Dennis M. Ritchie: The Evolution of the Unix Time-sharing System, 1979. [2014. június 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. szeptember 30.)
- ↑ "The term fork is derived from the POSIX standard for operating systems: the system call used so that a process generates a copy of itself is called fork()." (2012) „A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes”. OSS 2012 The Eighth International Conference on Open Source Systems. Hozzáférés: 2012. október 20.
- ↑ Allman, Eric. "An Introduction to the Source Code Control System." Archiválva 2012. november 20-i dátummal a Wayback Machine-ben Project Ingres, University of California at Berkeley, 1980.
- ↑ Can somebody fork off a "net.philosophy"? (John Gilmore, net.misc, 18 January 1983)
- ↑ Shattering — good or bad? (Russell Nelson, gnu.misc.discuss, 1 October 1993)
- ↑ Re: Hey Franz: 32K Windows SUCK!!!!! (Bill Dubuque, cu.cs.macl.info, 21 September 1995)
- ↑ Lignux? (Marcus G. Daniels, gnu.misc.discuss, 7 June 1996)
- ↑ a b c Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!: Forking Archiválva 2006. április 5-i dátummal a Wayback Machine-ben (David A. Wheeler)
- ↑ Eric S. Raymond: Promiscuous Theory, Puritan Practice, 2002. augusztus 15.
- ↑ Forked (Jargon File), first added to v4.2.2 Archiválva 2012. január 14-i dátummal a Wayback Machine-ben, 20 Aug 2000)
- ↑ Az eredeti szöveg: „Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissioning of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.”
- ↑ Forked a project, where do my version numbers start?
- ↑ Fear of forking - An essay about forking in free software projects, by Rick Moen
- ↑ EnterpriseDB
- ↑ Fujitsu Supported PostgreSQL
- ↑ Netezza