Мои отношения с опенсорсом

Автор и мейнтейнер нескольких опенсорсных проектов, Эндрю Галлант пытается снять напряжённость, которая в последнее время накопилась в части опенсорсного сообщества. Крики души «Каково быть мейнтейнером свободного ПО», «Неблагодарный opensource» и другие жалобы мейнтейнеров породили дискуссию об агрессивности, грубости, неблагодарности, эмоциональном выгорании и тяжести бескорыстной поддержки проектов. Пост опубликован 19 января 2020 года, — прим. пер.

Хочу отойти от традиции говорить почти строго на технические темы — и поделюсь частью личных отношений со свободным и открытым программным обеспечением (FOSS). Хотя все люди разные, надеюсь, что обмен мнениями поможет наладить взаимопонимание, сопереживание и доверие в нашем сообществе.

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

Это ни в коем случае не призыв о помощи. Речь о понимании. Я не призываю изменить экономику FOSS или обсуждать моё психическое здоровье. Я не говорю о привлечении дополнительных мейнтейнеров. Просто хочу поделиться своей историей и попытаться увеличить эмпатию в сообществе FOSS.

Целевая аудитория: все, кто занимается опенсорсом.

Содержание

• История
• Проклятые эмоции
• Гнойный негатив
• Работа через силу
• Грубость
• Правомочия
• Ещё о правомочии
• Доверие
• Лучше, чем кажется
• Вывод

История

Мой самый первый опенсорсный проект вышел почти 16 лет назад — доска объявлений на PHP. В то время почти все создавали такие штуки, и именно так я научился программировать. Проект изначально начинался как школьная система для проведения обсуждений (в то время школы вообще никак не работали с интернетом, кроме хостинга дерьмовых сайтов). Тогда я впервые столкнулся с трудностью эстимейтов. Проект затянулся гораздо дольше, чем на один семестр, и постепенно перешёл в хобби, выходящее за рамки школьного проекта.

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

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

Моя история FOSS далее продолжалась с несколькими релизами моей доски объявлений и wtcSQLite, простого клона phpMyAdmin, но для SQLite.

Когда я перешёл с Windows на Linux где-то в 2009 году, то запустил ещё больше проектов, но на Python и X11. Среди них PyTyle для закрепления рамок в многооконном менеджере и openbox-multihead, моя реализация поддержки нескольких мониторов в Openbox. Эти проекты, вместе с некоторым исследованием Go, привели меня к созданию оконного менеджера на Go, который я использую до сих пор.

Шло время, и примерно шесть лет назад я начал писать на Rust. Первой библиотекой стала quickcheck, но за ней последовала масса других: regex, docopt.rs, rust-csv, fst, termcolor, walkdir и многие другие в течение следующих шести лет.

Хотя подавляющее большинство моих проектов Rust — это библиотеки, но есть и инструменты командной строки, такие как xsv и ripgrep.

Многие из моих старых проектов сейчас фактически мертвы или поддерживаются другими, но я продолжаю поддерживать большинство проектов на Rust. Или их вытеснили чужие крейты лучшего качества (например, как crossbeam-channel вытеснил chan).

Сегодня мне по-прежнему нравится много программировать, но я также трачу много времени на код-ревью, отладку проблем с конечными пользователями, ответы на запросы функций и другие подобные вещи. Это неизменно означает взаимодействие, работу и общение с другими людьми.

Проклятые эмоции

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

Эмоции протекают глубоко и могут быть действительно полезным источником для внутренней мотивации. Например, в течение некоторого времени после выпуска ripgrep я реально ненавидел трогать код, отвечающий за вывод результатов поиска. Он был путанным, глючным и трудноизменяемым. Полностью переписать код — совершенно логичное решение, которое можно принять на чисто технических основаниях, но я был мотивирован сделать это из чувства отвращения. Мне просто не нравились свои ощущения. Эмоции помогли исправить ситуацию, помочь самому себе. Например, теперь вывод изолирован в отдельную библиотеку с тщательными тестами, и я чувствую себя гораздо лучше каждый раз, когда нужно зайти в этот код и что-то делать. Это всё ещё не лучшая моя работа, но уже большое улучшение — по крайней мере, с эмоциональной точки зрения — по сравнению с предыдущим состоянием.

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

