Причина, по которой такие люди, как я, так твердо убеждены в том, что открытый исходный код - это единственный выход, не имеет ничего общего с «бесплатным», с деньгами.

Все сводится к более основному человеческому желанию - контролю.

Я хочу, чтобы программное обеспечение, от которого я зависел, нельзя было случайно изменить так, как мне не нравится. Если у организации, которая сейчас находится под контролем, есть плохие представления о будущем конкретного программного обеспечения, я хочу иметь возможность что-то с этим делать. В зависимости от того, сколько энергии я хочу вложить в свои действия, они должны быть эффективными - более эффективными, чем попрошайничество.

То, как это работает, - это один фундаментальный рычаг в балансе сил - право на разделение.

Давайте будем честными - почти все программные пакеты в настоящее время находятся под контролем людей, выбранных наугад. Очень мало оригинальных авторов. Как мы можем повлиять на них, чтобы они не сделали ничего безумного с этими программными пакетами?

Правильная лицензия на программное обеспечение с открытым исходным кодом позволяет людям «разделить» проект. Это означает, что любой может взять текущее состояние этого программного обеспечения (с исходным кодом), внести изменения, которые ему нравятся больше, чем текущие изменения старого владельца, а затем повторно опубликовать результат под новым именем, как новый проект с открытым исходным кодом. Новый проект имеет те же права на повторное распространение. С юридической точки зрения, с точки зрения будущего владения и с точки зрения пользователя исходный проект и разделение теперь идентичны и отталкиваются от них в будущем.

Это одно фундаментальное свойство «настоящей» лицензии с открытым исходным кодом, которое имеет для меня значение. Право на разделение.

[необязательный абзац] Прежде чем мы продолжим, позвольте мне предупредительно сказать, что я понимаю, насколько чуждо это звучит для некоторых. Некоторые могут захотеть позволить людям увидеть исходный код и включить изменения, поступающие от сообщества, в код продукта. Но давать полные права на такой откол? Разве это не разрушает сообщество для такого программного обеспечения? Разве не на пользу всему сообществу, работающему с этим конкретным программным обеспечением, если есть какое-то руководство? Может быть, с комитетом, в который входят посторонние? Ну нет. Для меня это не так. Если у меня нет права делить, это не в счет. Отсутствие права на разделение делает все другие права бесполезными с точки зрения будущего планирования. Мне все равно, что сегодня делает программа. Думаю на долгую перспективу.

Итак, право на разделение, как это помогает? Пример время.

У объекта, который в настоящее время контролирует мою почтовую программу (чтобы выбрать пример) есть какая-то дурацкая безумная идея для следующего выпуска. Я не хочу ничего в этом участвовать. Новая функциональность (вместе с существующей функциональностью, которую они должны удалить) ухудшает для меня программное обеспечение. Я знаю, что другие пользователи думают так же. Как разыгрываются сила и рычаги воздействия?

  • Я высказываю свои опасения
  • другие пользователи / участники согласны со мной, от 0% до 100%
  • нынешние владельцы говорят нам идти к черту, и они будут реализовывать свой план по улучшению / разрушению почтовой программы

Теперь я имею право взять весь проект в текущем состоянии, опубликовать где-нибудь копию и внести свои собственные изменения, которые мне больше по душе. Некоторые из тех людей, которым не нравятся изменения первоначального владельца, присоединяются ко мне и вносят свой вклад в мой раскол вместо того, чтобы вносить свой вклад в первоначальный.

Сейчас есть два проекта, и люди-власть разделены. Прогресс замедлен для обоих. Это действительно помогает?

Что ж, это не помогает, но вы просто пропустили шаг. Я сказал: «У меня есть право», а не «Я делаю». Угроза раскола - это рычаг воздействия на открытый исходный код, а не сам раскол.

Видите ли, первоначальные владельцы тоже пострадают, если я возьму некоторых из участников. Они делают меньше кода. Это плечо. Насколько эффективно кредитное плечо? Это зависит от того, сколько людей согласны со мной, сколько людей согласятся с моим расколом и сколько они внесли свой вклад. Кредитное плечо равно нулю, если никто из нас фактически ничего не внес (хотя мы все еще можем разделить и получить нашу стабильную версию).

Таким образом, количество рычагов, позволяющих случайным образом повлиять на находящуюся у власти организацию, пропорционально тому, сколько людей согласны с тем, что их план является фиктивным, и сколько людей взвешено по их вкладам.

Это отличный контроль. Если у меня есть точка зрения, с которой согласны многие ценные люди, у меня большие рычаги влияния. Если я просто бормочу бессвязные жалобы, у меня нет рычагов, независимо от того, сколько других победителей согласны со мной, если они также никогда не вносили свой вклад. Даже если я раскололся, никого не будет волновать новый разветвленный раскол.

Итак - суть здесь в том, что, хотя власть и контроль работают через Right-To-Split, на самом деле игра ведется вокруг отсутствия разделения.

