ИТ-подразделения должны продуманно подходить к внедрению, интеграции и использованию ПО с открытым кодом в своих организациях. Опрошенные порталом Enterprisers Project эксперты обсуждают основные аспекты, которые нужно учесть при разработке корпоративной стратегии Open Source.

Вы можете выбирать различные количественные и качественные критерии для измерения проектов Open Source, но есть одно общее: путь к успеху или неудаче по определению виден невооруженным взглядом.

«Проект с открытым исходным кодом, как и любой другой проект, требует понимания проблем, которые вы пытаетесь решить для своих пользователей, и видения того, как вы будете это делать, — говорит Джонатан Кац, вице-президент по проектированию платформ в Crunchy Data и член основной команды PostgreSQL Global Development Group. — Отличие такого проекта в том, что все видят, как он развивается, что дает возможность получения быстрой обратной связи от более широкой аудитории». Отзывы при этом вовсе не обязательно будут положительными.

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

И эта стратегия имеет первоочередное значение, поскольку внедрение Open Source на предприятиях стало очень распространенным явлением. В отчете Red Hat «2020 State of Enterprise Open Source» 95% из почти 1000 опрошенных ИТ-лидеров заявили, что открытый код является стратегически важным; 77% ожидают, что его использование на предприятиях продолжит расти.

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

1. Вам нужно запастись терпением и уметь играть вдолгую

По словам Кена Соха, инженера по продуктам AI Singapore и создателя инструментов RPA с открытым исходным кодом TagUI и RPA для Python, без этих важных качеств невозможно реализовать Open Source-стратегию и успешно реализовать проекты создания ПО с открытым кодом. Это то, что отличает устойчивые проекты от заброшенных в репозитории GitHub с гуляющими по ним перекати-поле.

«Вы имеете дело с массивным мировым рынком с бесчисленными бесплатными опциями для пользователей, — говорит Сох. — Без способности оставаться в игре шансов нет».

Эта способность может быть подкреплена самым разным образом: от личной страсти до спонсорства вашего работодателя или венчурного финансирования либо других внешних инвестиций. Вам, по сути, нужно ответить на вопрос: кто будет платить по счетам? (Эти могут быть как денежные счета, так и «потный» капитал.)

Например, для Соха RPA for Python — это проект его страсти, который он поддерживает на стороне. TagUI, с другой стороны, привлек интерес и получил поддержку Лоранса Лью, директора по ИИ-инновациям AI Singapore. «Лью верит в него, и это главное, — говорит Сох. — Он один из пионеров Open Source в Сингапуре».

2. Пропаганда проектов с ясной целью

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

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

«Пропаганда релевантных проектов и парадигм способствует их принятию Open Source-сообществом, — говорит, например, И.Г. Надхан, главный архитектор и стратег Red Hat в Северной Америке. — Однако такая пропаганда допустима только для тех проектов, которые приводят к ощутимым результатам для экосистемы, частью которой являются предприятия. Экосистемы могут определяться отраслью промышленности, бизнес-функцией, областью технологии, бизнес-моделью и т. д.».

3. Да, нужен маркетинговый план

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

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

«Хороший инструмент, о котором никто не знает, не так полезен, как некачественный инструмент, о котором многие говорят и который используют», — говорит Сох.

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

Но сначала люди должны узнать о существовании технологии — и почему она существует. И вы должны с чего-то начать.

«На заре TagUI и RPA for Python я писал по электронной почте письма тысячам пользователей GitHub, которые занимались проектами цифровой автоматизации, чтобы привлечь их внимание, — говорит Сох. — И я делал это вручную, вместо того чтобы использовать автоматизацию, только для того, чтобы узнать больше о каждом потенциальном пользователе из его профиля».

4. Разработка четких контуров обратной связи и документации

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

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

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

Сох считает, что в целом потратил больше времени на написание документации для TagUI и RPA for Python, чем на написание кода.

«Хорошая документация, которая пытается охватить часто задаваемые вопросы или нерешенные проблемы, не требуя высокого технического уровня для понимания, означает, что все будут в выигрыше», — говорит он.

5. Не обделяйте пользователей функциями

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

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

«Все наши проекты с открытым кодом должны сами по себе быть полезными, автономными инструментами, — говорит Лиз Райс, вице-президент по Open Source-разработке в Aqua Security. — Мы также включаем их в нашу коммерческую платформу, где они становятся частью гораздо более сложной и взаимосвязанной системы, но мы не ограничиваем возможности самих проектов с открытым кодом».

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

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

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