10.18 Офис программы открытого исходного кода (OSPO) и вклад вверх по течению

Обзор и мотивация

Ваша организация уже работает на программном обеспечении с открытым исходным кодом: операционные системы, языки, базы данных и библиотеки, несущие ваш продукт, в основном написаны людьми, которые на вас не работают. Глава 10.3 охватывает закупки и соответствие лицензиям, а глава 10.12 решение «открытое против закрытого». Эта глава о функции, делающей всё это связным: офисе программы открытого исходного кода (OSPO), команде, владеющей тем, как компания потребляет открытый исходный код, вносит в него вклад и выпускает его. OSPO центр тяжести для отношений, которые иначе размазаны по каждому инженеру, набирающему import.

Большинство организаций приходят к открытому исходному коду задом наперёд, по одной зависимости, а затем обнаруживают накопленную экспозицию разом: вопрос о лицензии во время должной осмотрительности при поглощении, критичная библиотека с одним измотанным сопровождающим, бюллетень безопасности по коду, о котором никто не знал, что отгружает. OSPO превращает эту суету в управляемую возможность. Он задаёт политику потребления, которая позволяет, а не блокирует, решает, когда вклад вверх по течению служит бизнесу, опекает проекты, что вы выпускаете, и применяет открытое сотрудничество внутри компании через InnerSource. Это стратегическая функция, связанная с вашими ценностями программной инженерии (глава 1.1), а не галочка соответствия.

Для корпораций двигатель масштаб: тысячи зависимостей, экспортные и лицензионные обязательства по юрисдикциям и сотни инженеров, каждый из которых ежедневно принимает малые решения об открытом исходном коде. Единый офис даёт этому разрастанию хребет. Для государства двигатель политика и общественное доверие. «Открытый исходный код по умолчанию» и «общественные деньги, общественный код» всё чаще закон, поэтому государственным органам нужен кто-то, способный безопасно публиковать код, повторно использовать его между ведомствами и держать поставщиков на открытых стандартах. В обоих условиях OSPO окупает себя, превращая невидимый неоценённый риск в намеренную бюджетированную работу.

Ключевые принципы

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

Рекомендации

Поднимите OSPO соразмерно вашей реальности

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

Потребляйте ответственно и делайте безопасный путь лёгким путём

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

Вносите вклад вверх по течению, потому что это окупается, а не потому что это мило

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

Выпускайте собственные проекты с настоящим управлением

Когда вы открываете исходный код программного обеспечения, которое построили, делайте это намеренно или не делайте вовсе. Сначала решите, является ли код товаром, стоящим того, чтобы им делиться, или отличием, которое стоит держать закрытым, используя рассуждение главы 10.12. Если выпускаете, выберите лицензию, соответствующую вашему намерению (разрешительную для максимизации принятия, копилефт для сохранения экосистемы взаимной), документируйте, кто что решает, через письменную модель управления, и зарегистрируйте торговую марку на название проекта, чтобы защитить его от злоупотребления, сохраняя код свободным. Обязуйтесь к настоящему стюардству: публичный трекер заявок, руководство по вкладу, кодекс поведения и политика безопасности с координированным раскрытием, чтобы сообщающие знали, как до вас дотянуться (глава 4.2). Назовите сопровождающего и заложите в бюджет его время. Проект, запущенный с помпой и заброшенный через год, вредит вашей репутации больше, чем тот, что вы никогда не выпускали.

Применяйте InnerSource для сотрудничества внутри компании

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

Финансируйте и поддерживайте сопровождающих, от которых вы зависите

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

Задайте политику вклада, одобряющую быстро

