Разработка программного обеспечения и законодательная деятельность в чем-то схожи
Валерий Коржов — обозреватель Computerworld Россия. С ним можно связаться по адресу oscar@osp.ru

Модель разработки программного обеспечения с открытым кодом кажется чем-то чрезвычайно необычным, не имеющим аналогов. Однако это не совсем так. Подобные технологии коллективного творчества постепенно появляются и в других областях человеческой деятельности, где необходимо совместное принятие решений. Опубликованное в одном из западных изданий сообщение о том, что Линус Торвальдс собирался участвовать в предвыборной кампании на пост губернатора Калифорнии (статья называется «Пингвин против Терминатора»), конечно же, было шуткой. Тем не менее если Торвальдсу удается координировать деятельность большого количества разработчиков ядра Linux, то почему бы ему не применить ту же схему для управления штатом? Идея только на первый взгляд кажется абсурдной, но если разобраться, то окажется, что аналогичные примеры можно найти в российском законодательстве.

Сходство и различия

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

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

Впрочем, эту методологию разработки программ используют создатели как «закрытого», так и «открытого» программного обеспечения. Ключевыми являются ответы на следующие вопросы: «Известны ли фамилии разработчиков всех фрагментов текста или они обладают коллективной ответственностью?», «Как учитываются мнения пользователей?», а также «Может ли пользователь повлиять на функционал разрабатываемого продукта?».

Рассмотрим в качестве примера принятие закона «Об ЭЦП», который не заработал спустя полтора года после его вступления в законную силу. Он разрабатывался межведомственной комиссией, куда входили представители Центробанка, Минсвязи, ФАПСИ и некоторых других заинтересованных ведомств, однако все наиболее спорные корректировки были внесены в его текст уже перед третьим чтением (то есть прямо перед выпуском продукта). Причем найти авторов этих исправлений не удается и по сей день.

Рекомендации по закону собирались от всех заинтересованных лиц, но в окончательном варианте они учтены не были. Приходится констатировать, что разработка закона «Об ЭЦП» соответствует скорее закрытой модели.

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

Open Source для законов

Акт, регламентирующий открытую процедуру законотворчества, был принят в 2002 году и начал действовать с середины 2003 года. Это закон «О техническом регулировании». По идее он должен заменить существующую систему российских стандартов. В частности, закон опирается на так называемые регламенты безопасности, которые формулируются для каждой категории продуктов самостоятельно и принимаются на уровне законов. Причем законодательный статус регламентов не дает ведомствам права отменить их подзаконными актами.

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

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

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