У эмоций есть и обратная сторона. Любой, кто выпускал и поддерживал какое-то достаточно популярное программное обеспечение, обязательно контактировал с другими людьми. Оказывается, другой человек может оказать ошеломляющее влияние на ваше эмоциональное состояние. Позитивный жест или комментарий может украсить ваш день. То самое чувство: да, выложить мой код было так важно, что помогло этому человеку. Но, как подтвердит любой мейнтейнер, положительные комментарии почти всегда затмеваются отрицательными.

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

Эти мысли могут привести к эмоциям, которые начнут вас разъедать. И это самый вероятный сценарий, когда речь заходит о негативных комментариях.

Гнойный негатив

Я быстро научился преодолевать негативные эмоции от баг-репортов. В самом деле, хорошие сообщения об ошибках с лёгким воспроизведением вскоре становятся приятными, потому что они, как правило, очень редки. Большинство багов вообще не воспроизводятся, даже если вы предоставляете шаблон для проблемы с явным запросов всех параметров (issue template). Вероятно, отправитель хочет как лучше, но информации просто недостаточно, чтобы воспроизвести ошибку. И начинается возня взад-вперёд в попытке изолировать баг.

Лично для меня именно это самая мучительная область. Эмоции берут верх, потому что я могу думать только об одном: почему этот человек не нашёл время, чтобы прочитать и заполнить шаблон для проблемы? Или если баг возникает из-за ошибки пользователя, который не читал документацию, я могу думать только: я потратил время, чтобы подарить этому пользователю какое-то программное обеспечение, а он перед подачей баг-репорта даже не может прочитать README?

Это сводит с ума. Конечно, эмоции не всегда рациональны. Вероятно, документация могла быть яснее. Или пользователь мог не заметить этот пункт. Может, у него нет опыта ведения проектов FOSS или подачи баг-репортов и, возможно, он не знает, как помочь в простом воспроизведении бага. Всё это вполне разумные предположения, и именно поэтому я делаю всё возможное, чтобы эмоции не взяли верх. Хотя сопереживание человеку на другом конце провода тоже важно.

Пусть нигде не написано «Приглашаю вас использовать мой код», но я делаю массу вещей только потому, что моё намерение состоит в том, чтобы другие использовали мой код. Я пишу более подробную документацию, примеры использования. Я настроил непрерывное интеграционное тестирование. Сделал README для новичков. Ссылка на проект указана на многих моих страницах. Если люди принимают это приглашение использовать мой код или считают открытый баг-трекер приглашением сообщать об ошибках, то я не должен наказывать их, когда они действительно присылают эти сообщения. Автор плохого баг-репорта наверняка думает, что он сделал всё возможное. И пока они действуют из добрых побеждений, я действительно стараюсь отвечать тем же.

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

Иногда моё нетерпение проявляется в излишне кратких ответах. Я изо всех сил стараюсь стать лучше в этом отношении. Процесс самосовершенствования ещё не закончен.

Работа через силу

Если вы мейнтейнер популярного проекта или нескольких обычных репозиториев, вам идёт почти непрерывный поток баг-репортов и пул-реквестов. Они поступают ежедневно. Угнаться за ним почти невозможно. Размер кэша моего мозга необычайно мал, поэтому я не очень хорошо переключаю контекст между проектами. Как результат этого феномена, я быстрее разгребаю баг-репорты и пул-реквесты для тех проектов, с которыми недавно работал. Вероятно, эти проекты более доступны или лучше адресуются на последних страницах мозгового кэша.

