Эрик Реймонд - Искусство программирования для Unix

Таким образом, с конца 90-х годов прошлого века более нет никакого смысла рекомендовать стратегию и тактику повторного использования кода без обсуждения открытого исходного кода, соответствующих практических приемов, вариантов лицензирования и норм сообщества открытого исходного кода. Даже если данные проблемы в других сообществах могли бы быть обособленными, в мире Unix они связаны неразрывно.

В оставшейся части данной главы рассматриваются различные проблемы, связанные с повторным использованием открытого исходного кода: оценка, документация и лицензирование. В главе 19 модель разработки открытого исходного кода обсуждается шире, а также рассматриваются соглашения, которых следует придерживаться при опубликовании кода для массового использования.

В Internet доступны для использования буквально терабайты исходных кодов для системных и прикладных Unix-программ, служебных библиотек, GUI-инструментариев и аппаратных драйверов. Большинство из них с помощью стандартных инструментов можно скомпилировать и запустить за считанные минуты: ./configure; make; make install;для выполнения инсталляционной части обычно требуются привилегии администратора.

Люди за пределами мира Unix (особенно нетехнические пользователи) склонны рассматривать программное обеспечение с открытым исходным кодом (или "свободное") как непременно худшее по сравнению с коммерческим, т.е. как низкокачественное, ненадежное и вызывающее больше проблем, чем способно решить. Они упускают из виду важный момент: в общем, программное обеспечение с открытым исходным кодом пишется людьми, которым оно не безразлично, которые сами его используют, и, опубликовывая его, рискуют своей личной репутацией. Они также склонны тратить меньше времени на совещания, давние изменения конструкции и бюрократические издержки. Следовательно, они сильнее мотивированы и лучше нацелены на выполнение качественной работы, чем оплачиваемые невольники, для которых главное — соблюсти невозможные сроки завершения проекта в частных предприятиях.

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

Кроме эффекта коллегиальной оценки существует другая причина ожидать более высокого качества: в мире открытого исходного кода разработчики никогда не закрывают глаза на ошибки под давлением срока завершения проекта. Главное отличие между открытым и коммерческим кодами заключается в том, что версия 1.0 фактически означает готовое к использованию программное обеспечение. В действительности версия 0.90 или выше является довольно убедительным свидетельством того, что код готов к серийному использованию, но разработчики еще не вполне готовы утверждать это.

Читателю, который не является Unix-программистом, может быть трудно поверить в это. Еще один аргумент: в современных Unix-системах C-компилятор почти неизменно является программой с открытым исходным кодом. Коллекция GNU-компиляторов (GNU Compiler Collection — GCC) Фонда свободного программного обеспечения настолько мощная, хорошо документированная и надежная, что рынка для коммерческих Unix-компиляторов фактически не осталось, а для Unix-поставщиков стало нормой создавать версии GCC для своих платформ, не разрабатывая собственных компиляторов.

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