În ingineria software, un fork al unui proiect are loc atunci când unii dezvoltatori preiau o copie a codului sursă a unui pachet de software și încep o dezvoltare independentă, creând un software distinct și separat. Termenul înseamnă de multe ori nu doar un branch de dezvoltare, ci și o divizare a comunității de dezvoltatori, un fel de schismă.[1]
Software-ul liber și open-source, prin definiție, poate fi copiat de la echipa de dezvoltare originală, fără permisiune prealabilă, fără a încălca drepturile de autor. Cu toate acestea, au loc uneori și forkuri de software proprietar (de exemplu Unix).
Etimologia
Cuvântul „fork” este preluat din limba engleză, unde înseamnă „bifurcare”, fiind folosit cu acest sens încă din secolul al XIV-lea.[2] În mediul software, cuvântul face referire și la apelul sistem fork, care determină împărțirea unui proces în curs de rulare în două exemplare (aproape) identice, care (de obicei) diverg pentru a efectua diferite sarcini.[3]
În contextul dezvoltării de software, termenul de „fork” a fost folosit cu sensul de creare a unui „branch” de către Eric Allman încă din 1980, în contextul CSSC:[4]
„Creating a branch "forks off" a version of the program.”
Termenul a fost utilizat pe Usenet până în 1983 pentru procesul de creare a unui subgrup în care să se mute unele subiecte de discuție.[5]
Cu sensul de divizare a comunității, termenul a început să se folosească odată cu originea Lucid Emacs (astăzi, XEmacs) (1991) sau la BSD-uri (1993-1994); Russ Nelson a folosit termenul de „shattering” pentru acest fel de fork în 1993, atribuindu-l lui John Gilmore.[6] Cu toate acestea, cuvântul „fork” apare cu sensul actual din 1995 pentru a descrie divizarea XEmacs,[7] și era înțeles în acest sens în proiectul GNU la 1996.[8]
Forkul de software liber și open source
Software-ul liber și open-source se poate copia liber, fără aprobarea prealabilă a celor care îl dezvoltă, gestionează, sau distribuie conform definiției software-ului liber și a open source-ului:
„Libertatea de a distribui către alții copii ale versiunilor modificate de dumneavoastră (libertatea 3). Făcând aceasta, puteți da întregii comunități șansa de a profita de modificările dumneavostră. Accesul la codul sursă este o precondiție pentru aceasta.”
„3. Opere derivate: Licența trebuie să permită modificări și opere derivate, și trebuie să permită distribuirea lor în aceleași condiții ca și licența software-ului de origine.”
În software-ul gratuit, forkurile apar de multe ori când este o schismă în diferite obiective sau ciocniri de personalitate. Într-un fork, ambele părți pornesc de la baze de cod aproape identice, dar de obicei doar grupul mai mare, sau cel care controlează site-ul web, va păstra numele original și comunitatea asociată de utilizatori. Astfel, există o pierdere de reputație asociată forkului. Relația dintre echipe diferite pot fi cordială, dar și foarte tensionată.
Eric S. Raymond, în eseul său Homesteading Noosfera,[11] afirma că „cea mai importantă caracteristică a unui fork este că generează proiecte concurente, care nu mai pot face schimb de cod mai târziu, divizând potențiala comunitate de dezvoltatori”. El observa în Jargon File:[12]
„Forkul este considerat un Lucru Rău—nu doar pentru că implică irosirea de mult efort în viitor, ci pentru că forkurile tind să fie însoțite de multe frământări și tensiuni între grupurile succesoare pe teme de legitimitate, succesiune și direcție de design. Există o presiune socială puternică împotriva forkingului. Ca urmare, marile forkuri (cum ar fi divizarea Gnu-Emacs(en)[traduceți]/XEmacs(d), fisionarea grupului 386BSD în trei proiecte-fiice, și scurta divizare GCC/EGCS) sunt atât de rare încât rămân în memoria și folclorului hackerilor.”
David A. Wheeler nota[13] patru rezultate posibile ale unui fork, cu exemple:
Moartea forkului este de departe cel mai comun caz. Este ușor să proclami un fork, dar este un efort considerabil să continui dezvoltarea și suportul independent.
O reunire a forkului (de exemplu, egcs a fost „binecuvântat” ca noua versiune de gcc.)
Moartea originalului (de exemplu, X.Org Server a reușit și XFree86 a murit.)
O ramificare reușită, de obicei, cu diferențiere (de exemplu, OpenBSD și NetBSD.)
Instrumentele de control distribuit al versiunilor au popularizat o utilizare mai puțin încărcată emoțional a termenului de „fork”, estompând distincția față de noțiunea de „branch”.[14] Cu un DVCS cum ar fi Mercurial sau Git, modalitatea normală de a contribui la un proiect este de a crea un fork personal al repository-ului, independent de depozitul principal, și mai târziu integrarea modificărilor în cel principal. Site-urile cum ar fi GitHub, Bitbucket și Launchpad oferă gratuit găzduire DVCS sprijinind astfel în mod explicit branch-urile independente, astfel că barierele tehnice, sociale și financiare ale forkului unui cod sursă sunt reduse considerabil, iar GitHub folosește „fork” ca termen pentru această metodă de contribuție la un proiect.
Forkurile adesea duc la reînceperea numerotării versiunilor de la 0.1 sau 1.0, chiar dacă software-ul original era, de pildă, la versiunea 3.0, 4.0 sau 5.0. O excepție este atunci software-ul divizat este proiectat pentru a fi un înlocuitor direct pentru proiectul inițial, cum ar fi MariaDB pentru MySQL[15] sau LibreOffice pentru OpenOffice.org.
Forkul de software proprietar
În software-ul proprietar, dreptul de autor este deținut de regulă de angajator, nu de către dezvoltatorii de software individuali. Codul proprietar este, astfel copiat doar atunci când proprietarul trebuie să dezvolte două sau mai multe versiuni, cum ar fi o versiune cu ferestre și una în linie de comandă, sau versiuni pentru diferite sisteme de operare, cum ar fi un procesor de text pentru mașini compatibile IBM PC și calculatoare Macintosh. În general, astfel de forkuri interne se concentrează pe același aspect, format al datelor, și comportament între platforme, astfel încât un utilizator familiarizat cu unul poate să fie productiv sau să partajeze documente generate pe celălalt. Acest lucru este aproape întotdeauna o decizie economică pentru a genera o mai mare cotă de piață și, astfel, duce la recuperarea costurilor de dezvoltare asociate forkului.
Un notabil fork de software proprietar de acest gen îl constituie numeroasele soiuri de Unix proprietar—aproape toate derivate din AT&T Unix sub licență și toate numite „Unix”, dar din ce în ce mai incompatibile între ele.[16]
Licența BSD permite ca forkurile să devină software proprietar, cu scopul de a încuraja mediul comercial, ceea ce face proprietarizarea aproape inevitabilă. Exemple sunt macOS (bazat pe proiectul proprietar NeXTSTEP și FreeBSD din lumea open source), Cedega și CrossOver (forkuri proprietare de Wine, deși CrossOver urmărește și Wine și contribuie considerabil la acesta), EnterpriseDB (un fork de PostgreSQL, care îi adaugă acestuia caracteristici de compatibilitate cu Oracle[17]), PostgreSQL suportat cu sistemul de stocare proprietar MES,[18] și derivatul proprietar Netezza[19] al lui PostgreSQL. Unii dintre acești furnizori contribuie cu modificări înapoi la proiectul comunitar, în timp ce unii își păstrează modificările drept propriul lor avantaj competitiv.
^"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()." Robles, Gregorio; González-Barahona, Jesús M. (). A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes(PDF). OSS 2012 The Eighth International Conference on Open Source Systems. Arhivat din original(PDF) la . Accesat în .
^e.g. Willis, Nathan (). „An "open governance" fork of Node.js”. LWN.net. Arhivat din original la . Accesat în . Forks are a natural part of the open development model—so much so that GitHub famously plasters a "fork your own copy" button on almost every page.; Vezi și Nyman, Linus (). "Understanding Code Forking in Open Source Software" (Ph.D.). Hanken School of Economics. p. 57. Where practitioners have previously had rather narrow definitions of a fork, [...] the term now appears to be used much more broadly. Actions that would traditionally have been called a branch, a new distribution, code fragmentation, a pseudo-fork, etc. may all now be called forks by some developers. This appears to be in no insignificant part due to the broad definition and use of the term fork by GitHub.
