Открытый код против коммерческого ПО

Олег Татарников, Наталия Елманова

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

Однажды компания Microsoft обвинила сообщество OpenSource, продвигающее ПО открытым исходным кодом, в торможении прогресса и покушении на «незыблемые мировые ценности». Один из руководителей Microsoft предлагал даже законодательным путем запретить операционную систему Linux (откуда, собственно, и берет свое начало движение OpenSource), которая, якобы, так же как скандально известный Napster (распространитель музыкальных записей в Интернете), подрывает священное право на интеллектуальную собственность.

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

Но ведь открытые лицензии действительно утопичны, по-

скольку значительных денежных вливаний в производство софта, который не принесет прибыли за счет его продажи и обслуживания, никто делать не будет. А популярность движения OpenSource основана только на том, что все очень любят «бесплатный сыр», забывая о том, что он бывает только в мышеловке.

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

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

А что касается получения прибыли за счет продажи и обслуживания программ, то никто не отменяет такую возможность и при условии поставки ПО с исходными текстами программ. Только в этом случае сложнее будет брать большие деньги за некачественные разработки или откровенный ширпотреб. В результате программирование перестанет быть источником сверхприбыли для таких корпораций, как Microsoft. И кстати, растущее влияние ОС Linux, которая распространяется бесплатно или продается по низкой цене, недавно вынудило компанию Microsoft выпустить дешевую версию Windows XP Starter Edition, которая будет распространяться, по заявлениям компании, в развивающихся странах с октября этого года.

Да, снизить цены на ПО можно, но кто вообще станет покупать программу, если можно взять ее исходники, откомпилировать и получить продукт бесплатно?

Ну положим, и сама Microsoft некоторые свои продукты распространяет бесплатно, но при этом не открывает исходный код и сохраняет его в своей собственности. Значит, дело тут совсем не в деньгах. Кроме того, OpenSource бесплатен, только если ваше время ничего не стоит! Ведь не секрет, что между написанием текста программы и созданием пакета, предназначенного для коммерческого распространения, часто лежит глубокая пропасть. Даже для простой компиляции исходника и сборки продукта нужно иметь по крайней мере компилятор и обладать некоторыми профессиональными навыками, не говоря уже обо всем прочем.

А вам не кажется, что сама стратегия OpenSource уничтожает интеллектуальную собственность? Ведь западный мир — это мир секретов и бережного обращения с ними. И во многом благодаря именно этому коммерческие компании добились своих успехов. Возможно, российскому человеку, особенно после 70 лет социализма, трудно прочувствовать это на собственном опыте, но принцип патентного права объясняется так: изобретатель раскрывает свой секрет государству (то есть сообщает его некоему государственному агентству — патентному бюро) по существу именно для того, чтобы сделать его общедоступным. Но в обмен на это изобретатель получает право монопольно применять изобретение в течение определенного срока (в зависимости от страны — до нескольких десятков лет) и возможность апеллировать к органам государственной защиты, если его монополия нарушается. При этом полезность изобретения заключена в самой идее, то есть в сути изобретения, а не в тексте, формулирующем эту идею. Сами по себе тексты мало кому интересны, а вот смысл изобретения становится понятен довольно быстро, и именно его не захотел бы открывать изобретатель, если бы не был защищен патентом. А монополию полезно предоставлять именно на начальном этапе, так как благодаря ей изобретения начинают применяться в широких масштабах. А вы предлагаете «открыть все карты»!

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

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

Кстати, ваше сравнение с картами здесь как нельзя более удачное. Прямо как в анекдоте: «Мы — джентльмены, мы друг другу верим... и тут у меня карта пошла!» — что вполне отражает смысл происходящего сегодня. А OpenSource предлагает играть в шахматы, то есть в игру, где нет места обману и ставка делается только на интеллект. В конце концов алгоритмы можно запатентовать, а в том случае, когда исходные тексты прилагаются к программам, легко проверить, у кого какие алгоритмы используются.

