Владимир Пржиялковский,
независимый консультант, координатор ЕАГПО
Директор ИС, #03/2000

Уже не одно поколение программистов учат тому, что такое "промышленное производство программного обеспечения" и как выполняются проекты создания программных продуктов. Но именно сегодня эти вечные по компьютерным меркам представления начинают колебаться. Заявлено о новом (или даже "революционном") способе разработки ПО. Такое заявление не может не попасть в фокус внимания руководителей ИТ-коллективов. Хороший повод и одновременно хорошую основу для разговора о смене традиций в программировании дает появившаяся в конце прошлого года книга Эрика Рэймонда "Собор и базар" (The Cathedral and the Bazaar. Eric S. Raymond. O'Reilly & Associates. October 1999. 281 pages).

В этой статье даются очень краткий обзор книги Рэймонда и начальные рекомендации руководителям - как перейти к использованию новых способов выполнения проектов ПО.

Рэймонд и его книга

Эрик Рэймонд - знаковая фигура в программировании. Это программист более чем с 20-летним стажем, поклонник научной фантастики, музыкант, обладатель черного пояса в таэквон-до. Здесь, однако, нас интересует другое. Последние несколько лет Рэймонд известен как главный идеолог движения "открытых текстов" (open source), того самого "нового" и "революционного". И в такой роли он выступает "представителем" Internet, ОС Linux, самого популярного в мире Web-сервера Apache. Это - системы-лидеры, но кроме них есть еще с десяток других программ, систем и проектов, названия которых на слуху, а сверх этого - еще сотни, пусть не имеющих такого глобального значения, но создаваемых на тех же принципах.

Объединяет это пестрое множество разработок то, что все они без исключения осуществлены на некоммерческой основе "открытым способом". Это и дало Рэймонду основание прибегнуть для характеристики продуктивности нового способа к известному нам по старым сказкам образу "волшебного горшочка".

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

Главным героем книги, несомненно, является "хакер". Смысл, который Рэймонд вкладывает в это слово, существенно отличается от используемого в СМИ и принятого многими читателями. Хакер (hacker) в его понимании - это программист высокой квалификации, профессиональная деятельность которого совпадает с его увлечением: создавать новые "полезные" программы. Тех же, кого в обиходе именуют хакерами, Рэймонд называет кракерами (cracker) - программистами, занимающимися "взломом" чужих программ. Между первыми и вторыми большая разница. Хакер (по Рэймонду) создает новые программы для других и охотно делится своими "производственными секретами"; кракер же предпочитает работать в одиночку и секреты своего ремесла держать при себе. Очевидно, что интерес ИТ-руководителя к ним совершенно различен.

Не надо думать, что хакеры обитают только в фирмах, ориентированных на создание программных продуктов. По утверждению Рэймонда, 95% всей программистской рабочей силы получает зарплату не за составление программ на продажу, а за сопровождение уже существующих или за создание программ для внутреннего пользования (предлагается посмотреть объявления о найме на работу). В этом случае отделы ИС для хакеров - родная среда.

В этой среде они существовали всегда, то есть со времени появления компьютеров, и Internet с Unix не самые старые их творения. Что же нового у современных хакеров по сравнению с их предшественниками? Радикально изменился способ ведения работ, характерными чертами которого стали:

а) массовость участников конкретных проектов;

б) выход рабочих групп за пределы традиционных оргструктур путем создания виртуальных коллективов посредством Internet.

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

Старый и новый способ организации программирования

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

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

В середине 60-х годов фирма IBM доказала, что "промышленным" способом можно производить и относительно небольшие системы, и большие программные комплексы. Еще через десять лет Брукс в своей нашумевшей книге "Мифический человеко-месяц" (вышедшей сейчас обновленным изданием, между прочим, и на русском языке) описал достоинства и изъяны такого способа. Вот пример изъяна по Бруксу: при увеличении числа программистов объем проделанной работы растет линейно, в то время как сложность проекта и стоимость организации взаимодействия растут квадратично. В результате подключение дополнительных программистских ресурсов к запаздывающему проекту отодвинет срок его выполнения еще дальше. Другой пример - это "вечная" проблема предсказания потребительной стоимости создаваемой системы: сколько раз случалось, что дорогостоящие разработки в конечном счете не находили спроса.

В "хакерском" способе производства, новом уже с позиции наших дней, все наоборот. Программы составляются программистами для себя, а не по планам руководства (их потребительная стоимость по этой причине гарантирована!). Коллектив разработчиков извне неуправляем - подсоединиться к нему может любой имеющий выход в Internet - и неконтролируем. Исходный код программ открыт безвозмездно всем желающим.

