Относительно недавно я сменил движок блога с Ghost на статичный Hugo. А вместе с этим сделал полноценную тему для него – простую, без наворотов, в стиле минимализма.

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

Спустя пару-тройку дней я сильно удивился – уже пошли первые звёзды и форки на гитхабе. Но радовался я недолго – сразу же за местными лайками пошли местные проблемы – issues (это слово будет без перевода в данном посте).

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

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

Не представляю, как справляются авторы популярных библиотек. Приведу примеры, которые видел (все из мира PHP, так как мне ближе всего).

• Faker, библиотека для генерации случайных данных: ФИО, адреса, полноценные тексты и прочее. На момент написания поста - 154 PR, 56 issues. Беглый взгляд по PR — фикс UK почтовых кодов, добавление ещё одного языка, фикс опечатки в немецкой профессии. Как это всё ревьюить – я не представляю. Либо искать/ждать людей, которые могут подтвердить, либо добавлять на веру.
• Codeception, популярная тестовая библиотека, с помощью модулей позволяющая проводить и юнит, и интеграционное, и UI тестирование. 455 issues, 10 PR. Насколько я знаю, всего лишь один активный maintainer. Ещё есть создатель самого фреймворка, но он в основном делает CodeceptJS.I ssues — реальные баги в фреймворке, запросы на улучшения, просто вопросы по использованию.
• Phpstan, библиотека для статического анализатора кода. 430 issues, 0 PR. Баги, баги, баги и изредка запросы улучшений. При создании баг-репорта – просьба воспроизвести проблему на специальном сайте и приложить ссылку с примером. Автор пытается всеми силами избавиться от ложных проблем.

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

У меня всего лишь тема и далеко не такой уровень популярности, но я уже столкнулся со следующими ситуациями:

• предлагают изменение на две минуты, чуть ли не написанным кодом, но PR не делают;
• просят что-то сделать, и это не перекликается с моими планами, хотя в целом выглядит полезно;
• создают большой PR по неизвестному мне функционалу, в котором я сначала разбираюсь, а потом сижу и проверяю код. И думаю во время проверки, что быстрее бы написал с нуля, чем проверял всё это (и порой это даже правда);
• сообщают о странной ошибке, которую не получается воспроизвести. После запроса дополнительной информации issue закрывается на следующий день без комментариев.

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

Каких ещё ситуаций жду:

• просят сделать слишком специфичную фичу (не PR, а именно просят);
• делают PR, ты его вроде потестировал и принял, но он поломал всё;
• делают PR, в котором не слишком хороший код. Прошу о правках, никто не реагирует. PR остаётся висеть.

Восторг, красота!

Так вот, к чему я это всё. Перефразируя великого философа современности дядю Бэна, с большой популярностью репозитория на гитхабе приходит большая ответственность.

Тем не менее, звёзды – это кайф, конечно.