Политика вклада существует, чтобы быстро говорить «да», а не медленно говорить «нет». Распишите, что инженер может внести, не спрашивая (исправления ошибок, документация, небольшие функции в проекты, которыми вы уже пользуетесь), что требует лёгкой проверки (всё, касающееся отличия или патента) и как интеллектуальная собственность и соглашения участников обрабатываются один раз, централизованно, а не для каждого вклада. Автоматизируйте скучные части: проверки лицензий, заранее подписанное корпоративное соглашение участника и бот, помечающий редкую заявку, нуждающуюся в человеческих глазах. Измеряйте время до одобрения и воспринимайте медленную очередь как ошибку в политике.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Центральный OSPO	Согласованная политика, глубокая экспертиза, ясное владение	Может стать узким местом, если только блокирует и никогда не обеспечивает
Федеративный OSPO (чемпионы в командах)	Масштабируется, держит решения близко к инженерам	Нужна сильная координация, иначе политика расходится
Вклад вверх по течению	Удаляет налог частных патчей, покупает влияние, помогает найму	Постоянные усилия, рецензия ИС, работа по чужому графику
Несение частных форков	Полный контроль, отгрузка по вашему графику	Постоянный налог на сопровождение, отрыв от исправлений безопасности вверх по течению
Выпуск собственного проекта	Экосистема, репутация, общее сопровождение	Реальная цена стюардства; заброшенность вредит репутации
Финансирование сопровождающих	Защищает критичные зависимости, покупает добрую волю	Прямая цена, а выбор того, кого финансировать, политичен
Нет OSPO (стихийно)	Нулевая цена настройки	Невидимый юридический долг, долг безопасности и устойчивости

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

Вопросы для обсуждения с командой

