Fork (szoftverfejlesztés)

A Wikipédiából, a szabad enciklopédiából

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 Linux-disztribúciók elágazásainak kronológiája

Etimológia[szerkesztés | forrásszöveg szerkesztése]

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 | forrásszöveg szerkesztése]

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:

  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, [14] or vagya a LibreOffice és az OpenOffice.org kapcsolata.

Tulajdonosi szoftverek forkolása[szerkesztés | forrásszöveg szerkesztése]

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 | forrásszöveg szerkesztése]

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. A hitszakadás jelentésű „skizma” (schizm) kifejezés tényleges használatban van, pl. "the Lemacs/FSFmacs schism" (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" (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).
  2. Entry 'fork' in Online Etymology Dictionary
  3. Dennis M. Ritchie: The Evolution of the Unix Time-sharing System, 1979. (Hozzáférés: 2012. szeptember 30.)
  4. "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 OutcomesOSS 2012 The Eighth International Conference on Open Source Systems.. Hozzáférés: 2012. október 20.. 
  5. Allman, Eric. "An Introduction to the Source Code Control System." Project Ingres, University of California at Berkeley, 1980.
  6. Can somebody fork off a "net.philosophy"? (John Gilmore, net.misc, 18 January 1983)
  7. Shattering — good or bad? (Russell Nelson, gnu.misc.discuss, 1 October 1993)
  8. Re: Hey Franz: 32K Windows SUCK!!!!! (Bill Dubuque, cu.cs.macl.info, 21 September 1995)
  9. Lignux? (Marcus G. Daniels, gnu.misc.discuss, 7 June 1996)
  10. ^ a b c Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!: Forking (David A. Wheeler)
  11. Eric S. Raymond: Promiscuous Theory, Puritan Practice, 2002. augusztus 15
  12. Forked (Jargon File), first added to v4.2.2, 20 Aug 2000)
  13. 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.”
  14. Forked a project, where do my version numbers start?
  15. Fear of forking - An essay about forking in free software projects, by Rick Moen
  16. EnterpriseDB
  17. Fujitsu Supported PostgreSQL
  18. Netezza

További információk[szerkesztés | forrásszöveg szerkesztése]