В разработке программного обеспечения разветвление проекта происходит , когда разработчики берут копию исходного кода из одного пакета программного обеспечения и начинают над ним независимую разработку, создавая отдельную и отдельную часть программного обеспечения. Этот термин часто подразумевает не просто ветку разработки , но и раскол в сообществе разработчиков; как таковое, это форма раскола . [1] Основаниями для разветвления являются различные предпочтения пользователей, а также застой или прекращение разработки исходного программного обеспечения.
Бесплатное программное обеспечение с открытым исходным кодом — это то, что по определению может быть создано первоначальной командой разработчиков без предварительного разрешения и без нарушения закона об авторских правах . Однако встречаются и лицензионные форки проприетарного программного обеспечения ( например, Unix ).
Слово «вилка» использовалось в значении «разделиться на ветви, пойти разными путями» еще в 14 веке. [2] В программной среде это слово вызывает системный вызов fork , который заставляет работающий процесс разделиться на две (почти) идентичные копии, которые (обычно) расходятся для выполнения разных задач. [3]
В контексте разработки программного обеспечения «вилка» использовалась в смысле создания «ветви » контроля версий Эриком Оллманом еще в 1980 году в контексте системы контроля исходного кода : [4]
Создание ветки "отделяет" версию программы.
К 1983 году этот термин использовался в Usenet для обозначения процесса создания подгруппы для перемещения тем для обсуждения. [5]
Неизвестно, чтобы слово «вилка» использовалось в смысле раскола сообщества во время зарождения Lucid Emacs (ныне XEmacs ) (1991) или Berkeley Software Distributions (BSD) (1993–1994); Расс Нельсон использовал термин «разрушение» для этого типа вилки в 1993 году, приписав его Джону Гилмору . [6] Однако слово «вилка» использовалось в нынешнем смысле к 1995 году для описания разделения XEmacs, [7] и к 1996 году стало понятным использованием в проекте GNU . [8]
Бесплатное программное обеспечение и программное обеспечение с открытым исходным кодом может быть юридически разветвлено без предварительного одобрения тех, кто в настоящее время разрабатывает, управляет или распространяет программное обеспечение как в соответствии с « Определением свободного программного обеспечения», так и с «Определением открытого исходного кода » : [9]
Свобода распространять копии ваших модифицированных версий среди других (свобода 3). Сделав это, вы дадите всему сообществу возможность извлечь выгоду из ваших изменений. Доступ к исходному коду является предварительным условием для этого.
3. Производные работы. Лицензия должна разрешать модификации и производные работы, а также разрешать их распространение на тех же условиях, что и лицензия на исходное программное обеспечение.
В свободном программном обеспечении ответвления часто возникают в результате раскола по поводу различных целей или личных конфликтов. В форке обе стороны предполагают практически идентичные базы кода, но обычно только большая группа или тот, кто контролирует веб-сайт, сохраняет полное исходное имя и связанное с ним сообщество пользователей. Таким образом, существует штраф за репутацию, связанный с разветвлением. [9] Отношения между разными командами могут быть как теплыми, так и очень ожесточенными. С другой стороны, дружественный форк или софт-форк — это форк, который не намерен конкурировать, но хочет в конечном итоге слиться с оригиналом.
Эрик С. Рэймонд в своем эссе «Homesteading the NoSphere » [12] заявил, что «самой важной характеристикой форка является то, что он порождает конкурирующие проекты, которые не могут позже обмениваться кодом, разделяя потенциальное сообщество разработчиков». В «Жаргонном файле» он отмечает : [13]
Форкирование считается плохой вещью — не только потому, что оно предполагает много напрасных усилий в будущем, но и потому, что форки, как правило, сопровождаются сильными раздорами и враждебностью между группами-преемниками по вопросам легитимности, преемственности и направления разработки. . Существует серьезное социальное давление против форка. В результате крупные форки (такие как разделение Gnu-Emacs / XEmacs , разделение группы 386BSD на три дочерних проекта и недолговечное разделение GCC/EGCS) достаточно редки, поэтому в хакерском фольклоре их помнят по отдельности.
Дэвид А. Уиллер отмечает [9] четыре возможных результата форка с примерами:
Инструменты распределенного контроля версий (DVCS) популяризировали менее эмоциональное использование термина «вилка», стирая различие с «ветвью». [14] При использовании DVCS, такого как Mercurial или Git , обычный способ внести свой вклад в проект — сначала создать личную ветку репозитория, независимую от основного репозитория, а затем попытаться интегрировать с ним ваши изменения. Такие сайты, как GitHub , Bitbucket и Launchpad , предоставляют бесплатный хостинг DVCS, явно поддерживая независимые ветки, так что технические, социальные и финансовые барьеры для разветвления репозитория исходного кода значительно сокращаются, а GitHub использует термин «разветвление» для этого метода вклада. в проект.
Форки часто перезапускают нумерацию версий с 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, как известно, размещает кнопку «разветвить свою собственную копию» почти на каждой странице.См. также Найман, Линус (2015). Понимание разветвления кода в программном обеспечении с открытым исходным кодом (доктор философии). Ханкенская школа экономики. п. 57. HDL : 10138/153135.
Если раньше практики имели довольно узкое определение вилки, то теперь этот термин, похоже, используется гораздо шире.
Действия, которые традиционно назывались ветвью, новым дистрибутивом, фрагментацией кода, псевдо-форком и т. д., теперь некоторые разработчики могут называть ветвями.
Похоже, что это в немалой степени связано с широким определением и использованием GitHub термина «форк».