Эрик Реймонд - Волшебный котел

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

1. Собор и базар: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/, русский перевод: http://www.osp.ru/os/1999/09-10/071.htm.

2. Заселяя ноосферу: http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/, русский перевод: http://www.bugtraq.ru/law/articles/noo/index.html.

3. De Marco and Lister, Peopleware: Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6

4. Шон Харгривс (Shawn Hargreaves) написал хороший анализ применимости методов открытого программирования к теории игр; Playing the Open Source Game ( http://www.talula.demon.co.uk/games.html).

Несколько обсуждений стимулирования с Дэвидом Д. Фридманом (David D. Friedman) помогли мне усовершеноствовать модель «общин наоборот» применительно к сотрудничеству в области открытых разработок. Я также весьма обязан Маршалу Ван Эльстину (Marshall van Alstyne), который указал на концептуальную важность конкурирующих информационных ресурсов. Рей Онтко (Ray Ontko) из Indiana Group снабжал меня полезной критикой. Очень много людей при встречах, с которыми я беседовал до июня 1999 года, также помогли мне; если Вы — один из них, Вы знаете, за что я Вам благодарен.

Еще одно свидетельство в пользу открытой модели — то, что эта работа была существенно улучшена благодаря обратной связи с помощью электронных писем, которые я получил в течение нескольких дней после ее публикации. Ллойд Вуд (Lloyd Wood) указал на важность открытого программного обеспечения, являющегося «защищенным от будущего» (future-proof), а Дуг Данте (Doug Dante) напомнил мне о деловой модели «открой потом». Вопрос от Адама Мурхауса (Adam Moorhouse) спровоцировал обсуждение исключений, при которых лучше оставить исходный текст закрытым. Лайонел Оливира Гресс t (Lionel Oliviera Gresse) дал мне лучшее название для одной из деловых моделей. Стивен Тернбалл (Stephen Turnbull) обозвал меня глупым из-за небрежной трактовки «эффектов халявщика».

Изготовители периферийных аппаратных средств ЭВМ (карты Ethernet, контроллеры дисков, видеокарт и т. п.) исторически отказались открывать исходные тексты. Сейчас это положение изменяется в случае с фирмами наподобие Adaptec и Cyclades, начинающими систематически раскрывать спецификации и исходный код драйверов своих плат. Однако, все еще существует сопротивление этому процессу. В этом приложении мы попытаемся опровергнуть несколько неправильных с точки зрения экономики представлений, которые подкрепляют эту тенденцию.

Если вы — производитель аппаратных средств ЭВМ, вы можете бояться, что открытие кода может сделать известной важную информацию о том, как работает ваше оборудование и конкуренты смогут ее скопировать, таким образом получая несправедливое преимущество. Раньше, в эпоху трех — и пятилетних циклов разработки, это было весомым аргументом. Сегодня инженеры ваших конкурентов истратили бы на копирование и понимание копии существенную часть цикла разработки изделия, при этом не используя это время для нововведений или создания особенных функций для собственного устройства. Плагиат — западня, в которую Вы должны желать заманить Ваших конкурентов.

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

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

Даже для сложных устройств наподобие видеокарт, Вы мало что можете сделать, чтобы воспрепятствовать умному программисту, вооруженному дизассемблером. Затраты на такую разработку низки, а юридические барьеры — зыбкие; Linux — международная разработка и есть всегда юрисдикция, в которой дизассемблирование будет законным.

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

Что из этого следует? Сохранение вашего драйвера в тайне сразу же после его выпуска выглядит привлекательным, но, в конечном счете, является плохой стратегией (конечно, если Вы конкурируете с другими продавцами, которые уже открыли код). Но, если Вы должны закрыть код, пропишите его в ПЗУ платы. После этого опубликуйте программный интерфейс к нему. Будьте открытым в максимально возможной степени, для того, чтобы построить свой сектор рынка и продемонстрировать потенциальным клиентам, Вашу веру в способность придумывать новое, и вводить больше новшеств, чем конкуренты.

Если вы остаетесь закрыты, это обычно будет худшим исходом — ваши тайны будут выставлены напоказ, вы не будете получать бесплатную помощь в развитии продукта, и не потратите впустую время ваших глупых конкурентов на клонирование. Наиболее важно то, что вы пропускаете дорогу, ведущую к быстрому распространению вашего оборудования. Большой и влиятельный рынок (люди, которые управляют серверами и всем Интернетом, а также более чем 17 % деловых центров данных), справедливо запишет вашу компанию в число невежественных и занимающих оборонную позицию, потому что вы не понимаете таких вещей. В этом случае они будут покупать оборудование у кого-то, кто это понял.

Это — $ Revision: 1.14 $.

Версии, не описанные здесь, имеют незначительные правки или опечатки в номере версии.

20 мая 1999, версия 1.1 — проект.

18 июня 1999, версия 1.2 — не публикуемая версия обзора.

24 июня 1999, версия 1.5 — первая публикация.

24 июня 1999, версия 1.6 — незначительная модернизация; исправление в определении «хакера».