Но в других проектах список проблем начинает накапливаться. Каждый день вы видите новый issue и говорите себе: «Да, на этот я действительно посмотрю, как только вернусь с работы». Но приходит что-то новое. В итоге, мотивация переключить контекст возникает только тогда, когда пользователь ежемесячно пингует вас в течение четырёх месяцев — вероятно, его пул-реквест действительно важен.

Извините, в последней фразе было немного сарказма, но в то же время это правда. Асимметрия пользователей и мейнтейнеров снова в действии, но я действительно стремлюсь расчистить очередь пул-реквестов и развивать проект. Я хочу внести вклад этого пользователя не только чтобы он продолжал использовать мой код, но и чтобы он сам был счастлив. Во многих случаях достаточно всего часа, чтобы проработать пул-реквесты и все проблемы, требующие действия.

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

Для этого феномена я применил способ, который очень эффективно использую в личной жизни: устанавливать границы. Вежливо, но твёрдо установить границы — один из тех волшебных лайфхаков, который приносит дивиденды сразу, как только вы ему обучитесь. Если вы не знаете, как это делается, то я вряд ли могу объяснить. Однако установление границ позволяет сосредоточиться на том, что важно для вас, а не для других.

Очевидно, надо стремиться к равновесию. Установление границ не означает, что можно сосредоточиться только на своих делах. Но способность поставить эту стену и сказать: «Нет, я не делаю X, но с радостью сделаю Y» — действительно сотворила для меня чудеса. Мой секрет — приводить доводы, с которыми другие не могут спорить, основываясь на собственном опыте и пожеланиях.

Какое отношение это имеет к опенсорсу? Лично для меня ключевым было установить границу между собой — и всеми этими бесхозными проблемами с пул-реквестами. Нужно как-то внушить себе: «Я добровольно трачу своё время, и это нормально, что я не отвечаю вовремя. Уверен, большинство людей поймут это и отнесутся разумно».

Это также проявляется при обсуждении запросов новых функций. Иногда запрос может иметь некий смысл для вашего проекта, но эта функция подразумевает большое бремя поддержки. Я научился устанавливать границы: можно сказать «Нет» функции только на том основании, что вы не хотите тратить дополнительное время на поддержку. Как это уже не раз случалось, потом можно и передумать! Например, если код улучшился, стал более доступным для обслуживания — вы можете заметить в себе больше желания внедрить новую функциональность. Но если нет, то я делаю всё возможное, чтобы нащупать свои границы и отказаться загружать себя лишней работой, которая не доставляет удовольствия.

Хотел бы я написать пошаговую инструкцию, как устанавливать твёрдые границы и перестать чувствовать себя плохо из-за нагромождения проблем. Это не совсем избавляет от негатива, но сильно помогает.

Грубость

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

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

• «Ваш инструмент не работает [для моего нишевого случая], поэтому он сломан».
• «Просто вмешаюсь, чтобы сказать, что мне тоже очень понравилась бы эта функция» (Примечание. Кажется, некоторые читатели никак не могут смириться, что я называю это «грубостью». Возможно, это слишком сильное слово, но когда в обсуждении накапливаются такие «поддакивальщики», это просто добавляет шума в электронной почте и может раздражать. Вместо этого приветствуются смайлики или можно добавить немного деталей к вашему конкретному случаю использования. Впрочем, это смотрится довольно мелко на общем фоне, и я действительно вижу, что здесь частично моя проблема).
• Настаивать на том, что для реализации функции нужно «всего лишь сделать X».
• Пассивная агрессия, когда вы передаёте дальше запрос на функцию.
• Неконструктивное нытьё о программном обеспечении в [вставьте тут любое социальное медиа].
• Вариации на тему «Почему вы изобретаете велосипед?» или «Почему бы вместо этого не внести свой вклад в существующий проект?»

Во многих случаях грубость является результатом искреннего разочарования со стороны пользователя. Сколько раз вы сами бурчали себе под нос, когда какой-нибудь инструмент вёл себя не так, как вам хочется? Не имеет значения, что этот инструмент, вероятно, подарили вам бесплатно. Вы просто пытаетесь решить проблему, а инструмент становится на вашем пути. Я сам определённо чувствовал это. По-моему, совершенно нормальное человеческое чувство.

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

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

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

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