Рэймонд был одним из первых, кто в середине 90-х привлек внимание к такому факту: опыт проекта Linux показал, что открытым способом можно создавать не только относительно небольшие вспомогательные программки, но и ПО класса современных операционных систем. А вот один из показателей "революционности" нового способа: закон Брукса в нем не работает. Добавление новых участников в проект не только сокращает время выдачи результатов, но и повышает качество продукта.

Модель открытой разработки

В общих чертах модель открытой разработки выглядит так. Одним из основных понятий является проект. Проект - это совокупность работ, осуществляемых для достижения некоторых объявленных целей. Нужно сразу оговориться, что к целям проекта отношение может быть достаточно вольное и со временем они могут видоизменяться - существенно или не очень.

Имеется держатель, или хозяин, или владелец (owner) проекта, то есть один или несколько программистов, осуществляющих сразу несколько важнейших функций: общую координацию работ по проекту, сбор и обработку поступающих заявок и мнений, сбор и обработку поступающего кода, формирование и опубликование версий продукта.

Наконец, есть участники, или конкретные исполнители, осуществляющие программирование, отладку, тестирование и принимающие участие в обсуждениях и подготовке рекомендаций. Присоединиться к участникам может любой пользователь Internet, обладающий необходимым уровнем подготовки (без нее участие будет фикцией). Участники формируют общественное мнение, определяющее направление развития проекта.

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

1. получив это звание по наследству от предыдущего держателя;
2. объявив себя таковым вместе с объявлением нового проекта;
3. объявив себя таковым вместе с объявлением нового проекта, "отпочкованного" от уже имеющегося;
4. объявив себя таковым для "заброшенного" проекта, не проявляющего активности в течение длительного времени.

Пример: Линус Торвальдс, бессменный руководитель проекта по созданию открытого ядра ОС Linux, стал им в соответствии с п. 2, то есть явочным порядком. Сам Рэймонд - руководитель проекта по разработке программы для передачи сообщений электронной почты fetchmail, ставшей повсеместной в Internet, оказался таковым по наследству, в соответствии с п. 1.

"Отпочкование" проекта (п. 3) выполняет очень важную регулирующую роль, при отсутствии которой описанная схема была бы неработоспособна. Возможность "отпочкования" декларируется, но на практике не приветствуется и скорее служит организующим воздействием на держателя, аналогичным праву на забастовку в обычном производстве.

"Отчего все не так?"

Для руководителей служб ИС описанная выше модель - крепкий орешек, разгрызть который не очень-то помогает даже такой ее знаток, как Рэймонд. Что имеется в виду?

Вот типичные задачи, к выполнению которых привыкли руководители традиционных проектов:

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

Столкнувшись с моделью открытой разработки, руководитель проекта увидит (с удивлением для себя), как привычные функции сразу теряют свой смысл или изменяются до неузнаваемости. Ресурсы распределять не надо, так как добровольные участники сами подключаются к работе с тем, что имеют, - со своими компьютерами и прочими устройствами. Организовывать людей привычным образом не требуется: дешевле найти в Internet несколько специалистов высокой квалификации, понимающих, как и что следует делать, чем набрать традиционную группу программистов, рассадить их по комнатам и каждому объяснять его задачу. Мотивациями участника проекта (по крайней мере, преобладающими) являются его собственный интерес и желание самореализации. И так далее.

В игру вступают новые категории: добровольность и творчество, а это, согласитесь, не такое уж привычное для традиционного менеджмента поле деятельности. В модели открытой разработки держатель ("руководитель проекта") уже не может назначать, требовать исполнения и вообще диктовать свои требования. Иначе он рискует остаться без "своей армии" либо получить "отпочкование" несогласной части. Как утверждает Рэймонд, такие ситуации имели место в жизни.

Самой известной "неудачей" (почему в кавычках - см. ниже) использования модели открытой разработки является пример mozilla.org. В начале 1998 года фирма Netscape опубликовала исходные тексты браузера Communicator, дав начало проекту открытой разработки с организованным ею держателем (группа лиц). (Фирма продолжает разрабатывать коммерческий браузер, но "отпочковала" от него открытый проект.) Читатель может зайти на mozilla.org и убедиться, что проект жив и развивается, однако ожидавшегося "взрыва" активности, сравнимого с Linux, увы, с ним пока не получилось. Случай с Netscape - тема для осмысления, но не сыграло ли здесь роль отсутствие согласованности между держателем и участниками проекта? Например, из-за того что держателем проекта была сделана попытка навязать свой интерес и свои правила работы?

