Docker спонсировал этот пост. Insight Partners является инвестором Docker и TNS.
Последствия того, что Bitnami прекратила свою программу поддержки библиотеки популярных контейнеров с открытым исходным кодом и удалила свои популярные диаграммы Helm для этих контейнеров, заставили многие команды задаться вопросом, когда появится следующая версия программного обеспечения с открытым исходным кодом. Решение Bitnami вызвало серьезный сбой, вынудив Cloud Native Computing Foundation (CNCF) опубликовать сообщение в блоге, в котором отмечалось, что действия Bitnami не повлияли на статус открытого исходного кода проекта Helm.
Решение Bitnami — лишь последний крупный пример изменений в доступности, упаковке и лицензировании открытого исходного кода, влияющих на непрерывность бизнеса пользователей. Elastic, HashiCorp, Redis, Linkerd и Red Hat внесли изменения, которые заставили команды пересмотреть использование компонентов с открытым исходным кодом.
Эпизод с Битнами — еще одно напоминание о том, что программное обеспечение с открытым исходным кодом больше похоже на бесплатного щенка, чем на бесплатное пиво. Стоимость владения значительна, и ее не следует игнорировать.
Каждой организации, платформе и команде безопасности необходимо не только следить за тем, чтобы их сканеры работали, а процесс обеспечения безопасности приложений был надежен. Им также необходимо просмотреть каждый контейнер с открытым исходным кодом, который они используют, узнать, кто его обслуживает и насколько они доверяют этой организации в продолжении его поддержки. Это также верно для всех пакетов с открытым исходным кодом. И это все строго бизнес.
Все это не означает, что у компаний, внесших эти изменения, не было деловых причин. Но в каждом случае пользователям приходилось реагировать и меняться. Нравится нам это или нет, но каждый компонент с открытым исходным кодом следует рассматривать через призму непрерывности бизнеса.
Миф о доброй воле экосистемы с открытым исходным кодом
В мире открытого исходного кода существует устойчивый миф о том, что тысячи проектов поддерживаются исключительно благодаря доброй воле увлеченных разработчиков, вносящих свой вклад в свое свободное время. В редких случаях этот миф правдив.
Есть некоторые разработчики с открытым исходным кодом, поддерживающие важные проекты. В основном они поддерживают меньшие пакеты или библиотеки, а не полноценные продукты. Аналогичная иллюзия существовала и для организаций, создающих важные артефакты с открытым исходным кодом, такие как официальные образы контейнеров или пакеты. Станьте свидетелем того, что произошло с Битнами.
Проверка реальности. Практически за каждым значительным проектом или артефактом с открытым исходным кодом стоит компания или фонд. Кто-то финансирует разработку. Кто-то делает инвестиции. И что кто-то ждет отдачи.
В тех редких случаях, когда отдачи не ожидается, отдельный разработчик или небольшая команда создают что-то интересное, но идут по непростому пути. Они могут сгореть или отказаться от проекта. Или, как одиночному разработчику, им может не хватать пропускной способности для принятия мер безопасности, которые могли бы быть в более надежной организации.
В конце концов, как бы нам не хотелось это говорить, открытый исходный код — это вопрос экономики, будь то для бизнеса или для частного лица. Если больше нет смысла поддерживать и поддерживать, тогда всем будет больно.
Необходимость выходить за рамки обычных показателей
Когда инженеры оценивают технологию с открытым исходным кодом, они обычно сосредотачиваются на самой технологии. Они смотрят на социальные сигналы, такие как звезды GitHub, форки, запросы на включение, силу сообщества, качество кода и набор функций.
Будем надеяться, что они также обратят внимание на то, сколько сопровождающих у проекта, кто эти сопровождающие, где они работают, является ли программное обеспечение частью фонда и каковы условия лицензирования. Эти факторы имеют значение, но их недостаточно для принятия правильного бизнес-решения о том, от чего следует зависеть.
Чего не хватает? Оценка компании, организации или отдельных лиц, стоящих за проектом. А именно, очень важно задаться вопросом: кто финансирует разработку? Это отдельная компания, консорциум, фонд с разнообразной поддержкой или просто волонтеры? Если это компания, является ли эта компания хорошо финансируемой и стабильной? Как бизнес зарабатывает деньги?
Если проект с открытым исходным кодом, от которого вы зависите, не вносит прямого вклада в модель дохода компании-спонсора, это красный флаг. Когда экономические условия ужесточаются или меняется стратегия, проекты, не приносящие дохода, первыми подвергаются агрессивному сокращению или монетизации. Какова модель управления? Контролирует ли одна компания все ключи? Есть ли несколько организаций, внесших значимый вклад? Можно ли легко разветвить проект и поддерживать его, если основной спонсор уйдет?
Например, изменения в Битнами не должны были удивлять тех, кто обращает внимание на основы бизнеса. Когда Broadcom приобрела VMware и впоследствии изменила способ распространения Bitnami, об этом уже было известно. Посмотрите, как Broadcom зарабатывает деньги. Посмотрите на его историю с приобретениями. Движение по ограничению того, что было «бесплатным», было вполне предсказуемым.
Тревожный звонок Bitnami: зависимости на всем пути вниз
Контейнеры Bitnami и диаграммы Helm — это лишь верхний уровень риска. Каждый проект с открытым исходным кодом зависит от десятков или сотен других проектов с открытым исходным кодом. У каждого из них своя бизнес-модель, источник финансирования и профиль риска. Риск усугубляется на каждом уровне.
Рассмотрим зависимости, о которых большинство команд даже не задумывается. Ваше приложение использует популярный веб-фреймворк. Эта структура зависит от конкретной библиотеки SSL. Эта библиотека почти полностью поддерживается инженерами одной крупной технологической компании. Что произойдет, если эта компания изменит приоритеты? Что произойдет, если существует критическая уязвимость, и никто ее не обслуживает?
Этот риск каскадных зависимостей означает, что вы не можете просто оценить компоненты с открытым исходным кодом верхнего уровня, которые вы используете непосредственно. Вам нужно понять, что находится под ними, и что под этим. Это полностью черепахи, и большинство организаций не имеют представления о большинстве этих черепах.
Как принимать лучшие решения
Эпоха внедрения открытого исходного кода без глубокого размышления о непрерывности бизнеса закончилась. Вот что необходимо изменить в подходе организаций к открытому исходному коду.
- Оценка рисков должна включать анализ бизнес-модели. Прежде чем внедрять какой-либо значительный компонент с открытым исходным кодом, командам необходимо ответить на эти вопросы. Стоит ли за этим устойчивый бизнес? Как этот бизнес приносит деньги? Что произойдет, если этот бизнес потерпит неудачу или изменит направление?
- Видимость цепочки поставок становится критически важной. Организациям нужны инструменты и процессы, чтобы понять свое полное дерево зависимостей, а не только их прямые зависимости. Им необходимо знать, кто обслуживает каждый компонент, и оценивать риски на каждом уровне.
- Лицензирование должно быть тщательно изучено. Юристы и инженеры должны работать вместе, чтобы понять, что лицензии разрешают, а что ограничивают. Речь идет не только о соблюдении требований. Речь идет о том, чтобы у вас была свобода действовать, если основной сопровождающий исчезнет или изменит условия.
- Имейте стратегию устойчивости. Что касается действительно критически важных компонентов, организациям необходимо подумать о своей способности самостоятельно создавать и поддерживать код, если это необходимо. Это может означать участие в проектах, от которых вы зависите, поддержание отношений с другими пользователями той же технологии или сохранение собственного опыта.
- Диверсифицируйте зависимости. По возможности избегайте единых точек отказа в вашем технологическом стеке. Если вы полностью зависите от предложений одной компании с открытым исходным кодом по нескольким компонентам, вы рискуете, если стратегия этой компании изменится. Ищите альтернативы и будьте готовы их использовать.
- Полагайтесь на защищенные изображения, где это возможно.. Поставщики защищенных образов удаляют как можно больше зависимостей, создавая безопасный минимальный образ контейнера, который более устойчив и менее зависит от получения утвержденных образов контейнеров для репозиториев. Кроме того, минималистичные изображения с меньшей вероятностью будут уязвимы для распространенных уязвимостей и угроз (CVE), возникающих в периоды потрясений в проекте с открытым исходным кодом или в компании, производящей продукт.
Что означает устойчивость открытого исходного кода на практике
Чтобы внести ясность, это не означает отказ от открытого исходного кода или паралич риска. Открытый исходный код остается одной из самых мощных сил в сфере технологий, обеспечивая инновации и сотрудничество в беспрецедентных масштабах. Но нам необходимо иметь ясное представление обо всем спектре бизнес-рисков, которые представляет собой открытый исходный код, а также о том, каковы затраты или необходимые шаги для смягчения этих рисков. Без планирования и предусмотрительности эти затраты могут возникнуть внезапно, что может подтвердить любой, кто пытается восстановить или найти альтернативный источник контейнеров Bitnami.
Шаг Bitnami просто подчеркивает, что внедрение открытого исходного кода также должно быть стратегическим бизнес-решением, а не только техническим. Приходится оценивать не просто код, а компанию. Не только текущее состояние, но и вероятная траектория будущего. Это больше работы. Это требует разных навыков и разных процессов. Но это единственный способ уверенно опираться на открытый исходный код, зная, что фундамент, на котором вы строите, сохранится и завтра.
Миллионы разработчиков используют Docker для создания, совместного использования и запуска приложений с помощью интегрированного, надежного и безопасного рабочего процесса, который ускоряет доставку приложений из кода в облако. Посмотрите, как это сделать, на docker.com. Insight Partners является инвестором Docker и TNS. Узнайте больше Последние новости от Docker. ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одного эпизода. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Майкл Донован — вице-президент по продуктам Docker. Он является инженером-лидером, специализирующимся на создании корпоративных приложений для крупнейших компаний мира. Обладая более чем 15-летним опытом, его миссия состоит в том, чтобы предоставлять реальные… Читать далее от Майкла Донована
