Закрытая открытость Open Source
Какие мотивы могут побудить создателя программы к распространению исходных текстов? Какие мотивы могут этому воспрепятствовать? Решение о "закрытости" или "открытости" как правило применяется на бессознательном уровне. Логика здесь отдыхает.
Часто приходится слышать, что исходные тексты содержат корпоративные секреты, которые ни в коем случае нельзя разглашать, иначе компания просто рухнет. Что за ерунда?! Как уже говорилось выше, в современном мире секреты уступили место патентам. Если некоторая фирма создала действительно революционный продукт (например, безупречный распознаватель речи) и выбросила его на рынок, машинный код тут же дизассемблируют конкуренты и восстановят алгоритм. Никто даже пункнуть не успеет! Помешать им может только патент, а патент требует раскрытия секретности. В России и Европе, правда, алгоритмы еще не патентуются… Ну, как бы не патентуются, но это ограничение легко обойти, например, описав абстрактное устройство с процессором, выполняющее такие-то и такие-то действия. Устройство уже патентовать можно. И ведь патентуют! Причем в промышленных масштабах!
Еще существует мнение, что наличие исходных текстов позволит создать аналогичный (или даже сильно улучшенный) продукт на основе уже существующего. Отчасти это действительно верно, однако, только отчасти. Взгляните на Open Source. Исходные тексты доступны, но… продукты не плодятся как кролики. То есть, плодятся конечно, но побочные ветви быстро сдыхают. А если права модифицировать исходники нет, то никому и в голову не придет что-то там дорабатывать, ведь не сегодня-завтра придут судебные исполнители и зарубят проект к чертовой матери. Лучше быстро выпустить "пиратку" по демпинговой цене и уползти с наваром. Для это даже исходные тексты иметь не нужно!
Единственная объективная причина— это кривизна исходников, демонстирующая тупость их создателей, умышленно оставленные закладки и ворованные компоненты, плюс еще стадный признак. Если никто не показывает исходных текстов, то и мы не будем этого делать.
Особенно меня умиляют начинающие программисты, объявляющие, что их продукт "запатентован", а его исходные тексты покрыты мраком тайны. На самом деле, исходные тексты недоступны потому, что программисты боятся показать их народу, и все сразу увидят какие они корявые и неструктурированные. Дураки. Если коллеги укажут тебе на ошибку, то ты сможешь выявить ее и исправить, ликвидировав еще один пробел в своих знаниях. Чтобы научиться писать хорошие и конкурентоспособные программы, необходимо не раз ткнуться носом в собственное дерьмо. Воняет? Конечно воняет. Но более чистых путей увы не бывает.
Если исходные тексты не открывают, то воруют. За примерами ходить далеко не надо. Только ленивый не найдет в сети сырцы MS-DOS 6.x и W2K. Ну и что? Какой от этого ущерб? Аналогичных продуктов на основе уже существующих так и не появилось, корявость рук программистов конечно стала видна (даже несколько дыр новых нашли), но о том, что в Microsoft умных людей практически не осталась и так все знают (достаточно взглянуть на Longhorn, beta-версия которого занимает ~450 Мб памяти), так что ровным счетом никакого ущерба. Сплошной пиар. А вот программистом это помогло лучше понять некоторые туманные места в документации. Теоретически, Microsoft должна быть заинтересована в том, чтобы привлечь как можно больше разработчиков на свою платформу. Практически, она вкладывает миллиарды убитых енотов в рекламу и устраивает разные акции, зазывающие разработчиков, так что распространение исходных текстов идет на пользу как самой Microsoft, так и программистам вместе с пользователями.
А вот другой случай. Несколько лет назад были украдены исходные тексты CISCO IOS. Какой разразился скандал. Руководитель компании драл задницу в поисках похитителя, вылив на него столько грязи, сколько не увидишь даже в российском придорожном сортире. А ведь IOS представляет собой смесь Линуха и BSD. "Свое", "родное" там только драйвера и кое-что еще. Для этого, кстати говоря, даже не нужно заглядывать в исходные тексты.
Как и любой цельнодернутый продукт, CISCO наследует все дыры своего "донора". Так что здесь все просто: вор у вора лошадку увел. Какой смысл закрывать исходные тексты, если они и так доступны? Их даже воровать не нужно! Стек протоколов во всяком случае уж точно писан не CISCO! Но это не мешает компании выпускать самые популярные роутеры, ведь роутер это не исходный текст. Это железка. Наличие/отсутствие исходных текстах операционной системы на объем продаж никак не влияет. И это не единичный пример!
Теперь разоблачим миф, связанный с безопасностью. Дескать, имея на руках исходные тексты, можно обнаружит любые баги и закладки или, говоря научным языком, провести аудит. А вот и ни хрена подобного! Типичная современная программа представляет собой миллионы строк сложным образом взаимодействующих с "окружающим миром" и с друг с другом. Несомненно, исходные тексты упрощают анализ, но не до такой степени, чтобы радикально что бы то ни было изменить. Чтобы разобраться, что в каком файле находится и кто за что отвечает, необходимо угробить кучу времени…
В команде Open Source или в коммерческой фирме существует жесткое разделение. Каждый ведет свою часть проекта и в чужие суется либо от не фиг делать (и за это ему дают по рукам), либо на стыке взаимодействия своей части проекта с остальными. За это ему тоже дают по рукам или ругаются матом. Об этом хорошо сказал Евгений Зуев в статье "Редкая Профессия": "Возникало тяжелое ощущение того, что это большая темная комната, а у тебя только маломощный фонарик, который в состоянии осветить небольшой аппарат - твои модули. От аппарата тянутся в темноту провода и вереницы зубчатых колес. Что делается в дальних углах, неизвестно. Иногда вокруг раздаются какие-то звуки, из темноты выступают части каких-то движущихся механизмов, назначение которых остается неведомым, даже если осветить их. Время от времени из темноты раздается голос, настоятельно требующий: "нажми на кнопку с надписью ABC", "переведи рычаг XYZ в правое положение".
Что делается в комнате и как все работает вместе, понять совершенно невозможно".
В команде разработчиков обязательно имеется несколько человек, своеобразных "носителей знания", которые держат в голове максимум подробностей структуры кода и координируют работу остальных "суб-носителей", окучивающих каждую команду. Все это сделано для того, чтобы обезопасить проект от воли отдельных разработчиков. Если член команды покидает/погибает ряды компании, его место занимает другой, которому "вливают" все старые знания в черепную коробку. В больших фирмах существует развитая инфрастуктура докуменообророта, в Open Source – списки рассылки. Благодаря этого, вновь пришедшие разработчики могут разобраться с вверенной им волостью и навести мосты с ближайшими соседями. Процесс вживления в команду протекает долго и практически всегда очень болезненно.
Сами по себе исходные тексты любой серьезной системы (например, компилятора gcc или ядра linux) полностью лишены смысла. Это только груда файлов, которую, если повезет, с N'ой попытки удается откомпилировать. Без соответствующей поддержки, разобраться в них практически невозможно. Возьмем тот же gcc. Допустим, мне необходимо добавить в него поддержку новой фичи или исправить ошибку кодогенератора. Поклонники Open Source говорят, что в случае с Microsoft Visual C++ мое дело труба. Все, что я могу — бомбардировать Microsoft факсами и умолять о пощаде. А вот в gcc – просто взял и добавил. Ага, щас! Мне тут программировать нужно, а не ковыряться в исходном коде gcc!!! Да за то время, пока я с ним буду разбираться, можно сто раз найти обходное решение проблемы или дождаться очередного фикса от Microsoft! Так что, чем крупнее проект, тем меньшую пользу можно извлечь из исходных текстов. К тому же, куда мне девать свои изменения при переходе на новую версию? С большой степенью вероятности, перенести их будет очень непросто и потребуется угробить еще одну кучу времени. И так каждый раз.
Интерфейс плагинов в этом смысле намного более привлекателен.
Сторонним разработчикам предоставляется более или менее документированный и унифицированный API, дающий им возможность создавать собственные расширения. Заглядывать в исходные тексты при этом не требуется. К тому же снимается проблема переноса расширений во все остальные версии. В Open Source мире ведь как — или сообщество принимает твое расширение и включает его в поставку (но в любой момент может исключить), либо посылает на xyz, и ты вынужден вести свою версию, что приводит к путанице и всеобщей дисгармонии. А так — конечный пользователь сам решает какой ему плагин ставить, а какой нет.
Еще один миф. О тысячах энтузиастов по всему миру… Это чистейшей воды брехня. Я не знаю ни одного продукта, созданного толпой. Всегда во главе стоит один-два толковых парня, а остальные ходят с понтом, что "мы пахали". Вот, например, DOS Navigator от RIT Labs. Отличный продукт, с нехилым количеством пользователей и фанатов. После того как фирма свернула свои работы и выложила его исходники в сеть, проект сдулся. Да, сейчас существует NDN и еще несколько "отпрысков", но все они находятся в сильно заболоченном состоянии. Конечно, можно привести и контр пример. Скажем Лис (он же FireFox), который развивается настолько бурно, что даже теснит IE, а потеснить IE это не туалет обосрать скажу я вам. Но… как же он тормозит! Вся программа в одном исполняемом файле. Так умные люди не пишут! Так что рая на земле не бывает…
Что там у нас еще? Ах да, бэк-доры. Дескать, в Open Source их не внедришь. Как бы не так! Хорошо продуманную закладку обнаружить практически невозможно. Достаточно "случайно" допустить ошибку переполнения буфера, проявляющуюся только при стечении множества маловероятных обстоятельствах на стыке разных модулей. Ну, вот например, такой сценарий: один модуль делает удар по памяти, искажая данные другого так, что буфер переполняется на строках в 69 символов, но не переполняется при всех остальных (срабатывают дополнительные проверки).Чтобы обнаружить эту ошибку необходимо удержать в голове работу двух разных модулей, связав их воедино, что не сильно легче чем дизассемблировать машинный код. А переполнение буфера это уже shell. Со всеми вытекающими…
