Трудно быть мейнтейнером проекта Open Source

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Автор — Сальваторе Санфилиппо, разработчик и мейнтейнер свободной СУБД Redis

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

Прошло несколько недель, я несколько раз начинал писать этот пост и останавливался, потому что не было времени хорошенько всё обдумать. Теперь, кажется, я завершил самоанализ своих слабостей, трудностей и желания свободы. Эти чувства неизбежно охватывают человеческий разум, когда он концентрируется на какой-то задаче, а в течение длительного времени проявляется негативный аспект. Безусловно, поддержка проекта Open Source также приносит много радости и удовольствия. Последние десять лет моей профессиональной жизни, безусловно, запомнятся надолго. Это хорошие годы, хотя и не самые лучшие (ещё веселее было во время запуска). Но здесь я сосредоточусь на негативной стороне. Просто имейте в виду, что есть и положительные моменты.

Лавина запросов


Я не верю в «быстрые действия», «быстрое мышление», «победу над временем» и тому подобное. Мне не нравится поверхностный мир с отсутствием концентрации и внимания, в котором мы живём из-за социальных сетей, чатов, электронной почты и графика, полного мероприятий. В первые годы Redis у меня ещё было много времени. Когда приходило письмо, я мог спокойно сосредоточиться на том, что пытается сказать автор. Мог вспомнить релевантную часть кода Redis и после тщательного рассмотрения вопроса, наконец, высказать свои реальные мысли. Я считаю, что именно так должны работать большинство людей, независимо от того, какова их работа.

Когда программный проект достигает популярности, как у Redis, а коммуникации между людьми настолько упрощаются, как в современных социальных инструментах, то всё меняется. Пользователи относятся к вам как неодушевлённой сущности, а количество сообщений, вопросов, запросов, предложений растёт экспоненциально. Но одновременно в сообществе Redis (хотя мне кажется, это общая проблема) очень медленно растёт количество людей, которые способны квалифицированно ответить на эти вопросы. Создаётся очевидная перегруженность. Большинство людей слишком прагматично подходят к этой проблеме. Закрываем тикет, если топикстартер в течение двух недель не ответил на наш вопрос. Закрываем все тикеты с расплывчатыми формулировками. И другие варианты по механической чистке потока. Но реальность такова, что для качественной обработки отзывов нужно время. Иначе вы просто притворяетесь, что в проекте мало открытых тикетов. Хорошо бы иметь много ресурсов для найма оплачиваемых фултайм-экспертов для поддержки каждой подсистемы Redis на полный рабочий день, но в реальности это неосуществимо.

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

Смена роли


Из-за лавины запросов, описанной выше, ваша работа тоже внезапно меняется. Redis стал популярным, потому что я вроде как умею проектировать и писать код. А теперь вместо этого я занимаюсь, в основном, рассмотрением проблем и пулл-реквестами. И постоянно кажется, что я сам написал бы лучший код, чем в этих пулл-реквестах. Хотя иногда код лучше, чем я мог бы сделать сам, потому что в сообществе Redis есть программисты и получше. Но большинство просто написаны для решения одной конкретной проблемы. В то время как я всегда представляю систему в целом, потому что работаю над ней уже много лет. Но больше нет времени этим заниматься. Таким образом, большие новые функции менее органично вливаются в основной код. Что тут поделать? Иногда я просто на нескольких недель забиваю на тикеты и пулл-реквесты, потому что кодирую или проектирую: это работа, которую я действительно люблю и наслаждаюсь. Но это, в свою очередь, усиливает психологическое давление, потому что я всех игнорирую.

Чтобы делать то, что я люблю и умею делать хорошо, приходится чувствовать себя дерьмом.

Время


Есть две проблемы длительной работы над одним проектом, по крайней мере, для меня.

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

