Взаимная ценность доступа к хранителям

В мае прошлого года я ушел из Google, чтобы построить более устойчивую модель сопровождения Open Source. После летнего перерыва я возобновил работу по сопровождению проекта Go в сентябре и начал предлагать свои услуги компаниям, которые полагаются на Go.

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

Предлагая свои услуги компаниям, я продаю три вещи: постоянное обслуживание, доступ к сопровождающему и маркетинг. Легко упускаемый из виду компонент доступа – это взаимная ценность компаний, имеющих прямую связь с сопровождающими проектов, на которые они полагаются.

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

Я не говорю о дополнительных функциях или отдельных исправлениях. Обычно их можно внести в качестве PR (хотя это увеличивает нагрузку по сопровождению и требует времени сопровождающего на разработку, принятие решений и рецензирование кода). Все примеры, которые я перечислил выше, – это то, что вам в первую очередь нужно, чтобы сопровождающий расставил приоритеты в своей собственной дорожной карте.

Как поощрить их к этому и поддержать их в этом? В нынешних моделях Open Source нет хорошего, надежного ответа.

Конечно, есть много способов связаться с мейнтейнером. Публичный трекер проблем, их электронная почта… даже Twitter DMs (пожалуйста, не надо). Я не всегда отвечаю, но я действительно читаю все, что приходит мне на почту. Проблема в том, что бесконечный поток неквалифицированных запросов не очень полезен для принятия решений.

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

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

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

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

Именно это и делают договорные отношения с сопровождающим: они институционализируют отношения высокого доверия и внимания и делают их надежными.

С другой стороны, наличие прямой связи с основными пользователями моего кода ценно для меня как для сопровождающего: Я могу связаться с ними, задать вопросы и узнать, как они его используют. Так ли важен этот компонент, как я думаю? Использует ли кто-нибудь эту функцию? Возможно ли ее устаревание? Каковы болевые точки этой вещи, которую я планирую рефакторить? Сможет ли это новое решение решить реальные проблемы?

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

Эта взаимная ценность, как мне кажется, очень характерна для модели финансирования, которая предполагает прямые отношения с несколькими компаниями. Если в дело вмешивается посредник, канал связи прерывается. Если есть только один финансист, то широкие возможности исследования теряются.

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

Картинка

Викторина: как зовут этого льва?