Секреты Open Source

Крис Касперски ака мыщъх

Спецвыпуск: Хакер, номер #060, стр. 060-076-6

В команде Open Source или в коммерческой фирме существует жесткое разделение. Каждый ведет свою часть проекта и в чужие суется либо от нечего делать (и за это ему дают по рукам), либо на стыке взаимодействия своей части проекта с остальными. За это ему тоже дают по рукам или ругаются матом. Об этом хорошо сказал Евгений Зуев в статье "Редкая Профессия": "Возникало тяжелое ощущение того, что это большая темная комната, а у тебя только маломощный фонарик, который в состоянии осветить небольшой аппарат - твои модули. От аппарата тянутся в темноту провода и вереницы зубчатых колес. Что делается в дальних углах, неизвестно. Иногда вокруг раздаются какие-то звуки, из темноты выступают части каких-то движущихся механизмов, назначение которых остается неведомым, даже если осветить их. Время от времени из темноты раздается голос, настоятельно требующий нажать на кнопку с надписью ABC, перевести рычаг XYZ в правое положение... Что делается в комнате и как все работает вместе, понять совершенно невозможно".

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

Сами по себе исходные тексты любой серьезной системы (например компилятора gcc или ядра Linux) полностью лишены смысла. Это только груда файлов, которую удастся откомпилировать, если повезет, с N-ой попытки. Без соответствующей поддержки разобраться в них практически невозможно. Возьмем тот же gcc. Допустим, тебе необходимо добавить в него поддержку новой фичи или исправить ошибку кодогенератора. Поклонники Open Source говорят, что в случае с Microsoft Visual C++ твое дело - труба. Все, что ты можешь, - бомбардировать Microsoft факсами и умолять о пощаде. А вот в gcc просто взял и добавил. Как же! Тебе тут программировать нужно, а не ковыряться в исходном коде gcc. За то время, пока ты будешь разбираться с ним, можно сто раз найти обходное решение проблемы или дождаться очередного фикса от Microsoft! Так что чем крупнее проект, тем меньшую пользу можно извлечь из исходных текстов. К тому же, куда тебе девать свои изменения при переходе на новую версию? С большой степенью вероятности перенести их будет очень непросто и потребуется угробить еще одну кучу времени. И так каждый раз. Интерфейс плагинов в этом смысле более привлекателен. Сторонним разработчикам предоставляется более или менее документированный и унифицированный API, дающий им возможность создавать собственные расширения. Заглядывать в исходные тексты при этом не требуется. К тому же снимается проблема переноса расширений во все остальные версии.