В программной инженерии форк проекта происходит, когда разработчики берут копию исходного кода из одного программного пакета и начинают независимую разработку на его основе, создавая отдельную и отдельную часть программного обеспечения. [ необходим пример ] Термин часто подразумевает не только ветвь разработки , но и раскол в сообществе разработчиков; как таковой, это форма раскола . [1] Основаниями для форка являются различные предпочтения пользователей и застой или прекращение разработки исходного программного обеспечения.
Бесплатное и открытое программное обеспечение — это то, что по определению может быть ответвлено от исходной команды разработчиков без предварительного разрешения и без нарушения закона об авторских правах . Однако лицензированные ответвления проприетарного программного обеспечения ( например, Unix ) также случаются.
Слово «fork» использовалось в значении «разделяться на ветви, идти разными путями» еще в XIV веке. [2] В программной среде это слово вызывает системный вызов fork , который заставляет запущенный процесс разделяться на две (почти) идентичные копии, которые (обычно) расходятся для выполнения различных задач. [3]
В контексте разработки программного обеспечения термин «fork» использовался в значении создания « ветви » контроля версий Эриком Оллманом еще в 1980 году в контексте Системы контроля исходного кода : [4]
Создание ветки «ответвляет» версию программы.
Этот термин использовался в Usenet к 1983 году для обозначения процесса создания подгруппы, в которую можно было переносить темы для обсуждения. [5]
Неизвестно, чтобы слово «fork» использовалось в смысле раскола сообщества во время зарождения Lucid Emacs (теперь XEmacs ) (1991) или Berkeley Software Distributions (BSDs) (1993–1994); Расс Нельсон использовал термин «shattering» для такого рода форка в 1993 году, приписывая его Джону Гилмору . [6] Однако слово «fork» использовалось в нынешнем смысле к 1995 году для описания раскола XEmacs, [7] и было понятным использованием в проекте GNU к 1996 году. [8]
Бесплатное программное обеспечение с открытым исходным кодом может быть законно разделено без предварительного одобрения тех, кто в настоящее время разрабатывает, управляет или распространяет программное обеспечение, согласно как Определению свободного программного обеспечения , так и Определению открытого исходного кода : [9]
Свобода распространять копии ваших измененных версий среди других (свобода 3). Делая это, вы можете дать всему сообществу возможность извлечь выгоду из ваших изменений. Доступ к исходному коду является предварительным условием для этого.
3. Производные работы: Лицензия должна разрешать внесение изменений и создание производных работ, а также их распространение на тех же условиях, что и лицензия на исходное программное обеспечение.
В свободном программном обеспечении форки часто возникают из-за раскола из-за разных целей или личных столкновений. При форке обе стороны принимают почти идентичные кодовые базы, но обычно только большая группа или тот, кто контролирует веб-сайт, сохраняет полное оригинальное имя и связанное с ним сообщество пользователей. Таким образом, с форком связано снижение репутации. [9] Отношения между различными командами могут быть как сердечными, так и очень горькими. С другой стороны, дружественный форк или софт-форк — это форк, который не намерен конкурировать, но хочет в конечном итоге слиться с оригиналом.
Эрик С. Рэймонд в своем эссе Homesteading the Noosphere [12] заявил, что «самой важной характеристикой форка является то, что он порождает конкурирующие проекты, которые впоследствии не могут обмениваться кодом, разделяя потенциальное сообщество разработчиков». Он отмечает в Jargon File : [13]
Форкинг считается Плохим Делом — не только потому, что он подразумевает много напрасных усилий в будущем, но и потому, что форки, как правило, сопровождаются большой борьбой и желчью между группами-преемниками по вопросам легитимности, преемственности и направления дизайна. Существует серьезное социальное давление против форкинга. В результате крупные форки (такие как раскол Gnu-Emacs / XEmacs , разделение группы 386BSD на три дочерних проекта и недолговечный раскол GCC / EGCS) достаточно редки, чтобы их помнят по отдельности в хакерском фольклоре.
Дэвид А. Уиллер отмечает [9] четыре возможных результата разветвления с примерами:
Инструменты распределенного управления версиями (DVCS) популяризировали менее эмоциональное использование термина «форк», размывая различие с «ветвью». [14] С DVCS, такими как Mercurial или Git , обычным способом внести вклад в проект является сначала создание личной ветви репозитория, независимой от основного репозитория, а затем попытка интегрировать ваши изменения с ней. Такие сайты, как GitHub , Bitbucket и Launchpad, предоставляют бесплатный хостинг DVCS, явно поддерживающий независимые ветви, так что технические, социальные и финансовые барьеры для разветвления репозитория исходного кода значительно снижаются, и GitHub использует термин «форк» в качестве своего термина для этого метода внесения вклада в проект.
Форки часто перезапускают нумерацию версий с номеров, обычно используемых для начальных версий программ, таких как 0.0.1, 0.1 или 1.0, даже если исходное программное обеспечение имело другую версию, например, 3.0, 4.0 или 5.0. Иногда делается исключение, когда разветвленное программное обеспечение предназначено для замены исходного проекта, например, MariaDB для MySQL [15] или LibreOffice для OpenOffice.org .
Лицензии BSD позволяют форкам становиться проприетарным программным обеспечением, и сторонники копилефта говорят, что коммерческие стимулы, таким образом, делают проприетизацию почти неизбежной. (Однако лицензии копилефта можно обойти с помощью двойного лицензирования с проприетарным грантом в форме лицензионного соглашения участника .) Примерами служат macOS (основанная на проприетарном NeXTSTEP и открытом исходном коде FreeBSD ), Cedega и CrossOver (проприетарные форки Wine , хотя CrossOver отслеживает Wine и вносит значительный вклад), EnterpriseDB (форк PostgreSQL , добавляющий функции совместимости с Oracle [16] ), поддерживаемый PostgreSQL с их проприетарной системой хранения ESM [17] и проприетарная высокомасштабируемая производная PostgreSQL от Netezza [18] . Некоторые из этих поставщиков вносят обратные изменения в проект сообщества, в то время как некоторые сохраняют свои изменения как свои собственные конкурентные преимущества.
В проприетарном программном обеспечении авторские права обычно принадлежат нанимателю, а не отдельным разработчикам программного обеспечения. Таким образом, проприетарный код чаще всего разветвляется, когда владельцу необходимо разработать две или более версий, например, оконную версию и версию командной строки , или версии для разных операционных систем, например, текстовый процессор для машин, совместимых с IBM PC, и компьютеров Macintosh . Как правило, такие внутренние разветвления будут сосредоточены на том, чтобы иметь одинаковый внешний вид, ощущение, формат данных и поведение между платформами, чтобы пользователь, знакомый с одной из них, также мог быть продуктивным или делиться документами, созданными на другой. Это почти всегда экономическое решение для создания большей доли рынка и, таким образом, окупить связанные с этим дополнительные затраты на разработку, созданные разветвлением.
Известным проприетарным ответвлением не такого рода являются многочисленные разновидности проприетарного Unix — почти все они произошли от AT&T Unix по лицензии и все называются «Unix», но все более несовместимы друг с другом. [19] См. Unix wars .
Форки являются естественной частью открытой модели разработки — настолько, что GitHub, как известно, размещает кнопку "создай свою копию" почти на каждой странице.См. также Nyman, Linus (2015). Understanding Code Forking in Open Source Software (PhD). Hanken School of Economics. стр. 57. hdl :10138/153135.
Там, где у практиков ранее были довольно узкие определения fork, [...] этот термин теперь, по-видимому, используется гораздо шире. Действия, которые традиционно назывались бы веткой, новым распределением, фрагментацией кода, псевдо-fork и т. д., теперь могут называться fork некоторыми разработчиками. Это, по-видимому, не в последнюю очередь связано с широким определением и использованием термина fork на GitHub.