Иллюстрация 1. Сообщество вокруг свободного программного продукта
Когда разработка одного экземпляра вычислительной машины длилась годами, а сам этот экземпляр выглядел как магазин продажи холодильников, программы для этой машины числились наряду с мелкими и средними деталями для неё. Скажем, для записи данных на перфоленту прежде всего необходим перфоратор, затем — процессор, который будет этим перфоратором управлять, а уж затем — всякие там провода, программы для записи данных и прочая необходимая мелочь. Красноречиво этот факт подтверждает термин «операционная система», точнее, его исходное английское написание — «operating system». Дескать, есть некоторая «система» (system) — это высокоорганизованный набор электронных деталей. Но система на настолько сложна, что «использовать» (operate) эту систему лучше по определённым правилам, тут вот даже кой-какие программки для этого написаны, они и задают правила «использования системы» (operating system). И том же говорят и наши термины: «аппаратное обеспечение ЭВМ» и «программное обеспечение ЭВМ», подразумевающие, что утилиты и компиляторы так же крепко привязаны к этой вот конкретно машине, как микросхемы и вентиляторы.
Различение «набора деталей» (system) и «набора программ» (operating system) далось машиностроителям не вдруг. Сначала открыли цикл ПКМ: «программирование — компиляция — отладка (неуспешная) — программирование — и. т. д.... — отладка (успешная)». С чугунной деталью так не поступают: выточил деталь — поставил в машину — она взорвалась вместе с деталью... Затем выяснилось, что, в отличие от детали, программу удобно разрабатывать совместно, когда каждый может подключиться к работе и добавить несколько нужных лично ему функций; надо только определиться, кто отвечает за всю программу целиком и принимает решения.
Только после распространения языка программирования «Си» и операционной системы UNIX стало зарождаться понятие кроссплатформенности, которое сделало это отличие совершенно очевидным, и навсегда оторвало программный продукт от жёсткой привязки к «system» и даже «operating system». Кроссплатформенность, то есть возможность использования одного и того же программного продукта независимо от того, где он запускается («платформы» или «среды»), открыла новые возможности в совместной разработке. К одному и тому же проекту стали присоединяться программисты, работающие на разных компьютерах. Они свободно обменивались друг с другом программами, но ещё чаще — исходными текстами к ним, так как выполняться скомпилированная программа может только в рамках одной платформы, а исходные тексты всё равно нужны для доработки и исправления.
Где-то в это время, в конце семидесятых прошлого века, стало очевидным и свойство, которое так сильно — и технологически, и экономически — отличает программные продукты от продуктов других производств. Это свойство безущербного копирования.
Что нужно сделать, чтобы вместо единственной хорошей детали стало две одинаковых? Купить чугунную болванку, а рабочий выточит из неё деталь. Вторая деталь нам ни к чему, мы её отдали; чего мы при этом лишаемся, ведь первая-то при нас? Разумеется, денег: болванку мы покупали, а токарю — платили, это его труд создал копию. Копирование причиняет ущерб, который, по-честному, надо возмещать. Например, тем, что детали отныне мы будем не дарить, а продавать.
Так. А что нужно для того, чтобы из единственной хорошей программы стало две одинаковых? Выполнить операцию копирования, больше ничего. Если тот, кому вы собираетесь эту программу подарить, принесёт с собой записываемый лазерный диск, вам это ни во что не станет. Копирование экземпляра программы безущербное для хозяина этого экземпляра.
Тут между разработчиками программ случился раскол. Одни (будем называть их «эгоистами») говорили: «надо запретить свободное распространение не только исходных текстов, но и вообще самих программ. Программы надо продавать! Это ж сколько денег можно выудить прямо из воздуха. А вы, господа альтруисты (назовём их так), просто олухи царя небесного, маргиналы, пиджаков не носите, питаетесь кофе и гамбургерами, и ничего не знаете о том, как вести бизнес».
«Альтруисты» возражали: «нам всё равно, что носить, мы любим кофе, и это наши программы, мы их написали, мы хозяева — что хотим, то и делаем. А если мы не будем свободно распространять исходные тексты, как вообще тогда программы разрабатывать? В одиночку, что ли?»
«Зачем в одиночку? — напирали эгоисты — Из воздуха-то можно много денег понаделать, мы наймём вам помощников, сколько надо, только не показывайте никому трудов своих, а для пущей крепости хозяевами вашим программ будем считаться мы, а уж мы-то позаботимся о том, чтобы каждая копия превращалась в зелёную бумажку».
Мировое сообщество в прошлом веке в целом знать не знало ни о каком безущербном копировании, так что с удовольствием начало вырабатывать законы, это копирование запрещающие. Главный ход, конечно, состоит в том, что право распоряжаться такой вот «эгоистской» программой (в отличие от чугунной детали) должно всегда оставаться у одного человека — правовладельца. Он и будет получать доход с продажи, его права и защищают законы.
Это нужно знать, между прочим. Допустим, вы пошли в магазин, и купили там втридорога лазерный диск с копией «операционной системы» или каким-нибудь другим программным продуктом, предоставляемым без исходных текстов и без возможности их получить. Ущерб, который потерпит ваш карман от такого безущербного копирования, наводит на мысль о том, что ваша копия сопровождается правовладельческой лицензией. По сути дела, обладая копией — экземпляром — программы, вы не становитесь хозяином программы как произведения. Вам бы дальнейшее её распространение не причинило никакого ущерба, но права на это у вас нет, такое право сохраняется только за «продавцом» или другим правовладельцем программы.
Правовладельческие программы называют также ПО ЗК — Программное Обеспечение с Закрытым Кодом, потому что исходный текст этих программ использовать запрещено, а чаще всего и смотреть на него нельзя, или «проприетарными» (от proprietary, «собственнический»), что отражает правовладельческую суть дела.
Люди, названные нами «альтруистами», — программисты университетской школы и вообще люди, ищущие интереса прежде выгоды, поначалу просто не обращали внимания на воцаряющийся правовладельческий строй. Они продолжали свободно обмениваться текстами и совместно дорабатывать программы друг друга. Однако чувствовали они себя неуютно, и неспроста. В начале восьмидесятых последовала серия громких судебных процессов по алгоритму «ты написал принадлежащую мне программу и украл её у меня, передав товарищу». Беспокойство нарастало.
Между тем стало вполне понятно, что именно отличает традиционный свободный способ существования программы от «правовладельческого». Достаточно, чтобы любой, кто получил копию программы, вместе с ней получал те же права, что и сам автор, в первую очередь право её изменять и копировать. При этом каждый становится «хозяином программы как произведения». Тогда можно будет с чистой совестью продолжать работать совместно и свободно: тиражировать программу, продавать её, раздавать за так, улучшать и ухудшать, тиражировать то, что получилось, и т. д.
Принципы свободы программного обеспечения несколько позже сформулировал видный деятель Фонда Свободных Программ (FSF) Ричард Столлман:
Смысл этих принципов ясен: во-первых, пользоваться, во-вторых исправлять то, что не нравится, в-третьих, привлекать всех, кто пожелает, в-четвёртых, работать совместно. Стоит один из четырёх принципов нарушить, и работать над программой сообща будет невозможно.
Перечисленные четыре принципа свободы ничем не ограничивают потенциального хозяина копии программного продукта. Он может делать с этой копией что угодно, в том числе нарушать своими действиями хоть все четыре принципа. Скажем, исправлять ошибки и распространять результат с правовладельческой лицензией, то есть объявить себя хозяином всех последующих копий. Исправления и исходный текст исправленной программы он, конечно, никому не откроет — это «ноу-хау», рычаг для добычи прибыли из воздуха. Немало в прошлом свободных программ и их частей заключено нынче во мрак несвободных программных продуктов. Плохо здесь совсем не то, что кто-то зарабатывает на чужом, в сущности, труде; зарабатывает — это хорошо!
Плохо, что общественной пользы от такого сокрытия никакой: никто не узнает, что это были за ошибки; свой талант человек, считай, в землю зарыл — в надежде, что вырастет золотое дерево. Эффективность разработки при этом — мизерная: второму такому же умнику придётся начинать с того же самого места, с открытого исходного кода, и третьему, и десятому. И вот сидят они по своим углам, никому ничего не говорят, и исправляют одни и те же ошибки без надежды поделиться результатами успеха с коллегами.
После нескольких болезненных судебных столкновений с правовладельческими лицензиями по схеме «программировал-то ты, а хозяин — я», Ричард Столлман и его коллеги из сообщества профессиональных программистов GNU разработали собственную лицензию — соглашение между хозяином копии программы и предполагаемым получателем этой копии. Она получила название GNU Public License (Общественная Лицензия GNU). Только после принятия условий этой лицензии человек может считаться хозяином полученной им копии программного продукта и исходных текстов.
Общественная Лицензия GNU декларирует пресловутые «четыре свободы», которые гарантированы хозяину копии, содержит некоторые юридические тонкости относительно их соблюдения и — главное — накладывает на хозяина единственное строгое ограничение: если новоиспечённый хозяин захочет распространять программу или изменённый её вариант, условия её распространения должны быть не хуже GPL, то есть включать в себя «четыре свободы» и вот это самое требование их дальнейшего соблюдения. Программисту, знакомому с понятием «наследование» идея вполне прозрачна, законникам пришлось объяснять, а со стороны это выглядит совсем просто: требования свободы нельзя нарушать, и всё. Чаще всего проще не мучиться, изобретая собственные лицензии, а публиковать плоды совместных трудов по той же GPL.
GPL не имеет прямого отношения к сути свободного ПО, это инструмент, оружие, которое в мире правовладельческих лицензий помогает сообществу отстаивать право на свободу.
Важнейшее прикладное следствие свободы программного продукта — свободная совместная его разработка. Всякий, кто хочет и может поучаствовать в общем деле, может приступать к работе без каких-либо не имеющих отношения к вопросу ограничений. В каком качестве заинтересованный человек может присоединиться к сообществу?
Во-первых, ответственный и квалифицированный человек может взять на себя часть разработки программного продукта, и, что гораздо важнее и сложнее, принятие решений по всем принципиальным вопросам. Таких людей, как правило, совсем немного, а доля их участия в жизни продукта велика. Неважно, почему они согласны тянуть лямку впереди всех, важно, что они это делают, имеют достаточно рабочего времени и личных достоинств. Они составляют ядро сообщества. Как правило, это умудрённые опытом программисты или эксперты, словом, те, к чьему мнению заслуженно прислушиваются. Именно от мнения ядра зависит, как будет развиваться продукт, как и когда вносить в него предложенные поправки, когда и как делать выпуски (release) и т. п.
Ядро соответствует понятию «команда разработчиков» старой, индивидуалистической схемы. Здесь более или менее срабатывают и практические рекомендации старой школы: ядро должно быть небольшим, чтобы могло само с собой договариваться, должно иметь разделение труда, чтобы каждый занимался в первую очередь тем, к чему имеет больший талант, должно иметь «главного» для волевого разрешения неразрешимых вопросов и т. п., словом, типичный «team» из пяти-семи человек.
Сообщество разработчиков — самая главная часть любого свободного программного продукта. Дело в том, что полдюжины человек в ядре, конечно, не могут слишком быстро заниматься разработкой. Что ещё важнее — они не могут в одиночку управляться со всей эксплуатационной историей, то есть отслеживать, как, когда и с каким успехом применялась программа, какие были ошибки, были ли они исправлены и как. Именно свобода ПО предоставляет любому, кто поучаствовал в эксплуатационной истории, сделать эту историю публичной и внести её в русло общей работы.
Самый простой способ подключиться к сообществу — найти ошибку в программе, исправить её и написать разработчикам. Вполне вероятно, что вы, в силу специфики работы, наткнулись на эту ошибку впервые. Программа свободная, исходные тексты имеются, право на публичное её изменение — тоже, так что толковый программист в состоянии ошибку найти и исправить. Если он при этом будет настолько ленив и неблагодарен, что не сообщит авторам, всё сообщество укажет на него с осуждением. Если узнает, конечно.
Что всего приятнее — практически любой человек, мало-мальски сведущий в программировании, может поправить ошибку. Титаном мысли для этого можно и не быть. Если предложенная тобою заплата (patch) написана из рук вон плохо, ответственный разработчик из Core Team предпочтёт скорее переписать это место наново, чем выбросить и забыть, на то он и ответственный.
Свободные проекты очень много внимания и ресурсов уделяют поддержке сообщества разработчиков. Техническая документация по проекту (руководство по сборке и установке), как правило, не уступает пользовательской. Для разработчиков заводятся специальные списки почтовой рассылки, в которых они обмениваются информацией друг с другом и задают вопросы, и — что тоже очень важно — автоматизированные системы отслеживания ошибок и предложений (т. н. «bug tracker»-системы).
Эта политика весьма эффективна ещё и вот в каком плане. Программист, вместо того, чтобы кидаться к клавиатуре и начинать программировать порученный ему продукт с нуля, берётся за мышь и педантично обшаривает такие ресурсы, как SourceForge, FreshMeat или NonGNU, на предмет подходящего свободного проекта, который решает те же задачи. С очень высокой степенью вероятности такой проект найдётся, хотя, возможно, и не будет обладать какими-то специфическими для конкретной ситуации способностями. Всё что останется программисту — это модифицировать свободный продукт, дополнив его этими возможностями. Добросовестный и благодарный человек не преминет поделиться с сообществом, а от происков любителей правовладельческого лицензирования его защищает GPL: если программу вообще собираются распространять, исходный код необходимо открыть, а уж от этого до интеграции изменений ядром разработчиков в основной проект дорожка прямая.
Само собой, этот Добросовестный Программист автоматически становится членом сообщества разработчиков, что, помимо прочего, сулит и некоторые служебные перспективы.
Бессмысленно говорить о каком-то программном продукте, не упоминая тех, кто им будет пользоваться. Старая «хакерская» практика — разработчик и пользователь суть одно лицо, потому что программировать гораздо интереснее, чем запускать программу — преобразовалась за эти годы до неузнаваемости. Мы не знаем, почему те или иные члены сообщества разработчиков занимаются нашей программой — из-за денег, славы, спортивного интереса, производственной необходимости или на голом энтузиазме; они работают — и огромное им спасибо. Но почему мы, пользователи, хотим видеть программу мощной, толковой и надёжной — совершенно понятно: программа нам нужна.
Конечно, пользователь-программист или программист-пользователь продолжают играть немаловажную роль в развитии свободного ПО. Такой человек в сообществе решает сразу три задачи: активно тестирует продукт, находя ошибки и выдумывая, что ещё «в супе не хватает», сам формулирует программистское задание, и сам же его выполняет. Поэтому сообществу всегда выгодно привлечь активного пользователя в ряды разработчиков либо убедить талантливого программиста пользоваться свободным ПО.
Но уверенно надеяться на чудесное слияние столь разных ролей можно только в редких случаях «программирования для программирования», чаще всего пользователем может быть кто угодно, а иногда профессия типичного пользователя не позволяет ему быть программистом. Например, пользователь компилятора — скорее всего программист, музыкального проигрывателя — совсем неважно кто, а пользователь кассового аппарата скорее всего имеет самое смутное представление о том, каким образом аппарат цифры показывает.
В конце концов, трёхступенчатый процесс поиска эксплуатационных трудностей, формулировки задачи и программирования давно уже освоен «классической» схемой разработки: пользователь отыскивает повод для улучшения, пользователь и программист совместно формулируют задачу, программист её решает. И от программиста, и от пользователя в этом случае требуется желание, возможность и умение взаимодействовать. Не очень-то и редкие качества, если учитывать, что человек — животное общественное и вообще склонен общаться с себе подобными. Однако даже это может стать камнем преткновения: несвободный, «закрытый» способ разработки пошёл по экстенсивному пути развития; для решения каждой задачи нанимается специальный отдельный человек (тестер, консультант, менеджер проекта).
Преткновение как раз в том, в чём закрытый способ разработки отказывает решительно всем, даже самим пользователям: в заинтересованности. Общественная схема начинает работать только тогда, когда и пользователь, и разработчик хотят (неважно, по каким причинам) решать возникшую задачу (а не только «чтобы была решена»). Но ведь сообщество образуется как раз из заинтересованных, из тех, кому для работы не жалко трудов. Дополнительное требование — пользователь и разработчик должны быть в состоянии решить задачу, то есть иметь достаточную квалификацию каждый в своей области. Сообщество вокруг свободного ПО — не для неучей, что правда, то правда. Впрочем, мало найдётся людей, столь невосприимчивых к знаниям, чтобы остаться неучами вопреки активному интересу и всеобщему образованию.
Иллюстрация 1. Сообщество вокруг свободного программного продукта
Для того, чтобы приведённая выше схема заработала, одного желания мало. Недостаточно и умения. Делать что-то сообща можно только если есть возможность сообщать и общаться. Передавать друг другу информацию — во-первых, и ориентироваться в ней — во-вторых.
В самом деле. Группы в сообществе — ядро, разработчики и пользователи — представляются эдакими тремя комнатами, где каждый знаком с каждым, все затруднения активно обсуждаются между собой, а двери из комнаты в комнату никогда не закрываются: всякий результат обсуждения нужно довести до сведения товарищей по сообществу, да и просто так поговорить, чтобы быть в курсе, не мешает. А ведь в действительности даже ядро сообщества может состоять из людей, которые живут на различных континентах, и лично каждый не с каждым и знаком. Что и говорить о всемирном сообществе разработчиков или пользователей?
Переоценить вклад глобальных сетей в развитие свободного ПО невозможно. Именно за счёт свободного распространения информации людям не обязательно постоянно находиться в одной комнате в обществе друг друга. Именно за счёт связности сети Интернет все пользователи и разработчики имеют возможность собираться вместе, обсуждать проблемы, обмениваться новостями, узнавать друг о друге, словом, вести себя так, как если бы все находились в «одной комнате».
Ещё важнее простота, оперативность и надёжность связи между группами, без которой не может жить никакой проект свободного ПО. Если на схеме убрать стрелочки, она превратится в три беспомощных замкнутых множества, в каждом из которых будет куча нерешаемых задач. Ядро не сможет быстро и оперативно разрабатывать программу, внешние разработчики — договориться о том, какие именно задачи решать, куда идти, да и решать ли вообще, а пользователи — добиться удобной и безошибочной работы программы.
Прежде, чем говорить о технических возможностях, которые обеспечивают взаимодействие людей в сообществе, стоит сказать пару слов о том, зачем это техническое обеспечение им нужно.
Необходимость общения в сообществе очевидна (сами слова-то почти одинаковые). Столь же очевидно, что никто не сможет заставить члена сообщества общаться, кроме него самого, кроме желания побольше узнать и помочь. С другой стороны, редко у кого такое желание — часть профессии. Иными словами, за жажду знаний, как и за миссионерство, нечасто платят. Это означает, что сам способ общения и приёма-передачи знаний должен быть настолько прост и вместе с тем соблазнителен, чтобы им добровольно стало пользоваться как можно больше хороших и нужных людей.
Живых людей, которыми движет желание работать и необходимость общаться (а не наоборот). Из чего следует, что чем удобнее инструмент и структура обмена информацией, тем проще уступить желанию, смирившись с необходимостью. (В скобках заметим, что закрытый путь разработки решает эту проблему привычным экстенсивным способом: нанимаются специалисты по PR, профессиональные проповедники и автоответчики во плоти, обязанность которых — отвечать на вопросы, даже если в ответах нет никакого смысла).
Каналы связи между группами существуют и сами по себе — за счёт пользователей-разработчиков, которых в свободных проектах немало. Однако этого крайне недостаточно. Как всякий труд, совместная разработка требует дисциплины и формализации, причём чем больше в её составе людей и чем меньше между ними социальных связей, тем строже должна быть дисциплина и требовательнее формальность. В случае свободного сообщества, когда коллеги по проекту могут не быть даже знакомы, вопрос дисциплины и формы встаёт особенно остро: без этого культурные, социальные, психологические и прочие различия возьмут верх, и результатом будет неуправляемое вече. С другой стороны, нельзя перегибать палку, иначе свободно пришедший в сообщество человек плюнет на все формальности и свободно уйдёт.
Первым делом сообществу стоит договориться о том, кто какие права и возможности имеет, и каким образом их осуществляет. Где хранятся исходные тексты программы и согласно какой дисциплине их менять. Как принимать сообщения об ошибках и реагировать на них. Какая документация существует по программному продукту, где её взять и как с ней работать. Что необходимо знать, прежде чем включаться в сообщество. Где, наконец, находятся готовые версии программного продукта, и чем одна отличается от другой.
Вопросов много, и способы ответа на каждый из них мировое сообщество нащупывало десятилетиями. Дело осложнялось тем, что разработчики — движущая сила любого сообщества — редко когда оказывались толковыми веб-дизайнерами. Не в смысле умения проектировать что-либо, а в смысле умения это наглядно показывать. Впрочем, со временем необходимость выдумывать что-то совсем уж своё отпала, потому что выработались эффективные шаблоны организации труда. Тогда-то и стали появляться сетевые проекты, которые предлагают уже готовый набор таких шаблонов — порталы. Сообществу остаётся только согласиться использовать этот набор в работе и наполнить шаблоны содержательной информацией.
Так, например, устроен упомянутый выше проект Source Forge: система хранения и обновления исходных текстов, хранилище готовых программ, система отслеживания ошибок, форумы для обсуждения, списки рассылки и т. д. — всё для успешной организации сообщества. Зарегистрироваться, положить первые десятки строк программы — и пошло-поехало. Кстати, на сегодня в SF зарегистрировано больше десяти тысяч проектов и много больше миллиона пользователей.
Что меньше всего стоит передоверять универсальным службам, вроде SF, так это — эстетическую и идеологическую составляющую любого сообщества. В конце концов, технические средства — это всего только инструмент, а как им распорядиться решает, ядро при поддержке всех единомышленников. Немалую роль здесь играет всем уже сегодня привычное понятие «сайт» — сетевой WWW-ресурс, посвящённый самому программному продукту, его задачам, способам использования, дисциплине разработки и т. п. От того, как устроен сайт проекта, в немалой степени зависит и интерес новых посетителей сайта, и активность самого сообщества. Сайт — это лицо проекта.
Сайт совсем не обязан быть огромным и сложным. Скорее наоборот: чем легче будет посетителю ориентироваться, тем выше вероятность, что он найдёт себе подходящее место в сообществе. На сайте обычно лежат материалы трёх видов. Во-первых, научно-популярные и идеологические, которые описывают, зачем проект нужен самим его создателям, и чем он может помочь пользователям. Во-вторых — информационная часть с пользовательской и технической документацией, что делает включение в сообщество вопросом чисто техническим. И в-третьих — технически-структурная часть, которая описывает все элементы взаимодействия в сообществе, а также отсылает к используемым ресурсам. Нередки ситуации, когда несколько титульных страниц проекта, особенно небольшого, — дело рук разработчиков, а всю структурную и ресурсную часть (хранение исходных текстов и готовых программ, отслеживание ошибок, информационные рассылки и прочее) берёт на себя какой-нибудь портал.
Несколько раз уже упомянутая служба отслеживания ошибок — чуть ли не самый важный из механизмов, формирующих сообщество. Дело в том, что распространение свободных программ, равно как и информации о них, через сайт — дело благое, но чрезвычайно неблагодарное, если не предусмотреть обратной связи от тех, кто эту информацию усвоил, а программу использует. Стрелки на схеме обязаны быть двунаправленными, иначе ядро не получит никакой выгоды от сообщества разработчиков, и все они вместе — от сообщества пользователей.
Чтобы сообщить об ошибке разработчику, необходимо иметь: ошибку, разработчика, и — главное! — механизм, позволяющий оформить подобное сообщение. Причём в случае распределённой совместной работы этот механизм должен сопровождаться известной дисциплиной оформления, чтобы первый попавшийся разгильдяй не принялся докучать ответственному разработчику посланиями вроде «Дорогие учёные. У меня который год в подполе происходит подземный стук. Объясните, пожалуйста, как он происходит». В неменьшей степени это относится и к прямой работе сообщества над исходными текстами программы.
Стоит ещё раз подчеркнуть, что средства совместной разработки должны быть в первую очередь удобны технически, то есть самим разработчикам и активным пользователям. Именно с этим связано разнообразие и солидная история как систем отслеживания ошибок, так и систем совместного написания текста программ. В числе первых назовём GNATS, BTS, BugZilla, Mantis, Eventum и множество других, как родившихся в недрах больших сообществ для собственных нужд, так и специально предназначенных для шаблонов совместной работы любого сообщества. Системы совместного ведения архива исходных текстов традиционно называются системами «контроля версий» (version control), хотя их возможности давно уже этим не исчерпываются. Среди них — всемирно популярная CVS, её наследники SubVersion и GNU Arch, специализированные на особые задачи git или monotone, крайне простые (darcs) и весьма мощные (вплоть до поддержки автоматической сборки получившейся программы — aegis), и некоторые другие.
Всякому, кто хочет включиться в сообщество разработчиков, придётся научиться взаимодействовать и с тем, и с другим. Только так можно сохранить относительный порядок при полной свободе добровольно собравшихся вместе людей.
Для организации взаимодействия внутри группы, особенно вне рамок исходных текстов, нужны другие средства. Нужно то самое произвольное общение, которое привиделось в форме «трёх комнат с открытыми дверями». Где формальная сторона была бы сведена к минимуму, а преобладала бы, насколько это возможно, общечеловеческая.
Лет пятнадцать-двадцать назад было трудно себе представить, что в обмене символами посредством компьютера есть так уж много человеческого. Бытовало мнение, что электронная почта — удел профессионалов-компьютерщиков, уже не различающих электронную и явную реальности, а, скажем, сетевой дневник (web log, или «the blog») — это такая форма электронного эксгибиционизма полностью исключённого из «настоящего» социума киберпанка. Скорей уж инструментом, приближающим электронное к человеческому, мыслился ужасный электрод, вставляемый непосредственно в голову и навевающий электронные сны, либо передающий мысли по проводам. Что было и продолжает оставаться фантастикой. Гора не шла к Магомету.
Сейчас мы стали свидетелями того, как охотно Магомет, то есть современное человечество, двинулся к горе. Электронная почта заменила бумажную. Слово «форум» вызывает стойкие ассоциации с веб-сайтом, и только после некоторого напряжение вспоминаешь его словарное значение. В последнее время наблюдается взрыв увлечения электронными дневниками (не в последнюю очередь, кстати, из-за того, что исходный текст «движков» некоторых из них открыт, и теперь каждый может основать свой сайт с дневниками). Купить вещь в Интернет-магазине с доставкой на дом зачастую дешевле, чем влачиться за нею куда-то на склад, не говоря уже о посещении чистого и сверкающего, но людного и дорогого магазина.
Первое, что было придумано, а скорее — возникло само собой для информационного сплочения сообщества — тематические списки рассылки1. Как правило, каждое сообщество имеет несколько таких списков — для разработчиков, для пользователей, для обсуждения стратегических вопросов, технические, дизайнерские, наконец, для «роботов», собирающих статистику; крупные проекты, например, дистрибутивы, имеют их до сотни. Список рассылки — то самое место, куда надо задавать вопросы: если человек читает рассылку, ему это для чего-нибудь нужно. Он поможет вам, а когда само попадёт впросак, кто-нибудь поможет ему.
Для общения в совсем необязательном режиме — трёпа, тусовки и прочего, что в цифровом мире заменяет совместное времяпрепровождение — используются пресловутые «форумы», сетевые журналы и обмен текстами в реальном времени (chat). Это ресурсы уже не совсем сообщества, а, так сказать, пригород его, тропки, которыми можно в сообщество прийти. А можно и не прийти, если процесс обмена словами важнее совместной работы. Так что эти форумы — ещё и фильтр ответственного отношения к делу. Гулякам праздным там живётся лучше, чем в дисциплинированной среде сообщества.
Первое исключение из этого правила: ресурсы Internet Relay Chat (irc), которые достаточно стары, как следствие — слегка сложноваты для освоения гуляками и имеют свои культурные традиции защиты от дурака. IRC-каналы часто используют профессионалы для оперативного решения задач в стиле «вопрос-ответ». Второе: всё чаще дневники (Blogger, Live Journal и т. п.) стали использоваться с самыми серьёзными целями: информация для сообщества, обсуждение принципиальных вопросов и т. п. Причина этого — особый способ доступа к информации в сетевых дневниках, когда пользователь читает не то, что ему захотели прислать, а те источники информации, что он предварительно согласился читать. Получается отличный фильтр действительно заинтересованных, что, собственно, и надо сообществу.
Наконец, в последнее время набирает обороты практика совместной разработки сайтов. Эта практика и сопутствующая ей технология получила название «Wiki» (от гавайского wiki-wiki, «быстро-быстро»). Практика в том, чтобы сделать процесс наполнения сайта содержимым очень простым. Настолько простым, чтобы туда написать мог кто угодно, было бы желание. Ответственному за сайт придётся только просматривать новые поступления на предмет очевидного хулиганства (пресечь которое в Wiki-технологии достаточно просто) и, возможно, самому добавлять страницы структурирующего характера (чтобы сайт не превращался в свалку бессвязных текстов). Несмотря на молодость технологии, большинство крупных проектов уже обзавелось своими Wiki — официальными и неофициальными, которые служат отличным хранилищем данных и поисковой системой по ним. Надо ли говорить, что качество и наполнение Wiki-сайта целиком зависит от усилий сообщества?
Сообщество вокруг программного продукта добивается успехов, если созданы условия для совместной работы: свободное распространение, три части сообщества — ответственная (ядро), компетентная (разработчики) и заинтересованная (пользователи), доступное и толковое информационное пространство, в первую очередь — простые и надёжные каналы связи в группах и между ними.
Тогда каждый занимает в сообществе место по силам и желанию, и делает только то, что может и должен. Чем грамотнее спланировано информационное пространство, тем меньше накладных расходов и тем больше приходит компетентных людей, которые по тем или иным причинам готовы развивать программный продукт. Проект, фактически, пишет сам себя, остаётся только направлять его движение и следить за тем, чтобы сообществу хорошо жилось.
Конечно, в настоящей жизни бывает всякое, любая правовая, политическая или экономическая неприятность может пагубно сказаться на жизни программы, но успех крупных свободных программных проектов в наибольшей степени зависит от умения управлять сообществом.
За чертой остаются все, кто по какой-то причине не может включиться в сообщество. Это не означает, что, изолируясь от сообщества, человек не может получить определённую выгоду от использования свободного программного продукта. Большинство свободных программ вполне «дистрибутивны»: их распространяют и используют как по отдельности, так и в составе дистрибутива — тематического или системного сборника программ, с помощью которых пользователь может решать задачи определённого направления. Как правило, дистрибутив даже единственного программного продукта содержит достаточно информации, чтобы пользоваться им автономно. Но в этом случае пользователь лишается главного преимущества — поддержки сообщества, непосредственной помощи со стороны знающих людей, которую невозможно ни запрограммировать, ни задокументировать.
К тому же любая толковая просьба о помощи — сама по себе уже помощь сообществу! Если вопрос возник, а ответа на него нет ни в документации, ни в списках рассылки, скоро с такими же трудностями столкнутся и другие пользователи. Так отчего бы не прояснить вопрос до того, как станет неудобно многим? А сообщение об ошибке или короткая методичка по найденному вами решению задачи — это уже услуга сообществу, которую легко и приятно оказать в корыстных целях: ошибка будет исправлена, а ваш текст опубликован. Взаимодействие с сообществом — это естественный способ существования пользователя свободного ПО; если, например, вы страстно хотите каких-либо изменений в программе, но боитесь в этом признаться, вы их не дождётесь. А если вы их изложите сообществу, да подкрепите просьбу добрым словом, пивом, сотней рублей, сотней долларов — чем-нибудь вполне адекватным объёму работ, ответ не заставит себя ждать.
Теперь нетрудно понять, когда разработка ПО по открытой схеме себя не оправдывает. Как только какое-нибудь из перечисленных «условий успеха» нарушается, ограничивается одна из свобод, сразу возникают затруднения, подчас — совершенно непреодолимые в рамках свободной модели.
Нашлись какие-то правовладельческие документы и соблюдать «четыре свободы Столлмана» нельзя? Прощай, открытая совместная разработка! Только своими силами, да ещё и подписку о неразглашении давать придётся.
В стране запрещён или не поощряется Интернет и вообще открытая передача данных? Тогда нет смысла в совместном проекте — без обратной-то связи. Не случайно в Китае так много сильных программистов и хакеров и так мало сообществ свободного ПО (да есть ли они вообще?).
Если пользователи не заинтересованы в самой программе, работают из-под палки или просто ничего не понимают и не хотят понимать, возникает огромный зазор между ними и разработчиками. Тогда каждый, кто и пользователь и разработчик одновременно, бесценен. А таких может не оказаться. Например, до недавнего времени инструментарий менеджера — программные средства управления персоналом, сетевого менеджмента и т. п. — был представлен в свободном ПО очень скудно. По причине, как это ни смешно, застарелой нелюбви разработчиков и управленцев друг к другу. Только в последние лет пять свободное ПО начало входить и на этот рынок.
Другой подобный пример — компьютерные игры, где пропасть, разделяющая разработчика и пользователя-игрока преодолевается только на могучей волне энтузиазма; а чаще — не преодолевается и замыкается в ПО ЗК. Правда, и здесь наметились сдвиги: архитектуру компьютерной игры («движок») теперь иногда делают открытой, надеясь на помощь сообщества в главном — в наполнении.
Если потенциальных пользователей очень мало, скажем, дюжина человек на весь мир, то открытость или закрытость разработки никакой роли не играет: всё равно придётся работать с каждым индивидуально, а ждать чудесного самозарождения сообщества разработчиков вообще не приходится. С другой стороны, здесь могут сыграть как раз индивидуальные пристрастия: в научном мире, к которому вполне могут относиться эти двенадцать пользователей, принято открыто обмениваться если не всей информацией, то уж точно — инструментами (а программа для учёного — именно инструмент).
Если в проекте большая «расходная статья» на непрограммистские задачи (скажем, много работы для художника, электронщика, сценариста и т. п.), а «доходная статья» (техническое обслуживание, заказная доработка, обучение и т. п.) — маленькая или вообще не предусмотрена, делать его свободным, к сожалению, невыгодно. Ситуация, характерная опять-таки для больших компьютерных игр — и для узкопрофильных разработок, где оплачивается участие многих специалистов а возможности пользовательского сообщества невелики.
И всё-таки главное препятствие развитию свободного ПО — у нас в головах. Человечество тысячелетиями вырабатывало культуру права собственности, имея перед собой исключительно материальные объекты, копирование которых требует затрат. Объекты нематериальные, «технологии», появились в массовом порядке менее двух веков назад, а «программным продуктам», безущербность копирования которых очевидна, ещё не скоро исполнится полвека. Неудивительно, что люди, которые сами не программируют (управленцы, экономисты, юристы и прочие), всё ещё не готовы отличить собственность на чугунную болванку от собственности на программу. Культура нематериальной собственности только вырабатывается.
Время одиночек, которые самостоятельно, от начала до конца, прорабатывают весь программный продукт, прошло. Для того, чтобы написать хорошую программу, требуются усилия различных специалистов: от системного архитектора до кодировщика и от художника до эксперта в прикладной области. Собрать всех этих людей воедино можно либо на добровольной, свободной основе, либо «кнутом и пряником» — деньгами и крепостной зависимостью, правовладением.
Правовладельческая «команда» устроена так: неважно, как человек изначально относится к своим обязанностям и что думает, главное — платить ему и создавать условия для эффективной работы. Тогда он либо начнёт приносить пользу, либо лишится места. Ущерб, который он в этом случае может нанести компании, надо ограничить запретительной лицензией.
Свободное сообщество устроено строго наоборот: неважно, почему человек хочет участвовать в разработке, важно, чтобы он хотел этого, мог быть полезен и относился к работе ответственно. Ущерб, который может быть нанесён сообществу путём сокрытия информации, ограничивается открытой лицензией GPL.
Важно помнить, что свобода — это в первую очередь ответственность. И дело не только в том, что в свободном мире каждый обязан отвечать за свою работу и не может свалить ответственность на другого. В свободном мире безответственные действия не приносят выгоды. Например, крахом обернётся попытка продавать воздух в стиле ПО ЗК: любой свободный продукт стоит столько, сколько заслуживает, как это и полагается настоящими требованиями рынка; а если искусственно завышать цену одного экземпляра, всегда найдутся желающие приобрести и продавать его по цене естественной.
Что же приносит доход в мире свободного ПО? А что везде: труд, оперативность, информация, качество.
Время одиночек, наверное, прошло. Прошло и время вождей, ведущих за собою толпы, неведомо куда под неведомо какими лозунгами. Человек — свободная личность — хочет выбирать свой путь самостоятельно, и следовать своему собственному пути, опираясь на опыт и помощь других свободных людей. Не такая уж и малая, в сущности, часть общества — пользователи и разработчики свободных программ — подают пример такого свободного взаимодействия. Возможно, этот пример нельзя скопировать на произвольную повседневность. Даже наверняка нельзя. Повседневность каждого из нас — если, конечно, это наш свободный выбор — невозможно скопировать. Это как программа, написанная лично тобой.
Тем не менее этот пример актуален. Свободные программы для свободных людей.
1Наверное, уже и не надо объяснять, что такое «список рассылки»? Это такая форма электронной почты, когда один человек её отправляет, а несколько — подписчики — получают.