System76: Пример того, как не сотрудничать с апстримом

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

Этот текст — перевод статьи от Криса Девиса. Оригинал можно найти здесь.

Прим. переводчика: есть несколько терминов и названий, которые следует знать, прежде чем начать читать статью:

Недавно было горячее обсуждение будущего GNOME. Это привело к распространению большого количества опасений, неуверенности и сомнений в отношении GNOME, а также к нападкам и враждебности по отношению к GNOME в целом и к отдельным участникам. Во многом это началось благодаря действиям сотрудников компании System76.

Это не первый раз, когда System76 оказывается в центре публичного конфликта с сообществом GNOME, и это не первый случай, когда ситуация нормально не разрешилась. На данный момент мне более не комфортно работать с System76 без какого-либо признания ошибок и извинений за их плохое поведение и обещания, что это больше не повторится.

Вы можете подумать: о каком поведении идёт речь? Что сделала System76, чтобы заслужить такое отношение? Что же, это не какой-то единичный инцидент — это модель поведения, многократно повторяющаяся за последние несколько лет. Я расскажу об инцидентах, о которых знаю из прошлого, их поведении в настоящем и своих мыслях о будущем.

Дисклеймер: данный текст является моим мнением и только моим мнением. Я не говорю от лица GNOME в целом, только от себя и использую сделанные мной наблюдения. Эти наблюдения могут быть неверными.

Дисклеймер от переводчика: я надеюсь, что данный перевод точно передаёт изначальную мысль автора. Если что-то не так, не стесняйтесь писать об ошибках в наш телеграм-чат!

System76 и LVFS

Это первая серьезная проблема, о которой я знаю. Она также продемонстрирует некоторые из моделей поведения, которые будут повторяться. Еще в 2017 и 2018 годах Ричард Хьюз (прим. переводчика: автор LVFS) общался с System76, чтобы заставить их прошивки работать с LVFS и fwupd (прим. переводчика: LVFS — стандартный для дистрибутивов Linux репозиторий, где размещаются прошивки различных устройств. fwupd — утилита для работы с этим репозиторием). Затем неожиданно System76 анонсировала собственную инфраструктуру и программное обеспечение для обновлений прошивок. Они также сказали Ричарду, что он должен использовать их инфраструктуру вместо своей. Ричард выразил удивление и разочарование по поводу этого шага в своем блоге.

Поначалу это кажется ошибкой коммуникации наряду с техническими разногласиями. Однако действительно неприемлемое поведение началось с ответом System76 на сообщение Ричарда. Они начинают с обмена корреспонденцией между обеими сторонами. Я считаю, что нарушение общения происходит в этом разделе, где Ричард объясняет, почему их текущие методы не будут работать для LVFS. Затем они идут дальше и подразумевают, что LVFS передает личные данные (прим. переводчика: LVFS никогда не передавал личные данные):

Будьте осторожны

Мы намеревались использовать LVFS в будущем, но это уже не так; с проектом слишком много проблем. Если вы хотите использовать LVFS, отключите сбор данных. В этом нет необходимости. Поймите, что первый инстинкт руководителей проекта заключается в необязательном и выключенном по-умолчанию (opt-in) сборе данных с пользовательских установок. Помните, что вы выбираете для своего дистрибутива связи со сторонними серверами. Чем больше серверов, с которыми ваш дистрибутив обменивается данными из коробки (особенно с правами root), тем больше уязвимостей. Внимательно изучите любое добавление стороннего сервера на предмет обновлений. Поймите, что если вы компания, специализирующаяся на устройствах только для Linux и рассматривающая возможность использования LVFS, вы передаете свои данные о частных продажах в LVFS. Мы предлагаем возможность разместить LVFS на своих серверах.

Сотрудники System76 продолжали распространять эту идею в интернете в начале 2019 года, что, вероятно, вызвало публикацию Ричарда, опровергающую их утверждения. Позже команда LVFS начала работу по поддержке сценария использования System76, чтобы поставщики могли использовать LVFS без какой-либо отчетности. Вскоре после этого System76 начала использовать LVFS и fwupd без каких-либо фанфар или опровержения своих предыдущих заявлений.

