ТОКИО — Создание проекта с открытым исходным кодом никогда не является первым выбором. Это вызывает разногласия, опасно и политически рискованно. Но иногда, как сказали лидеры Valkey Роберто Луна Рохас и Мэделин Олсон во время своего выступления в понедельник на саммите Open Source в Японии, у вас нет выбора. Это единственный реальный путь вперед для защиты проекта с открытым исходным кодом.
Для тех, кто не знает этой истории, резюмируем: в 2024 году Redis, производители широко используемой в памяти базы данных NoSQL «ключ-значение», решили отказаться от своей трехпунктной лицензии Berkeley Software Distribution (BSD) и заменить ее доступной лицензией Redis Source Available License (RSALv2) и серверной публичной лицензией (SSPLv1) только для чтения. Это прошло как воздушный шар с членами основной команды разработчиков.
Поэтому они быстро решили внедрить код в программу, которую мы теперь знаем как Valkey. Valkey оказался очень успешным форком. Благодаря Amazon Web Services, Google, Microsoft, Oracle и другим технологическим державам, поддерживающим Valkey, этот форк с открытым исходным кодом работает отлично. Пожалуй, наиболее показательно то, что в мае этого года Redis решил вновь открыть кодовую базу программы под лицензией GNU Affero General Public License (AGPL).
Однако в 2024 году члены команды форка Valkey этого не знали. Они просто знали, что им нужно переехать. Это их история.
Выступая перед полным залом на саммите Open Source в Японии, Олсон и Луна Рохас, давние участники Redis, подробно рассказали о предупреждающих знаках, которые предшествовали ответвлению Valkey от Redis, о шагах, которые сообщество предприняло для подготовки, и о с трудом завоеванных уроках, которые, по их мнению, должен усвоить каждый сопровождающий открытого исходного кода.
Обнаружение красных флажков
Олсон, ныне главный инженер AWS, сказал, что самые большие проблемы возникли из-за управления, которое медленно централизовало контроль внутри компании Redis.
Оглядываясь назад, по ее словам, разработчики Redis с открытым исходным кодом, такие как она, увидели три основных предупреждающих знака, на которые им следовало обратить внимание.
Первым было закрытое управление: назначенные Redis сопровождающие «имели особые разрешения в рамках проекта», в то время как внешние сопровождающие, такие как Олсон, «по сути были просто обычными участниками», оставляя основные решения в руках сотрудников компании.
Тогда вся власть была в руках компании, а не сообщества. «У Redis также было явное право вето… [and] возможность наложить вето на все, что они хотят», — добавила она. Это позволило компании принудительно включать функции в проект — даже если сопровождающие не соглашались.
Олсон привел Redis Functions как один из примеров функции, «введенной в проект Redis… потому что они думали, что это то, что им нужно», несмотря на сопротивление со стороны сопровождающих сообщества.
Сообщество также заметило, что функции были отклонены по нетехническим причинам, что Олсон назвал «очень важным предупредительным знаком». Одна широко запрашиваемая функция от AWS, Google и других — статистика слотов кластера — была отклонена просто потому, что Redis не хотел ее.
По словам Олсона, помимо управления, инфраструктура проекта Redis была непрозрачной. Сборки, тестирование производительности и даже хосты, с которых были выпущены артефакты с открытым исходным кодом, были частными или проприетарными. «Только люди Redis могли выпускать настоящие релизы», — отметила она, что стало серьезным препятствием позже, когда произошел форк.
Redis отказался комментировать заявления сопровождающих Valkey.
В марте 2024 года Redis сменила лицензию. Олсон сказал, что сопровождающие открытого исходного кода знали, что что-то не так и изменения могут быть неизбежными. Этот сдвиг повлек за собой создание Valkey, полностью открытого форка под управлением Linux Foundation, предназначенного для сохранения управления сообществом и непрерывности работы пользователей.
Вырываясь
Команда Valkey сразу расставила свои приоритеты:
- Сохраните основные процессы и поведение, чтобы пользователи могли обеспечить непрерывность работы.
- Создайте сильную, нейтральную структуру управления.
- Держите сообщество вместе.
- Вынесите все возможное на открытое пространство
Команда Valkey приняла модель Технического руководящего комитета Linux Foundation, потому что она была «очень похожа на то, что у нас было раньше» и с самого начала была ориентирована на инженеров. Но на этот раз, как пообещала команда, решения будут публичными, прозрачными и подотчетными.
Одним из первых изменений было исключение частных встреч. «Все встречи являются публичными», — сказал Олсон. «Если мы когда-нибудь увидим, что люди пытаются провести частные встречи, мы заставим их отменить их и сделать публичными».
Она подчеркнула универсальный принцип: «По умолчанию все должно быть открыто» — изменение, которое «очень хорошо сработало для проекта».
Поскольку внутренняя инфраструктура Redis была невидимой, специалисты по сопровождению Valkey быстро обнаружили, что им не хватает базовой информации. Например, они не знали, как создавались двоичные файлы, откуда исходные дистрибутивы получали Redis и кто обслуживал критически важные пакеты.
Им «очень повезло», сказал Олсон, встретить на мероприятии упаковщика Fedora, потому что без этой связи «мы бы точно не знали… с чего начать» в восстановлении последующей поддержки.
Чтобы не повторять непрозрачность Redis, новая команда также сделала приоритетными документацию и автоматизацию. Альтернатива, по словам Олсона, «в основном заключалась в попытке документировать все либо явно, либо автоматизировать это и сделать общедоступным. Любой может взглянуть на код… и довольно быстро получить относительно хороший ответ».
автоматизация позволила любому, а не только инженерам AWS, выпускать официальные выпуски. «Два релиза были созданы людьми, а не AWS», — с гордостью сказала она. Теперь это все механизмы «одного щелчка», исправления видны и исправляются с помощью GitHub Actions и CI.
Одной из основных претензий к предварительному форку Redis была непредсказуемая частота релизов. Олсон описал Redis 7.0.2, в котором сокращение кода произошло в мае, но релиз вышел только в августе.
Валки выбрал для начала шестимесячный период выпуска; члены команды удивили себя, превзойдя ожидания. «Наличие предсказуемости для вашего сообщества действительно важно», — сказал Олосон. По ее словам, регулярная периодичность помогает пользователям решать, когда и как вносить исправления и функции.
Неровности на дороге
Не все прошло гладко. С открытостью пришли и проблемы роста.
Поскольку любой мог инициировать релизы, случались ошибки. Один инженер «перемаркировал» релиз после того, как забыл о коммите, что привело к поломке последующих систем, таких как Homebrew. «Не позволяйте вашему сообществу делать это», — сказал Олсон со смехом. Простым и правильным решением было бы создать новую версию и правильно пометить ее.
Защита филиалов также оказалась жизненно важной. Несколько участников случайно отправили коммиты непосредственно в рабочие ветки. «Это не потому, что мы не доверяем людям», — сказал Олсон. «Все совершают ошибки», и существуют меры защиты для предотвращения несчастных случаев, а не намерений полиции.
Коммуникационные инструменты создавали свои собственные проблемы. Сообщество использовало Slack, но многим он не нравился, в том числе Олсону: «Я его ненавижу».
Итак, сопровождающие попробовали Matrix и Discord. Все эти попытки переехать провалились. «Никто не пошевелился», — признался Олсон. Несмотря на ограничения Slack, в том числе срок действия сообщений и неработающие ссылки для приглашений, «в конечном итоге мы медленно вернулись в Slack», — сказала она, потому что там уже были участники.
Контрольный список перед форком
Если вы видите эти предупреждающие знаки в вашем корпоративном проекте с открытым исходным кодом (непрозрачное управление, руководители игнорируют запросы разработчиков и клиентов), Олсон и Луна Рохас предлагают вам начать рассматривать форк, чтобы вы не были застигнуты врасплох, если ваша компания попытается закрыть ваш проект с открытым исходным кодом.
Луна Рохас завершила сессию метафорой: «Когда вы видите, как монстр-форк выскакивает из вашей кодовой базы, вы не хотите сталкиваться с ним в одиночку. У вас есть Linux Foundation, который будет рядом с вами и поможет вам создать проект, принадлежащий сообществу».
Он подчеркнул наличие четкого контрольного списка для любого проекта, рассматривающего возможность форка:
- «Начните составлять устав прямо сейчас».
- «Гигиена контроля версий — старайтесь быть в безопасности, защищая ветки и теги».
- «Держите свое сообщество вместе… неважно, где оно находится».
- «Все документируйте».
- И всегда поддерживайте нижестоящих сопровождающих — «невоспетых героев», которые делают программное обеспечение пригодным для использования во всех дистрибутивах по всему миру.
Разветвление может быть последним средством, но, как показала команда Valkey, когда сгущаются предупреждающие грозовые тучи и управление больше не служит обществу, разветвление может стать самым здоровым и устойчивым путем вперед.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Стивен Дж. Воан-Николс, он же sjvn, писал о технологиях и технологическом бизнесе с тех пор, как CP/M-80 была новейшей операционной системой для ПК, скорость 300 бит/с — высокоскоростное подключение к Интернету, WordStar — современный текстовый процессор, и он нам понравился. Узнайте больше от Стивена Дж. Воана-Николса.
