10.12 Открытый и закрытый исходный код

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

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

Перед сравнением важны два уточнения. Во-первых, «свободный» двусмыслен. Сообщество различает свободу как свободу (вольность изменять и делиться, иногда пишется «libre») и свободу как цену (нулевая цена, «gratis»). Открытый исходный код о свободе, а не обязательно о цене. Во-вторых, лицензии открытого исходного кода делятся на два семейства. Разрешительные лицензии (такие как MIT, BSD и Apache 2.0) позволяют делать почти что угодно, включая встраивание кода в закрытый продукт. Лицензии с копилефтом (такие как Универсальная общественная лицензия GNU, GPL) требуют, чтобы распространяемые вами производные работы также выпускались на тех же открытых условиях, правило взаимности, которое критики порой называют «вирусным», а сторонники «разделяй на тех же условиях».

Эта глава рассматривает выбор с двух сторон. Как потребитель, вы решаете, принимать ли компонент с открытым исходным кодом или проприетарный. Как производитель, вы решаете, открывать ли исходный код программного обеспечения, которое построили. Для больших корпораций и особенно государства оба решения несут вес далеко за пределами файла лицензии. Они касаются закупок (глава 10.3), цифрового суверенитета (глава 10.11), безопасности цепочки поставок (глава 4.2), интероперабельности (глава 3.8) и расчёта «строить или покупать» (глава 6.1).

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

Лицензия, а не цена, определяет «открытое». Читайте лицензию; бесплатное и открытый исходный код разные утверждения.
Ни одна модель не безопаснее по природе. Обе могут быть превосходными или небрежными; практики вокруг кода важнее его открытости.
Открытость рычаг снижения зависимости. Доступ к исходному коду высшая защита от привязки к поставщику.
Операционное бремя всегда на вас. Бесплатное в приобретении никогда не бесплатно в эксплуатации; совокупная стоимость владения рассказывает реальную историю.
Отличительное остаётся закрытым; товарное можно открыть. Открывайте то, что вас не отличает; охраняйте то, что отличает.
У копилефта есть последствия. Поймите обязательства взаимности, прежде чем встраивать код с копилефтом в продукт, который вы распространяете.
Живое сообщество актив; заброшенный репозиторий обязательство. Судите проект, а не только лицензию.

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

Измерение	Открытый исходный код	Закрытый / проприетарный
Цена приобретения	Обычно ноль	Лицензионный платёж или подписка
Совокупная стоимость владения	Цена смещается на эксплуатацию и персонал	Более предсказуема, но премия за привязку
Контроль и настройка	Полные: можно читать и менять исходный код	Ограничены тем, что открывает поставщик
Поддержка и подотчётность	Сообщество или платная третья сторона; нет единого ответственного	Договорная поддержка и ясная подотчётная сторона
Позиция безопасности	Проверяемо; «много глаз», если действительно сопровождается	Управляется поставщиком; непрозрачно; неясность не защита
Долговечность / заброшенность	Можно форкнуть, если сопровождается; всё равно может зачахнуть	Зависит от жизнеспособности поставщика и дорожной карты
Привязка к поставщику	Низкая: исходный код и открытые форматы позволяют выход	Высокая, пока не смягчена стандартами и депонированием
Экосистема	Открытое сообщество и интероперабельность	Курируемая, интегрированная, порой огороженная

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

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