Теперь, прежде чем мы перейдем к следующему инциденту, следует иметь в виду несколько ключевых выводов. Это будет повторяющееся поведение:

System76, Ubuntu и багфиксы

В 2019 году Себастьен Башер из Canonical поделился сообщением о том, как System76 обращается с апстримами — в данном случае как с Ubuntu, так и GNOME:

Недавно я видел несколько случаев возникновения таких ситуаций

  1. System76 / Pop! OS находит ошибку (где “находит” часто означает, что они подтверждают, что существующая ошибка влияет на их версию ОС)
  2. Они пишут патч или workaround, включают его в свой пакет, но не выкладывают изменение/фикс в апстрим (или просто выкладывают .patch, помеченный как workaround, в комментарии, а не отправляют его на надлежащую проверку).
  3. Позже они начинают комментировать баг-трекеры в upstream (Ubuntu, GNOME, …), указывая пользователям, что проблема была решена в Pop! OS, рекламируя, как они заботятся о пользователях и именно поэтому они решили проблему в своей команде OSSystem76 / Pop! OS. Хотя вы и должны гордиться работой, которую вы делаете для своих пользователей, я думаю, что вы идёте неправильным путём. Работа над исправлениями и включение их в свой продукт на ранних стадиях — это одно, но не выкладывать эти исправления и использовать это для маркетинга, считая себя лучше своих апстримов — это рискованная игра.

На данный момент System76 уже установила модель поведения, когда вместо того, чтобы работать с апстримами, они используют эту возможность для продвижения себя и своих решений.

System76, GNOME Shell и тайлинг

Это довольно простой инцидент, но он вызывает беспокойство, поскольку связан с вводящим в заблуждение рассказом, который System76 вела в течение двух лет. В конце 2019 года System76 начала работу над расширением, которое позволяло создать i3-подобный тайлинг в GNOME. Когда один из дизайнеров из апстрима обратился к нему с предложением о сотрудничестве в области тайлинга, Джереми Соллер, главный инженер System76, отказался работать с ним. Настоящая проблема заключается в том, что System76 продолжает повторять, что апстрим не заинтересован в тайлинге в течение последних нескольких лет. Несколько примеров:

Боюсь, что GNOME не хочет поддерживать окна с четвертным тайлингом.

Было бы здорово, если бы GNOME захотели интегрировать в свой рабочий стол возможность тайлинга. Но правда в том, что они этого не хотят.

— Майкл Мёрфи

Это неправда, и твит по ссылке показывает это. Тем не менее, сотрудники System76 продолжают повторять, что нам не нужен тайлинг.

System76 и GNOME 40

Вскоре после объявления направления развития GNOME 40, Джереми Соллер удивил нас заявлением о том, что System76 не давала “согласия” на новый дизайн GNOME Shell. Он также утверждал, что отзывы их дизайнера были отклонены. Дизайн GNOME 40 в основном обсуждался на созвонах дизайнеров, которые не записывались, поэтому это утверждение трудно проверить. Это тоже тяжёлый случай для рассмотрения, потому что, хотя, возможно, не было намерения причинить вред, их дизайнер все равно мог почувствовать себя неуслышанным или обиженным — причинение боли не требует намерения причинить боль. Итак, я сосредоточусь на том, что я могу рассмотреть.

Джереми утверждает и продолжает утверждать, что их предложения были отвергнуты. Это не так. Реальность такова, что у System76 был дизайнер, участвовавший примерно в течение одного года из трехлетнего процесса проектирования. Их дизайнер участвовала в звонках и обсуждениях с командой дизайнеров, и ее роль была сосредоточена на самом UX-исследовании (определение вопросов исследования, проведение интервью, анализ результатов и т.д.). В процессе проектирования от System76 никогда не было макетов или конкретных предложений. Я также слышал, что System76 провела опрос и не поделилась его результатами с командой, работавшей над дизайном 40.

Насколько я понимаю, единственный раз, когда System76 сделала предложение, был в самом конце процесса проектирования во время встречи команды разработчиков с заинтересованными сторонами. Там они представили COSMIC и не получили той обратной связи, которую хотели получить на тот момент. Возможно, именно это они и имели в виду, но в этот момент было уже слишком поздно для внесения каких-либо предложенных изменений.

