Субъективная попытка оценить мир open source, с позиции рядового контрибьютора, спустя два года ежедневного участия. Не претендую на истину, не напрягаю советами, только структурированные наблюдения. Возможно, эта статья поможет лично вам понять — быть или не быть open source contributor'ом.

NOTE: Примеры будут рассматриваться в контексте GitHub, так что Bitbucket, GitLab — извините за дискриминацию

Как разработчик, я с самого начала использовал готовые решения из мира открытого исходного кода. Это был бездумный Ctrl+C/Ctrl+V команд для установки и запуска чужого пакета из документации. Как теленок не думает откуда, берется молоко, так и Junior-разработчик не заморачивается над тем, кто и как пишет эти пакеты. Проблема решена — переходим дальше, не работает — продолжаем поиски.

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

Долгое время я выбирал путь "написания решений с нуля", но став осознаннее, начал создавать issues и вскоре перешел к работе над исправлениями и новым функционалом. Конечно страшно сходу вносить изменения в код, поэтому я зашел со стороны документации. Получив понимание процессов, я пробовал решать функциональные задачи. Так начался мой путь в open source, и теперь я воспринимаю этот мир по-другому, ведь я знаю "откуда молоко" и как сделать лучше.

За несколько лет я достаточно освоился и сейчас у меня есть 3 персональных проекта, за которые не стыдно (+7 проектов "так себе"). Возглавляю организацию figma-plugin-helpers и пытаюсь построить open source комьюнити вокруг Figma. Принимаю активное участие в комитете i18n проекта Node.js, где занимаюсь построением процессов локализации. Ну и сделал множество разовых issue и PR, в различных проектах, с которыми я случайно сталкивался. Ниже я выделил некоторые проблемы и преимущества замеченные на протяжении этого времени.

Преимущества

Начну с "хорошего", а именно почему мне нравится тратить +30 минут в день, на бесплатные проекты с открытым исходным кодом.

Разносторонний опыт в программировании

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

Рутина — главный убийца интереса, как в ежедневной работе, так и в профессии в целом. Наши заботливые (и не очень) начальники изо всех сил стараются угодить, ведь недовольный сотрудник завтра убежит к соседям. Тут тебе и смузи по утрам, и электрогитара в офисе, и абонементы в спортзал, но как бы они не старались, решающим фактором (после ЗП) остается проект. Будь то интересный стартап на модных фреймворках, или же enterprise на Angular 1.X, так или иначе настанет момент, когда всё надоест. Такова природа человека — обесценивать всё чем он обладает, и зариться на соседское.

Надоело писать на своем стеке? Не спеши бегать по собесам, а просто найди интересный для тебя проект в мире open source, и вперед.

NOTE: Я не против смены работы, просто нужно мыслить адекватно. Если проект объективно хороший, и всё нравится, но "просто надоело одно и тоже", то не стоит сразу менять футболку EServe на SoftPAM.

Другая проблема возникает если ты сидишь на одном проекте уже больше года и не можешь поддержать разговор про другие технологии. Чтобы не выпадать из контекста мировых событий, можно уделять по 30 минут на twitter/habr, но как насчет практики? Hackerrank, Codewars, LeetCode и другие платформы помогут с алгоритмами, но реальной практики по паттернам программирования, архитектуре и прочему не будет. Здесь может помочь — open source!

Огромный выбор проектов на любой вкус, от инди разработок до трендовых фреймворков, от больших monorepo до однофайловых пакетов. Захотелось попробовать новый фреймворк/подход/язык — глобальный поиск GitHub уже ждет.

Свобода

Да простит меня мой учитель математики, за мои изыскания ниже:

На работе A мы обязуемся выполнять x задач, за вознаграждение y на протяжении времени T. Эта формула для лабораторных условий в вакууме. Для применения её на практике следует добавить коэффициент реальной жизни q:

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

Если же применить этот расчет на open source, то все переменные будут вычеркнуты. В этом и есть свобода, никаких ограничений, требований, боссов и дедлайнов, только интересные задачи, которые можно решить используя новый подход или стек. Появилось желание — покрываю тестами v14 Node.js, завтра надоест буду смотреть YouTube, и никто не спросит с меня за тесты, даже если я никогда их не закончу.

NOTE: Формулы выше не более чем литературный прием, просьба не искать в них глубокий смысл или математическое обоснование.

Развитие soft skills

Одна голова хорошо, две лучше, а все maintainer'ы отлично, но сложно. Работая над очередным фиксом или фичей, конечно же хочется в итоге залить его в master. Для этого нужно не просто написать хороший код, но еще и отстоять свою идею и доказать правоту. В мире open source царит демократия, и каждый готов озвучить свою точку зрения.

Чем серьезнее проект и чем активнее в нем комьюнити, тем больше придется общаться. Каждый PR и каждый issue это новая дискуссия, новый шанс потренироваться в искусстве убеждения и попрактиковать English.

Кроме коммуникативных умений, можно развивать лидерские качества. Это могут быть как создание и управление своего проекта, так и лидирующие позиции в чужих. Конечно же, в личном проекте не стоит ожидать наплыва сотен тысяч пользователей, которыми нужно управлять, но чтобы правильно ответить на первый issue тоже потребуется сноровка. Например, в самом активном персональном проекте react-microsoft-login за полтора года существования набралось всего 18 issues. В более масштабных opensource проектах от Node.js, Figma, Adobe, я учусь вести переговоры, управлению командами и менторству. Врядли я бы мог заниматься тем же на основной работе, в силу специфики аутсорса, да и просто потому что дело гребца грести.

Самореклама

По ходу работы над проектом можно пересечься с разными людьми по всему миру, тем самым формируя сеть знакомств. Звучит немного по-еврейски, но связи сильнее денег, и на них держится кремниевая долина, где команда для стартапа может сформироваться в очереди за кофе. Здесь то же самое, только онлайн. Подискутировали под несколькими issue, потом в Slack просишь просмотреть твой PR, слово за слово и уже вроде как знакомы.

NOTE: Да-да, крупные open source проекты часто имеют свой slack-workspace

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

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

Если опустить романтичные мечты о собственном деле и вернуться в галерные будни, то здесь тоже есть своя выгода. Приходишь на собеседование, а тебе кофе, печеньки и оффер, потому что ты core contributor в create-react-app. Другому кандидату с идентичным опытом, скорее всего придется отвечать на банальные вопросы в духе "какие вы знаете типы в JavaScript?", ну вы понимаете.

Карма

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

Проблемы

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

Иерархия

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

Прочитав все CONTRIBUTION.md и поучаствовав в нескольких обсуждениях, можно определить активных участников и "теоретических" боссов. Казалось бы всё, вопрос решен, но! Никто ни за что не отвечает, ни в масштабах проекта, ни в масштабах отдельной задачи. Нет начальника, который назначит задачу и дедлайн, нет исполнителя, который обязан закрыть issue. Также как от меня никто не может требовать написания тестов для v14 Node.js, также и я не могу требовать этого от других. В результате, может случится так, что эти тесты никто и никогда не напишет.

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

• Как можно релизить не покрытую тестами новую версию продукта?
• Кто за это отвечает?
• Кто должен был написать тесты?

На коммерческом проекте эти вопросы резонны, в open source — нет. Это так называемая коллективная ответственность, в которой нет ни героев, ни виноватых.

Планирование

В отличие от коммерческих проектов, здесь отсутствует привычный план разработки. Здесь нет JIRA/Trello карточек, прикрепленных к конкретным личностями. Это non-paid участие и следовательно никто не может устанавливать сроки и требовать выполнения задач. Такое положение вещей приводит к хаосу, где каждый делает то, что ему вздумается.

Можно возразить, что мол есть GitHub Projects (Trello на минималках встроенный в GitHub) и Milestones, которые используются на серьезных проектах.

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

Наверное пора открыть завесу тайны — деда мороза не существует эти доски ведутся "заинтересованными" людьми. Интересом может выступать:

• финансовая поддержка — оплачиваемая из спонсорских взносов
• энтузиазм — авторы идеи или core-разработчики, которые просто радеют за продукт

В таких случаях всё работает по правилам коммерческой разработки, и если с денежной мотивацией всё ясно — работает пока платят, то с энтузиазмом — всё очень неконтролируемо. Из этого я сделал вывод, что модель бесплатного open source не может похвастаться стабильностью и планомерностью, что в свою очередь влияет на производимый продукт и developer experience. Оплачиваемый open source пока только начинает набирать обороты, поэтому его в расчет не берем.

Пинг

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

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

• day 0: я создал issue
• day 0: Отметил целевых участников: user1, user2
• day 1: user1 отреагировал смайликом 0_0
• day 2: user2 добавил метку "bug" и прокомментировал "Thanks for contribution. I'll take a look"
• day 5: user1 прокомментировал "please add details about X and Y"
• day 6: я добавил комментарий с деталями по X и Y
• day 7: user1 прокомментировал "okay thanks"
• day 12: я прокомментировал "any progress"
• day 24: я прокомментировал "friendly reminder"
• day 30: я прокомментировал "ping ping"
• day 60: user2 прокомментировал "was busy for last months, will take a look soon"
• day 60: я прокомментировал "sounds great, thanks"
• day 65: user2 прокомментировал "PR with fix #000"
• day 67: issue закрыто после успешно принятого PR

NOTE: Извините за такой формат вместо ссылки/скриншотов с реальным примером, не хочется палить контору, но скажу что проект достаточно большой и известный

Вывод

Подводя итог хочу отметить что мне нравится open source и что со всеми его недостатками можно жить. Возможно я поступил не совсем корректно, сравнив open source и коммерческую разработку. Моей целью не было раскритиковать или возвысить один из подходов, ведь они безусловно отличаются, хотя и преследуют одну и ту же цель — создать продукт. Я смотрю на мир open source из мира out source, и решил поделится собственными наблюдениями, которые могут быть полезны таким же мечтателям.