Для этого бывает достаточно просто сказать: «Мне не нравится, как вы сказали X. Думаю, будет намного продуктивнее, если мы откажемся от подобных обращений в будущем».

Но в некоторых случаях люди не очень хорошо реагируют на такие слова. По моему опыту, они обычно их игнорируют. Если они продолжают грубить, я могу повторить это пару раз, потому что некоторым нужно услышать что-то больше одного раза, чтобы до них дошло. По крайней мере, я знаю такое по себе (к большому неудовольствию моей жены). Если это по-прежнему не работает, и меня всё ещё беспокоит их тон, то я прекращаю взаимодействие. Достаточно просто закрыть или заблокировать issue или пул-реквест, или пойти дальше вплоть до блокировки пользователя на [вставить здесь социальное медиа].

Правомочия

Давным-давно я разговаривал с некоторыми близкими друзьями, которые уезжали за границу. Только вернувшись в США, они поделились небольшим примером культурного шока. Главное?

Никогда не думал о том, как сильно американцы любят принуждать.

Действительно ли это особенность всей американской культуры или только окружения — не будем обсуждать. Смысл в том, что одни люди любят говорить о том, что должны делать другие люди. Я вырос на таких подачах от людей с самых разных ступеней властной иерархии — и испытываю к этому поистине врождённое отвращение.

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

Немного отступая назад, использовать слово «должен» само по себе не обязательно плохо. Но что действительно меняет его значение, на мой взгляд, — это наличие приглашения. Если вы попросили у кого-то совета по теме, и он говорит что-то вроде «Да, вы должны сделать X», то это не так уж плохо звучит. Но если человек явился без приглашения, возникает совершенно другое чувство.

В опенсорсе я видел или испытал это в нескольких вариациях:

• Вы должны выпустить новый релиз.
• Вы должны переписать это на [вставьте здесь язык программирования].
• Вы должны переименовать проект.
• Вы должны [вставьте здесь фундаментальные архитектурные изменения].
• Вы должны изменить лицензию своего проекта.

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

Хотя я ещё не научился спокойно реагировать на такие комментарии, я делаю всё возможное, чтобы продолжать устанавливать границы. Здесь у меня две стратегии:

• В особо распространённых ситуациях, типа вопросов «Когда следующий релиз?», я отвечаю, что моё свободное время не распланировано. Это помогает поместить такие ответы в некое подобие FAQ.
• В противном случае стараюсь применять принцип пропорциональности. Если на входе одно или два предложения, бездумно предлагающие что-то огромное, то я потрачу только одно или два предложения в ответ.

Повторю, что этот тип комментариев иногда может привести к продуктивным вещам. Например, когда я начал первые открытые проекты на Rust, то везде указывал UNLICENSE. Однажды один прохожий посоветовал мне лучше использовать какую-нибудь «рабочую» лицензию, вместе с некоторой (казалось) снисходительной лекцией о том, как работает лицензирование. Я не очень хорошо отреагировал на это и был очень раздражён. Но совет оказался хорошим. Когда кто-то другой более вдумчиво поднял его, я действительно решил ему последовать.

Оглядываясь назад, можно посчитать меня мелочным. Как будто я отказался делать что-то правильное только потому, что мне не понравился тон комментатора. Но я ощущал всё совсем иначе. Поскольку меня сразу поставили в оборонительную позицию, то эмоции просто не позволяли ясно думать.

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

Ещё о правомочии

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

Здесь нет никаких юридических отношений. В моих лицензиях ничего не говорится о моих обязанностях это сделать. Я считаю, что этот факт подразумевается сам собой для людей, действующих добросовестно.

Доверие

И это приводит нас к доверию. Доверие является важной ценностью в open source. Я не только тщательнейшим образом выбираю, кому могу доверять, но и стараюсь действовать так, чтобы другие могли доверять мне.

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