Поведение компании повторило первоначальный шаблон. Когда System76 не увидела принятия их дизайна, она начала распространять дезинформацию. Этот конкретный случай дезинформации оказался невероятно вредным для репутации GNOME. Я часто видел, как первые два твита приводились в качестве “доказательства” того, что GNOME не хочет работать с downstream или прислушиваться к пользователям. В действительности они являются примером того, как System76 ведет себя по отношению к другим, когда они не получают того, чего хотят.

System76, libadwaita и GTK темы

Теперь мы добрались до последнего инцидента. Я участвовал в этом инциденте больше, чем в других, и наблюдал за его развитием с самого начала и до настоящего времени. Я решил углубиться в детали, разбив наиболее важные моменты по дням.

1е сентября

Все началось в начале месяца, когда Джереми заметил, что мы переопределяем gtk-theme-name и устанавливаем таблицу стилей Adwaita для приложений, использующих libadwaita. Он поделился этим в своем Twitter. Затем Джереми опубликовал дезинформацию о поддержке тёмной темы. Почему это дезинформация?

Затем Джереми очень публично обратился к GNOME в целом — что несколько человек восприняли как угрожающий ультиматум. Вскоре Джереми стало известно, что libadwaita — это WIP-библиотека и что еще есть время поработать с нами над вендорной тематизацией. Тем не менее, на этом его сообщения об этом в Twitter не закончились. Федерико с помощью Александра написал и разместил в блоге сообщение с подробным описанием наших целей и того, что можно сделать для разрешения ситуации.

2е сентября

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

3е сентября

Джереми заявил, что System76 рада использовать libadwaita. Уже на следующий день Майкл Мёрфи, один из членов основной команды, опроверг это заявление:

Я даже не знал о существовании libadwaita, когда Джереми начал писать о ней в Твиттере. Я не думаю, что кто-то из нас знал о libadwaita и ее целях.

Майкл также заявил, что мы не хотим сотрудничать, в то время как на данный момент мы просили их сотрудничать, а не указывать пальцем несколько раз, как показано в предыдущих архивах.

Наконец, через три дня появилась возможность поговорить, и я ею воспользовался. Ниже приводится краткое изложение разговора, скриншоты которого я также сохранил:

Затем Джереми открыл issue в GTK и был перенаправлен на libadwaita. После некоторого обсуждения проблемы libadwaita он открыл запрос на слияние.

6е сентября

После длительного обсуждения issue и MR, запрос на слияние был закрыт, как только стало ясно, что:

Послесловие

В очередной раз сотрудники System76 решили распространять дезинформацию и жаловаться в Twitter вместо того, чтобы попытаться работать с нами (апстримом) над своими проблемами. Разумно предположить, что они узнали о libadwaita и начали публиковать ультиматумы в Twitter в тот же день. В очередной раз они распространили дезинформацию о проекте и наших целях.

В течение нескольких недель после закрытия MR несколько различных сотрудников продолжали распространять дезинформацию о ситуации в Twitter. Существующая дезинформация уже вызвала волнения в сообществе, заставив многих людей взволноваться и делать заявления, например, что GTK4 предназначен только для GNOME, или что GNOME хочет стать “единственным” рабочим столом в Linux из-за нашего подхода к темам. В нашу сторону было направлено много ярости.

Слова System76 также выходят за пределы экосистемы Linux, и крупные создатели контента слышат только их версию истории.

Были предприняты дополнительные попытки дипломатического урегулирования, но они, похоже, не увенчались успехом. Буквально на днях генеральный директор заявил, что для изменений не было никаких технических или качественных причин, сильно намекая на то, что это было сделано только для того, чтобы навредить даунстримам.

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

Эпилог: Что на самом деле происходит с темами?

Теперь, когда мы разобрались с тем, что System76 приложила руку к разжиганию споров, позвольте мне прояснить, как на самом деле обстоят дела, и что могут сделать производители компьютеров и другие графические окружения в дальнейшем.

Термины, которые следует знать

Это поверхностный разбор, но поскольку мы говорим о технических деталях, необходимо знать некоторые термины:

GTK и темы

Позвольте мне сразу прояснить ситуацию: в самом GTK между GTK3 и GTK4 ничего не изменилось в инфраструктуре тематизации. Единственные изменения перечислены в руководстве по миграции, и в основном это удалённые или заменённые специфические для GTK функции CSS. Все изменения, вызвавшие споры, связаны с libadwaita.

Возможно, вы видели, как некоторые люди поднимали два открытых issue в качестве контраргументов к этому:

Что означают эти два issue? Ну, это означает, что команда GTK считает, что их лучше решать в библиотеках платформы. Это не значит, что речь только о libadwaita или только о libgranite, и не значит, что приложения на базе GTK больше не смогут иметь тёмную тему или разные темы. Платформенная библиотека будет отвечать за обработку этих элементов в соответствии со своими целями.

Графические окружения X, Y и Z могут работать вместе и создать libxyz, которая загружает различные таблицы стилей так же, как это делает GTK сейчас, или они могут создать свою собственную библиотеку для платформы, которая будет удовлетворять их специфическим потребностям. Предлагаемые изменения GTK просто отдадут выбор в руки каждой платформы.

GNOME, libadwaita и темы

В апреле, когда Adwaita была перенесена в libadwaita, было сделано спорное изменение, переопределяющее gtk-theme-name. В коммите объясняется обоснование этого конкретного изменения:

Убедитесь, что Adwaita загружена вместо темы по умолчанию, обратите внимание на загрузку Adwaita-hc, если HighContrast (прим. переводчика: режим высокой контрастности) выбран для всей системы.

Почему мы хотим быть уверены, что libadwaita загрузилась вместо других таблиц стилей? Это сводится к двум ключевым моментам:

В GNOME мы хотим иметь стабильную платформу, на которой разработчики приложений смогут создавать новые, полезные и хорошо интегрированные приложения. Частью стабильной платформы является стабильный визуальный API. Руководство по человеческому интерфейсу (прим. переводчика: Human Interface Guidelines или HIG) GNOME излагает идеи и цели, которым должны следовать приложения, ориентированные на GNOME, а libadwaita помогает разработчикам реализовать эти идеи. Сама таблица стилей является частью поддержания интерфейсов в соответствии с HIG.

В libadwaita виджеты, таблица стилей и HIG объединены в один простой в использовании пакет. С каждой новой версией GNOME мы можем итеративно дорабатывать их все сразу, поэтому разработчикам будет проще следить за различными изменениями. Это контрастирует с текущим состоянием разработки, когда разработчикам приложений приходится реализовывать собственные версии общих шаблонов или копировать их из других приложений.

Использование Adwaita таким образом означает, что приложения также должны полагаться на его наличие, и приложения будут делать предположения на основе этого. Например, мы хотим, чтобы разработчикам приложений было очень просто изменять цвет виджетов. Раньше, если приложения хотели это сделать, им нужно было зависеть от sassc и libsass и время от времени регенерировать темы на лету. Теперь все, что им нужно сделать, это установить background-color у виджета.

Этот новый метод отлично работает с новой таблицей стилей Adwaita. Здесь у нас есть простое приложение Color Picker:

Color Picker использующий таблицы стилей Adwaita

Color Picker использующий таблицы стилей Adwaita

Переокрашивание по-прежнему хорошо работает с таблицами стилей, основанными на Adwaita, например, Yaru:

Color Picker использующий таблицы стилей Yaru

Color Picker использующий таблицы стилей Yaru

Все начинает ломаться с таблицами стилей, которые слишком сильно отклоняются от Adwaita:

Color Picker использующий таблицы стилей Pop

Color Picker использующий таблицы стилей Pop

Без форсирования Adwaita в качестве таблицы стилей, приложения могут выглядеть некорректно, а в некоторых случаях вообще не функционировать. Более подробное описание проблемы с большим количеством примеров можно найти в статье Тобиаса Бернарда “Рестайлинг приложений в масштабе”.

Послесловие от переводчика

Добавлю от себя личное мнение: System76 не стоит вообще никакого позитивного внимания. И вот почему:

Полезные ссылки