Принуждаем ли мы политику лицензий с автоматическим SCA и SBOM в конвейере, особенно чтобы поймать сильный копилефт до отгрузки? Встраивание библиотеки GPL в распространяемый проприетарный продукт может обязать вас выпустить собственный исходный код, и этот сюрприз обычно всплывает поздно, когда его дорого раскручивать. Ведите опись каждого компонента и его лицензии, принуждайте, какие семейства лицензий приемлемы для каких использований, и запускайте анализ состава программного обеспечения автоматически, чтобы конвейер блокировал нарушения, а не юрист ловил их к моменту отгрузки. Генерируйте SBOM как само собой разумеющееся. Для большого или государственного хозяйства это также гигиена цепочки поставок и нередко требование закупок. Принесите вашу текущую опись лицензий или факт, что её у вас нет, и решите, кто владеет политикой.
Когда мы принимаем зависимость, оцениваем ли мы здоровье проекта и фактор автобуса как должную осмотрительность? Библиотека с открытым исходным кодом с одним сопровождающим и небольшой проприетарный поставщик несут один и тот же риск: проект рушится, если уходят один или несколько ключевых людей. Прежде чем принимать что-либо, оцените ритм выпусков, число и разнообразие сопровождающих, отзывчивость на сообщения о безопасности и широту принятия и запишите оценку. Ни одна модель не безопаснее по умолчанию; «много глаз» помогает, только если квалифицированные люди действительно смотрят, а многие широко используемые проекты скудно сопровождаются. Принесите три-четыре зависимости, на которых ваш продукт держится больше всего, и спросите для каждой, сколько человек должно уйти, прежде чем это станет вашей проблемой. Если вы не можете ответить, это оценка, которую вы должны себе.
Когда мы покупаем проприетарное, обеспечиваем ли мы защиты выхода заранее? Проприетарное программное обеспечение предлагает подотчётность и удобство в обмен на контроль, а скрытая цена привязка: цены переключения, позволяющие поставщику поднять цены или ухудшить обслуживание почти без средства защиты. Договаривайтесь о защитах до подписания, пока у вас ещё есть рычаг: экспорт данных в открытых форматах, документированные API и депонирование исходного кода, выдающее исходный код, если поставщик откажет. С открытым исходным кодом ваш выход способность форкнуть; с проприетарным выход нужно вписать в контракт. Принесите ваши самые критичные проприетарные системы и спросите, что на самом деле случится, если поставщик удвоит цену или обанкротится. Если ответ «мы застряли», исправьте контракт при продлении.
Для программного обеспечения, которое мы строим сами, как мы решаем, что открывать, а что держать закрытым, и у кого полномочия принимать это решение? Ошибитесь в одну сторону, и вы отдадите именно тот код, что вас отличает; ошибитесь в другую, и вы копите товарную сантехнику, чьё сопровождение сообщество охотно разделило бы. Конкурирующие давления реальны: инженеры хотят плюса найма и репутации публичного репозитория, а продукт и юристы опасаются дать соперникам преимущество или раскрыть чувствительную к безопасности эвристику. Принесите честную классификацию ваших систем на отличающие миссию и неотличительную инфраструктуру и назовите человека или совет, подписывающий выпуск, потому что стихийное решение того, кто запушил репозиторий, то, как утекают жемчужины короны. Для большой корпорации это вопрос стратегии портфеля, а для государства он сталкивается с «общественные деньги, общественный код», принципом, что программное обеспечение на деньги налогоплательщиков должно быть по умолчанию публичным, поэтому решите заранее, какие исключения (национальная безопасность, обнаружение мошенничества, персональные данные) оправдывают держание кода закрытым.
Охватывают ли наши сравнения «строить или покупать» полную совокупную стоимость владения или мы всё ещё воспринимаем нулевую лицензию как нулевую цену? Самая частая финансовая ошибка с открытым исходным кодом чтение «бесплатно в приобретении» как «бесплатно в эксплуатации» с последующим обнаружением того, что интеграция, эксплуатация, реагирование на безопасность и платная поддержка затмевают любую избегнутую лицензию. Напряжение в том, что проприетарная подписка выглядит дорого в счёте, скрывая премию за привязку, а открытый компонент выглядит бесплатным в счёте, смещая цену на ваш собственный персонал. Принесите сопоставимую модель TCO для двух-трёх реальных решений: приобретение, интеграция, эксплуатация, поддержка, обучение, обновления, реагирование на безопасность и в итоге замена, оценённые на всей жизни, а не первом годе. В корпоративном или государственном хозяйстве добавьте цену самой операционной модели, поскольку самостоятельно поддерживаемый открытый исходный код требует внутренних навыков, которые нужно нанять и удержать, и воспринимайте сравнение, опускающее эти строки, как свидетельство, а не анализ.
Судим ли мы безопасность компонента по его практикам или опираемся на ярлык открытости, будь то «много глаз» или секретность закрытого кода? Оба умолчания ловушки: «много глаз» защищает, только когда квалифицированные люди действительно рецензируют код, а многие широко используемые открытые проекты держатся на одном измотанном сопровождающем, тогда как закрытый код, рассчитывающий на то, что атакующие его не увидят, безопасность через неясность, а не средство контроля. Спор важен, потому что меняет, куда вы тратите дефицитные усилия по безопасности, и честный ответ в том, что обе модели несут риск цепочки поставок, открытый исходный код через скомпрометированные или заброшенные зависимости, а проприетарный через непрозрачные каналы обновлений, которые вы не можете проверить. Принесите свидетельства для ваших самых критичных компонентов: кто их действительно рецензирует, как быстро исправляются бюллетени, закреплены ли версии и проверено ли происхождение и генерируете ли вы SBOM. Для большого или государственного хозяйства привяжите это к закупкам и обязательствам непрерывного сканирования, потому что регулятор спросит, что вы проверили, а не был ли исходный код публичным.

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

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

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

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

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

Примеры

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

Крупная организация. Крупный страховщик ведёт основную платформу на основаниях с открытым исходным кодом: Linux, широко используемая база данных с открытым исходным кодом и оркестратор контейнеров. Но он покупает проприетарный набор актуарного моделирования, потому что предметная экспертиза поставщика, регуляторные сертификации и контракт поддержки стоят платежа, а сопоставимой открытой альтернативы нет. Он платит подписку за коммерческий открытый исходный код (поддерживаемые поставщиком дистрибутивы открытых компонентов), чтобы получить подотчётность и исправления на сантехнику, держа алгоритм ценообразования, который его отличает, строго проприетарным и внутренним. Анализ TCO (глава 10.10) двигает каждый выбор, а не идеология.

