В последние несколько лет мы слышим довольно много разговоров о ПО с открытым кодом (Open Source Software, OSS). Много продуктов этого типа - Linux, Apache Web Server, JBoss Application server, PostgreSQL и MySQL - оказываются конкурентоспособными не только по цене. Да, многие заказчики первоначально сомневались в качестве и достаточной поддержке ПО с открытым кодом. Однако постепенно многие из этих сомнений были отброшены, по мере того как ПО с открытым кодом находят применение в центрах обработки данных. Наиболее яркие примеры - использование Yahoo FreeBSD, чтобы управлять Yahoo.com, использование Dell Computer и агентством "Рейтер" Linux на многих из их внутренних операционных серверов и работа Weather.com на Apache.
Все это замечательно, об этих примерах нам постоянно напоминают апологеты ПО с открытым кодом. Но проблема в том, что все они весьма односторонние. Более внимательный анализ показывает, что все успешные примеры можно свести к трем вариантам применения ПО с открытым кодом. Первый и самый распространенный вариант - это использование такого ПО для Web-серверов. Второй - использование их на периферии сети, для решения второстепенных задач, имеющих отношение скорее к инфраструктуре, чем к бизнес-приложениям. И третье - это использование в основном Linux для специфических приложений, требующих сложных серверных комплексов и большой вычислительной мощности. Это все отнюдь не самые сложные и первостепенные задачи большинства компаний во всем мире. Где же примеры использования ПО с открытым кодом для критических бизнес-приложений типа CRM, ERP, деловых баз данных и систем электронной коммерции?
Нет, на поверку оказывается, что и такие есть, только… только все они, как бы это помягче сказать, небезупречны. Утверждать, что сегодня ПО с открытым кодом уже проникло на уровень поддержки критических бизнес-приложений предприятия - большая ошибка. И дело здесь отнюдь не в традиционных вопросах качества ПО и его поддержки. Вопросов, которые необходимо рассмотреть, принимая стратегическое решение об использовании ПО с открытым кодом, для поддержки критических бизнес-приложений предприятия, гораздо больше. Это решение зависит от разнообразных факторов: типа компании, ее ресурсов, клиентов, реальной степени важности бизнес-приложений и так далее. Поэтому нам показалось разумным привести список пунктов, на которые необходимо обращать внимание при оценке применимости ПО с открытым кодом.
Поддержка. Это, безусловно, остается одним из главных вопросов. До недавнего времени пользователи ПО с открытым кодом были недовольны поддержкой. Теперь мы видим появление многих независимых консультационных компаний, которые могут обеспечить экспертизу OSS-решений. Однако многие из этих компаний - незрелы по части ведения бизнеса и их положение непрочно, и долгосрочный успех неочевиден. Кроме того, во многих случаях их консультационный опыт не слишком велик. Очень немного ИТ-консультантов работали над большими OSS-решениями в течение долгого времени, и они так же дороги, как и консультанты по коммерческому ПО. Намного проще найти опытного консультанта по решениям на IBM WebSphere, чем на JBoss Application server, и гораздо меньше администраторов базы данных может разбираться с проблемами на MySQL, чем на Oracle.
Масштабируемость решений. Безусловно, много продуктов с открытым кодом поддерживают приложения масштаба предприятия, но многие другие не имеют такого опыта. Например, Linux и Apache доказали свою способность работать на уровне предприятия. Другие, например базы данных с открытым кодом, не имеют истории поддержки больших, критических приложений предприятия. Много продуктов с открытым кодом развились из небольших, однопользовательских программ или приложений масштаба отдела. Кроме того, много разработчиков ПО с открытым кодом не имеют большого опыта написания кода для хорошо масштабируемых, ресурсоемких приложений.
Существует мнение, что ПО с открытым кодом должно быть обязательно лучше, потому что любой может видеть код и исправлять ошибки. Это представление правильно только до некоторой степени, поскольку, когда программа имеет миллионы строк, очень немного разработчиков могут оценивать всю программу в целом. А именно это необходимо для масштабирования. Однако популярные, хорошо опробованные приложения типа Apache, Linux и FreeBSD можно использовать в приложениях масштаба предприятия, потому что они работают во многих больших организациях и, таким образом, уже справились со многими ошибками.
Стабильность сообщества разработчиков. Для некоторых деловых приложений есть много продуктов с открытым кодом, так что выбор должен частично базироваться на их зрелости и поддержке сообществом разработчиков. Проекты по разработке продуктов с открытым кодом могут умирать, если сообщество разработчиков теряет к ним интерес. В таких случаях расширение и поддержка приложения будут ограничены. Хотя, конечно, имея исходный текст, расширение приложения будет возможным, даже если сообщество его разработчиков распалось. Говоря о сообществе разработчиков приложения с открытым кодом важно оценить уровень его поддержки и скорость исправления ошибок. Много сообществ разработчиков реагируют на проблемы быстро, но у других разработчиков устранение ошибок может занять намного больше времени.
Функциональные требования к системе. Делая выбор между открытым и коммерческим ПО, важно четко определить, какие функциональные особенности могут быть необходимы. Например, если оказывается, что нужна сложная балансировка загрузки сервера приложений, то имейте в виду, что большинстве продуктов с открытым кодом эти возможности сильно ограничены. Точно так же поддержка репликации баз данных может стать проблемой, если нужно обеспечить автоматизированную репликацию центрального информационного хранилища и частной базы данных. В таких ситуациях необходимо использовать коммерческие продукты, которые более полноценно реализуют эти функции. Во многих важных прикладных областях типа аналитики или систем поддержки принятия решений все еще нет достаточно серьезных и функциональных продуктов с открытым кодом. Во многих случаях это только частные или незрелые решения. Одно из существенных преимуществ коммерческих решений - готовность многих поставщиков добавить в свои продукты те возможности, которые необходимы заказчикам, особенно, когда это помогает увеличить продажи. В отношении ПО с открытым кодом это пока можно сказать только с большой натяжкой. Поэтому очень важно индентифицировать все эти особенности как можно раньше.
Юридические проблемы. Наконец, стоит учесть, что в организации могут возникнуть проблемы с лицензионными политиками ПО с открытым кодом. Дело в том, что есть несколько разновидностей лицензионных правил использования ПО с открытым кодом. И некоторые из этих лицензий требуют, чтобы любая интеллектуальная собственность, основывающаяся на OSS-продукте, также должна иметь открытый код. Это требование может быть неприемлемо, особенно если компания планирует продавать сервисы, основанные на приложениях с открытым кодом. Или ваша организация хочет использовать удачное внутреннее приложение совместно со своими партнерами, не открывая его конкурентам, что нарушает OSS-лицензию. Представьте себе, что вам придется открыть исходный текст вашего решения конкурентам из-за боязни судебных преследований!
ИТ-стандарты. Безусловно, ИТ-стандарты играют важнейшую роль в выборе приложений. И здесь ПО с открытым кодом может подбросить несколько сюрпризов типа сложности интеграции с существующей системой управления, неспособности обработать определенные форматы данных или зависимости от дополнительных драйверов. Конечно, эти проблемы решаются, но это увеличивает стоимость владения таким ПО. Причем стоимость решения таких проблем часто может превышать стоимость лицензий на открытое ПО. Еще раз повторим постоянно муссируемую максиму - только то, что продукт с открытым кодом и не имеет стоимости лицензирования, не означает, что он не имеет никакой стоимости поддержки. Стоимость лицензий не должна быть основным критерием.
***
В заключение можно сказать, что много приложений с открытым кодом заслуживают серьезного отношения. Но оценивать их надо тем же самым способом, каким оцениваются коммерческие решения. Стоимость неправильных решений может быть очень значительной и существенно превосходить экономию на лицензиях.
