Почему сейчас актуальны open source проекты?
Open source — разработки с открытым кодом, доступ к которому есть у сообщества. Участники стремятся поддерживать и развивать продукт для эффективного использования.
В последние пару лет open source заиграл новыми красками, так как крупные бренды ушли с рынка, забрав с собой фирменные решения. Для компании, использующей эти продукты, всегда есть риск: сейчас у тебя есть доступ, поддержка и ресурсы со стороны бренда, но в любой момент без объяснения причин тебе могут отключить доступ.
Open source решает эту проблему: решения остаются в общем доступе и не зависят от мнения компаний и введенных санкций. Например, ОС Linux или библиотека React — продукты с открытым кодом, которыми пользуются разработчики по всему миру.
Как фронтенд-разработчик, я использую в работе множество решений с открытым кодом, они хранятся в специальной папке для используемых на проекте библиотек. Есть даже шутка: «Тяжелее черной дыры может быть только папка node_modules».
Кроме того, участвую в работе над Feature-Sliced Design — архитектурным подходом, который помогает решать множество проблем фронтенда в мобильных приложениях. Над проектом работает core team, основная группа разработчиков, и сообщество. Когда я только узнал о FSD, вдохновился и решил помочь: стал рассказывать о подходе коллегам на митапах и в статьях — например, упомянул о нем в статье про выбор архитектуры фронтенда.
Сейчас посвящаю проекту больше времени: готовлю с ребятами практический курс о том, как работать с Feature-Sliced Design, и помогаю собирать обратную связь от сообщества. В сентябре провел опрос через гугл-форму, после которого вместе с core team выявили 14 аспектов, вызывающих трудности у пользователей, — будем о них рассказывать подробнее и собирать базу знаний. Так, я не пишу ни строчки кода, но вношу вклад в развитие проекта.
Кто создает проекты с открытым кодом?
Open source продукты могут создавать как отдельные юзеры, так и команды или компании. Таким проектом может считаться даже пара строк кода, которая упростит жизнь другим разработчикам. Например, алгоритм, определяющий четность чисел.
Проектов, созданных пользователями в одиночку, больше — количественное преимущество. Тем не менее и отечественные, и иностранные компании готовят свои продукты и шерят их с сообществом. На рынке есть конкуренция: каждый стремится сделать полезный продукт, которым будут пользоваться. Это стимулирует развивать разработки и не забрасывать поддержку. К тому же, так как все проекты с открытым кодом, части алгоритмов переносятся друг в друга и тем самым улучшаются.
Какие специалисты нужны open source проектам?
Продукты с открытым кодом создают люди, очень важно развивать разработки. Для сложных проектов потребуются технически подкованные специалисты или медийные личности, которые могут рассказывать о продукте большой аудитории. В обычной ситуации помочь может каждый, главное — желание: если умеешь писать код, можно проработать issues, если умеешь рисовать — визуализируй части проекта.
Кроме того, можно развивать документацию, собирать базу знаний, переводить документацию на другие языки, взаимодействовать с сообществом. Координируют сообщество комьюнити-менеджеры — общаются, собирают обратную связь, рассказывают о планах и выстраивают доверительные отношения аудитории и продукта.
В open source очень важна прозрачность: сообществу нужно понимать, куда и как сейчас двигается проект, чтобы не ставить под сомнение его целесообразность. Как отдельным пользователям, так и компаниям важно знать, что у библиотеки, которой они пользуются, есть будущее и через год поддержка не исчезнет. Риск в такой ситуации — самостоятельно в сжатые сроки переписывать код и тратить на это много времени и ресурсов команды.
Проблемы open source проектов и пути их решения
Кроме исчезновения разработчиков есть еще несколько ключевых трудностей.
Можно навредить продукту
Так как доступ к коду есть у всего сообщества, любой пользователь может добавить вредоносные элементы. Например, в феврале-марте прошлого года пришлось ограничивать доступ к обновлениям отдельных продуктов, чтобы обезопасить юзеров. Такие случаи обычно единичны, и я надеюсь, что сообщество научится их предотвращать.
Решение: автоматизировать проверку пакетов перед использованием.
Основатель проекта — один человек, который может перестать работать
Я называю это bus factor. Если кто-то не сможет продолжить работу из-за болезни, потери интереса или несчастного случая (буквально человека может сбить автобус, отсюда и название) — сколько людей нужно потерять проекту, чтобы его нельзя было поддерживать? Если bus factor = 1, то достаточно одного человека, чтобы проект перестал существовать. Такое случается, когда доступ к коду есть только у создателя проекта: сложно предсказать поведение или намерения этого человека.
Например, у библиотеки Vue.js главный разработчик Эван Ю только один, поэтому, если мне нужно будет выбрать между Vue.js и React для разработки приложения на несколько лет вперед, использую вторую библиотеку. Во-первых, React поддерживается Facebook (запрещен на территории РФ), целой компанией, которая заинтересована в работе продукта. Во-вторых, с Эваном может произойти bus factor, и никто не предугадает будущее проекта.
Есть реальный кейс про библиотеку, которая определяет четность чисел. Из-за простоты и востребованности она легла в основу других проектов, стала транзитивной зависимостью для многих библиотек, и когда в один момент создатель решил удалить проект, некоторые open source продукты просто перестали работать.
Еще один риск единственного руководителя проекта — он может развивать продукт в направлении, которое не одобряет сообщество. Пользователям могут быть полезны другие изменения, но из-за противоположности пожеланий когда-то популярные библиотеки могут терять юзеров.
Решение:
- Децентрализация управления. Проектом управляет не отдельный человек, а команда.
- Общение с сообществом. Нужно коммуницировать с пользователями, делиться успехами и неудачами и рассказывать о планах проекта.
- Документация. Если регулярно вести документацию, то получится такая база знаний, которая поможет и в случае bus factor = 1.
Юридические проблемы
Часто крупные компании используют open source продукты, но если разработчики проекта захотят рассказать об этом на своем сайте и разместить логотип бренда-клиента, могут прийти юристы. В сфере есть множество правовых тонкостей, которые тормозят развитие продуктов, тратят средства и время разработчиков.
Решение:
Здесь нет готового подхода, но, как мне кажется, важно сформировать правильное отношение к open source проектам: большие компании используют ресурсы продуктов и зарабатывают на этом средства, поэтому стоит пересмотреть юридические аспекты так, чтобы участники рынка не мешали друг другу.
За open source проекты не платят
Если разработчики дошли до уровня, когда они могут вносить значимые качественные изменения в продукты с открытым кодом, то, скорее всего, это уже senior-специалисты, тимлиды или сотрудники еще более высокого уровня. Час таких специалистов стоит больших денег, и они могли потратить его на основную работу или проекты, но вкладываются в open source. Они не получают с этого материального результата, поэтому не смогут работать так фултайм.
Больше о реальных проблемах фултайм open source разработчиков могут сказать специалисты — например, Денис Пушкарев, основатель core-js с 34 миллионами скачиваний в неделю. В статьях он рассказывал о проблемах в open source, можно почитать подробнее.
Решение:
- Краудфандинг или Патреон. Можно собирать донаты от сообщества. Конечно, это не сравнится с той зарплатой, которую получают даже начинающие разработчики в крупных компаниях.
- Коллаборация с брендами. Иногда удается предложить компании свое решение, развивать его и поддерживать за регулярное денежное вознаграждение. Это тоже не покроет зарплату сотрудника, но будет надежнее, чем донаты.
- Продажа услуг на базе open source решения. Допустим, к разработчику базы данных могут обратиться за консультацией о том, как пользоваться продуктом, или за анализом, как эффективно внедрить инструмент в компанию.
Также у некоторых сервисов, например Notion и Miro, есть специальные тарифные планы для open source разработчиков, которые предоставляют бесплатный доступ или пониженную стоимость.
Почему стоит участвовать в open source проектах, несмотря на все проблемы?
- Ключевое преимущество — опыт. Можно смотреть, как пишут код коллеги, получать фидбэк и ревью на реквесты.
- Нетворкинг. Через проекты ты взаимодействуешь с активными участниками тусовки, появляется больше полезных связей.
- Возможность внести вклад в развитие технологий. Можно считать себя хорошим человеком, приносящим пользу обществу, — для многих это правда важно.
- Личный бренд. Можно рассказывать друзьям и знакомым не только про основную занятость, но и про дополнительные проекты — это формирует цельный образ.
- Преимущества на собеседованиях. Среди разработчиков ценится опыт работы над open source продуктами, так что это может стать большим плюсом при приеме на работу.
- Собственное удобство. Когда в open source проектах есть баги, можно самостоятельно костыльно их поправить либо внести изменения в открытый код — сделать проще работу и себе, и другим пользователям.
Вместо итогов
Open source — возможность недополучить средства, провести меньше времени с партнером или стрессовать из-за юридических трудностей. Но на самом деле, несмотря на эти образы и сомнения, open source разработчиков много, и это энтузиасты, которые хотят сделать мир лучше. Они развивают сферу и задают тренды. Любой разработчик из любой точки мира может внести свой вклад в изменение отрасли.
Самое главное: open source — это не про деньги, не про компании, а именно про людей. Про тех, кто готов идти за идеей и менять мир.