Отношение к патентованию алгоритмов во всем мире неоднозначное. В США, например, изобретение не будет признано патентоспособным, если оно представляет собой исключительно математический алгоритм. Однако если положенный в основу изобретения способ при помощи ПО позволяет получить конкретные, промышленно применимые результаты, то изобретение является патентоспособным (так же как, например, схемы ведения бизнеса). В отличие от США, в РФ в соответствии с Патентным законом от 23.09.1992 г. алгоритмы не признаются патентоспособными изобретениями ни в каком виде. Защита программ осуществляется только на основании норм законодательства об авторском праве. В Европе тоже не существует однозначного ответа на вопрос, патентуются ли там алгоритмы, поскольку там принята другая терминология (ресурс противников выдачи патентов на алгоритмы, разъясняющий, что сейчас происходит в Европе в связи с этим, — http://swpat.ffii.org/index.en.html). Кстати, против патентования алгоритмов и программ выступают в первую очередь сами программисты.

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

Так что законодательства об авторском праве для защиты программ вполне достаточно. При этом в подобных отраслях идут даже разговоры об ограничении копирайта (смотри, например, http://www.libertarium.ru/libertarium/minimal-theses). Там автор в числе прочего делает акцент на то, что издается, тиражируется и хорошо продается множество низкопробной продукции. Получается, что более успешны не те, кто занимается серьезными вещами, а те, кто штампует так называемую попсу. А если разрешить публике копировать, что она хочет, она будет копировать именно эту самую низкокачественную продукцию и тем самым значительно сократит прибыли ее производителей. Собственно, то же самое наблюдается и на рынке ПО — пиратами распространяются в основном компьютерные игры, музыка, видео и прочие поделки, а серьезного ПО, создание которого требует значительных усилий, на пиратских лотках практически не бывает. Да и мало кто покупает серьезное ПО у пиратов.

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

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

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

Как писал Карл Маркс, собственность — это не предмет, а отношение людей к этому предмету, то есть тот факт, что люди признают этот предмет вашим. Поэтому воровство надо искоренять другими методами, чтобы человечество не страдало от методов сохранения собственности больше, чем от самого воровства. А то ведь иногда доходит даже до того, что производители закрывают спецификации файлов и форматы данных. То есть исчезнувшая с рынка программа может унести с собой не только свой интеллектуальный потенциал, но и информацию пользователя. Причем неоднократно многие коммерческие производители пытались брать деньги за использование такой «интеллектуальной собственности», как форматы записи.

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

Ведь ни в коей мере не поощряется создание своего собственного рассказа или песни путем компиляции фрагментов существующих произведений других авторов. А OpenSource в области программирования предлагает именно такой подход.

В результате мы наблюдаем огромное количество похожих, но плохо совместимых версий одного и того же. Одних только дистрибутивов Linux столько, что при создании приложений, более сложных, чем простые утилиты, серьезные разработчики выбирают ограниченное число дистрибутивов (так в свое время сделала компания Borland, выпустив Kylix — средство разработки платформы Linux) или вообще отказываются от поддержки Linux по причине нерентабельности поддержки большого количества дистрибутивов (так поступила компания Citrix, выпустившая MetaFrame Access Suite для Windows и UNIX и отказавшаяся от поддержки Linux).

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

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

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

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

Эксперт, может, и найдет, однако сколько на это потребуется сил и времени! И любая бизнес-модель, построенная на таких принципах, неизбежно обречена на провал. Причем так полагает не только компания Microsoft. Сторонники такой точки зрения есть и в Linux-компаниях, которые традиционно строились на открытых кодах.

На каких принципах? Сейчас существует много моделей лицензирования: от «экстремистской» GPL (General Public License) до вполне «умеренной» лицензии BSD (от семейства UNIX-продуктов Berkeley Software Distribution), а также других — согласительных или договорных (все это зависит также и от бизнес-модели распространения продукта). О других «открытых» лицензиях можно узнать на http://www.opensource.org/. BSD-лицензия, например, в отличие от GPL, позволяет создавать на основе своего ПО и коммерческие продукты с закрытыми исходниками. При этом как раз возможность коммерциализации ПО под BSD-лицензией не раз приводила к тому, что производителям приходилось решать довольно сложные юридические и даже технические задачи. И в конце концов именно для того, чтобы не допустить таких коллизий, сообщество OpenSource при создании ОС Linux предложило свою так называемую универсальную открытую лицензию GPL. Эта лицензия была разработана для того, чтобы гарантировать право получения исходного текста и возможность внесения изменения в любую GPL-программу, а при использовании программы, лицензированной по GPL в другом ПО, новая программа должна, в свою очередь, наследовать лицензию GPL.

Таким образом, GPL-лицензия действует подобно вирусу, принуждая вас открывать весь свой код в том случае, если вы вдруг воспользуетесь GPL-программой? И если даже вы встроили в свое ПО десяток строк GPL-кода, то должны в ответ открывать миллионы своих собственных? Идея «открытого кода» действительно так ценна или сообщество OpenSource так пренебрежительно относится к труду программистов?

Сравнение с вирусом в данном случае неуместно. Вирус распространяется самостоятельно и заражает принудительно.

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

А почему здесь действует столь жесткий принцип: или все, или ничего? Такой подход несправедлив по отношению к разработчикам. Есть же, в конце концов, какие-то методики расчета трудоемкости. Пусть они не точны, но ими все-таки пользуются. Пусть даже кто-то поставил вам недельный срок, но если вы выполнили работу за пять минут, то вправе получить вознаграждение в размере стоимости рабочей недели. Но здесь-то ведь явное нарушение пропорций по трудоемкости — хотя бы в объемах, поскольку чаще всего производительность программистов измеряют именно в строках в месяц.

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

Но ведь производственным процессом как-то управлять надо, а для этого нужны какие-то численные показатели.

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

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

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

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

Но не все же занимаются написанием программ с открытым кодом в нерабочее время.

Есть и такие, кто получает

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

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

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

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

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

Кроме того, если бы все люди выполняли только те задачи, которые были поставлены им руководителями, то откуда бы тогда вообще взялись руководители? Так, например, когда создатель ОС Linux Линус Торвальдс устраивался на работу в компанию Transmeta, то у него в договоре был специальный пункт, который разрешал ему заниматься Linux.

Это возможно для Линуса Торвальдса — талантливого программиста, а рядовым работникам фирма предъявит вполне обоснованные претензии даже по поводу сделанного ими в свободное от работы время.

Если фирма не будет разрешать своим работникам ничего подобного, то они и не будут этим заниматься. Однако

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

Хороший программист просто не станет устраиваться на подобную рутинную работу. Но талантов единицы, а средний современный программист и от слова UNIX шарахается как от чумы и ни в чем, кроме Visual Studio или Delphi, работать не умеет. Какой уж тут OpenSource? А работодатели, в свою очередь, предпочитают нанимать сотрудников с опытом работы именно с коммерческими продуктами (и с наличием соответствующих сертификатов). Возможно, альтруизм и свойственен тем, у кого существует какой-то интерес к абстрактному программированию, но большинство коммерческих программистов пишут программы только потому, что за это платят деньги.

Если бы за написание программ не платили денег, то их не писали бы даже талантливые программисты. Точно так же, как художники не писали бы картин, а композиторы — музыку. Люди эксплуатируют свои знания, умения и природные склонности.

Но не стоит считать движение OpenSource элитным хобби крайне немногочисленных талантов, ведь глубинная цель открытых кодов — сделать всех программистов чуточку аккуратнее и скромнее, выставляя их труд на посмешище, согласно совету Петра I: «дабы дурость каждого видна была».

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

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

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

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

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

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

Что касается «повторяемости» кусков кода и неиспользуемых операторов, то этим больше грешат коммерческие программисты с их традиционной «построчной» оплатой, а также китайскими методами code reuse и cat&paste с последующим латанием того, что получилось в результате.

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

Отнюдь нет, такое сравнение вполне корректно! Так, например, нелюбимый вами Microsoft имеет сотни мегабайт общедоступного исходного кода (SDK, DDK, MSDN, Frontpage SDK, InterDEV SDK и т.д.), и при компиляции никаких предупреждений эти коды не выдают. Аналогичная ситуация и с SDK и входящими в комплект поставки примерами и обучающими программами у всех других коммерческих пакетов. Возможно, в этих кодах хватает ошибок, но там хотя бы отсутствует такая неаккуратность написания, которая, безусловно, является элементом непрофессионализма. А неаккуратность написания напрямую указывает и на неаккуратность планирования, и на пренебрежение к отладке, и вообще на неупорядоченность мышления при написании таких программ. Ведь из-за избытка пусть и несущественных предупреждений компилятора можно упустить из виду серьезные замечания и даже настоящие ошибки. Поэтому устранение таких замечаний должно быть просто правилом хорошего тона и безусловным элементом подготовки исходника к распространению в любой форме. А проблемы переноса ПО с платформы на платформу решаются при проектировании, а не при написании программ. И если этого не было сделано, то количество предупреждений при компиляции — это только цветочки.

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

Кроме того, огромное количество программистских поделок, написанных в рабочее время или на досуге, не обязательно связано с OpenSource — также речь идет о всяком share-, free- и прочих -ware с закрытым кодом. Но если продукт распространяется под GPL и ей подобными популярными открытыми лицензиями, то желающие по крайней мере могут посмотреть, что у него внутри, и оценить профессионализм создателя.

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

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

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

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

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

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

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

Однако в коммерческих компаниях аккуратность кода мотивируется зарплатой и жестко контролируется. Поскольку менеджеру проекта ясно, что из плохо написанного кода ничего хорошего не выйдет, найти в нем ошибки при тестировании сложнее, а за увольнением работника, написавшего такой код, может последовать катастрофа, так как никто не сможет разобраться в такой программе. А в том случае, если разработка изначально предполагается совместной, как в OpenSource, то такие требования тем более должны неукоснительно выполняться.

OpenSource как явление сродни свободе слова. Поэтому здесь не может быть однородности.

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

Собственно, и закрытое Free Software не запрещено из-за принципов свободы слова, что, кстати, в какой-нибудь другой отрасли промышленности может быть расценено как ценовой демпинг. Как это связано с «открытыми кодами»?

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

Но беда OpenSource-проектов заключается в том, что их делают программисты, мало интересующиеся подобными вещами.

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

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

Тем не менее это опять же программистский подход. А, к примеру, разработка интерфейса — это гораздо более сложная задача, чем разработка самой программы. Людей, способных разработать хороший интерфейс, гораздо меньше, чем хороших программистов, и их работа заключается совсем в другом, так что никакие исходные коды для ее выполнения не помогут. Кто будет таким дизайнером в OpenSource-проекте? Или они тоже будут работать на голом энтузиазме?

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

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

У больших коммерческих компаний поддержка часто бывает неудовлетворительной. Так, например, знаменитая Microsoft очень медленно и тяжело реагирует на запросы пользователей, особенно если последние не являются сотрудниками больших корпораций, выступающих в качестве Microsoft Authorized Parthner.

А разработчики OpenSource, возможно, неорганизованные разгильдяи, но они — огромное сообщество, поэтому более мобильны и всегда готовы к переделкам. К ним достаточно просто обратиться со словами: «Ребята, как вам не стыдно, поправьте...» Аккуратность программирования можно утвердить фундаментальным постулатом его «религии», а для кода, предназначенного для продажи, сделать качество основным свойством, тем более что здесь оно поддается простой проверке, в отличие от программ с закрытым кодом. Ведь есть же и в сообществе OpenSource профессиональные и аккуратные команды.

Это все слова, а на деле OpenSource не выглядит светочем истины, как и Microsoft не является империей зла. Так, например, если мы рассматриваем длительность жизни программного обеспечения, то Microsoft осуществляет поддержку своих продуктов в течение 10 лет. Другие производители коммерческого ПО, как правило, осуществляют поддержку своих продуктов в течение как минимум пяти лет. А где, например, можно сейчас получить поддержку RedHat Linux 6?

Кстати, Microsoft передает своим разработчикам и исходные коды своих продуктов (полностью или частично). Например, полные тексты операционных систем в соответствии с программой Shared Source передаются правительствам ряда стран с тем, чтобы компании, обслуживающие их в области IT, имели возможность убедиться в том, что код не содержит «закладок» и иных вредоносных частей, способных причинить ущерб. В частности, правительству России более полутора лет назад также были переданы исходные коды Windows. Так что по многим позициям компания Microsoft имеет перевес.

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

Возможно, сегодня характер софтверного бизнеса и меняется, но оригинальные пути для его ведения снова предлагают коммерческие компании, а не мифическое сообщество OpenSource (это и «интерактивные» лицензии, и многое другое). А «сообщество открытого кода» между тем пускает слюни и ударяется в религиозные церемонии: OpenSource как среда для реализации программистских амбиций, Интернет — как средство распространения информации, харизма лидера Линуса Торвальдса — как лучшая реклама и PR-кампания. Добавьте сюда мощную рекламную поддержку Sun, IBM и других «обиженных» компаний, а что получается в результате — мало кого волнует.

А какие проблемы в работе что в рамках Proprietary software, что по принципам сообщества OpenSource? Возможно, лишь отсутствие второго такого гения бизнеса, как Билл Гейтс, который начал бы зарабатывать на OpenSource, тормозит развитие последнего?

Да, по мнению многих производителей коммерческого ПО, маркетинговые кампании типа «OpenSource против коммерческих продуктов» — это просто борьба одних компаний против других, например IBM против Microsoft. А нападки на Linux (да и на GPL-лицензию заодно) компания Microsoft, возможно, затеяла не потому, что боится покушения на «непререкаемые мировые ценности», а только для того, чтобы напомнить об ОС Linux и при очередном разбирательстве официально заявить, что Linux является конкурентом Windows. После чего, естественно, Microsoft уже перестает быть монополистом (по крайней мере с формальной точки зрения).

Тем не менее компания Gartner, например, прогнозирует, что через два года количество компаний (преимущественно финансового сектора и Retail Banking), работающих на платформе Linux, достигнет 40% с вероятностью 0,9 — вследствие растущей функциональности и открытости ОС Linux, а также более низких цен. Потенциальных пользователей привлекает надежность, расширяемость и низкая стоимость решений на базе Linux, поскольку все это позволяет осуществить миграцию с других операционных систем и снизить суммарную стоимость владения.

Однако если аккуратно посчитать совокупную стоимость владения, то вовсе не факт, что она окажется в пользу OpenSource. Так, например, стоимость сертифицированного администратора Linux сейчас намного выше, чем стоимость сертифицированного администратора серверов Microsoft (имеется в виду не только зарплата, но и стоимость обучения и приобретения нужной квалификации). То же самое касается и затрат на разработку приложений для Linux — в среднем они оказываются выше, чем разработка приложений аналогичной функциональности для Windows. Кроме того, Microsoft предоставляет поддержку по разработке и изменению продуктов на базе Windows, а «профессиональные и аккуратные команды» в Linux-компаниях — нет.

Поэтому суммарные затраты в случае применения решений OpenSource могут оказаться и выше, что подтверждают результаты исследований четырех ведущих аналитических компаний: Forrester Research, Meta Group, IDC и Embedded Market Forecasters (см. http://www.microsoft.com/rus/business/news/totalcostofownership.asp). Например, аналитики Giga Research выяснили, что совокупная стоимость разработки Web-сервисов, в которую вошли такие показатели, как лицензионные отчисления, дополнительное ПО, техническое обслуживание, оплата труда и обучения сотрудников, на платформе .Net на 25-28% ниже, чем на Linux. При этом оказалось, что объем лицензионных отчислений не оказывает решающего влияния на стоимость разработки. Высокая себестоимость разработки Интернет-приложений для платформы Linux объясняется большими затратами на оплату труда и сложностью процесса разработки.

Несмотря на это, в последнее время все больший интерес проявляют к OpenSource правительства разных стран, и особенно грандиозны в этом смысле планы азиатских государств: Китай, Южная Корея и Япония собираются создавать свои собственные варианты операционных систем с открытым кодом. А в Северной Корее уже было объявлено, что в ближайшие три года на новых операционных системах с открытым кодом будут работать тысячи компьютеров.

Еврокомиссия призвала государственные учреждения европейских стран полностью отказаться от применения продуктов корпорации Microsoft и распространила среди членов Евросоюза рекомендации о том, как переходить с использования закрытого коммерческого ПО на OpenSource в государственных организациях.

Продвигается в этом направлении и Россия: недавно Министерство связи и информатизации открыло по соглашению с компанией IBM центр изучения Linux. Видимо, в российском правительстве тоже считают, что услуги Microsoft нашим чиновникам «не по бюджету». Такие же соглашения о продвижении ОС Linux в общественном секторе заключило и правительство Бразилии. Сами чиновники считают, что благодаря снижению затрат на разработку проектов с открытым кодом, а также их масштабируемости общественный сектор может получить в этой области огромную экономию.

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

Однако «бесплатность» корпоративного ПО с открытым кодом является не более чем мифом. Ели речь идет не о дешевых приложениях для конечных пользователей (а ведь Linux чаще применяется как серверная платформа), а о продуктах для корпоративного сектора, то и сам дистрибутив Linux, сертифицированный на совместимость с каким-нибудь коммерческим продуктом, например с СУБД компании Oracle, отнюдь не бесплатен — его цена в этом случае сравнима с ценой серверной версии Windows. То же самое касается и аппаратно-программных решений, основанных на Linux, например созданных на серверах производства IBM, — они не так уж и дешевы. Ведущие производители ПО, такие как IBM, Novell, Oracle, Sun, сейчас вкладывают немалые средства в эту платформу для того, чтобы просто иметь альтернативу продукции Microsoft, и в основном это касается серверных версий операционных систем.

Да, но это реальная альтернатива во многих областях, которая позволит значительно ослабить позиции корпорации Microsoft, заставит ее снизить цены и более внимательно отнестись к нуждам пользователей. Поэтому такие крупные IT-компании, как IBM, AMD, HP, Intel, Fujitsu Siemens, Oracle и др., все больше внимания уделяют продуктам OpenSource. Linux быстро переносится на все новые платформы (причем, например, процессорные технологии AMD Opteron были добавлены в ядро Linux раньше, чем появились где-либо еще).

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

Но офисные решения на базе Linux пока еще довольно слабы, чтобы обеспечить «единую корпоративную операционную среду». Даже такие широко рекламируемые альтернативы Microsoft Office, как StarOffice или OpenOffice, способны заменить решения Microsoft только на пользовательском уровне. При функциональности, приближающейся к возможностям Microsoft Office пятилетней давности, эти продукты практически не позволяют создавать на их основе корпоративные решения, аналогичные тем, что можно создавать на базе Microsoft Office. Средства их интеграции с серверами обмена сообщениями, корпоративными порталами, инструментами для анализа данных, их SDK для разработчиков пока еще, к сожалению, находятся на уровне, не сравнимом с уровнем интеграции Microsoft Office c серверами Exchange, SharePoint, а также с уровнем поддержки этим пакетом технологий COM и .NET. Поэтому рассказы о том, что, мол, StarOffice или OpenOffice не хуже Microsoft Office, всерьез могут воспринимать только начинающие пользователи, не знакомые с современными требованиями к офисным пакетам.

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

Возможно, ведущие поставщики ПО могут позволить себе распространять ПО с открытым кодом (причем по низкой цене или вообще бесплатно), поскольку они заработают достаточно средств на своем коммерческом ПО для корпоративного пользователя. Но не стоит забывать и о маркетинговой составляющей подобной деятельности — ведь, привлекая на свою сторону сторонников OpenSource, они, по сути, уводят пользователя на другую платформу, где могут оказаться в привилегированном положении, так же как и Microsoft с Windows. То же самое касается и компаний поменьше. Например, средства разработки Borland поддерживают J2EE-серверы категории OpenSource, при этом многие потребители такого «тандема», разработав с его помощью свое решение, для промышленной эксплуатации купят уже коммерческий J2EE-сервер — и с большой долей вероятности это будет J2EE-сервер от Borland.

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

КомпьютерПресс 9'2004