Dj Walker-Morgan
Перевод -- АКбара

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

Когда движения за свободное ПО и открытый код только появились, главный вопрос был таков: "Как на этом заработать деньги?" На него отвечали: вы отдаёте бесплатно программы и продаёте поддержку и услуги. Современные поставщики ПО на основе открытого кода развиваются именно по этой простой бизнес-модели. Многие из них говорят, что их программы открыты, но это не значит, что вы как клиент воспользуетесь всеми благами открытого кода.

Другой сценарий

Ситуация могла бы развиваться по другому сценарию, если бы в Examples нашли уязвимость безопасности: пользователи открытой версии смогли бы пропатчить её, как только патч появился бы, но корпоративные пользователи должны были бы ждать, пока Examples Corp выпустит новые поддерживаемые бинарники с исправленной уязвимостью. В идеальном мире временная разница должна быть незначителной, но у корпоративных пользователей нет возможности получать исправления так же быстро, как их получают пользователи открытой версии.

Позже сотрудники ACME захотят добавить некоторые функции в Examples, так что они скачают открытую версию и начнут работать с ней. Затем они обнаружат, что эта версия Examples не идентична по функциональности Enterprise Examples -- в ней не будет, например, таких функций, как кластерная система и некоторых других функций, важных большим предприятиям. Они доступны только в Enterprise Examples и внесены производителем как часть корпоративного предложения. Это и есть функциональная ограниченность. И хотя ядро пакета открыто, части, касающиеся развёртывания и управления, к примеру, являются скорее проприетарными, нежели открытыми.

Разработчики ACME понимают проблему и решают побыстрее справиться с ней, они начинают добавлять функции в открытую редакцию Examples. Всё прошло удачно, и они решают, что хотели бы использовать собственную версию -- ACME Examples -- наравне с Enterprise Examples. Но вы помните, что есть проблема с поддержкой собственных исправлений? То же самое происходит и в большем масштабе. Разработчики Example Corp говорят, что не будут поддерживать версию ACME, даже немодифицированные её части.

Разработчики ACME решают, что будут отдавать свои улучшения в открытую редакцию Examples и ждать, пока Example Corp внесёт их в новый версию Enterprise Examples. Всякий раз, когда выходит новая версия, в ней нет долгожданных улучшений, потому что они дублируют функциональность (хотя и в меньшем масштабе) готового продукта, который Example Corp уже продаёт.

В конце концов, ACME не становится партнёром Example Corp. Партнёры нашей выдуманной Example Corp обязаны подписать партнёрское соглашение, по которому они не могут устанавливать или работать с открытой версией Examples. Причина проста: Example Corp поддерживает партнёра и поставляет ему свои ресурсы, но при этом не желает, чтобы партнёр устанавливал на клиентские компьютеры открытую версию Examples. Это разумная позиция, но в ней кроется ловушка для партнёров: они не могут работать с открытой версией и улучшать её. Партнёры могут изменять код и отсылать его Example Corp, но не могут участвовать в делах сообщества. Это "партнёрская ограниченность" и стоит заметить, что партнёры как пользователи могут быть ограничены только работой с версией Enterprise.

То же можно сказать и о корпоративных пользователях, которые по вышеупомянутым причинам не могут работать с открытыми версиями, поскольку они не будут поддерживаться. А без участия этих пользователей вклад сообщества будет приносить пользу лишь разработчикам Example Corp.
Проверка на открытость

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

Ниже список вопросов, которые нужно задать себе:
1. Предлагает ли производитель поддержку открытой версии продукта?
2. Предлагает ли он поддержку открытой версии по запросу?
3. В открытой и корпоративной версии доступен набор одних и тех же функций?
4. Свободна ли корпоративная версия от проприетарных компонентов? Если нет, то есть ли им открытая замена?
5. Будет ли производитель поддерживать модифицированные корпоративные версии своего продукта, если клиент купил лицензию?
6. Доступен ли весь исходный код пользователям корпоративной продукции (или это присутствует только в открытой версии)?
7. Разрешено ли партнёрам производителя устанавливать и работать с открытой версией программы?
8. Может ли клиент, если он захочет того, заменить корпоративную версию на открытую?
9. Участвуют ли посторонние люди (не только сотрудники компании-производителя) в развитии открытой версии?

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

От переводчика: буду благодарна за помощь в исправлении ошибок.

*Данный текст является переводом оригинальной статьи и не является официальным. Ссылки работоспособны на момент публикации.
_____________________________________

Копирование материала разрешено только при наличии ссылки на источник:
неофициальный проект GNU/Linux ХМАО-Югра www.oslinux.ru