Назад к пользователю

Чем технически сложнее программа, чем она монолитнее, чем шире она используется, и чем больше программистов от нее зависит, тем сильнее ее ценят.

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

Вообще-то, среди пользователей многих приложений почти нет программистов. Например, их нет в области управления отношениями с клиентами (customer relationship management, CRM) или цепочками поставок (supply chain management, SCM). А у программистов, кроме финансовых стимулов, нет прямой мотивации для решения чужих проблем. Простые пользователи не должны ничего тестировать или отлаживать, им нужны стабильно работающие решения, а не технические головоломки.

Качество не означает отсутствия ошибок

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

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

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

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

Цена качества

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

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

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

Дэвид Мессершмитт (messer@eecs.berkeley.edu) — профессор кафедры электротехники и вычислительной техники Калифорнийского университета в Беркли. Соавтор книги Software Ecosystem: Understanding an Indispensable Technology and Industry.

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

Приведенные им примеры страдают крайним максимализмом и полностью укладываются в рамки моей первой фразы. Из них следует, что открытый код является антидотом против монополистического поведения. Разумеется, открытый код имеет и сильные, и слабые стороны, но рынок (а не профессиональные программисты) все расставит по своим местам, и для разных типов программных продуктов успех будет неодинаков. Открытый код и его двоюродные братья, такие как публикации с открытым доступом, не делают никаких революций; они являются участниками здоровой конкуренции методологий. И я не понимаю, чем вызваны столь яростные нападки на венчурных капиталистов (или, как говорит Эрик, спекулятивных инвесторов)? Ведь именно они противостоят застойным явлениям и поощряют ничем не стесняемые инновации, обеспечивая в то же время достойный заработок программистам.

Эрик говорит, что при неограниченных ресурсах и отсутствии докучливого планирования и ограничений со стороны заинтересованных лиц мы сможем создавать программы без ошибок. Да, без назойливых пользователей и въедливых менеджеров программист может сделать неплохую карьеру. Но менеджеры нужны для того, чтобы распределять ограниченные ресурсы, решать споры между всеми заинтересованными лицами и жестко соблюдать напряженный график. Активное же вовлечение пользователей (или их представителей) в эти процессы существенно повышает их эффективность.

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

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

— Дэвид Мессершмитт