Содержание
Большинство проектов с открытыми исходным кодом проваливаются.
Мы не часто обращаем внимание на провалы. Только успешные проекты привлекают внимание, но общее количество свободных проектов настолько велико[2], что даже несмотря на низкий процент выживаемости, нам есть на что посмотреть. Мы не обращаем внимание на провалы еще и потому, что провал это не событие. Нельзя вычленить момент, в который проект внезапно перестает быть жизнеспособным. Люди начинают потихоньку расходится, перестают над ним работать. Может наступить момент, когда участник вносит последнее изменение в проект, но он еще не знает, что внесенное им изменение станет последним. Нет даже четкого определения потухшего проекта. Можно ли считать угасшим проект, над которым никто не работал в течение шести месяцев? Или это проект, количество пользователей которого перестало расти,не успев перевалить за количество разработчиков? Что если разработчики одного проекта забросили его после того как обнаружили, что все это время они дублировали работу другого проекта? Что если они решили присоединиться к тому, другому проекту, чтобы расширить его, вложив в него плоды своего прежнего труда? Исчез ли прежний проект насовсем или просто поменял место жительства?
Из-за перечисленных сложностей, невозможно определить точный процент провалов. Но десятилетние наблюдения за миром свободного ПО, нехитрый расчет по данным SourceForge.net, несколько несложных запросов к Гуглу - все ведет к одному и тому же выводу: соотношение провалов чрезвычайно велико и составляет около 90–95 процентов. Это число будет еще выше если мы учтем выжившие, но не работающие проекты: те, что вроде бы и производят рабочий код, но предоставляют не самую благоприятную среду для разработчиков, недостаточно быстро или стабильно эволюционируют.
Эта книга посвящена тому как избежать провала. Она описывает не только хорошие практики, но и плохие, таким образом вы сможете распознать и разрешить проблемы на раннем этапе их появления. Я надеюсь, что после прочтения этой книги, вы обзаведетесь большим арсеналом методов, которые позволят вам не только не наступать на наиболее частые грабли разработки свободного ПО, но и поддерживать успешный открытый проект, управлять его ростом. Успех проекта - это не игра с нулевой суммой, и эта книга вовсе не о том как выиграть или обогнать конкурентов. Более того, важной частью ведения открытого проекта является крепкое сотрудничество с другими, похожими проектами. В конечном счете, каждый успешный проект делает вклад в благополучие мирового фонда свободного ПО.
Легко поддаться искушению и сказать, что причины неудач свободного ПО теже, что и у коммерческих проектов. Конечно, при разработке свободного ПО возникают проблемы с завышенными требованиями, расплывчатыми спецификациями, неэффективным управлением ресурсами, слишком короткой фазой проектирования и другими сложностями давно известными в индустрии разработки ПО. На эти темы написаны горы литературы, и в своей книге я постараюсь избежать повторения уже описанных проблем. Вместо этого, я хочу описать проблемы характерные только для разработки свободного ПО. Когда проект по разработке свободного ПО садится на мель, причиной тому чаще всего будет неумение разработчиков (или менеджеров) учитывать специфические проблемы разработки открытого ПО, хотя к проблемам присущим разработке коммерческого ПО они могут быть основательно подготовлены.
Одной из наиболее распространенных ошибок является переоценка достоинств идеи открытого ПО. Использование открытой лицензии не гарантирует, что орды активных разработчиков неожиданно изволят потратить время на ваш проект. Открытие исходников проблемного проекта не решит его проблем автоматически. Как раз наоборот, раскрытие проекта может принести целый ворох дополнительных сложностей, и увеличить стоимость проекта в краткосрочной перспективе по сравнению с разработкой внутри компании. Раскрыть проект означает реорганизовать код так, чтобы он был понятен новым разработчикам, незнакомым с вашим проектом, создать официальный веб-сайт проекта и настроить списки рассылки,а зачастую еще и впервые взяться за написание документации. Это - уйма работы. И если всё-таки появятся заинтересованные разработчики, к этому добавится еще и бремя отвечать на кучу их вопросов, прежде чем от их присутствия будет хоть какая-то польза. Как сказал Джейми Завински о ранних трудных временах проекта Mozilla:
Концепция свободного ПО и вправду работает, но не является лекарством от всех болезней. Если в моей истории и содержится предостережение, то лишь о том, что нельзя просто так взять загибающийся проект, посыпать его волшебной пылью "открытого ПО" и по волшебству разрешить все проблемы. Разрабатывать ПО трудно. Решать проблемы не так уж просто.
Еще одна похожая ошибка заключается в том, что в проекте пренебрегают созданием установочных пакетов и презентацией ПО, наивно полагая, что эти вещи можно оставить на потом, когда проект будет идти полным ходом. Презентация и создание установочных пакетов включают в себя широкий круг задач, служащих одной цели - упростить вступление в проект потенциальным разработчикам. Сделать проект более привлекательным можно при помощи написания руководств пользователей и документации разработчиков, создав сайт проекта, содержащий информацию для новичков, автоматизировав процессы компиляции и установки и т.д. Многие программисты, к сожалению, считают эту задачу второстепенной и ставят её после написания кода. На это есть несколько причин. Во-первых, эта работа кажется мартышкиным трудом, потому что её результат заметен лишь тем, кто меньше всего знаком с проектом и наоборот. В конце концов, людям написавшим код не нужны никакие установщики. Они и так знают как устанавливать, администрировать и использовать собственное ПО. Во-вторых, умения необходимые для того чтобы грамотно презентовать ПО и сделать хороший установочный пакет сильно отличаются от тех, что нужны для написания кода. Люди склонны уделять больше времени тому, в чем они хороши, даже если они знают, что пожертвовав немного времени на то, что им менее интересно, они помогут проекту гораздо больше. В главе Глава 2, Начало работы, более подробно рассказывается о презентации ПО и создании установочных пакетов, а также объясняется почему они должны стоять в приоритетах с самого начала проекта.
Следующее заблуждение состоит в том что свободным проектом не нужно управлять, либо нужно управлять совсем немного, или наоборот, что ему подходят принципы управления, используемые для разработки внутри фирмы. Признаки управления проектом не всегда видны, но в успешных проектах, управление в той или иной форме обычно осуществляется за сценой. Достаточно провести небольшой мысленный эксперимент, чтобы понять почему. Типичный свободный проект состоит из группы случайных программистов—печально известных вольнодумцев —, скорее всего незнакомых лично друг с другом, каждый из которых, преследует собственные личные цели в работе над проектом. Представьте себе что произойдет с такой группой людей безо всякого руководства. Если не случится чуда, они потерпят крах или разбредутся кто куда довольно быстро. Дела не будут вестись сами собой, насколько бы нам этого ни хотелось. Управление проектом, даже если его много, часто осуществляется неформально, мягко и не на повышенных тонах. Единственное, что может удержать группу разработчиков вместе - это совместная вера в то, что они могут достигнуть большего вместе, чем каждый по отдельности. Таким образом, основной целью руководства становится поддержание этой веры в людях, путем установления стандартов общения, слежения за тем, что полезные разработчики не оказываются изолированными от сообщества из-за личных особенностей характера, и путем превращения проекта в такое место, куда хочется возвращаться снова и снова. Конкретные способы достижения этого будут рассмотрены далее в книге.
Наконец, существует общая категория в которую попадают проблемы, которые можно классифицировать как "ошибки культурного значения".Лет десять назад или даже пять, было бы преждевременно говорить о всемирной культуре свободного программного обеспечения, но не теперь. Постепенно возникла особенная культура свободного ПО, и, даже не будучи единой и монолитной (по меньшей мере она настолько же склонна к внутренним разногласиям и распрям как и региональные культуры), она имеет общий устойчивый фундамент. Самые успешные свободные проекты обладают всеми или хотя бы некоторыми из этих фундаментальных характеристик. Они вознаграждают за определенные типы поведения и наказывают за другие; создают атмосферу, которая поощряет незапланированное участие, иногда в ущерб центральной координации; у них есть понятия грубости и вежливости, которые могут значительно отличаться от принятых в других проектах. Самое важное, что люди, долго участвующие в проекте, по большей части перенимают эти стандарты, таким образом между участниками проекта образуется в целом единый образ поведения. Неуспешные проекты обычно, хотя и не намеренно, отклоняются в значительной степени от этих фундаментальных стандартов, и зачастую не имеют единогласного соглашения о том, что же представляет собой допустимое поведение. Это приводит к тому, что в случае возникновения проблемы, ситуация может быстро ухудшиться, из-за что участники не обладают общими культурными ценностями, на которые бы можно было положиться в разрешении сложностей.
Эта книга - практическое руководство, а не курс антропологии или истории. Тем не менее, понимание истоков современной культуры свободного ПО необходимо, чтобы подкрепить любой практический совет. Человек, который понимает эту культуру, может путешествовать по миру свободного ПО практически без границ, открывая для себя местные различия в обычаях и диалекте, и несмотря на них быть быстро и без проблем втягиваться в любой проект. Человек, который эту культуру не усвоил, напротив, найдет для себя процесс организации или участия в проекте сложным и полным сюрпризов. Так как количество людей разрабатывающих свободное ПО все еще растет скачками и рывками, многие из них относятся к этой последней категории— по большому счету это поведение присуще недавним мигрантам, и оно сохранится у них на некоторое время. Если вы считаете себя одним из них, следующий раздел послужит вам уроком истории и подготовит к дальнейшим дискуссиям, которые вы встретите позже, как в этой книге, так и в интернете. (С другой стороны, если вы уже работали над свободным проектом достаточно долго, вам уже наверняка известна большая часть истории, и вы можете пропустить следующий раздел.)
Обмен программным обеспечением существовал столько же долго сколько и сами программы. На заре компьютеров, производители считали, что конкурентные преимущества могут быть извлечены лишь из совершенствования аппаратных средств и следовательно не относились к ПО как к бизнес активу. Множество пользователей тех первых машин были учеными или лаборантами. Они сами могли изменить или расширить, поставляемое вместе с компьютерами, ПО. Иногда пользователи отправляли свои программные патчи не только обратно изготовителю, но и другим владельцам совместимых компьютеров. Компании изготовители очень часто дозволяли это и даже поощряли: по их мнению, усовершенствования сделанные над их ПО, без разницы чьи и откуда, только делали машину более привлекательной для потенциальных покупателей.
Хотя этот ранний период и напоминает современную культуру свободного программного обеспечения, он отличается по двум ключевым моментам. Во-первых, на тот момент не существовало почти никакой стандартизации среди аппаратных средств—это было время расцвета инноваций в компьютерном дизайне, но разнообразие компьютерных архитектур означало, что все было несовместимо со всем остальным. Таким образом, программы, написанные для одной машины обычно было не возможно использовать на другой. Программисты старались специализироваться в одной архитектуре или семействе архитектур (также как сегодня программисты скорее специализируются в определенном языке программирования или их семействе, в полной уверенности, что их знания можно будет перенести на любую вычислительную платформу, с которой им придется работать). Из-за того, что личные знания человека обычно относились к одному виду компьютеров, накопление знаний приводило к тому, что эти компьютеры становились более привлекательными для него и его коллег. Следовательно, в интересах производителя было распространять машинно-зависимый код и знания как можно шире.
Во-вторых, тогда не было Интернета. И хотя в те времена было меньше юридических ограничений на распространение чем сегодня, было гораздо больше технических: средства для получения данных из того или другого источника были относительно неудобными и громоздкими. Существовали некоторые маленькие, локальные сети, которые были хороши для обмена информацией между сотрудниками внутри одной исследовательской лаборатории или предприятия. Но оставались преграды, которые нужно было преодолеть, если человек хотел обменяться информацией с кем-нибудь другим, вне зависимости от того, где они находились. Эти преграды преодолевались во многих случаях. Иногда, различные группы вступали в контакт друг с другом независимо, посылая диски или магнитные ленты обычной почтой, а иногда сами производители служили центральным информационным центром для обновлений. Помогало и то, что многие из разработчиков компьютеров раннего периода работали в университетах, где публикация чьих-либо знаний была ожидаемым явлением. Но реалии физической передачи данных означали, что всегда существовало сопротивление при обмене, сопротивление, пропорциональное расстоянию (реальному или организационному), которое должно было преодолеть программное обеспечение. Широко распространенный, свободный от "трения" обмен, каким мы знаем его сейчас, был невозможен.
С развитием отрасли, одновременно произошло несколько взаимосвязанных изменений. Ужасающее разнообразие аппаратных платформ, постепенно уступило место нескольким бесспорным победителям - победителям, обладавшим лучшей технологией, лучшим маркетингом или комбинацией обоих. В тоже время, и не совсем случайно, разработка так называемых языков программирования "высокого уровня", привела к тому, что, кто угодно мог один раз написать программу, на одном языке, и потом автоматически перевести ("скомпилировать") ее в код, исполняемый на любом типе компьютеров. Последствия коснулись и производителей аппаратных платформ: теперь клиент мог приложить значительные усилия по проектированию и разработке программного обеспечения, без необходимости привязывать себя к определенной компьютерной архитектуре. Одновременно с этим стиралась разница в производительности различных компьютеров, происходило вытеснение менее эффективных архитектур. Производители, для которых оборудование было единственным видом актива, почувствовали будущее падение прибыли. Чистая вычислительная мощность становилась взаимозаменяемым товаром, а ПО превращалось в новую границу раздела. Продажа программного обеспечения, или, хотя бы, отношение к нему как к неотъемлемой части продажи оборудования, выглядело хорошей стратегией на будущее.
На практике это привело к тому, что производители стали намного строже охранять авторские права на свой код. Если пользователи просто продолжали бы свободно обмениваться между собой и изменять код, они могли бы независимо реализовать какие-нибудь усовершенствования, которые продавались поставщиком как "добавочная ценность". Еще хуже, свободный код мог бы попасть в руки конкурентов. Ирония в том, что все это происходило примерно то же время, когда Интернет вставал на ноги. Как раз тогда, когда действительно беспрепятственный обмен программным обеспечением стал наконец технически возможным, изменения в компьютерном бизнесе сделали его экономически нежелательным, как минимум с точки зрения каждой отдельной компании. Поставщики предприняли меры, либо запрещающие пользователю доступ к коду, выполняющемуся на его машине, либо настаивающие на соглашении о неразглашении, которые сделали обмен полезной информацией невозможным.
В то время как мир неограниченного обмена кодом медленно угасал, в голове по крайней мере одного программиста выкристаллизовалась идея контрреакции. Ричард Столлмэн работал в лаборатории Искусственного Интеллекта в Массачусетском Технологическом Институте в 1970-х и в начале 80-х, в месте и во времени, которое как оказалось было землей обетованной и золотым веком свободного обмена кодом. В лаборатории ИИ существовала строгая "этика хакеров",[3] и людям не только позволяли, но и ждали от них, что любое изменение, внесенное в систему, станет достоянием общественности. Как Столлмэн писал позже:
Мы не называли наши программы "свободным ПО", поскольку этот термин еще не существовал, хотя они были таковыми. Если сотрудники других университетов или компаний желали перенести программу на свои машины и применять ее для своих целей, мы с радостью позволяли сделать это. Если вы видели, что кто-то использует необычную и интересную программу, всегда было возможно попросить ее исходные тексты, так что вы могли ознакомиться с программой, изменить ее либо использовать ее фрагменты в новой программе.
Это райское сообщество, окружавшее Столлмэна, распалось очень быстро после 1980 года, когда изменения, происходившие во всей остальной индустрии, в конце концов докатились и до лаборатории ИИ. Начинающая компания, наняла многих программистов, работавших в лаборатории, для разработки операционной системы, похожей на ту, над которой они работали в лаборатории, только под закрытой лицензией. В тоже время, лаборатория ИИ получила новое оборудование, в состав которого входила проприетарная операционнная система.
В том, что происходило, Столлмэн увидел общую тенденцию:
Современные компьютеры тех лет, такие, как VAX или 68020, имели собственные операционные системы, но ни одна из них не была свободной: вы обязаны были подписать обязательство нераспространения даже чтобы получить исполнимый код.
Это значило, что первым шагом в использовании компьютера стало обещание не помогать окружающим. Сотрудничество тем самым было запрещено. Собственники программ установили правило: "Если вы поделились программой с вашим соседом, вы пират. Если вам требуются модификации, умоляйте нас реализовать их."
По своему личному капризу, он решил сопротивляться общему течению. Вместо того чтобы продолжать работу в теперь уже опустошенной лаборатории ИИ или устроится программистом в одну из новых компаний, где результаты его труда были бы заперты в ящике, он отказался от лаборатории и начал проект GNU, а также основал Фонд свободного программного обеспечения (FSF).Целью GNU [4] была разработка абсолютно бесплатной и открытой компьютерной операционной системы и набора прикладных программ, пользователям которых никогда бы не запрещалось исследовать код или распространять внесенные ими изменения. Он, в сущности, пытался воссоздать то, что было разрушено в лаборатории ИИ, но в масштабе всего мира и без тех слабых мест, которые привели сообщество лаборатории ИИ к распаду.
Одновременно с работой над новой операционной системой, Столлмэн разработал авторскую лицензию, чьи условия гарантировали, что его код всегда будет бесплатным. Открытая лицензия (GPL) Фонда свободного программного обеспечения от GNU, была очень умным образцом дзюдо в юридическом пространстве: в ней говорилось, что код может быть скопирован и изменен безо всяких ограничений, и что и копии и работы, основанные на данном коде (например, измененные версии) должны распространяться по той же лицензии как и оригинал, без каких либо дополнительных ограничений. Таким образом, она использует закон об авторском праве, для достижения эффекта, противоположного традиционному авторскому праву: вместо того, чтобы ограничить распространение программного обеспечения, она не позволяетникому, даже автору, ставить какие-либо ограничения. Для Столлмэна, это было даже лучше, чем просто выкладывать код в общий доступ. Если бы он находился в общем доступе, любая отдельная копия могла бы быть встроена в проприетарную программу (такое, как известно, случалось с кодом, распространяемым по разрешающим правовым лицензиям). Пока такое использование никаким образом не уменьшало существующую доступность оригинального кода, но оно могло значить, что усилия Столлмэна могли пойти на пользу врагу — проприетарному программному обеспечению. GPL можно рассматривать как вид протекционизма для бесплатного программного обеспечения, так как она не позволяет не-бесплатному программному обеспечению полностью воспользоваться преимуществами кода, доступного по GPL. GPL и ее отношения с другими лицензиями на бесплатное программное обеспечение подробно обсуждается в Глава 9, Licenses, Copyrights, and Patents.
С помощью многих программистов, некоторые из которых разделяли идеи Столлмэна, а некоторые просто хотели увидеть некоторое количество доступного бесплатного кода, проект GNU начал выпускать бесплатные замены большинства самых важных компонентов операционной системы. В связи с уже широко распространенной стандартизацией в компьютерном аппаратном и программном обеспечении, стало возможным использовать замены от GNU для не-бесплатных систем, и многие так и поступали. Текстовый редактор от GNU (Emacs) и компилятор Си (GCC) были особенно успешны, и получили большую и преданную армию поклонников не на идеологической основе, а просто из-за их технических характеристик. Примерно к 1990 году, GNU создало большую часть бесплатной операционной системы, за исключением ядра — части, с которой начинается загрузка компьютера, и которая отвечает за управление памятью, диском и другими системными ресурсами.
К несчастью, проект GNU выбрал архитектуру ядра, которую оказалось реализовать труднее, чем предполагалось. Получившаяся задержка не позволила Фонду свободного программного обеспечения выпустить первую версию полностью бесплатной операционной системы. Вместо них, заключительная часть была вставлена на свое место Линусом Торвальдсом, финским студентом факультета компьютерных наук, который, с помощью добровольцев со всего мира, закончил ядро, использовав более консервативный дизайн. Он назвал его Linux, и когда оно было соединено с существующими GNU программами, результатом была полностью бесплатная операционная система. В первый раз вы могли запустить компьютер и работать без использования какого-то ни было проприетарного программного обеспечения.[5]
Большое количество программного обеспечения для этой новой операционной системы не было создано проектом GNU. В действительности, GNU была даже не единственной группой, работавшей над созданием бесплатной операционной системы (например, код, который в конечном итоге стал NetBSD и FreeBSD в то время уже находился в стадии разработки). Значимость Фонда свободного программного обеспечения была не только в коде, который они писали, но в их политической риторике. Так как они вели разговор о свободном программном обеспечении как о причине, а не следствии, программистам было сложно не иметь своего политического отношения к нему. Даже те, кто не соглашался с FSF, все равно имели с ним дело, просто занимая другую позицию. Эффективность FSF как пропагандистов, состояла в том, что они связывали код со своим посланием, посредством GPL и других документов. По мере того, как их код распространялся все шире, распространялось и их послание.
В зарождающемся мире свободного программного обеспечения, однако, происходило еще и множество других событий, и некоторые из них были явно идеологическими, как и GNU проект Столлмэна. Одним из таких событий стал Программный пакет университета Беркли (Berkeley Software Distribution) (BSD ), последовательная переработка операционной системы Unix, которая до начала 1970-х была в некоторой степени проприетарным исследовательским проектом в AT&T, выполняемым программистами Калифорнийского Университета в Беркли. Группа BSD не делала никаких открытых политических заявлений о том, что программистам нужно объединятся и обмениваться друг с другом, но они воплощали эту идею со вкусом и энтузиазмом, координируя сильно распределенную разработку, где Unix-утилиты командной строки и библиотеки кода, а иногда и само ядро операционной системы, были переписаны с нуля добровольцами. Проект BSD стал первым примером не-идеологической разработки свободного программного обеспечения, а так же послужил тренировочной площадкой для многих разработчиков, которые хотели продолжать работать, чтобы оставаться действующими лицами мира в мире свободного программного обеспечения.
Другим горнилом совместной разработки была система X Window System, бесплатная, обладающая сетевой прозрачностью, вычислительная среда, разработанная в Массачусетсском технологическом институте (Massachusetts Institute of Technology, MIT) в середине 1980-х в сотрудничестве с продавцами оборудования, чьи интересы сходились на возможности предоставить заказчикам многооконный интерфейс. Лицензия Х не противопоставляла себя себя миру проприетарного ПО и умышленно позволяла добавлять проприетарные расширения поверх бесплатного ядра—каждый член консорциума получал шанс расширить стандартную поставку X, и таким образом, получить конкурентное преимущество над другими членами. X Windows[6]сама по себе была свободным программным обеспечением, но по большей части служила способом установить единые правила игры для конкурирующих бизнес-интересов, а не желала покончить с преобладанием проприетарного программного обеспечения. Еще одним примером, появившимся на несколько лет раньше GNU, был TeX, свободная издательская система Дональда Кнута. Он выпустил ее под лицензией, которая позволяла любому изменять и распространять код, но не называть ее "TeX" до тех пор, пока она не пройдет набор очень строгих тестов на совместимость (это пример из класса свободных "защищающих-товарный-знак" лицензий, подробнее обсуждаемых в Глава 9, Licenses, Copyrights, and Patents). Кнут не занимал ту или иную позщицию в вопросе свободного-против-проприетарного программного обеспечения, ему просто была нужна улучшенная компьютерная типографская система, чтобы достичь своей настоящей цели—книги о компьютерном программировании—и он не видел причин не выпустить систему в мир по завершении.
Даже не перечисляя каждый проект и каждую лицензию по отдельности, определенно можно сказать, что в начале 1980-х, существовало много свободного программного обеспечения, доступного под широким набором лицензий. Разнообразие лицензий отражало соответствующее разнообразие мотивов. Даже некоторые из программистов, выбравших GNU GPL были намного меньше движимы идеологией, чем то подразумевал проект GNU. Хотя им и доставляло удовольствие работать над свободным программным обеспечением, многие разработчики не рассматривали проприетарное программное обеспечение как социальное зло. Были люди, которые почувствовали душевный порыв к освобождению мира от "программного обеспечения за забором" (термин Столлмэна для не-свободного программного обеспечения), но мотивом остальных в большей степени было техническое любопытство, удовольствие от работы с соратниками, объединенными общими взглядами, или даже простое человеческое желание славы. В общем и целом, взаимодействие этих не сопоставимых мотивов не пошло по пути разрушения. Частично, из-за того, что программное обеспечение, в отличие от других форм творчества, таких как проза или изобразительные искусства, должно пройти полу-объективный тест, чтобы можно было признать его успешным: оно должно работать, и быть, в разумной степени, лишено ошибок. Это в какой то мере автоматически дает всем участникам проекта общую точку отсчета, основание и инфраструктуру для совместной работы, позволяя не слишком заботиться о квалификации, кроме технической.
У разработчиков была так же и другая причина держаться вместе: получилось так, что мир свободного программного обеспечения производил очень высококачественный код. В некоторых случаях, он был очевидно технически лучше, чем ближайшая не-свободная альтернатива;в других, он был, как минимум сопоставим, и, конечно, он всегда стоил дешевле. Лишь немногие программисты занимались свободным ПО из исключительно философских побуждений, подавляющее большинство людей были счастливы заниматься им, потому что оно лучше справлялось со своей работой. А среди тех, кто использовал его, всегда находился процент людей, готовых жертвовать своим временем и навыками, чтобы помочь поддержать и улучшить программное обеспечение.
Эта тенденция производить хороший код, была конечно не всеобщей, но проявлялась со все возрастающей частотой в свободных программных проектах по всему миру. Направления бизнеса, которые сильно зависели от программного обеспечения постепенно стали обращать на это внимание. Многие из них обнаружили, что они уже используют свободное программное обеспечение в повседневных операциях и просто не знают об этом (высший менеджмент не всегда интересуется всем, что делает отдел ИТ). Корпорации стали играть более активную и заметную роль в проектах свободно программного обеспечения, вкладывая время и оборудование, а иногда даже напрямую финансируя разработку свободных программ. Такие инвестиции могут, в лучших случаях, оправдать себя во много раз. Спонсор оплачивает небольшое число высококвалифицированных программистов, которые посвящают проекту полный рабочий день, но получает результат еще и от работы любого участника, будь то неоплачиваемый волонтер или программисты, оплачиваемые другими корпорациями.
По мере того, как корпоративный мир уделял все больше и больше внимания свободному программному обеспечению, программисты столкнулись с новыми проблемами понятий. Первая заключалась в самом слове "свободный".Услышав в первый раз термин "свободное программное обеспечение" многие люди ошибочно думают, что оно обозначает только "программное обеспечение с нулевой стоимостью". Это правда, что все свободное программное обеспечение является продуктом с нулевой стоимостью,[7]но не все программное обеспечение с нулевой стоимостью является свободным. Так, во время войны браузеров в 1990-х, и Netscape и Microsoft предоставляли свои конкурирующие браузеры бесплатно, в борьбе за завоевание доли рынка. Ни один из браузеров не был свободным в понятии "свободного программного обеспечения". Вы не могли получить исходный код, и даже если смогли бы, вы не имели прав изменять его или распространять его дальше.[8] Единственной вещью, которую вы могли сделать, была загрузка исполняемого файла и его запуск. Браузеры были не более свободны, чем коробочные версии ПО, купленные в магазине; у них просто цена была ниже.
Эта путаница вокруг слова "свободное" возникла исключительно из-за неудачной двусмысленности в английском языке. Большинство других языков отличают низкую цену от свободы (например,разница между gratis и libre сразу понятна говорящим на Романских языках). Но место английского языка как де факто связующего языка Интернета, означает, что проблема в английском, в некоторой степени, стала проблемой для всех. Неправильное понимание слова "свободный" было так широко распространено, что программисты, разрабатывающие свободное программное обеспечение выработали стандартную формулу ответа: "Оно свободноекак свобода—как свобода слова, не как бесплатное пиво." И все же, необходимость объяснять снова и снова была утомительна. Многие программисты чувствовали, с некоторой оговоркой, что двойственность слова "свободный" препятствует общественному пониманию такого программного обеспечения.
Но проблема зашла еще дальше. Слово "свободный" неотъемлемо связано с понятием морали: если свобода была самоцелью, то становилось не важно, будет ли свободное ПО лучше или выгоднее для бизнеса в определенных условиях. Все это становилось лишь довеском к побуждению, которое по сути своей не было ни техническим, ни меркантильным, а духовным. Более того, позиция "свободное как свобода" наиболее ярко высветила несоответствия в поведении корпораций, которые хотели поддерживать определённые свободные программы ради одних направлений своего бизнеса, но продолжали торговать проприетарным программным обеспечением в других.
Сообщество, которое уже было на пороге кризиса самоопределения, столкнулось с этими дилеммами. Программисты, которые действительно писали свободное программное обеспечение, никогда не приходили к единому мнению относительно общей цели (если она была вообще) движения по созданию свободного программного обеспечения. Сказать, что мнения были диаметрально противоположны, - значит ввести вас в заблуждение, сведя их к небольшому набору вариантов. На самом деле существовало огромное число мнений, разнившихся не только по степени убежденности, но и по точке зрения на проблему. Откинув тонкие различия, все таки можно выделить две большие группы. Одна из них согласилась со Столлмэном в том, что свобода распространения и изменения является ключевым фактором, и,следовательно, если мы перестанем говорить о свободе, то будем игнорировать главный вопрос. Другая группа считала, что ПО должно говорить само за себя, и что объявлять проприетарное ПО плохим по причине его проприетарности неверно. Часть, не все, разработчиков свободного ПО считают, что автор (или работодатель в случае оплачиваемой работы) должен иметь право выбора условий распространения своего ПО, и этот выбор не должен быть связан с моральными суждениями.
В течение долгого времени эти различия не нуждались во внимательном изучении или четких формулировках, но востребованность свободного ПО в мире бизнеса росла и решение этого вопроса стало нельзя откладывать. В 1998, коалиция программистов, которая впоследствии стала Комитетом по Программному Обеспечению с Открытым Исходным Кодом (Open Source Initiative (OSI)) создала на замену термину "свободный" термин с открытым исходным кодом.[9] OSI чувствовало не только то, что термин "свободное программное обеспечение" мог сбить с толку , но и что суета вокруг термина "свободный" была лишь признаком более глубокой проблемы: движение нуждалось в маркетинговой программе, которую можно предложить корпоративному миру, программе, которая положила бы конец разговорам о "морали" и "социальных благах" в залах заседаний корпораций. По их собственным словам:
OSI—является маркетинговой программой для свободного программного обеспечения. Это подача "свободного программного обеспечения" на твердой прагматичной основе, а не напыщенных речей. Суть ПО дающего всем выигрыш не изменилась, символика и отношение, ведшие к упадку - да. ...
Что надо было изменить многим технарям, так это не концепцию открытого исходного кода, а его имя. Почему бы не называть его, по традиции, свободным программным обеспечением?
Самая очевидная причина в том, что термин "свободное программное обеспечение" можно очень легко понять неправильно, таким образом, что это ведет к разногласиям. ...
Но настоящей причиной для смены ярлыка является маркетинг. Мы пытаемся донести нашу концепцию корпоративному миру. У нас есть выигрышный продукт, но наше позиционирование в прошлом, было отвратительным. Термин "свободное программное обеспечение" неправильно понимался бизнесменами, которые ошибочно принимали желание обмениваться за анти-коммерцию, или, еще хуже, за воровство.
Президенты и технические директора основных корпораций никогда не купят "свободное программное обеспечение". Но если мы возьмем абсолютно ту же традицию, тех же людей и те же свободные лицензии и поменяем название на "с открытым исходным кодом"? Такое они купят.
Многим хакерам трудно в это поверить, но это потому, что они технари, которые думают конкретными, реальными терминами, и не понимают, как важен образ того что вы продаете.
В маркетинге внешний вид—это реальность. Именно внешний вид мы хотели спустить с баррикад и работать, считаясь с корпоративным миром настолько, насколько позволяют реалии нашего поведения, убеждений и программного обеспечения.
(с http://www.opensource.org/. Этот текст там был.OSI очевидно убрала страницы с сайта с того времени, но их все еще можно найти на http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php и http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing.)
Вершины целых айсбергов противоречий видны в этом тексте. Он ссылается на "наши убеждения", но очень умно избегает точного изложения того, каковы эти убеждения. Для одних это может быть убеждение в том, что код разработанный согласно положениям об открытости будет лучшим кодом; для других это может быть убеждение в том, что вся информация должна быть общедоступна. Встречающееся использование слова "воровство" для ссылки (предположительно) на незаконное копирование—использование, на которое указывают многие, так как по своей сути это не является воровством, если первоначальный владелец и после этого владеет предметом. Неоднозначно и замечание о том, что движение за свободное программное обеспечение может быть ошибочно обвинено в анти-коммерции, но очень осторожно в стороне оставлен вопрос, имеет ли это обвинение под собой какую-либо фактическую основу.
Эти факты однако не дают нам повода сказать, что сайт OSI непоследователен или вводит в заблуждение. Это не так. Скорее, это хороший пример того, что, по словам OSI, отсутствует в движении свободного программного обеспечения: хороший маркетинг, где "хороший" означает "жизнеспособный в мире бизнеса." Комитет по Программному Обеспечению с Открытым Исходным Кодом дал большому количеству людей именно то, что они искали—словарь для разговора о свободном программном обеспечении как о методике разработки и стратегии бизнеса, вместо идеологического крестового похода.
Появление Комитета по Программному Обеспечению с Открытым Исходным Кодом изменило ландшафт свободного программного обеспечения. Оно формализовало двойственность, которая долгое время была безымянной, и делая это, заставило движение признать, что у него существует как внутренняя, так и внешняя политика. Результатом сегодня является то, что обеим сторонам нужно найти общий язык, так как большинство проектов включают разработчиков из обоих лагерей, так же как и участников, которые не попадают ни в одну определенную категорию. Это не значит, что люди никогда не говорят о моральной мотивации— иногда, например, обнаруживаются отклонения от традиционной "хакерской этики". Но разработчик свободного программного обеспечения/программного обеспечения с открытым исходным кодом редко в открытую спрашивает об основной мотивации других участников проекта. Вклад главнее вкладчика. Если кто-то пишет хороший код, вы не спрашиваете его, делает ли он это по нравственным соображениям, или потому что ему платит работодатель, или потому что он улучшает свое резюме, или по любой другой причине. Вы оцениваете вклад на основе технических знаний и отвечаете на основе технических знаний. Даже явно политические организации, такие как проект Debian, чьей целью является предоставление 100% свободной (именно так, "свободной как свобода") вычислительной среды, явно не беспокоятся об интеграции с не-свободным кодом и о сотрудничестве с программистами, которые не разделяют точно таких же целей.
[2] На SourceForge.net, одном из известных хостинг-провайдеров для таких проектов,к апрелю 2004 года их было зарегистрировано 79,225. Конечно, эта цифра далека от общего числа свободных проектов в интернете, она отражает лишь количество тех, что избрали своим хостингом SourceForge
[3] Столлмэн использовал слово "хакер", подразумевая под ним "любого, кто любит программировать и получает удовольствие от того, что хорошо в этом разбирается", а не в относительно новом смысле "любой, кто вторгается в компьютеры"
[4] Это расшифровывается как "GNU не Unix", а "GNU" в этом определении означает...эту же фразу
[5] Технически, Linux не была первой. Бесплатная операционная система для IBM-совместимых компьютеров, называемая 386BSD, вышла незадолго до Linux. Однако, 386BSD было гораздо сложнее заставить работать. Linux наделала много шума не только потому что была бесплатной, но и потому, что она с очень большой вероятностью загружала ваш компьютер после того как вы ее установили.
[6] Они предпочитали чтобы ее называли "Оконная система X (X Window System)", но на практике, люди обычно называли ее "Икс Окна (X Windows,в России неформально "иксы́")", потому что произносить три слова очень громоздко .
[7] Кто-либо может брать деньги за раздачу копий свободного программного обеспечения, но, так как он не может запретить получателям в дальнейшем предлагать их бесплатно, цена фактически немедленно упадет до нуля.
[8] Исходный код Netscape Navigator был в конце концов был выпущен под лицензией с открытым исходным кодом в 1998 и стал основой для браузера от Mozilla. Смотрите http://www.mozilla.org/.
[9] страница OSI в интернете http://www.opensource.org/.