Кто владеет вашими отношениями с открытым исходным кодом сегодня и мог бы он ответить на трудный вопрос завтра? Если бы юристы потенциального покупателя попросили опись ваших лицензий или журналист спросил, какая несопровождаемая библиотека сидит на вашем платёжном пути, есть ли у ответа имя? Для большинства организаций честный ответ «никого», а значит каждый инженер тихо задаёт политику, и никто не подотчётен за сумму. Принесите на совещание свидетельства: попробуйте представить список одобренных лицензий, перечень компонентов программного обеспечения и человека, который отвечал бы на вопрос о копилефте во время должной осмотрительности. Если этих артефактов нет или они указывают на никого, вы нашли первую задачу OSPO. Решение не в том, иметь ли функцию, а в том, кто ею владеет и какой мандат несёт, пусть даже офис один человек на один день в неделю.
Несёте ли вы частные патчи, которые могли бы передать вверх по течению, и чего это вам стоит? Многие команды ведут тихую груду локальных изменений против зависимостей, вручную применяя их заново при каждом обновлении и поглощая боль слияния, словно закон природы. Каждый из этих патчей повторяющийся налог, и каждый кандидат на вклад обратно, чтобы налог исчез. Принесите детали: перечислите форки и локальные патчи, что ваша сборка действительно несёт, оцените инженерные часы, которые каждый стоит в год, и отметьте, какие проекты вверх по течению вероятно приняли бы изменение. Конкурирующее соображение реально, поскольку передача вверх по течению стоит усилий сейчас и идёт по графику сопровождающего, но сравнение с вечной оплатой налога на патчи. Ответ должен превратить «мы всегда просто применяем заново» в намеренный выбор, с путём вклада достаточно быстрым, чтобы инженеры им пользовались.
Какая зависимость больнее всего ударила бы, если бы её сопровождающий ушёл, и что вы с этим сделаете? Где-то в вашем стеке компонент, чья поломка остановила бы приносящий выручку или критичный для миссии сервис, сопровождаемый человеком или горсткой людей, которых вы никогда не финансировали и не благодарили. Общее кажется бесплатным вплоть до момента, когда перестаёт, и дорогая версия этого урока суета после заброшенности или неисправленная уязвимость. Принесите ваш перечень компонентов и ранжируйте зависимости по радиусу поражения, затем отметьте число сопровождающих и состояние финансирования нескольких верхних. Для каждой критичной тонко укомплектованной решите заранее, будете ли вы спонсировать, вносить время, вступать в фонд или готовиться заменить. Это превращает скрытую единую точку отказа в управляемые отношения, на том же стандарте, что и любой другой операционный риск (глава 2.18).
Прежде чем открывать исходный код следующего внутреннего инструмента, готовы ли вы опекать его годами или отгружаете запуск и последующее извинение? Публичный выпуск постоянное обязательство: трекер заявок, который кто-то должен сортировать, ящик безопасности, за которым кто-то должен следить, и имя, которое кто-то должен защищать. Команды тянутся к открытию исходного кода ради найма или доброй воли, а затем обнаруживают, что заброшенный проект с устаревшими заявками вредит репутации, которую они надеялись построить, сильнее, чем отгрузка ничего. Принесите свидетельства: перечислите проекты, которые вы уже выпустили, и для каждого покажите возраст открытых заявок, есть ли названный сопровождающий с бюджетированными часами, есть ли модель управления, зарегистрированная торговая марка и политика координированного раскрытия и является ли код товаром, стоящим обмена, или отличием, которое стоит держать закрытым (глава 10.12). Конкурирующее соображение в том, что настоящее стюардство стоит инженерного времени, которое можно было бы потратить на продукт, поэтому честный выбор нередко выпускать меньше и опекать должным образом. Для корпорации это значит юридическую и брендовую рецензию до запуска; для государства это значит, что торговая марка, канал раскрытия и процесс исключений из публикации по умолчанию урегулированы до того, как репозиторий станет публичным.
Сколько времени на самом деле занимает у инженера одобрение зависимости или очистка вклада и не медленнее ли это обхода вас? Политика открытого исходного кода напрямую конкурирует с самым быстрым обходным путём, что инженер может найти, а любой процесс медленнее копирования кода обходится, порождая невидимые теневые зависимости, что офис призван был предотвратить. Напряжение между контролем и обеспечением: каждая ручная рецензия добавляет след аудита и ловит редкую настоящую проблему, но также добавляет задержку, выталкивающую медианный случай с соответствующего пути. Принесите на совещание числа: измеренное время до одобрения для стандартной зависимости и стандартного вклада, долю решений, обрабатываемых автоматически против человеком, и число исключений, которые действительно нуждались в суждении за последний квартал. В корпорации с сотнями инженеров, каждый из которых ежедневно принимает малые решения, двухдневная очередь тихо превращается в тысячи обойдённых рецензий; в государстве та же задержка сталкивается с обязательствами закупок и аудита, требующими след бумаг, который обходной путь пропускает, поэтому исправление в автоматизации обычного случая, а не в комплектовании большего барьера.
Какие внутренние проекты больше всего выиграли бы от InnerSource и что мешает другой команде отправить вам запрос на слияние сегодня? Практики, заставляющие работать открытый исходный код (публичные репозитории, руководства по вкладу, рецензия по достоинствам, низкий барьер для первого патча), окупаются за брандмауэром, ломая силосы, распространяя повторное использование и обучая людей именно тому рабочему процессу, что они будут использовать для вклада вовне. Конкурирующее соображение в том, что открытие внутреннего проекта требует руководства по вкладу, свободной мощности рецензии и решения о том, какой код должен остаться ограниченным по соображениям безопасности или регулирования. Принесите детали: назовите высокоценные общие библиотеки, отметьте, какие уже публикуют внутреннее руководство по вкладу, и опишите, как сегодня обрабатывается межкомандный запрос на слияние, приветствуется или теряется в очереди. Для корпорации отдача измеряется избегнутыми дублированными внутренними построениями по многим командам; для государства та же привычка простирается через границы ведомств как межведомственное повторное использование, так что публикация по умолчанию и общие компоненты сокращают дублированные общественные расходы, а не умножают их.

Взгляд по секторам

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

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

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

Государственный сектор. Работайте по «открытому исходному коду по умолчанию» и «общественным деньгам, общественному коду»: публикуйте новые услуги в публичном репозитории, если не применяется документированное исключение по безопасности или приватности. Ведите межведомственный каталог, чтобы команды использовали повторно, прежде чем строить, вписывайте требования открытого исходного кода и открытых стандартов в закупки, чтобы поставщики поставляли повторно используемый код с сохранением прав, и обрабатывайте координированное раскрытие для того, что публикуете. Финансируйте сопровождение общих библиотек, от которых зависят несколько ведомств, чтобы ни одна команда молча не владела инфраструктурой, на которую полагается всё правительство.