Государственный сектор. Национальное налоговое ведомство по политике «общественные деньги, общественный код» строит новый сервис определения права на пособия на компонентах с открытым исходным кодом и открытых стандартах (глава 3.8), чтобы другие ведомства могли использовать его повторно, а граждане проверять правила. Оно публикует неконфиденциальный код в публичном репозитории, оставляя закрытыми по соображениям безопасности только эвристики обнаружения мошенничества. Это снижает привязку к поставщику и продвигает цифровой суверенитет (глава 10.11). Правила закупок (глава 10.3) требуют от любого проприетарного компонента предоставления экспорта данных в открытых форматах и депонирования исходного кода, чтобы гарантировать непрерывность, если поставщик откажет.

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

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

Бизнес-обоснование проприетарного программного обеспечения подотчётность и удобство: единый поставщик, отвечающий за продукт, контракт поддержки, который можно принудить, интегрированные функции и предсказуемое бюджетирование. Его скрытая цена привязка, цены переключения, позволяющие поставщику поднять цены или ухудшить обслуживание почти без средства защиты, плюс зависимость от платёжеспособности поставщика и его дорожной карты. Распространённые бизнес-модели размывают линию: открытое ядро (открытая основа с проприетарными платными дополнениями), двойное лицензирование (тот же код предлагается и по копилефт-лицензии, и по платной коммерческой), программное обеспечение как услуга (SaaS) (программное обеспечение работает как размещённый сервис, который вы арендуете, где исходный код может быть неважен, потому что вы никогда не владеете бинарным файлом) и модели поддержки/подписки, продающие сервис вокруг иначе свободного кода.

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

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

«Свободно значит бесплатно»: воспринимание нулевой цены приобретения как нулевого TCO с последующим недофинансированием эксплуатации и поддержки.
Слепота к лицензиям: встраивание кода с сильным копилефтом в распространяемый проприетарный продукт и запуск обязательств, которых вы никогда не планировали.
Вера в «много глаз»: предположение, что открытый проект проверен, когда у него один перегруженный сопровождающий и нет рецензии безопасности.
Безопасность через неясность: вера, что закрытый исходный код безопасен просто потому, что атакующие не могут его прочесть.
Идеологический абсолютизм: предписание «всё открытое» или «всё проприетарное» вместо выбора по компоненту по достоинствам и TCO.
Игнорирование происхождения: подтягивание зависимостей без SBOM, закрепления версий или проверки цепочки поставок (глава 4.2).
Открытие жемчужин короны: выпуск именно того кода, что вас отличает, с отдачей вашего преимущества.
Форкни и забудь: форк заброшенного проекта без возможности действительно сопровождать форк.

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

Уровень 1 (Начальный). Компоненты с открытым исходным кодом и проприетарные входят в хозяйство стихийно. Лицензии не читаются, нет описи или SBOM, а выбор между моделями делается по привычке или одной цене. Заброшенность и риск лицензий всплывают, только когда что-то ломается, и каждая команда реагирует сама.

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

Уровень 3 (Стандартизация). Документированная рамка управляет и потреблением, и производством по организации. Компоненты выбираются по TCO и здоровью проекта, лицензии принуждаются автоматически в конвейере, так что нарушения блокируют сборку, SBOM генерируются само собой, а явная политика говорит, что организация открывает против того, что держит закрытым. Защиты выхода вроде открытых форматов и депонирования исходного кода стандарт в закупках, и каждая команда следует одним правилам, а не собственным.

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

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

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

Где в вашем хозяйстве потеря единственного поставщика или сопровождающего была бы экзистенциальной и каков ваш план выхода?
Какие из ваших собственных систем товарные, которые вы могли бы открыть, а какие подлинные отличия для защиты?
Воспринимает ли ваша организация «много глаз» как реальное средство контроля безопасности или непроверенное допущение?
Для читателей государственного сектора: что изменило бы умолчание «общественные деньги, общественный код» в вашей следующей закупке?
Насколько хорошо ваши сравнения TCO охватывают операционные цены и цены поддержки, которые открытый исходный код смещает на вас?

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

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

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

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft and others, various O’Reilly titles on open-source strategy and operations
Free Software Foundation, The Free Software Definition (and the GNU General Public Licence texts)
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
Yochai Benkler, The Wealth of Networks

10.12 Открытый и закрытый исходный код

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

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

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

Оценивайте компонент по проекту, а не только лицензии

Читайте и отслеживайте лицензии как первоклассное обязательство

Судите безопасность по практике, а не открытости

Проектируйте выход и интероперабельность

Взвешивайте совокупную стоимость владения, а не цену на ценнике

Как производитель, открывайте то, что вас не отличает