Достоинства открытой модели часто мотивируют компании передавать свои внутренние разработки сообществу. Разумеется, в этом нет никакой идеологии — как правило, это прагматичные решения, которые принимаются для привлечения к проекту новых программистов и тестеров. Причём, с минимальными материальными затратами, по крайней мере, в теории.
Однако следует понимать, что из перевод в Open Source автоматически не гарантирует достижение какого-либо положительного эффекта. Дуэйн О’Брайен из PayPal сформулировал четыре важных вопроса, на которые должно ответить руководство компании перед принятием такого решения.
Нужен ли проект самой компании?
Не стоит рассматривать свободное сообщество как сундук, куда можно складывать отслужившее своё вещи. Разумеется, такая точка зрения имеет право на жизнь, но тогда ваш проект будет просто «пылиться», поскольку вряд ли кто-то заинтересуется тем, что уже не развивается основным разработчиком.
Если компания прекратила активно развивать приложение, то она не сможет собрать вокруг него сколько-нибудь значимое сообщество. Никакой проект не будет делаться «толпой» — кто-то должен отслеживать уязвимости, кто-то — заниматься сортировкой баг-репортов, кто-то — вводить в курс дела новых участников и т. д. Всё это требует времени.
Если руководство компании рассматривает потерявшие для неё актуальность решения как некое пожертвование сообществу, то оно очень быстро убедится в том, что само сообщество в этом совершенно не нуждается. Ненужное вам не нужно никому — это реальность, с которой нельзя не считаться.
Перевод проекта в Open Source позволит сэкономить ресурсы, сделать разработку максимально эффективной. Но это вовсе не означает, что дело будет делаться само, без участия и интереса со стороны компании.
Нужен ли проект сообществу?
Даже если приложение необходимо вашей компании, то оно может оказаться совершенно безразлично другим. Концепция Open Source предполагает, что сообщество добровольно примет участие в проекте, руководствуясь собственными интересами, а не потребностями вашей фирмы.
Либо компания платит разработчикам зарплату, либо она пытается заинтересовать их чем-то ещё. При этом важную роль играет взаимодействие фирмы с сообществом.
Недостаточно, чтобы программа была просто интересной — следует убедить в этом независимых разработчиков. Для этого нужно принимать участие в разнообразных конференциях, радикально усилить информационную составляющую своей деятельности, даже если руководство скептически относится ко всяческому «пиару».
Разумеется, если ответ на этот вопрос отрицательный, то это не означает, что следует сразу опускать руки. Не исключено, что при некоторой доработке программа станет востребованной независимыми программистами.
Тут нужно оценить затраты и ожидаемые выгоды. Возможно, есть резон вложить какие-то небольшие средства, чтобы сделать проект интересным сообществу и потом извлекать из этого выгоду для себя.
Есть ли у вас ресурсы для поддержки?
Поддержка открытого проекта требует значительных временных затрат. Причём, открытая модель — это довольно гибкая сущность, и оперируя масштабами разработки можно как-то регулировать собственные расходы.
Например, если руководство компании считает, что они должны полностью контролировать разработку, но не готовы выделить достаточно средств, то проект вряд ли будет успешным. И тем более не следует рассматривать Open Source как крайнее средство спасения, когда денег на поддержку нет совсем.
Руководство компании должно абсолютно точно представлять, какие именно расходы потребуются. Если оно сочтёт это неразумным или нереальным, то проект требует доработки.
Можно ли передать сообществу не весь код?
Иногда компания хочет передать сообществу не весь код используемого ею ПО, а его часть. Причина такого решения, как правило, заключается в том, что руководство опасается за какие-то критически важные внутренние системы и считает, что их не следует открывать для публичного доступа.
Однако возможна ситуация, когда открытый код каким-то образом зависит от закрытого. Приводит это к тому, что предлагаемое сообществу приложение является неполным, что снижает интерес к нему.
В этом случае код должен быть каким-то образом изолирован. Например, реализован в виде модуля к какому-либо открытому ПО. Если компания к этому не готова, то ожидаемого эффекта от открытия не будет.
При этом важно понимать, что комбинированная схема, когда часть ПО разрабатывается внутри компании, а часть — силами сообщества, вряд ли будет успешной. Дело в том, что такой подход ограничивает возможность коммуникации, исключает совместные обсуждения, в результате чего независимые программисты, вероятнее всего, покинут проект.