Что должен решить для себя руководитель отдела ИТ

Новый способ разработки ПО стал настолько заметным явлением, что ИТ-руководителю все труднее откладывать ясную формулировку своего отношения к нему. Считать ли его набором совпадений, тенденцией или делом будущего? Стоит или не стоит его использовать в своей практике, и если да, то как, в какой степени?

Понятно, что в ваших планах - вполне конкретные задачи и вы не собираетесь оповещать о них весь мир через Internet и не имеете возможности нанять сотню дополнительных программистов со стороны для ускорения работ. Но подумайте и о другом. Конечно, в области "промышленных" ПО-проектов традиционализм, как и в крестьянском деле, разумен, гарантируя проверенный опытом результат. Но жизнь - штука не всегда предсказуемая, и вот она дарит вам (и не только вам!) готовый и эффективный способ ведения программных разработок. Что мешает проверить его "примеркой на себя"? Осторожность понятна, но ведь полностью переходить на новый метод не требуется. Есть немало фирм, совмещающих ту и другую практику. Взять хотя бы десятки компаний, занимающихся распространением той же Linux.

Мне кажется, что самая большая сложность, поджидающая руководителя, - это необходимость перестройки привычных образов его собственного мышления и действий. "Новое программирование" не имеет такого количества детальных моделей и такой проработки метрик, какое имеет "старое" (это не случайно: помимо фактора новизны здесь еще и противоположная направленность конструирования, не "сверху вниз", когда принципиальной является последовательность "модель - результат", а "снизу вверх", где роль традиционного моделирования то ли исчезает, то ли видоизменяется). Это может настораживать. Однако не следует забывать, что общая неэффективность традиционных подходов тоже всем известна. "Процент проектов, оканчивающихся неудачей", "процент проектов, перебравших все планировавшиеся ресурсы" и т. д. - высокие значения этих показателей давно стали общим местом. И это несмотря на то, что чаще всего на бумаге в проекте ПО все смотрится гладко! Так может быть, новая модель программирования - это действительно шанс на перспективу?

Рекомендации руководителю

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

Найдите место открытому ПО в своем отделе

Не исключено, что такое ПО у вас уже есть (вы можете об этом и не знать). Если в вашем подразделении используется Unix, то вполне вероятно, что на ваших компьютерах обнаружится и транслятор gcc, и упаковщик GNU tar, и языки сценариев Tcl, Perl или Python, а то и весьма развитая система резервного копирования/восстановления многомашинных сред AMANDA. Если ваша операционная среда - Windows, не исключено, что ваши программисты уже используют те же Perl и Python или (о чем могут благополучно не подозревать ни вы, ни пользователи) файл-сервер и сервер печати Samba.

Вот важный тезис: не надо бояться использования открытого ПО. При имеющихся у каждого конкретного программного продукта недостатках (а недостатки есть и у "закрытых", то есть коммерческих программных продуктов), это ПО проверено массовым употреблением. Достаточно надежные оценки числа используемых копий для отдельных "открытых" программных продуктов достигают нескольких миллионов.

Узаконьте использование открытого ПО в своей работе (естественно, контролируя сам процесс, номенклатуру и масштаб) и научитесь работать с ним в том, что касается сопровождения, обновления версий, нахождения выхода из проблемных ситуаций и т. д. Ваши программисты подскажут вам конкретные шаги в этом направлении. Для вас как начальника эти процессы могут выглядеть совершенно непривычно, так что к ним придется приспособиться.

Сделав это, вы приобретете значительно больше уверенности, когда вам придется принимать более серьезные для себя решения, например об использовании Linux в качестве ОС и Apache в качестве Web-сервера для критичных узлов своей вычислительной инфраструктуры.

Дайте сотрудникам хороший доступ в Internet

Мне приходилось встречать рабочие коллективы, в которых запрещено пользоваться Internet, по крайней мере в рабочее время. Логика рассуждений руководства таких коллективов понятна, но не менее ясно, что при переходе на использование открытого ПО ее придется поменять. От запрета на использование Internet понадобится перейти к его контролю.

Без Internet (не intranet или extranet, а именно без Internet) работать с открытым ПО нельзя. Там лежат в исходном или откомпилированном виде все программы открытого ПО и регулярно появляющиеся обновления. Там находится документация по открытым продуктам - а она в некоторых случаях тоже обновляется активно. Там находится масса полезных ссылок, неутомимо плодящихся трудами ваших "невидимых сотрудников" - программистов, круглосуточно работающих в самых разных уголках земного шара. Наконец, там находится множество "групп поддержки", где к вашим услугам - консультанты со всех концов света или даже сами авторы ПО.

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