Когда я работал один, то мог позволить себе свободный график. Как только я начал получать деньги от Redis Labs, моя этика больше не позволяла такое. Пришлось заставить себя работать по нормальному графику. Это серьёзная борьба с собой, которую я веду в течение многих лет. Более того, я уверен, что из-за этого качество и объём работы снизились, но ничего не поделаешь: так всё устроено в этом мире. Я не нашёл способа решить эту проблему. Я мог бы сказать Redis Labs, что хочу вернуться к своему старому графику, но нет смысла, потому что в данный момент я «отчитываюсь» перед сообществом, а не перед компанией.

Другая проблема заключается в том, что много работать над одним проектом — тоже сложное дело, ментально. В прошлом я специально менял проект каждые шесть месяцев. Вот уже десять лет я делаю одно и то же. Чтобы сохранить рассудок, я завёл подпроекты внутри Redis. Один раз я сделал кластер, другой — дисковое хранилище (теперь заброшено), потом HyerLogLogs и т. д. В основном, эти вещи полезны для проекта, но по сути представляют собой что-то другое. Но в конце концов вы всегда возвращаетесь к той же странице с тикетами и пулл-реквестами и каждый день делаете одно и то же: «Реплика отключается из-за тайм-аута» и так далее. Что ж, давайте разберёмся с этим ещё раз.

Страх


У меня всегда был некоторый страх потерять технологическое лидерство в проекте. Не потому что я недостаточно хорош в проектировании и разработке Redis, а потому что я знаю, что мои пути не совпадают с тем, чего хочет значительное количество пользователей, и с тем, что большинство людей в IT считают хорошим программным обеспечением. Поэтому приходится постоянно балансировать между тем, что я считаю хорошим дизайном, набором функций, скоростью разработки (медленной), размером проекта (минимальным) и тем, что я должен выдать большинству пользователей. К счастью, есть процент пользователей Redis, которые прекрасно понимают Redis-way, поэтому, по крайней мере, время от времени мне приходит пару слов поддержки.

Разногласия


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

Тщетность


Иногда мне кажется, что даже самое отличное программное обеспечение никогда не сохранится на века, как шедевр литературы. Обратите внимание, что это не из-за его качества, а как побочный эффект его утилитарной функции… Оно полезно на практике. Именно поэтому на смену придёт что-то более полезное. Хотелось бы иметь время и на другие занятия. Поэтому иногда кажется, что вся моя работа, в конце концов, тщетна. Мы проектируем и пишем системы, но потом появятся новые. Вообще, разве хоть один прикладной программист, а не теоретик с «большими идеями», способен оставить после себя какой-то след? Время от времени я думаю, что у меня была возможность работать над большими идеями, но я сосредоточился на написании программного обеспечения, а не на размышлениях о нём. Поэтому не смог использовать свой потенциал в этом отношении. Это некая противоположность синдрому самозванца: извините, что приходится быть более скромным.

Тем не менее, я смог проработать в течение многих лет, делая то, что я действительно любил, что дало мне друзей, признание, деньги. Нельзя сказать, что это была плохая сделка. Тем не менее, я полностью понимаю, что люди сталкиваются с огромными проблемами, как только их проект становится популярным. Эта статья посвящена им.
Источник: https://habr.com/ru/post/452332/


Интересные статьи

Интересные статьи

Содержание Основные различия Reproducibility crisis Система контроля версий Data Version Control Полезные ссылки Введение Несмотря на всю пользу DVC, об этом инструменте знает ...
На Хабре несколько лет подряд публиковались новости и статьи о модульных гаджетах — телефонах, ноутбуках, часах. Почти все эти проекты получали мощную поддержку IT-сообщества. Но за...
Лицензию назвали Cryptographic Autonomy License. Процесс одобрения был долгим и сопровождался жаркими дискуссиями внутри OSI. Часть сотрудников посчитала, что лицензия нарушает принципы открытого...
В последние несколько месяцев всё внимание мирового блокчейн-сообщества было приковано к запуску одного из самых масштабных криптовалютных проектов — Telegram Open Network (TON). Что на сам...
Автокэширование в 1с-Битрикс — хорошо развитая и довольно сложная система, позволяющая в разы уменьшить число обращений к базе данных и ускорить выполнение страниц.