Пять заблуждений об открытом ПО
Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.
Наша компания участвует в открытых проектах с 2005 года — и благодаря разработке собственных open source решений (проекты OpenVZ, CRIU), участвуя в других открытых проектах (QEMU, OpenStack, libvirt, libcontainer, и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».
Проект с открытым исходным кодом это открытый проект.
Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта — это только его часть, свободный доступ к которой не даёт права называть весь проект открытым. Помимо исходного кода, свободный доступ должен быть открыт и к другим артефактам разработки, и чем больше артефактов открыто, тем больше проект открыт для контрибьюторов (людей, которые захотят сделать вклад в проект). Помимо этого, необходимы прозрачные процессы между всеми участниками сообщества, открытые коммуникации в проекте и т.д. Все эти меры будут только способствовать развитию проекта и плодотворному сотрудничеству участников сообщества.
Oracle VirtualBox — это пример закрытого проекта с открытым исходным кодом. Код полностью доступен, но процесс разработки закрыт и непрозрачен.
Продукты на основе открытых проектов содержат только открытый исходный код
Компании, которые разрабатывают коммерческие решения на базе открытых проектов, могут включать закрытые компоненты в свои продукты. Потому что именно дополнительная закрытая функциональность может дать им конкурентное преимущество среди компаний, которые также строят бизнес на основе этого открытого проекта. Именно закрытые компоненты зачастую формируют продукт, который компания может продавать своим клиентам и зарабатывать на нём деньги.
Например, недавно мы объявили о разработке следующей версии Virtuozzo, дистрибутив которой будет распространяться бесплатно. Пользователь получит возможность использовать виртуальные машины и последнюю версию наших контейнеров свободно и без ограничений, но при желании он сможет установить набор дополнений (распределенное хранилище данных, компонент для увеличения плотности контейнеров на одном физическом сервере и другие), которые помогут ему успешнее решать его задачи. В этом часть свободы открытого ПО. Вы сами выбираете тот вариант, который вам больше подходит: использовать базовую версию или расширенную. В нашей практике есть примеры компаний-клиентов, которые предоставляли услуги на основе технологий OpenVZ, но позднее оценили преимущества коммерческой версии, и с тех пор стали нашими платными клиентами. Это стратегия win-win, в которой выигрывают обе стороны.
Использование открытого ПО полностью бесплатно
Существует расхожее мнение о том, что свободный софт является в то же время и полностью бесплатным. Однако цена самого ПО — лишь малая часть расходов, связанных с его использованием. Свободное ПО — не исключение, поэтому перед его использованием необходимо оценивать весь его жизненный цикл. Только так можно сделать вывод о том, будет внедрение открытого ПО выгодным или нет.
Разберём это на примерах:
- Опытный пользователь установил и настроил на своём компьютере свободно распространяемую программу. Он заплатил за неё своим временем, потраченным на установку, освоение, поддержку (обновления и т.п.)
- Неопытный пользователь попросил опытного установить на свой компьютер свободно распространяемую программу, оплатив его услуги.
- Компания, предоставляющая услуги хостинга, начала предоставлять услуги на базе открытых решений. Такая компания будет платить или персоналу из своего ИТ-отдела или компании, которая участвует в разработке этого проекта, за внедрение и техподдержку. Какой вариант выберет компания — зависит от стоимости, но то, что проект по внедрению и использованию открытых решений не будет бесплатным — это факт.
Во всех примерах не было покупки права использования программы (лицензии), что на самом деле происходит во время приобретения коммерческого ПО. Но каждый раз возникала другая стоимость, к примеру, стоимость услуг или стоимость собственного бизнеса плюс экономия средств за счет свободного права использования.
Одно из достоинств Open Source — предельные затраты, по существу, отсутствуют, так как здесь, как правило, не требуется дополнительных лицензий по мере того, как расширяется внедрение.
Нельзя построить бизнес на открытых решениях из-за отсутствия технической поддержки
Поддержка — это ключевой момент для пользователей. Рядовой пользователь вполне может обойтись без нее при использовании открытого ПО, как мы это объяснили в примерах выше, но компаниям техническое сопровождение в большинстве случаев необходимо.
Серьёзные открытые проекты либо активно поддерживаются сообществом разработчиков, либо существуют компании, которые на коммерческой основе могут обеспечить поддержку для крупного бизнеса. А при необходимости — и добавить в продукт нужную функциональность.
Именно такой модели мы придерживаемся в проекте OpenVZ. Компоненты проекта распространяются свободно, но если вам нужна поддержка или разработка дополнительной функциональности, то мы можем её обеспечить.
Качество открытого ПО хуже, потому что код для него может писать любой желающий
Главный принцип открытого ПО — открытая совместная разработка — сам по себе является залогом того, что некачественный код, костыли и заплатки попросту невозможно будет скрыть от других участников. Человек, участвуя в такого рода проектах, готов к тому, что его работа будет подвергнута и анализу, и критике, а, значит, халтурить не будет. На кону его репутация, а её терять никто не хочет.
Кроме того, в некоторых сообществах (например, сообщество вокруг разработки Linux-ядра) существует и жесткий принцип — в исходное ядро принимается только самый лучший, оттестированный и идеальный код. Попытку добавить некачественные изменения отклонят, вторая попытка чревата потерей репутации для человека или компании-контрибьютора.
То есть открытый проект действительно даёт возможность любому человеку принять участие в написании кода, но в серьёзных проектах из-за высокого порога вхождения код не будет принят от людей с недостаточным уровнем экспертизы.
В большинстве крупных ИТ-компаний (IBM, Google, Canonical, Parallels и т.д.) есть целые департаменты, в которых специалисты получают зарплату за то, что работают над проектами с открытым исходным кодом и таким образом косвенно работают над продуктами компании.
Отдельно стоит упомянуть, что компании, которые разрабатывают продукты на базе открытых проектов, в ходе тестирования заинтересованы в улучшении кода открытых проектов, которые они используют. Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта. Наши продукты используют код других открытых проектов, поэтому проблемы, найденные в коде этих проектов, мы исправляем и отправляем в upstream. Так было с уязвимостями в ядре RHEL: Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014–0203 и CVE-2014–4483 в одном из обновлений ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014–5045, Дмитрий Монахов — за CVE-2012–4508. Факт хорошего тестирования Linux-ядра был даже отмечен Эндрю Мортоном (кто это?): «Мне интересно. За последние несколько месяцев люди из @openvz.org нашли (и исправили) кучу непонятных, но серьезных и довольно древних багов. Как вы обнаружили эти баги?»
Итог
На самом деле все перечисленные мифы возникают по большей части у пользователей, которые либо только начинают работать с OpenSource ПО, либо не пробовали этого делать вообще. Лучший способ избавиться от предубеждений — начать вплотную работать с такими решениями.
Мы недавно анонсировали открытый процесс разработки новой версии нашего продукта Virtuozzo 7. Если вы также заинтересованы в создании лучшей технологии контейнерной виртуализации, то присоединяйтесь.