Некодирующие вклады и мощность

Не каждый может или хочет внести большой технический вклад в проект. Эти люди все еще могут быть очень обеспокоены изменением направления оригинала и действительно выиграют от разделения. Что они могут сделать?

Вы можете нанять программистов, чтобы они внесли желаемый вклад в ваш раскол. Это могут быть программисты, которые у вас уже есть и которые отвлекают время. Или подрядчиков, которые занимаются только вашей работой с открытым исходным кодом. Это не должно оставаться таким бесконечно. Если ваши идеи окажутся популярными, вы можете позже привлечь неоплачиваемых участников. Может быть, вам просто нужен рабочий код, чтобы объяснить свою точку зрения? Кодовые переговоры. Эти вундеркинды с открытым исходным кодом пристально смотрят на презентации PowerPoint. Код имеет значение. Рабочий код убеждает.

Сравните это, скажем, с Turbo Pascal. Текущий владелец решает превратить быстродействующий язык программирования среднего уровня в какой-нибудь фантастический язык (только с одной реализацией) и объединить его с игрушечной базой данных. Какого черта? Некоторым старым пользователям это нравится, некоторым нет. Как вы можете повлиять на владельца Turbo Pascal, чтобы он этого не сделал? Что ж, это коммерческое предприятие. Вы можете купить у них программный комплекс. Если они не продаются, вы можете купить всю (умирающую) компанию. Или вы можете умолять. Все варианты не очень привлекательные. Или вы можете пообещать много $$$ от будущих покупок, если этот сумасшедший план не будет реализован. Теперь у вас утечка $$$, а у вас все еще нет прав ни на что.

Splitty и non-splitty сообщества с открытым исходным кодом

Здесь стоит обратить внимание на то, что некоторые сообщества регулярно и случайно разделяются, а некоторые - нет.

Хороший пример - операционные системы - BSD против Linux. Ядро Linux очень сильно скреплено, и большие объемы кода поглощаются одной и той же кодовой базой. Как-то это управляемо, и люди не расходятся. Операционные системы BSD сильно различаются и специализируются. NetBSD и FreeBSD - см. Историю, опубликованную в другом месте. Затем OpenBSD делает разделение, чтобы серьезно заняться дополнительной безопасностью. Это сработало великолепно, потому что другие BSD могут бесплатно выбрать из OpenBSD улучшения, которые оказались ценными в OpenBSD. DragonflyBSD отделяется от FreeBSD, потому что FreeBSD нужна сложная схема блокировки потоков ядра, а Dragonfly хочет остаться с более простой. Веская причина разделиться. PC-BSD на самом деле не является отделением от FreeBSD, но работает как отделенный. Они просто хотели быть более удобными для пользователей. По своему выбору это разделение оставалось очень близким к FreeBSD, так что почти все инженерные разработки разделялись. Они не использовали право на разделение, чтобы сделать из этого разделения что-то важное - но то, что сделало эту ценную работу возможной, - это то, что право на разделение было на месте.

Произошел успешный раскол, который пошел против меня лично. Я сделал работу по превращению CMU-реализации Common Lisp (CMUCL) в проект с открытым исходным кодом, ок. 1996 г. (еще раз спасибо Скотту Фальману). CMUCL было очень сложно перестроить с самим собой. В какой-то момент, я думаю, нас в мире осталось всего 5 человек. Один героический человек устал и разделил проект с конкретной целью разобрать кодовую базу, чтобы упростить загрузку - SBCL. Удаление циклических зависимостей в компиляторе отключило некоторые интересные вещи, некоторые 10 вариантов оптимизации были отброшены - что бы это ни значило. В то время я успешно работал с CMUCL и остро нуждался в быстром коде, который позволял бы выполнять первые поисковые запросы по недорогим авиаперелетам, которые многие из вас использовали для полетов по всему миру через ITA, Orbitz и бесчисленные сайты о путешествиях. Все еще люблю тебя, Орбиц. Я занимаюсь производством, и скорость имеет значение. Я не могу отказаться от 10% оптимизации, независимо от того, означает ли это потерю скорости выполнения на 5% или на 25%. Я не могу посоветовать своему боссу купить на 5% больше места и стоек для центра обработки данных, и я не могу заставить потребителей в своих веб-браузерах ждать еще дольше, чем они уже делают. Это живые запросы, уже через 10+ секунд. Тем не менее, SBCL стал популярным, и участники, привлеченные SBCL, которые не могли привлечь CMUCL, заставили SBCL быстро расползаться по всем CMUCL. (за исключением, возможно, некоторых операций с плавающей запятой). К тому времени, когда ITA наконец смогла перейти на 64-битную версию, SBCL был единственным выбором. Действительный раскол. Image У меня были средства и намерение контролировать вклад в CMUCL - и не допускать разделения. Мы все сегодня выглядели бы довольно глупо. Так же, как это делает Java.