Open Source: ключевые вызовы для разработчиков
Привет, Хабр! Меня зовут Саша Белоцерковский, я евангелист-архитектор из VK Tech, а еще раньше — из Microsoft, где волонтерил в качестве лидера глобального Open Source-сообщества. Я очень люблю Open Source, люблю людей, которые работают в нашем большом сообществе.
Некоторое время назад для поддержки разработчиков Open Source мы в VK решили провести митап. Выступить позвали zloirock — мейнтейнера одной из крупнейших библиотек core.js, Сашу Кирсанова — мейнтейнера KPHP из команды «ВКонтакте», и Костю Лебедева — архитектора из Почты Mail.ru. Мне выпала честь вести эту дискуссию.
Размах встречи оказался совсем не митаповый, но нам удалось сохранить теплую атмосферу. Если любите смотреть видео, запись лежит здесь. А для тех, кто предпочитает читать, я написал выжимку по самым интересным темам, которые мы обсудили, и включил цитаты из интервью. Митап прошел не вчера, но во время подготовки статьи произошли важные изменения в мире Open Source, поэтому мы задержали выпуск, чтобы понять, что же произошло, и добавить еще фактуры в раздел про бизнес и безопасность.
Что есть успешный Open Source
На митапе мы разговорились о том, что происходило за последние лет 10–15 в мире Open Source с точки зрения контрибьюторов и какие тенденции есть сегодня. Когда-то давно даже Open Source-проектов было мало, и любой разработчик чего-то стоящего получал свою долю внимания. Сейчас гораздо сложнее. Для Open Source-проектов пишутся стратегии, в их развитии участвует много нетехнических людей. Вопрос, вынесенный в заголовок, был ключевым в дискуссии. Ответить на него непросто, но мы сделали попытку подойти к нему логически. Итак, как сделать успешный проект?
Путь к успеху и само определение успеха Open Source-проекта можно разделить на две части:
- Рост использования. После публикации проекта кто-то должен им пользоваться, говорить о нем. Для этого требуется сарафанное радио или маркетинг и технопиар. Задачи для маркетинга и технопиара здесь как классические (разработать контент, нарисовать и уложить в корпоративный брендбук визуальную составляющую, регулярно анализировать происходящее), так и не совсем: например, правильно выстроить работу с инфлюенсерами, евангелистами, людьми, которые будут говорить о проекте. Иногда кажется, что контент не очень нужен либо люди из сообщества помогут его написать. Но когда проектом начинает пользоваться больше людей, автор сталкивается с динамической природой ПО как инструмента решения проблем: разработку начинают использовать такими способами, которые не планировались и иногда не укладываются в голове. Отсутствие оперативной и осознанной реакции, процесса разработки контента, который удовлетворит возникающий спрос, замедлит рост аудитории проекта. А без роста можно забыть о второй части пути к успеху.
- Новые контрибьюторы. Без постоянного притока новых участников разработки проект постепенно становится статичным и перестает быть интересным для аудитории. Поэтому стратегически важно будет правильно планировать опыт контрибьюторов. Бесконечно расширять базовую функциональность проекта невозможно, у всего есть какие-то границы разумного. Поэтому создатели крупных продуктов (например, Kubernetes) осознанно ограничивают их функциональность, чтобы сохранить дух, цель проекта и собственный рассудок.
Итак, успешному Open Source-проекту нужна стратегия по привлечению контрибьюторов, которые будут развивать кодовую базу или экосистему. А чтобы проектом пользовалось все больше людей и приходили контрибьюторы, нам нужна стратегия общения с сообществом. Она должна отвечать на два вопроса:
- Как привлечь и удержать пользователей? В первую очередь необходимо учитывать пользовательский опыт. 20 лет назад, когда мы не были избалованы обилием открытых проектов, у пользователей и контрибьюторов не было такого богатого выбора. Люди участвовали в том, что есть, даже если это было больно. Не все из тех проектов выжили, а часть больших разработок пожинает плоды в виде захламленных репозиториев, трекеров и токсичной атмосферы. Если вы напишете невнятную или скудную документацию, на пользователей упадет больше когнитивной нагрузки в виде попыток осознать, а как сделать то или иное действие, а можно ли его вообще сделать, а как относятся к X и многое-многое другое. Стоит упустить важный момент — описание лицензии, планы по развитию или правила комментирования — или забыть сделать раздел «кого спросить по какому вопросу» и т. д., и пользователь может уйти. Документация и правила поведения в проекте — это лицо проекта, по которому люди могут оценивать, стоит ли им тратить свои ресурсы.
- Как обнаружить контрибьюторов среди пользователей? В 1990-х говорили, что, если Software не устанавливается за 5–10 минут, оно станет Shelfware. В Open Source это состояние, когда человеку хочется помогать развивать проект, но он не понимает, как это сделать, поэтому откладывает, чтобы «вернуться позже». Если у проекта нет понятной стратегии работы с сообществом, то будут приходить случайные разработчики, чей код придется отклонять, а потом и они закончатся. Мой любимый пример — JIT-компилятор 2015 года. Пользователям может нравиться ваш продукт и они захотят его развивать, но если вы не скажете им, как это делать, то они додумают стратегию за вас.
Любопытно: в этом контексте в центре внимания оказывается проблема Freeloaders — людей, которые лишь пользуются вашим проектом, никогда не репортят, ничего не пишут и могут не отвечать на прямые обращения. Большое количество Freeloaders означает, что проект прост в использовании и востребован. С точки зрения маркетинга Open Source-проекта это может быть потенциальная аудитория, с точки зрения автора — потенциальные контрибьюторы. Но в реальности лучше оставить этот сегмент в покое и не пытаться «растормошить». Не стоит принимать решения или ставить KPI (да, видели и такое) по конвертации этих людей в контрибьюторов.
Вот что об этом думают мои коллеги:
Пушкарев: У проекта может отсутствовать сообщество, но он не будет мертвым. Может быть активный мейнтейнер, который устраняет все проблемы. Может быть наоборот. Может быть сообщество, а мейнтейнер может забить на этот проект. В данном случае живым можно считать тот проект, у которого мейнтейнер поддерживает все, что нужно. То есть это не сообщество в первую очередь. Приведу такой пример. Я не помню ни никнейм, ни имя разработчика.
В команде был японец. Два года назад просто перестал коммитить. Я вообще не знаю, хорошо ли с ним все или нет. Он поддерживал огромное количество плагинов, кучу различного инструментария. Часть утилит форкнули, успешно поддерживают. Другие пытались форкнуть, какие-то изменения вносят, однако эти изменения не синхронизируются. В итоге это куча мертвых проектов. Хотя сообщество изначального проекта живое. То есть в данном случае живой проект или нет — это вопрос мейнтейнера.
Как работать с сообществом? Оно может использовать этот проект, оно может быть огромным. При этом ничего в проект не контрибьютят. Для качества проекта это нехорошо. У Core-JS в этом плане все плохо, потому что контрибьюторов у проекта достаточно мало, порог входа довольно высокий.
Во многих проектах вроде Babel человек создает issue. Что с этим делать? Если это довольно простой issue, того, кто создал, часто спрашивают: «Не желаете ли вы исправить это сами, сделать pull request?»
Это рабочая практика, но часто компетенции человека не хватает. Обычно такие issue помечают как «help wanted». Бывает, они висят месяцами, при этом мейнтейнер проекта может исправить такой issue буквально за несколько минут. Так качество проекта и снижается.
По поводу привлечения контрибьюторов. Желательно разъяснить, что и как делается. Как что-то новое внести в проект. Будет очень полезен менеджер сообщества, который будет вести блог, общаться с людьми и помогать вовлекать их в проект.
Кирсанов: С сообществом интересная история в том плане, что конкретно у нас проект (KPHP) когнитивно очень сложный. Надо быть в теме. Бывает, что делают pull request, но ты, как на уроке литературы, понимаешь, что хотел сказать автор, но чувствуешь, что делать это надо по-другому. Тебе надо закрыть pull request и сделать то же самое, только правильно. Иногда получается так, что ты его не закрываешь и он висит. Это может человека и обидеть. Я до сих пор не понял, что в таких ситуациях делать. Понятное дело, что под работой с сообществом подразумевается не только это. Надо пытаться держать какие-то каналы связи с разработчиками.
По поводу когнитивной нагрузки. Если у человека, который пытается установить твой продукт, что-то не работает —, а так происходит часто, — то он, во-первых, должен понять, где про это можно спросить, а во-вторых, он должен получить и понять ответ. С последним не всегда выходит.
Общение показывает жизнь и активность. Если ты видишь, что кто-то что-то спрашивает и ему отвечают, значит, можно на что-то рассчитывать, можно в это вписываться, пытаться что-то пробовать. Если ты видишь, что есть несколько вопросов и молчание в ответ, наверное, что-то идет не так. В первую очередь это все-таки… не буду произносить слово «эмпатия» в более общем смысле, но какая-то обратная связь от разработчиков.
Лебедев: Я абсолютно согласен с этим. Но я думаю, что в случае вышеупомянутой ситуации это всё же моя ошибка как мейнтейнера проекта, что я не написал общие правила, как подготовить merge request, не добавил линтеры, что-то еще. Если проект растет стихийно, то вроде бы ты сделал это для себя, а потом начали приходить люди, которые используют проект в своей жизни, их все больше и больше. Они тебе пишут и пишут. В какой-то момент нужно сделать паузу. Не отвечаешь день никому, потому что, возможно, они сами разберутся. Я не вижу в этом ничего плохого. Я так всегда делал. Предложить прислать merge request. Нормально обговорить. Твое время тоже не резиновое, особенно когда ты не занимаешься проектом постоянно.
Еще в 2004 году Тим О«Рейли написал статью The Architecture of Participation о том, что архитектура проектов должна включать в себя и архитектуру участия внешних контрибьюторов. Но воз и ныне там: многие проекты и компании мало заботятся о работе с контрибьюторами или вообще пускают все на самотек. На митапе мы сошлись на том, что без менеджера сообщества обойтись сложно.
Open Source и бизнес
Разработка проекта, архитектура которого подразумевает расширение с помощью сообщества, должна учитывать еще один важный нюанс. Как только проект начинает расти, у пользователей возникает коммерческий интерес. Ведь проект уже утвердился на своем месте, появились практики использования и доверие, поэтому бизнес может захотеть использовать проект в своей деятельности.
Использование бизнесом Open Source-проектов создает риск коллизий. Недоработанная документация и стратегия — верный путь к непониманию между бизнесом, разработчиками и сообществом. А стремление бизнеса к бюрократизации и использованию процессов может привести к серьезным проблемам.
У каждого Open Source-проекта есть лицензия, регламентирующая его использование. При этом впечатляет печальная статистика игнорирования лицензий: в 54% случаев есть лицензионные коллизии. Проблема в том, что в какой-то момент (лично я склонен относить этот надлом к началу развития облачных западных платформ) стратегия управления интеллектуальной собственностью в Open Source-проектах перестала соответствовать сложным моделям коммерческих компаний, использующих эти проекты. В некоторых корпорациях, особенно активно использующих Open Source, это привело к появлению юристов и специальных экспертных команд по Open Source, которые не только анализируют важные для бизнеса изменения на рынке, но и напрямую влияют на перевод внутренних продуктов в Open Source. Движение сейчас набирает популярность, Open Source Programs Office оценивают как однозначно полезную инициативу для любого размера бизнеса, так как даже небольшая компания может активно использовать Open Source (и ставить под угрозу свое ПО).
Конечно, для компаний поменьше все может быть не так печально, но никто не забыл про случай с изменением лицензии у ElasticSearch. Причем экзистенциально проигравшей стороной остались не пользователи, а сама Elastic: Amazon просто форкнул проект. Сообщество не оценило неожиданного изменения лицензии проекта, который многие использовали в эксплуатации (по уму, в нее должны попадать проекты без лицензионных коллизий, это необходимо отслеживать). Linux Foundation так и не одобрил лицензию Elastic.
Из этой истории сложно сделать конкретные выводы, так как слишком много острых вопросов поднято. Однако она показывает, насколько важно иметь стратегию, учитывающую разные ситуации. Получается, что при монетизации Open Source компании должны прибегать к такому же анализу отрасли, как и в случае с коммерческими проектами. Бизнес стремится зарабатывать деньги, он один из ключевых потребителей больших открытых проектов. Open Source для него лишь инструмент, функционирующий в составе коммерческих продуктов, и не имеет смысла пытаться дистанцироваться от бизнеса, как и от политики или культурных особенностей.
Найти устраивающий всех баланс — сегодня ключевая задача сообщества Open Source.
Во время подготовки статьи произошло событие, которое уже начало влиять на экосистему, а некоторые, например, в TechCrunch в статье Why SUSE is forking Red Hat Enterprise Linux, отмечают, что это может порушить множество горизонтальных связей в сообществе и изменить ландшафт Linux. На митапе мы про Linux не говорили, но это все-таки фундамент Open Source, который заложил много культурных практик, если не подавляющее их большинство.
Вкратце (для любителей длинных текстов — обстоятельный рассказ от сотрудника Red Hat): в 2014 Red Hat приобрел CentOS, в 2019 IBM приобрел Red Hat, в 2020 Red Hat сделал серьезные изменения в линейке, выкатив CentOS Stream. Это дистрибутив, который предполагалось выпускать параллельно с CentOS. CentOS при этом развивается параллельно с платным Red Hat Enterprise Linux (RHEL). Если брать обновления, то вверху Fedora, где они обкатываются, потом все спускается в RHEL. CentOS формируется на RHEL, но при этом CentOS открыт и свободно распространяется. CentOS Stream должен был попасть где-то между Fedora и RHEL, иметь модель rolling preview и быть удобной платформой для разработчиков. А CentOS 7 стала последней версией с поддержкой LTS (до 2024).
Это привело к недовольству внутри сообщества, потому что означало, что CentOS и RHEL уже не будут полностью совместимы. Были созданы два ставших популярными Rocky и Alma Linux. В июне 2023 Red Hat объявил о реструктуризации размещений обновлений, резко сосредоточившись на CentOS Stream и переведя все обновления в его репозиторий. Это резко усложнило жизнь Rocky и Alma, а Oracle в официальном пресс-релизе даже использовал слово attacking.
Ситуация продолжает развиваться. Пока что выглядит так, будто крупные игроки Open Source продолжают усложнять логику связей внутри экосистемы как для пользователей, которым может быть непонятно, что взять для использования, так и для разработчиков.
Функция ИБ при использовании Open Source
Когда Open Source-проект становится частью какой-то важной инфраструктуры, злоумышленники начинают искать в нем уязвимости. После известных случаев по всему миру прошла волна пристального внимания к безопасности, принцип «тысячи глаз» подвергся серьезному переосмыслению, а открытые продукты — аудиту. Некоторые подходили к этому серьезно еще раньше (аудиты безопасности экосистемы от CNCF, OpenSSF).
Инструментально и процессуально движение за поиск и устранение уязвимостей воплотилось в виде практик DevSecOps, выйдя затем за пределы программного мира: появилась расширенная концепция безопасности Supply Chain Security. Она объединила в себе все, что касается жизненного цикла ПО, включая внешних поставщиков, команды. Вероятно, Supply Chain Security воплотила в себе желание бизнеса бюрократизировать разработку ПО и отслеживать то, что приходит внутрь периметра, желательно автоматически. Сбор и анализ зависимостей (Supply Bill Of Materials) стал одним из самых изучаемых аспектов.
Но к большим проектам эту концепцию применять рискованно: зависимости могут меняться очень часто, и непонятно, как принимать решения настолько быстро, чтобы не тормозить разработку и выход на рынок. Возможности для автоматизации здесь нет и вряд ли будет, так как пришлось бы учитывать не только сами уязвимости и их технический контекст, но и кажущиеся посторонними вопросы. При этом Supply Chain Security стала основой стратегии по безопасности ПО некоторых государств, что сделало ее значение для многих критическим. Однако многие эксперты индустрии высказывают опасения, что если делать все согласно рекомендациям в этих стратегиях, то бизнес просто встанет из-за количества процессов, проверок безопасности, анализа зависимостей и других этапов. Поиск золотой середины между обеспечением безопасности зависимостей и быстрым развитием бизнеса и обновлением ПО, нужного для бизнес-процессов, — задача следующих лет.
Вторая проблема — юридическая. Так как Open Source-проект является частью архитектуры системы, он может подлежать аудиту по внутренним процессам компании. Если проект небольшой, то провести аудит еще можно силами внутренних разработчиков. Но в больших проектах или при отсутствии внутренних ресурсов это может быть сложно или невозможно. Известны случаи, когда мейнтейнерам Open Source присылали опросники для аудита от компаний, о которых те даже не слышали. Увы, универсального решения этой проблемы тоже пока что нет.
Кирсанов: Люди и компании, для которых действительно важна безопасность, какие-то гарантии, скорее, не будут пользоваться Open Source. Они понимают, как оно работает. Если ты пишешь софт для авианосца, то будешь писать все с нуля. Если ты пишешь что-то для авиации, то тебе нужны совершенно другие гарантии, совершенно другой код. Степень ответственности у тебя как у разработчика другая. Это твои проблемы, если ты на корабельный софт поставил Kubernetes и что-то в контейнерах у тебя крутится, а потом что-то сломалось, абстракция протекла. В плане ответственности это черный ящик.
Пушкарев: В данном случае я не соглашусь. Когда человек пишет Open Source, он понимает, что другие люди это увидят. В большинстве случаев код, опубликованный как открытый, качественнее закрытого. Но как предъявлять претензии разработчику — это уже другой вопрос. Как по мне, достаточно безопасно использовать открытый исходный код, потому что разработчики закрытого кода могут много наворотить.
Ситуация с этими опросниками, государственными политиками безопасности известна. В твиттере сколько раз видел, в блогосфере часто обсуждается. Вот есть проект по самой популярной лицензии MIT. MIT — это copyleft, отказ от ответственности. По сути, мне как автору некому предъявлять претензии. Хотите — покупайте коммерческую лицензию, можете ее даже у меня купить. Это будет двойное лицензирование продукта. Хотя, с другой стороны, если ко мне вежливо придут, то почему бы не ответить?
В январе 2023 года европейские эксперты в области Open Source обеспокоились новым законодательным актом The ultimate list of reactions to the Cyber Resilience Act. О нем высказались буквально все, кто более-менее популярен в коммерческом ПО. С одной стороны, законодатели зашли с правильной стороны: необходимо понять, кто же ответственен за безопасность, кто является субъектом, а кто объектом. Но в июле 2023-го, когда перешли к обсуждению, опасения достигли максимума (The Cyber Resilience Act Threatens the Future of Open Source). Вероятно, если не произойдет никаких изменений, то разработчики Open Source-компонентов, которые используются в коммерческом или государственном ПО, станут полноценно рассматриваемыми объектами.
Достаточно ли просто вежливости
Кирсанов: Когда делаешь что-то в Open Source, не очень понятно, когда и какую реакцию ожидать. Представьте, что вы хотите научиться кататься на скейтборде. Покупаете скейтборд, приходите на площадку. Все видят, что вы ничего не умеете. Подходят и говорят: «Давай мы тебя научим. Ногу надо ставить так, толкаться надо так. Не расстраивайся, не у всех получается сразу». Начинают тебя подбадривать.
Что происходит в айтишном мире? Ты три месяца писал какую-нибудь игру, пиксели двигал, писал алгоритмы. Показываешь лучшему другу, а он говорит: «Зайди на App Store. Там за 99 центов скачаешь нормальную игрушку. Чего ты ерундой страдаешь?» В мире ИТ есть такое отношение друг к другу. Когда ты просишь твоих близких товарищей, коллег рецензировать тебя, они почему-то не относятся к тебе так, как чуваки со скейтбордом. Я не знаю почему. Это проблема не только для Open Source, это проблема ИТ. Эмпатию надо как-то развивать.
И здесь мы подходим к проблеме Open Source, которую называют трагедией Commons. Множество людей, поддерживающих проекты, на которых работают критические системы, зарабатывают достаточно скромные деньги. Скромные в том смысле, что на этих людях лежит ответственность за любимый проект, о которой они часто даже не просили. Кто-то много лет работает за идею или интерес или уже не пишет код, а управляет проектом и общается с сообществом. Тем не менее главной проблемой Open Source продолжает оставаться (и, скорее всего, останется еще долго) вопрос мотивации и самомотивации. Будь вы хоть трижды энтузиастом, вопросы «а почему так?» сложно обрабатывать без последствий для настроения.
Про трагедию общественного написано множество трудов, исследовательских и визионерских. Ее даже анализировали с позиции теории игр. К сожалению, лучше не становится. В условиях нескончаемых финансовых кризисов сложно обосновывать гранты для Open Source. В больших компаниях обеспокоены сложившейся ситуацией, но у них есть и ряд объективных помех.
Open Source Programs Office
Выше я затронул растущую популярность Open Source Programs Office. OSPO — это формат команды, которая занимается вопросами Open Source на уровне руководства, решая возникающие коллизии и снижая риски для компании и сообщества. Общепринятой структуры OSPO-команды еще не выработано, и каждый подходит к этому по-своему. Например, в больших компаниях стараются решать вопросы с лицензиями и проблемы с безопасностью Open Source-проектов, входящих в периметр (и вместе с внутренним ИБ пишут регламенты по предотвращению и реакции на инциденты).
Сейчас рабочая группа максимально формально подходит к архитектуре построения OSPO: GitHub — todogroup/ospodefinition.org: Open Source Program Office Definition (OSPOD).
В OSPO часто входят сотрудники, имеющие опыт работы с сообществами. У них любопытные обязанности. Например, они отвечают на запросы от команд разработки в компании, которые либо хотят уйти в Open Source, либо прогнозируют, что им придется это сделать. OSPO маршрутизирует такие запросы на всех ключевых направлениях, скрывая реализацию :). Команды общаются с одним-двумя сотрудниками из OSPO, которые подсказывают, как нужно выходить в Open Source и какие это несет риски для бизнеса, лицензирования и ИБ.
Акцент на ИБ делается не просто так, сегодня это сложнейший процесс. В корпорациях с этим немного легче благодаря отлаженным процессам, обучению и финансовым возможностям. Недавно компания Tidelift провела исследование, и оказалось, что половина мейнтейнеров не знают, что происходит со стандартами безопасности для Open Source (OpenSSF, NIST SSD, SLSA и др). 37% из этой половины признались, что не интересуются этим, потому что им не платят за работу.
В заключение
Никогда еще теме Open Source не уделялось столько внимания, как сегодня. Но нам только предстоит осознать, что при использовании Open Source-проектов мы смотрим совсем не туда и порой полностью забываем, что это движение возникло и развивается на основе взаимопомощи и взаимовыручки. И пытаясь решить, как же нам выделить больше денег, теряем ценное время и упускаем из виду главное: Open Source — это люди. И с ними нужно общаться, совместно обсуждать имеющиеся проблемы и строить сообщество.
Проблема видна невооруженным взглядом, и как в индустрии, так и в корпорациях есть множество людей, пытающихся изменить ход истории. Пожалуй, мир Open Source похож на виртуальную копию нашего реального психологического мира. В нем не всегда можно прописать правила поведения, часто происходят конфликты, но в конце концов практики, выработанные на этих конфликтах, могут вывести ИТ на совершенно новый качественный уровень.
Фактура
Безопасность
Случай с Red Hat
В общем