Примеры

Стартап. Стартап из двадцати человек делает ведущего платформенного инженера владельцем OSPO на неполный день с уставом на одной странице. Она задаёт простую политику потребления (разрешительные лицензии предварительно одобрены, копилефт рецензируется, сканер в конвейере) и замечает, что команда несёт три частных патча против библиотеки очередей с открытым исходным кодом, мучительно применяемых заново при каждом обновлении. Она передаёт все три вверх по течению; два принимаются в течение месяца, навсегда удаляя налог обновления. Она открывает один малый внутренний инструмент с настоящим README, лицензией и контактом безопасности, в основном чтобы привлечь инженеров, и заводит ежемесячное спонсорство для разборщика с единственным сопровождающим, от которого зависит продукт. Ничего из этого не требует штата, только названного владельца и ясного мандата.

Крупная организация. Глобальный банк ведёт центральный OSPO из шести человек плюс федеративную сеть чемпионов открытого исходного кода, встроенных в каждую продуктовую группу. Центральная команда владеет политикой, автоматическим сканированием лицензий и экспортного соответствия и лицензионным соглашением участника, покрывающим каждого инженера с первого дня. Чемпионы ведут местную рецензию и наставляют свои команды по вкладу. Банк финансирует несколько фондов, чьи проекты лежат в основе его торговых систем, передаёт исправления вверх по течению в широко используемый фреймворк данных, чтобы перестать сопровождать форк, и ведёт InnerSource по двумстам внутренним репозиториям, так что любая команда может отправить запрос на слияние любой другой. Время до одобрения стандартного вклада менее двух дней, отслеживаемая метрика, которую OSPO сообщает ежеквартально.

Государственный сектор. Национальное цифровое агентство работает по мандату «открытый исходный код по умолчанию» и «общественные деньги, общественный код». Его OSPO публикует новые услуги в публичном репозитории, если не применяется документированное исключение по безопасности или приватности, ведёт межправительственный каталог, чтобы ведомства использовали код повторно, прежде чем строить его, и вписывает требования открытого исходного кода и открытых стандартов в закупки, чтобы поставщики поставляли повторно используемый хорошо документированный код с сохранением государством прав. Офис также обрабатывает координированное раскрытие безопасности для публикуемого кода и финансирует сопровождение общей библиотеки идентификации, от которой теперь зависят несколько ведомств, так что ни одна команда не владеет молча компонентом, на который полагается всё правительство.

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

OSPO как врата. Офис, который только рецензирует и блокирует, никогда не обеспечивая, обходится, порождая теневые зависимости, что он призван был предотвратить.
Театр вклада. Объявление стратегии открытого исходного кода при том, что процесс одобрения столь медленен, что никто на самом деле не вносит вклад.
Заброшенный выпуск. Публикация проекта с запускным блогом, затем никогда не сортировка заявок, вредящая репутации больше молчания.
Форкни и забудь. Форк зависимости ради одного исправления с последующим несением его вечно, отрываясь от исправлений безопасности вверх по течению.
Безбилетничество на хрупких сопровождающих. Зависимость от критичной библиотеки с единственным сопровождающим при том, что человека за ней никогда не финансируют, не благодарят и не помогают.
Пренебрежение торговой маркой. Выпуск проекта без защиты его названия с последующим наблюдением, как форк или поставщик торгует вашей репутацией.
Владение только юристов. Размещение OSPO целиком в юристах, так что его руководство не имеет инженерного авторитета, и команды его отключают.
Метрики тщеславия. Подсчёт звёзд и упоминаний в прессе вместо здоровья зависимостей, времени до одобрения и выведенных частных патчей.

Модель зрелости