Научитесь работать с группами новостей

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

Однако группы новостей - это та технология, которая в состоянии обеспечить большее, а именно достаточно развитую поддержку групповой работы в проекте. Самыми оптимальными по соотношению "стоимость/возможности" средствами для работы с группами новостей являются Outlook Express и Collabra (Messenger) соответственно фирм Microsoft и Netscape. Их способность поддерживать групповую работу подтверждена практикой, например, такого большого издания, как журнал BYTE.

Заведите в своем отделе хакера

Для начала хотя бы одного, ведь хакер - это особый стиль работы и особая культура. К тому же для "традиционного" начальника хакер - непривычный сотрудник.

Это относится, например, к уже упоминавшейся хакерской мотивации. Обычный программист делает то, за что ему платят, и получает за то, что сделал (иногда даже сдельно). Хакеру же приходится платить за то, что он сделает и без денежного вознаграждения! Как отмечает Рэймонд, хакерская мотивация работы базируется на реализации своего профессионализма и на предоставлении результатов своей работы максимально широкому кругу заинтересованных лиц. Такая мотивация ставит перед начальником непривычные проблемы выведения оклада, но она же задает направленность критериев, которые следует принимать во внимание при создании хакеру среды, позволяющей добиться от него наибольшей продуктивности.

Другим непривычным для традиционного руководителя поведенческим аспектом хакера является его малая (по сравнению с "обычными" сотрудниками) управляемость. Тем не менее настоящий хакер может стать очень эффективным сотрудником сам по себе. Кроме того, его временами раздражающее "сидение в Internet" ("разве за это ему деньги платят?") способно обернуться подключением колоссального и дарового потенциала профессионалов, работающих во всемирной Сети! Наконец, открытость хакера - тоже часть его мотивации, поэтому всеми своими находками настоящий хакер поделится с остальными сотрудниками.

Найдите возможность для открытой разработки

Осуществление перечисленного будет особенно полноценным, если вы сумеете среди своих производственных задач выделить актуальную не только для вас, но и для многих других. Она не должна составлять коммерческую тайну, чтобы можно было открыто обсуждать ее даже с фирмой-конкурентом.

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

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

Чем шире интерес к вашей задаче, тем эффективнее такой механизм сработает. Но может оказаться, что ваши задачи совсем специфичны и объявление их во "всенародную разработку" ни к чему не приведет. Что ж, придется их решать самим или заказывать другой фирме, специализирующейся на таких задачах, - ведь даже энтузиаст открытой разработки Рэймонд не утверждает, что она единственна или универсальна как метод.

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

• купить коммерческий сервер;
• разработать свой собственный Web-сервер;
• присоединиться к группе разработки Apache.

Конечно, у первого решения могут быть свои веские доводы "за". Но не нужно забывать, что:

а. внешний разработчик при создании своего продукта не учитывал конкретику ваших условий;

б. все равно вам придется потратить массу времени на настройку сервера, поиск ошибок и путей их обхода и т. д.

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

Зато третье решение в состоянии обеспечить вам доступ к исключительно широкой базе опыта эксплуатации Apache в самых разных условиях. По некоторым данным, доля Apache среди общего количества серверов в мире составляет 61%, а по недавним оценкам Computerworld Россия, для домена ru эта цифра еще больше - 78%. Размер "базы знаний" и размах "консультационной поддержки" по Apache в Internet намного превосходит все аналогичное для других серверов и затрагивает все желаемые уровни - от простого использования до перепрограммирования компонентов.

Что дает волшебство

Звонкие слова, вынесенные в заголовок статьи, заимствованы из книги Рэймонда. Есть много людей, которые, не теряя почвы под ногами, видят в открытых разработках большое будущее. Другие считают, что это выдумки. "Большая промышленность" начинает проявлять благосклонность к отдельным "открытым" продуктам, но по поводу открытого способа разработки пока "окончательного" слова не сказала, так что ее действия могут трактоваться по-разному. Oracle, IBM и Informix, много других крупных и мелких фирм включили поддержку ряда систем открытой разработки в свои планы. Sun и Inprise/Borland открывают пользователям исходные тексты своих продуктов. Эти и другие фирмы поддерживают создание открытых Internet-форумов пользователей своих систем. Но о мере общего влияния открытых разработок на "большую промышленность" говорить пока рано.

Однако по прочтении книги Рэймонда становится совершенно ясно:

а. ставки высоки;

б. конкретные действия по приобщению к открытым разработкам могут стать для вас своевременным мостиком в будущее.