На дворе 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 выглядит плоской горизонтальной структурой. Пришел, форкнул, закоммитил — влили. Демократия и свобода чистой воды!
Но, как свойственно человеческому стремлению к иерархии, на самом деле это пирамида. Наверху — пара человек, которые решают, жить проекту или время отправиться на покой. Внизу — сотни тех, кто приносит баги и редко работает над самим решением. А посередине — прослойка, которая делает всю грязную работу.
Создатель
Тот, кто однажды написал git init и залил код на GitHub (или любую другую платформу). Мог написать криво, мог гениально — неважно. Он придумал идею и решил, что она должна жить.
Создатель в open source может выполнять почти все роли, но затем становится тяжелой артиллерией, так сказать. Он может ничего не делать потом годами, но без его благословения не мержится ничего спорного или масштабного. Если создатель уходит в закат и не передает права — проект рискует умереть. Могут форкнуть, но не всегда выживают.
Если вы на таком этапе, советую посмотреть лекцию Евгения Блинова о том, как он создал библиотеку transfunctions для Python и как пришел к этой идее.
Мейнтейнер
Вот кто реально герой. Это может быть знакомый создателя или зарекомендовавший себя контрибьютор, который первым начал разбирать issues, когда проект стал популяризироваться.
Их работа — буквально тушить пожары. Представьте: солнце светит, птички поют, вы с наслаждением хотите расслабиться, а вам приходится открывать гитхаб и видеть 15 новых issues и 8 пул-реквестов.
Мейнтейнер очень редко пишет новый код. Он разбирает чужой, ставит лейблы, закрывает дубликаты, объясняет новичкам, почему их правка не пройдет CI/CD. Поэтому, когда вы присылаете issue или PR, не забудьте сказать спасибо вашему мейнтейнеру за его работу, которую он выполняет из чувства долга.
Ревьюер
Они хотят, чтобы код не ломался у тех, кто ему доверится. А также чтобы остальные контрибьюторы могли работать и код был в едином стиле. А то никто не хочет увидеть, как одна часть кода писалась джава-энтерпрайзером с применением всех возможных паттернов ООП, другая — с неравнодушными чувствами к ФП, а третья была спагетти-кодом.
Бывают, конечно, и люди, которые ждут, что их PR примут сразу же и будут целовать ноги. А если не примут — они побегут писать в твиттере гневный пост. Не стоит быть такими: ревьюверы, кроме вас, обрабатывают несколько десятков других PR и также работают чаще всего за спасибо. А иногда и без спасибо.
Ревьюеры — это фильтр качества. Без них open source превратился бы в помойку из полусырых правок. Их ненавидят, но именно им обязаны тем, что библиотеки не падают в продакшене.
Контрибьютор
Тот, кто приносит код. А иногда находит баг и сразу приносит PR. Не мейнтейнер, не ревьювер, просто человек, которому чего-то не хватает в проекте.
Иногда это бывает случайно, когда человек заметил баг и решил сразу его решить. Иногда это целенаправленное желание сделать вклад.
Но в любом случае контрибьюторы — это кровь open source. Они приносят свежие идеи, фиксы, фичи. Большинство приходит один раз и уходит. Но кто-то залипает — и через год становится ревьюером или мейнтейнером.
Документатор/переводчик
Самая недооцененная роль. Все мы можем писать код, но мало кто может описывать, как с ним работать, а также переводить технические термины на разные языки. Иногда они могут залезть в код и понять, что в документации недосказано или вообще пример кривой.
Документатор переводит с человеческого на технический и обратно. Он объясняет код тем, кто не умеет читать код. Без него проект используют только авторы. С ним — тысячи.
Да и популярный проект open source от нового отличает наличие документации.
Баг-репортер
Эти люди также могут не писать много нового кода, но их вклад неоценим. Именно они позволяют находить баги, а самое главное — грамотно расписывать их. А иногда могут и целенаправленно искать баги. А также баг-репортеры могут зарабатывать деньги за счет баг-баунти программ крупных проектов open source!
Грамотный баг-репорт — основа хорошего PR. Контрибьютор или мейнтейнер смогут сами написать код, если поймут, что и где падает.
Каждая роль нужна. Каждая — вход в 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.
Так куда податься?
Теория закончилась. Дальше — чистая практика. Я собрал места, где только рады новым и старым опенсорсерам — и создателям, и контрибьюторам, и мейнтейнерам, и новичкам.
Крупные проекты
В крупные проекты все еще можно идти, будучи новичком. Они приучают к высокой культуре ревью и общения.
Не буду перечислять все, ибо их легко додумать. React, VS Code, CPython, Django, Kubernetes, Redis, Docker...
Там уже выстроены все процессы. Если ты принесешь код, тебя не пошлют, а популярно распишут, что и как подправить. Там есть и CONTRIBUTING.md, и CODE_OF_CONDUCT.md, и CI, который проверит все, что можно и нельзя, и мейнтейнеры, которые превратили это занятие в полноценную работу.
Но там сложно. Во-первых, конкуренция. Бывают сотни issue с меткой good first issue, каждый из которых смотрит по 50 человек в день. Твой PR может зависнуть на неделю, потому что мейнтейнеры завалены.
Но если ты хочешь прокачать английский для переписок и научиться писать код по стандартам индустрии — сюда.
Проекты для питонистов
Сам я питонист и воспользуюсь правом прорекламировать развитие экосистемы питона.
Во-первых, CPython. Там всегда рады новичкам, так как идет активное развитие. Кроме того, есть шанс попасть в Triage Team (команда из доверенных контрибьюторов), а оттуда — в CPython Core Developer. Например, один 19-летний парень стал CPython Core Developer'ом. Но нужно знать C.
Необязательно в сам CPython — можно и в python-typeshed. Там поменьше конкуренция, а задач всегда навалом.
Во-вторых, pytest. У pytest дружелюбное сообщество, много документации и четкие гайды для контрибьюторов. Они даже написали отдельную страницу how to contribute с примерами.
Если ты пишешь тесты каждый день — ты уже знаешь, что там бесит. Флаг в руки.
FastStream — молодая библиотека для работы с брокерами сообщений (Kafka, RabbitMQ и так далее). Растет быстро, кодовая база не огромная, мейнтейнеры на связи. Подходит для тех, кто хочет въехать в архитектуру, а не фиксить опечатки.
Dishka — фреймворк для внедрения зависимостей. Молодой проект, где еще много простора для помощи и доработки. Авторы активно ищут контрибьюторов и готовы объяснять новичкам, как устроен DI.
Площадки-агрегаторы
Up for grabs — сайт, где проекты сами выкладывают задачи для новичков. Фильтруй по языку, читай описание и переходи в репозиторий. Минус: не все проекты живые, проверяй дату последнего коммита.
Good First Issue — то же самое, но с автоматическим сбором меток с GitHub. Обновляется ежедневно. Выбираешь язык — получаешь список задач, которые реально висят в репозиториях.
Русскоязычные сообщества
Самый сок для многих, так как тут всегда рады новичкам и влиться в open-source-тусовку будет намного легче.
Первый канал легко найти в поиске Telegram по ключевым словам opensource findings python. Там регулярно постят интересные issues для новичков.
А если хочешь погрузиться в движуху, ищи открытый чат того же сообщества (в поиске по слову opensource_findings_chat). Там очень дружелюбная атмосфера, помогают новичкам, и можно пообщаться с мейнтейнерами реальных библиотек.
А также хочется порекомендовать сообщество Опенсорсеры — это большое сообщество опенсорсеров разного формата. Кроме того, там можно искать контрибьюторов в свои проекты, issue для решения, а также рекламировать свой проект.
Если остался иррациональный страх
На самом деле сообщество всегда радо новичкам. Будьте доброжелательны к остальным, и люди вам помогут, даже если вы только-только начинаете и задаете кучу вопросов по архитектуре. Изучите кодстайл, архитектуру, пообщайтесь с мейнтейнерами. Не забывайте говорить спасибо человеку, который смержил ваш PR или ревьювит его.
Самым лучшим способом вклада будет изучить, чем вы пользуетесь каждый день, и найти мешающие недочеты. Но даже если нет таких — то спокойно идите на вкладку Issues, ищите по лейблам good-first-issue и другим, и берите их смело.
Также можно создавать свои проекты — и необязательно огромные комбайны или фреймворки. Например, сообщество будет радо портированию какого-нибудь плагина из VSCode в Vim/NeoVim.
Ты прочитал доки, получил добро от мейнтейнера, сделал по гайдам. Теперь просто делай. Код может быть неидеальным. Ты можешь ошибиться в синтаксисе. Можешь забыть запустить тесты. Можешь назвать переменную не по стандартам проекта. Это абсолютно нормально.
Мейнтейнеры и ревьюеры не кусаются. Они напишут в PR:
«тут отступы поехали»;
«назови эту функцию вот так»;
«добавь тест на этот случай».
Даже могут показать место вместе с diff, а тебе останется только перенести его.
PR могут свернуть по тысяче причин. Половина (а то и больше) не про тебя и не про твой код. Твоя задача — не обижаться, а исправлять или идти дальше.
Если иррациональный страх остался — советую начать с документации. Это легальный способ вкатиться без кода. Найди в проекте файлы ридми, доков, примеров. Если найдешь опечатку, кривую формулировку или устаревший пример — это уже issue и статус контрибьютора.
А еще советую посмотреть интервью Никиты Соболева (он разработчик open source и CPython Core Developer), в котором он делится своим путем в разработке и предпринимательстве, размышлениями о том, что open source не просто часть работы, а философия, а еще рекомендациями по work-life-балансу и мыслями — как технологий влияют на настроение и личную энергию.
И помни: первый PR не обязан быть гениальным. Он обязан быть сделанным. Не ошибается лишь тот, кто ничего не делает, но это и есть его главная ошибка.