Уровень 1, Начальный: Инженеры добавляют, патчат и порой публикуют открытый исходный код без политики и владельца. Потребление, вклад и выпуск реактивны и стихийны, движимы личной инициативой. Частные форки накапливаются незаметно, никто не финансирует ни один проект вверх по течению, и никто не мог бы ответить на вопрос о лицензии во время должной осмотрительности.
Уровень 2, Развитие: Появляются базовые практики, различающиеся по командам. Существуют грубая политика потребления и список одобренных лицензий, и кто-то свободно ответственен, но вклад медленный и от случая к случаю, а некоторые группы делают гораздо больше других. Несколько критичных зависимостей известны, но устойчивость, выпуски и стюардство остаются непоследовательными.
Уровень 3, Стандартизация: Учреждённый OSPO владеет потреблением, вкладом, выпуском и сообществом, а практики документированы и принуждаются по организации. Сканирование и перечень компонентов программного обеспечения автоматизированы, существуют предварительно очищенное соглашение участника и быстрый путь одобрения, выпущенные проекты несут настоящее управление, торговые марки и политики безопасности, а InnerSource распространяется. Государственные команды публикуют по умолчанию.
Уровень 4, Управление: Функция открытого исходного кода измеряется и контролируется относительно базовых значений. Время до одобрения отслеживается относительно цели, сообщаются объём вклада и доля принятия вверх по течению, панели здоровья зависимостей и числа сопровождающих помечают единые точки отказа, мониторится покрытие финансированными сопровождающими самых рискованных зависимостей, а опись частных патчей и форков тренд вниз квартал за кварталом. У выпущенных проектов измеряется время реакции на заявки, исключения рецензируются по ритму, а метрики тщеславия вроде звёзд отброшены в пользу этих.
Уровень 5, Оркестрация: Открытый исходный код управляемая стратегическая возможность, интегрированная с планированием инженерии, юристов, безопасности и закупок и адаптируемая непрерывно. Вклад рутинен, критичные сопровождающие и фонды финансируются, организация опекает хорошо ведомые проекты и направляет экосистемы, от которых зависит, а InnerSource норма. Метрики вовлечённости и здоровья питают непрерывное улучшение, а портфель перебалансируется по мере сдвигов зависимостей, рисков и мандатов.

Идеи для обсуждения

Где линия между OSPO, который обеспечивает, и тем, который блокирует, и как вы узнали бы снаружи, какой из них построили?
Какие из ваших частных патчей или форков вы несёте по привычке, а не необходимости и что потребовалось бы, чтобы передать три верхних вверх по течению?
Как решить, каких сопровождающих и фонды финансировать, когда список критичных зависимостей длиннее бюджета?
Что действительно изменилось бы в вашем следующем выпуске, если бы пришлось опубликовать его с настоящим управлением, торговой маркой и политикой координированного раскрытия с первого дня?
Для читателей государственного сектора: каков защитимый процесс освобождения кода от публикации по умолчанию, не разъедая тихо принцип?
Какие внутренние библиотеки больше всего выиграли бы от InnerSource и что мешает другой команде отправить вам запрос на слияние сегодня?

Главные выводы

OSPO владеет всеми отношениями с открытым исходным кодом: ответственным потреблением, вкладом вверх по течению, выпуском собственных проектов и поддержкой сопровождающих, от которых вы зависите.
Вклад вверх по течению стратегия, а не благотворительность; он удаляет повторяющийся налог частных патчей, покупает влияние на направление и помогает нанимать.
Делайте соответствующий путь самым быстрым через автоматизацию и кураторство, чтобы офис обеспечивал инженеров, а не охранял врата.
Выпускайте свои проекты только с настоящим управлением, выбранной лицензией, защищённой торговой маркой и координированным раскрытием безопасности или не выпускайте вовсе.
Финансируйте и помогайте критичным сопровождающим, на которых держится ваша производственная система, потому что общее не самоподдерживается.
Применяйте InnerSource, чтобы принести сотрудничество открытого исходного кода внутрь компании, а в государстве по умолчанию открытое, публикация по умолчанию и повторное использование до построения.

Источники и дополнительное чтение

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance