На дворе 2026 год. Сообщество открытого ПО больше не про энтузиастов в подвалах или душных стариков, которые часами спорят за Pull Request +1/--1. Современная разработка открытого ПО напоминает толкучку: одни срочно переписывают код на Rust, другие так же срочно его оттуда выкидывают, а корпорации скупают проекты за миллиарды.

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

Я сам — разработчик и популяризатор открытого ПО, а также организатор сообщества питонистов в Новосибирске. Создаю свои проекты и активно помогаю dishka, faststream, wemake-python-styleguide и другим.

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

Зачем мы это делаем: три типа мотивации

Сейчас open source, мягко говоря, лихорадит как в горячке. Ломаются привычные процессы и всплывают накопленные ошибки. На дворе давно уже не 2010-е годы. Но факт остается фактом: сообщество меняется, меняются проблемы, а держится все за счет энтузиастов.

Представьте: вы за спасибо (а иногда и без него) изучаете код, который до вас писали сотни разных людей, чтобы решить бесячую ошибку. Мечта? В любом случае не все так страшно.

В open source не берут по блату. Тут не платят деньгами (во всяком случае, поначалу). Но сотни тысяч разработчиков каждый вечер открывают IDE и изучают чужие репозитории, тратя часы личного времени. А время, как мы знаем, самый ценный ресурс. Но зачем?

Я насмотрелся на многих людей и понял, что в итоге можно выделить три типажа. В реальности они перемешаны, но один мотив всегда перевешивает.

А можно так: утром PR, а вечером — деньги?

Каждый из нас знаком с типичными бизнес-задачами — еще та скука смертная. И карьера стоит на месте, и интерес пропадает. Но тут приходит идея — закоммитить фичу в библиотеку, которой вы сами пользуетесь. Не ради идеи, а потому что бесило ждать фикса.

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

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

Если ты хочешь роста и оферов, open source работает как лучший показатель навыков — не только хард-скилов, но и софт-скилов. Твой код уже проверили люди, которых нанимать не надо. Ты прошел ревью в проекте, который кормит пол-индустрии.

Например, Крис Латтнер — один из создателей LLVM, CLang, Swift и Mojo (язык-надмножество Python). Изначально работал на Apple, развивая LLVM, с 2017 по 2022 год работал в Tesla и Google. А в 2022-м основал компанию Modular AI для создания еще одной платформы для разработчиков ИИ.

Делать то, что доставляет удовольствие, — значит, быть свободным

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

Если ваша первичная цель не карьера и не деньги, то днем можно быть обычным тимлидом, а ночью — героем open source. Открывать чужие репозитории, слать PR в любимые утилиты. И не ради денег или карьеры. Ради чувства. Ради дофамина. Ради игры.

Например, Грег Хартман — человек, поддерживающий работу чуть ли не самого важного проекта в мире на чистом энтузиазме (и зарплате от фонда Linux).

А особенно яркий пример — Фабрис Беллар. Настоящая маниакальная тяга к творчеству. Этот человек не ищет славы или денег (хотя мог бы быть миллиардером). Он просто создает невероятные вещи ради вызова. Например, он создал QEMU и FFmpeg, а также придумал формат изображений TGA.

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

Такие люди — самая надежная прослойка open source. Они не выгорают, потому что получают удовольствие. Они приходят не за деньгами и остаются, даже когда денег нет. Но не стоит забывать и о контроле, так как выгорание мейнтейнеров — тоже известная проблема.

Ich dien!

Есть люди, которые верят и служат. Я бы сказал, что они могли бы позаимствовать девиз Принца Уэльского — Ich dien (нем. «Я служу»). Многие из них могут быть прагматичными, видеть в open source также и возможности для коммерциализации. Сам open source — по сути прагматичная эволюция FOSS.

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

Сразу же вспоминается Ричард Столлман, отец FOSS (и open source, по сути, более прагматичное направление FOSS), создатель GCC, проекта FSF, проекта GNU.

Кроме того, хочется вспомнить Вернера Коха — создателя GnuPG. В 2014 году Вернер оказался в тяжелом финансовом положении и публично заявил, что если не найдет 25 тысяч евро, ему придется бросить проект. Индустрия охнула и скинулась, но этот момент показал: один альтруист держал в руках безопасность половины open source. Он не ушел в бизнес, не запатентовал технологию — он просто делал работу, потому что это было правильно.

Было бы преступлением не упомянуть Патрика Фолькердинга — создателя Slackware Linux (старейший живой дистрибутив Linux). Он не идет ни в бизнес, ни в популярность — просто реализует свое видение UNIX-философии.

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

На практике все сложнее. Карьерист со временем начинает кайфовать. Игроку нравится идея свободного софта. Альтруист тоже хочет кушать. Но вектор понятен: open source держится на тех, кому это зачем-то реально нужно.

А деньги? Конечно, есть! Зеленые бумажки и тут замешаны. Бесплатный только сыр в мышеловке.

Во-первых — гранты. Многие компании поощряют развитие open source, пусть и, конечно, со своей выгодой. Например, тут же, на Хабре, часто проводят анонсы конкурсов open-source-проектов. Есть и иностранные гранты, но чаще всего вам требуется жить в другой стране.

Ну и, конечно, есть прогосударственное финансирование в виде Фонда содействия инновациям, всероссийского конкурса open source для студентов и школьников. А также финансируются и хакатоны.

Из более узкой сферы возможно спонсорство. Здесь играет роль, находишься ли ты в России, так как большинство программ (GitHub Sponsors, Patreon) нацелены на западные страны. Но даже у нас можно собирать донаты. Да, суммы очень скромные, если ты не Линус Торвальдс, но пара сотен рублей/долларов/криптотокенов на поддержку не помешают.

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

Устройство тусовки open source и роли

Со стороны open source выглядит плоской горизонтальной структурой. Пришел, форкнул, закоммитил — влили. Демократия и свобода чистой воды!

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

Open source подходит не всем

Многие из вас могут сомневаться, стоит ли пытаться делать вклад в проект open source.

Я помню свой первый PR: думал, опозорюсь на весь интернет, боялся, что ветку странно назвал. А еще и забыл тесты прогнать локально. Ревьюер, конечно, вздохнул и вежливо попросил проверять тесты. Кстати, тот PR в итоге отклонили: взялся за сложную задачу, связанную с typing.override из Python. Но я после пошел в другой проект, и там мой PR уже смержили. А началось все с того, что увидел простую задачу, — и понеслось. Сейчас, оглядываясь назад, понимаю: open source — это не страшно, это просто по-другому.

Правда в том, что open source подходит не всем. Он отсеивает людей жестче, чем любое собеседование. Просто тихо — ты либо остаешься, либо уходишь сам.

Кому в open source жить хорошо?

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

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

Мой опыт с первым PR был таким же. Ревьюер вежливо и популярно объяснил, где есть какие допущения. Я, увы, отказался — это было связано с проклятой вещью: typing override в Python.

Кроме того, open source полезен, если вам нужно портфолио. Рынок 2026 года — это рынок перегретых резюме. У каждого джуна два пет-проекта и стажировка. HR смотрит на стек, зевает и листает дальше. Но когда в резюме написано «контрибьютор CPython» или «фикс баги в pandas» — это работает иначе. Твой код уже проверили люди, которых нанимать не надо. Ты прошел ревью в проекте, который кормит пол-индустрии. Или, например, компания использует wemake-python-styleguide, а вы в нее как раз контрибьютили. Разницу между «исправил баг в Redis» и «pet-проект интернет-магазина» видно сразу.

И в-третьих, open source вам подойдет, если вы развиваетесь и вам нравится учиться и учиться у лучших. В open source нет курсов и менторов. Там есть код и люди, которые его написали. Если ты умеешь читать чужой код — ты будешь расти каждую минуту.

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

В open source нет отдела кадров, дружеской атмосферы и тимбилдинга с печеньками. Да, есть CODE_OF_CONDUCT, но многие общаются в соответствии со своим уровнем воспитания. Мейнтейнер может ответить сухо или даже резко — нужно быть готовым, что к коду будут относиться строго.

Как войти в open source?

Если у вас есть непреодолимое желание внести вклад в открытые проекты, то я расскажу как. Самый частый вопрос: с чего начать? Люди думают, что сначала надо выучить архитектуру проекта, прочитать тонну доков, стать гуру. А потом уже лезть с кодом.

Вранье!

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

Вот пошаговая инструкция. Делайте с чувством, с толком, с расстановкой — и все получится.

Найти проект, которым пользуешься сам

Не стоит идти в суперпопулярные проекты вроде React, VS Code и так далее. Там висят тысячи issues, конкуренция — как поступление в Гнесинку, а мейнтейнеры завалены PR и явно доберутся до новичков не скоро.

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

Например, вы пользуетесь библиотекой для создания CLI-приложений на Python и хотите добавить туда асинхронный режим. Создаете issue (если такого еще нет, конечно) и прикрепляете PR.

Или, например, вам не нравится просто формат текста исключения — оно непонятное. Идете в issue, описываете почему и как, прикрепляете и ждете ответа.

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

Отправиться в поиски своего Эльдорадо

Если вы хотите найти существующую проблему, а не заявить о найденной, то идите в issues. У issues есть лейблы (labels), которые позволяют помечать и сортировать сами эти issues.

Чаще всего это:

• good first issue;

• help wanted;

• beginner friendly;

• low hanging fruit.

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

• исправить опечатку в доке;

• добавить пример использования;

• пофиксить простую багу с воспроизводимым сценарием;

• перевести сообщение об ошибке.

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

Если метки нет — не берись. Значит, проект не готов к новичкам. Или все простые задачи разобрали. Или мейнтейнеры просто не ставят метки — тогда первый PR превратится в квест.

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

Изучить матчасть

Самое скучное и самое важное — изучи README, архитектуру и кодстайл проекта, а самое главное — файл CONTRIBUTING.md. Там написаны правила по неймингу, кодстайлу, нужно ли подписывать CLA (соглашение о передаче прав), как запускать тесты.

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

Сам я встречался с человеком, который растянул на неделю PR, так как не понимал, что такое CLA и как его подписать.

Потрать 10 минут на чтение. Сэкономишь время и нервные клетки.

Взаимодействовать с сообществом

Самая контринтуитивная часть. Кажется: зачем писать, если можно сразу сделать и отправить? Сделаю — увидят.

В реальности лучше так не поступать. Может возникнуть ситуация с двумя PR на один issue или задача, которая кажется простой, на деле требует рефакторинга проекта.

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

Это может дать подтверждение, что задача актуальна, возможно, даст подсказку, предупредит и просто запомнит тебя.

И не забывай коммуницировать и спрашивать, что тебя интересует, в комментариях под issue/PR.

Так куда податься?

Теория закончилась. Дальше — чистая практика. Я собрал места, где только рады новым и старым опенсорсерам — и создателям, и контрибьюторам, и мейнтейнерам, и новичкам.

Если остался иррациональный страх

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

Самым лучшим способом вклада будет изучить, чем вы пользуетесь каждый день, и найти мешающие недочеты. Но даже если нет таких — то спокойно идите на вкладку Issues, ищите по лейблам good-first-issue и другим, и берите их смело.

Также можно создавать свои проекты — и необязательно огромные комбайны или фреймворки. Например, сообщество будет радо портированию какого-нибудь плагина из VSCode в Vim/NeoVim.

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

Мейнтейнеры и ревьюеры не кусаются. Они напишут в PR:

• «тут отступы поехали»;

• «назови эту функцию вот так»;

• «добавь тест на этот случай».

Даже могут показать место вместе с diff, а тебе останется только перенести его.

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

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

А еще советую посмотреть интервью Никиты Соболева (он разработчик open source и CPython Core Developer), в котором он делится своим путем в разработке и предпринимательстве, размышлениями о том, что open source не просто часть работы, а философия, а еще рекомендациями по work-life-балансу и мыслями — как технологий влияют на настроение и личную энергию.

И помни: первый PR не обязан быть гениальным. Он обязан быть сделанным. Не ошибается лишь тот, кто ничего не делает, но это и есть его главная ошибка.