Используя СПО и стараясь быть разборчивым в зависимостях, невозможно просмотреть каждую строку кода во всех зависимостях. Даже если я каким-то образом сумею всё это прочитать, я уж точно не смогу понять код для уверенности, что он делает то, что положено.

Именно здесь огромную роль играет доверие. Доверие служит посредником для оценки некоторых качеств кода, который я использую. Оно помогает ответить на следующие вопросы:

• Разумно ли ожидать, что код будет вести себя так, как заявлено?
• Будут ли исправлены ошибки в разумные сроки?
• Продолжится ли этот проект?
• Присутствует ли здравый смысл при учёте конкурирующих интересов?

Это тяжкое бремя для мейнтейнера, который работает в свободное время. Как бы то ни было, таковы критерии надёжного мейнтейнера. Сейчас я не обязан использовать зависимости исключительно от мейнтейнеров, которым сам доверяю. Это непрактично. Вместо этого доверие — просто ещё один критерий для выбора, какой код использовать. Если автору можно доверять, то я с гораздо большей вероятностью возьму его библиотеку, когда речь заходит о решении сложной проблемы или поиске тонкого компромисса.

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

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

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

Лучше, чем кажется

До сих пор я много говорил о негативе. Любой разумный человек после этого спросит: «Зачем подвергать себя таким мучениям?» На самом деле, подавляющее большинство моих контактов в опенсорсном сообществе довольно нейтральны. Существует также очень много крайне позитивного общения. И если возникает негатив, большинство сразу извиняются, когда я объясняю свои границы. Один товарищ однажды настолько застыдился, что прислал мне подарочную карту (которую я пожертвовал) с извинениями.

Чтобы не быть голословным, вот что мне нравится как мейнтейнеру:

• Слышать, что люди используют мой код. И особенно слышать, как это им помогло. Наверное, мой любимый отзыв был такой: «Да, мы выпустили вашу библиотеку в продакшн, и она по сути просто работала. Нет вопросов».
• Получать хорошие баг-репорты, где баги легко воспроизводятся.
• Получать хорошие баг-репорты, где баги трудно воспроизводятся, но от автора, который хочет помочь в отладке. Лучшие случаи — это почти как сеанс асинхронного парного программирования, где мы пытаемся найти ключ к загадке.
• Обновлять changelog, каким бы маленьким он ни был, непосредственно перед релизом. Приятно вспоминать о работе, проделанной не только мной, но и другими.
• Хотя время обычно не позволяет, но люблю помогать пытливым ученикам, независимо от уровня опыта. Жаль, что не могу делать это чаще.
• Когда участники помогают мне найти простые решения сложных проблем. Это происходит гораздо чаще, чем вы могли бы ожидать, и каждый раз это прекрасно.
• Писать регрессионные тесты. Нет ничего лучше, чем кодировать знание, что баг не способен появиться снова.

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

Вывод

Будучи мейнтейнером FOSS, я получил много интересных впечатлений. И плохих, и хороших. В этой статье я попытался выразить некоторые из них, чтобы помочь всем лучше понять друг друга. Это не обязательно обобщение универсального опыта, потому что переживания прошли через моё личное восприятие мира. Например, мой индивидуализм по жизни сильно влияет на то, как я воспринимаю опенсорс. Для меня это в значительной степени личное дело, а не более альтруистическая попытка улучшить общество. Кто-то может смотреть на мир иначе, что повлияет и на его отношение к FOSS.

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

В статье я перечислил множество видов поведения, которые считаю негативными. Не все воспримут их так негативно, как я. Это нормально и ожидаемо. Более того, я сам совершал некоторые из этих негативных поступков. Люди не совершенны, и мы никогда не сможем быть полностью чуткими 100% времени. Это тонкие вопросы, и я надеюсь, что мы способны улучшить ситуацию, хотя бы немножко.

Автор: ITSumma

Источник