Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)
Ситуация с правами на код в Российской Федерации довольно интересная: по закону разработчик (физлицо) защищён очень и очень сильно. Нужно как-то весьма прилично косякнуть, чтобы оказаться неправым. А вот работодателю нужно довольно много и кропотливо бегать с бубном и бумагами, чтобы получить права на тот самый код, который пишется на его же зарплату.
Давайте рассмотрим, что говорят законы о правах на код с обеих сторон:
— Что такое авторские права на код?
В ГК про авторские права написано в главе 70. Если очень коротко, то код — это программа для ЭВМ. По правовому режиму она приравнивается к произведениям науки, литературы и искусства. Это как если бы вы написали рассказ или особо удачный стих.
Автором такого произведения (программы для ЭВМ) может быть только физлицо. Юрлицо не может ничего написать: всегда есть какой-то человек, который и был автором. Или несколько человек, если код писался вдвоём-втроём-вдесятером. Тогда они называются соавторами.
Авторские права возникают в момент создания произведения. Их не нужно нигде регистрировать или как-то подтверждать (хотя, если хочется, можно потом и зарегистрировать). Реестр прав на ПО, который ведёт Роспатент, решает задачу не возникновения права, а доказательства того, что именно вы обладаете правами на ПО. Данные этого реестра могут рассматриваться в суде в ходе разбирательств о том, кто же правообладатель, но никогда не будут 100 % гарантией вашего успеха.
У авторов (или соавторов, если работал коллектив) возникают личные неимущественные права и имущественные. Личные неимущественные — это право авторства, право на имя, право на неприкосновенность произведения и право на его обнародование. Их нельзя отчуждать никоим образом. Любой договор передачи этих авторских прав будет признан ничтожным по текущему законодательству. Передавать можно только имущественное право на ПО, которое по-другому называется исключительным правом. Кроме того, если вы обладаете исключительным правом или получили разрешение правообладателя, то можно продавать лицензии на ПО.
— Если я передал имущественное (исключительное) право, то как реализуются личные неимущественные?
Предположим, у вас подписаны договор и ещё стопка бумаг (про них — дальше), которые говорят о том, что вы разработали что-то по заданию работодателя, создали произведение — программу для ЭВМ — и сразу же передаёте исключительное право на него. То есть написали код, и теперь им может распоряжаться работодатель. Но при этом у вас сохраняются неимущественные права: вы можете говорить всем, что написали этот код, вы можете добиваться того, чтобы ваше произведение было подписано где-то в программе (хоть в дебрях, но чтобы это можно было увидеть), и вы можете говорить, что если кто-то добавил в ваш прекрасный код свой грязный баг, то это уже не ваш код. Потому что ваш и только ваш он в полностью неизменном прекрасном первозданном виде.
Что происходит, если на базе вашего кода кто-то написал свой новый? Про это — чуть позже.
Важно то, что если вы вдруг захотите передать право на имя, то не сможете этого сделать.
Личные неимущественные права охраняются бессрочно, а исключительное право — 70 лет (плюс время до 1 января следующего года) с момента смерти последнего соавтора. В течение этих 70 лет, когда вы уже мертвы, ваши интересы может защищать любое лицо: оно может обратиться в суд и сказать, что ваши права нарушены. Тогда злоумышленника накажут.
— Означает ли это, что можно использовать код в портфолио?
Нет, если у вас нет исключительного права на код или лицензии на такое использование, то вы можете только говорить публично, что написали его, но не демонстрировать сам этот код.
— Можно ли использовать код без указания имени автора?
Да. Право на имя означает, что автор может потребовать указания авторства и требует этого по умолчанию. Но в принципе вы можете разрешить не подписывать ваш код. На практике это часто происходит при передаче кода работодателю, при передаче фотографий в различные издания и так далее.
— Кто такие соавторы? Мой тимлид — соавтор?
Автором считается только тот человек, который собственноручно писал код. Если кто-то помогал созданию произведения, но не писал, — это не автор. Только техническое, консультационное, материальное, организационное содействие никак не помогает этим содействующим стать авторами произведения. То есть если вам дали материалы для написания кода (не другой код, а, например, среду разработки, ноутбук, стул и стол), если вас консультировали по коду или ставили задачи (даже очень подробно), но ничего в нём не меняли, — автор всё равно только вы. Это имеет прямое отношение к ревью: если вы отдали свой код на ревью тимлиду, а он только объяснил вам, где вы глубоко неправы, то он не автор. Но если он начал вносить изменения в код, то он становится соавтором. И степень вашего с ним участия с правовой точки зрения становится условно одинаковой: считается, что законченное произведение не могло бы появиться без усилий каждого из вас, даже если объём работ был сильно разный. Правда, такое правило действует только по умолчанию. Так что, если вам такая уравниловка не нравится, вы можете заключить соглашение с соавторами об ином.
При этом важно понимать, что о соавторстве можно говорить только в том случае, когда несколько человек пишут одну и ту же версию одной и той же программы. Если же кто-то изменяет готовое ПО, уже написанное вами ранее, то вы не становитесь соавторами, потому что вы авторы двух разных программ (подробнее об этом — ниже).
Кстати, если код для вас написал не человек, а ИИ, у вас могут возникнуть проблемы с признанием вообще каких бы то ни было прав на такой код. Наше государство (да и не только наше) пока однозначно не решило, как относиться к генерируемым кодам. Будем надеяться, что в ближайшем будущем ситуация прояснится.
— Как квантуется код? Если каждый писал отдельную функцию, а потом получилось большое приложение, то мы авторы отдельных произведений или одного общего?
Здесь всё зависит от того, что будет признано произведением: всё вместе будет считаться единым произведением или же отдельные части будут признаны разным ПО. На практике это зависит от многих вещей, в том числе от задачи, которую ставит работодатель. Чаще всего речь идёт про целостное произведение, то есть все разработчики первой версии в конечном итоге окажутся соавторами. Но надо учитывать, что даже в таком случае один из соавторов может использовать написанную лично им часть по своему усмотрению, если эта часть имеет самостоятельное значение.
Со следующими версиями ПО ситуация чуть интереснее.
— Что происходит, если на базе моего кода кто-то написал свой новый?
Есть смежные права, это когда великий композитор Иоганн Себастьян Бах написал музыку, а Иван Пупкин её исполнил в гараже на шампурах и крышке от кастрюли. В этом случае физлицо Бах имеет право на музыку, а физлицо Иван — на смежное произведение, то есть чужую музыку в своём уникальном авторском исполнении на шампурах и крышке. Но, как вы понимаете, нашего FAQ это не особо касается, потому что мы обсуждаем именно изменения ПО.
Если в ваш код вносятся какие-то изменения другим разработчиком — получается производное произведение. Чтобы создавать производное произведение, надо иметь исключительное право на то произведение, которое лежит в основе, или получить право на переработку первоначального произведения, купив соответствующую лицензию. Свободно перерабатывать можно также ПО, находящееся в общественном достоянии.
После внесения изменений произведений становится два: старое и только что созданное новое — производное — произведение. Это создаёт одну интересную особенность охраны прав разработчиков, про которую мы поговорим ниже.
— Кто такой правообладатель?
Правообладатель — это тот, у кого есть исключительное право. Если автором может быть только физлицо, то правообладателем может быть кто угодно: физлицо, юрлицо, субъект Федерации или вообще страна.
Исключительное право на программу для ЭВМ — это возможность использовать ПО и код на него любым способом, который только можно представить.
Иногда правообладателем также называют того, кто использует произведение по лицензии, но с точки зрения ГК термин «правообладатель» относится только к владельцу исключительных прав.
Вы можете заключить с правообладателем лицензионный договор, чтобы получить возможность использовать произведение какими-то определёнными способами в каком-то регионе и на какой-то срок.
— Означает ли наличие трудового договора то, что весь мой код принадлежит работодателю?
Нет, одного трудового договора недостаточно. В трудовых отношениях работодателю для появления у него исключительного права нужно доказать, что работник создал произведение в рамках выполнения своей трудовой функции.
И дальше начинается цепочка из документов, которые надо оформлять для правильной передачи исключительного права работодателю. Но даже если пройти её до конца и обложиться бумагами по всем правилам, то это не гарантирует на все 100 % того, что суд встанет на сторону работодателя. Равно как нет безусловной гарантии, что если вообще ничего не делать, то суд встанет на сторону работника. Вопрос правильного оформления — это вопрос снижения рисков. Скажем так, по моей оценке, можно на 99 % быть уверенными в том, что всё будет в порядке, если сделать всё до конца.
Но наличие в трудовом договоре фразы, что «исключительное право на служебные произведения возникает у работодателя», пока ещё ничего вообще не даёт работодателю.
— Если есть трудовой договор, где указана должность — программист?
Уже чуть больше шансов, но они всё ещё низки, потому что не указано, что именно вы делаете. Возможно, вас нанимали писать код для АСУ ТП, а вы написали код для управления видеокамерой в кабинете секретарши шефа. Если вам такая задача прямо не ставилась работодателем, то это было хобби, а не рабочая деятельность.
— ОК, а трудового договора с должностью плюс должностных обязанностей?
Нет, потому что там не указано, какой именно код и по какому ТЗ вы должны писать. Например, если вы админ и написали код для какой-то автоматизации, то это вообще не значит, что вы должны были это делать: с точки зрения закона это как принести собранный собственноручно дома прибор и использовать его на работе. Очень упрощая, конечно.
— А что тогда нужно?
— И что, всё время носиться с бумагами?
Да. Мы, например, носимся. И вам рекомендуем как минимум для первых версий.
— Почему для первых версий?
Потому что я обещал одну интересную особенность производных произведений. Помните, что любое (ну или почти любое) изменение кода порождает новый объект — производное произведение? А помните, что для этого нужно иметь имущественное право или лицензию с правом переработки на исходное ПО? Ну так вот, если работник допилил или использовал в своей программе какой-то код, а потом у него возникли трения с работодателем, то уже работнику придётся доказывать, что он имел право модифицировать исходное произведение. Если первый раз все бумаги были правильно оформлены, то есть не особо много шансов, что за ним признают право беспрепятственно использовать все следующие версии.
То есть если компания пять лет делает одну и ту же программу, то нужно на каждое изменение (а это мельче релиза и мельче спринта) делать набор бумаг с актами приёма-передачи и вот этим вот всем. Независимо от того, пошла фича в релиз или нет. Но иногда этим после появления первого законченного произведения не заморачиваются, потому что в суде разработчику нужно будет объяснить, что он не украл изначальный код.
— Если это не трудовой договор, а договор ГПХ?
Договор ГПХ — это гражданско-правовой договор. Как правило, речь идёт о договоре подряда и договоре авторского заказа (два в одном). Если ваш подрядчик не «физик», а организация, то будет применяться статья не о договоре авторского заказа, а о произведении, созданном по заказу. Почти то же самое, но есть нюансы. Когда вы заказываете произведение у фрилансера или подрядчика, нужно подписывать аналогичный набор документов. Правда, у некоторых будут немного другие названия: ГПХ вместо трудового договора, ТЗ вместо служебного задания. Должностная инструкция, понятно, не нужна вообще, отчёт — тоже. Как и с трудовым: нет 100 % гарантии, что суд встанет на чью-то сторону однозначно, так как всегда могут быть какие-то подводные камни. Но вы можете снизить ваши риски практически до нуля.
С получением прав от подрядчика есть ещё один важный момент: вам нужно убедиться, что подрядчик сам получил права у своих работников. То есть в идеале надо запросить весь набор документов из списка выше. Вполне вероятно, что вам его просто так не представят, поэтому не помешает прописать соответствующую обязанность подрядчика в договоре при заключении.
Если подрядчик не оформил переход прав от работников себе, то он не может передавать эти права вам (поскольку они у него и не возникали). Вы можете дальше судиться с ним за убытки, но права на код вы не получите. Вскрыться это может в любой момент при жизни разработчика и ещё 70 с небольшим лет.
— Если я с 10:00 до 18:00 работаю в компании, а дома пишу опенсорс-проект, то где какие права?
Всё то, что не относится к служебному заданию, — ваше. Напомню, по закону разработчику почти не нужно доказывать свои права на произведение, наоборот, это работодателю нужно доказывать правильную передачу прав от работника. В описанной ситуации, скорее всего, как-то оформлены права на служебные произведения, поэтому на работе вы делаете код под передачу имущественных прав работодателю, а дома — свой собственный.
— Если я делаю это на рабочем компьютере?
В большинстве случаев абсолютно неважно, что и где вы делали. Можно коммитить в опенсорсе в рабочее время с рабочего компьютера, можно писать свои проекты. Поскольку вам не ставил такую задачу работодатель, вопросы к правам на код не возникнут. Возникнут вопросы, чем вы занимаетесь в рабочее время. Но отлынивание от служебных обязанностей (а это именно оно) никак не создаёт права на то, что во время этого отлынивания было произведено.
Ещё я слышал про такой юридический лайфхак: работодатели прописывают, что сохранение кода на рабочей станции, являющейся имуществом работодателя, приравнивается к акцепту передачи прав на этот код. Но, по-моему, его действенность вызывает вопросы.
— Если я передал исключительные имущественные права в общественное пользование, то я могу создавать производное произведение?
Да, вы точно можете. Хотя возможность свободной передачи своего ПО в public domain по российскому законодательству как минимум небесспорна.
— Так, у меня ещё вопросы…
Задавайте вопросы в комментариях или по почте earkhipov@croc.ru.
Отдельно отмечу, что мы часто видим «жертв цифровизации», которым подрядчики неверно передают код. Вот в посте моего коллеги есть несколько жизненных примеров, какого размера может быть ущерб.
Почему в России так мало committers в крупные open source проекты
Всю свою недолгую профессиональную карьеру я с удовольствием работал с крупными Open Source фреймворками — Lucene, Solr, Hadoop (map-reduce и yarn), Spark, Zeppelin, IPython, etc. Выбирая между разработкой проприетарного продукта и чего-то на основе open source, я всегда выбираю open source по следующим причинам:
Джедай-разработка. Джедай — это в первую очередь человек, который может в одиночку изменить судьбу вселенной (не подпадающий под принцип «один в поле не воин»). И некоторые open source фреймворки позволяют решать сложные технические проблемы простым деплоиментом готовых решений. Теоретически можно написать свой map-reduce, свою распределенную файловую систему и даже свою supertable realtime database. Но это займет много времени и будет по качеству хуже существующих решений.
А вот свой Spark за пределами долины уже не написать — просто слишком сложная система, требующая слишком много очень высококвалифицированных разработчиков. Но зачем все это писать, если весь big data стек организации можно поднять на 2 дня. Террабайты логов? Cassandra + Spark + Zeppelin. Из готовых docker контейнеров опытный человек может поставить все и за один день.
— Apache Spark релизится раз в 3 месяца с мажорными фичами. Это радикальное увеличение стабильности, появление новых инструментов (SparkSQl, Dataframe, GraphX), увеличение количества реализованных алгоритмов (Gradient boosting в MLLib). Solr за пару лет научился шардироваться и посему работать с большими данными. Hadoop переродился в Yarn. Эти фреймворки обзаводятся новой полезной функциональностью без приложения моих усилий. А значит, я могу более эффективно решать поставленные перед мной задачи. В проприетарном продукте жизнь становилось бы легче только тогда, когда я бы сильно вкладывался в то, чтобы сделать ее легче.
Хорошая документация. Очень мало top level apache проектов с плохой документацией. В apache incubator плохую документацию можно встретить чаще. Но даже в этом случаи — в силу открытости проекта у него есть пользователи, которые оставляют следы своих изысканий на StackOverflow. То что в проприетарном проекте обычно первый шаг — обратится непосредственно к автору кода, является самым крайним шагом в open source. За 2 года своего самого тесного общения со spark мне пришлось писать на dev mailing list всего дважды.
Сложившееся коммьюнити. В open source у меня всегда есть чувство плеча и принадлежности к какому то кругу, который всегда поможет в корректно поставленном техническом вопросе. Появляется ощущение, что у тебя замечательные коллеги по всему земному шару. И они останутся, если ты даже сменишь фирму, но не сменишь фреймворк.
Работа на себя. Работая с open source вы увеличиваете свою экспертизу в нем и быстро растете в зарплатно-профессиональном плане. Действительно, если понадобиться сменить работу — на рынке есть 5 контор, технологический стек которых вы уже примерно знаете и можете приносить пользу с первого дня. Вам не нужно по полгода входить в контекст переходя с одного проприетарного стека на другой. И фирмам тоже проще — можно нанять сотрудников, которых практически не надо обучать.
Все это является плюсом для сотрудников и работодателей в России. И для того, чтобы воспользоваться этими преимуществами, не надо быть committer. Достаточно быть contributor. Для тех, кто не знает, кратко расскажу, чем они отличаются. Сontributor — это человек, который предложил патч к проекту и его committer вмержил в мастер. Committer — это человек, который имеет право (и обязанность) регулярно коммитить и вмерживать патчи в мастер.
Contributor, таким образом, идеальный сотрудник в российских реалиях. Он хорошо знает проект, раз пользовался им достаточно, чтобы понять, где его можно улучшить. Он смог его улучшить. Он может собирать проект из сорсов и править сорсы, а значит, всегда сможет залезть в код и кастомизировать, если понадобится.
Контрибьютером быть классно — тебе не надо сдавать Spark Certification за 300 баксов, при этом никто не поставит под сомнение твою компетентность в этом фреймворке.
Committer обладает большей экспертизой в проекте, но куда важнее — большей властью.
Intel нужно точно знать, что Spark хорошо совместим с Intel. Cloudera, Hortonworks — являются вендорами хадупа (а значит и Спарка). Они должны транслировать не только свои интересы, но и интересы заказчика. Компании, для которых Big Data и IT — основной бизнес, куда сильнее заинтересованы в committers. MapR, SAP, Oracle, IBM — сейчас активно ищут коммитеров Cпарка (хотя я не понимаю, как можно активно искать всего 30 людей, которых все поименно знают). И они готовы платить хорошие деньги. Стать комитером Спарка в долине — гарантировано поднять свою зарплату в 2 раза, если она была уже высока.
Компании, которые готовы платить большие деньги за коммитеров, в России отсутствуют. IT-интеграторы не имеют размах IBM и SAP не только в плане оборота, но и в плане амбиций определять развитие отрасли. Они следуют тенденциям, формируемым в долине. Committer просто не сможет принести им пользы.
Продуктовые же компании в России либо малы, либо сидят на проприетарном технологическом стеке. Yandex пытается развиваться по модели Google, где вся разработка in house. Как я понимаю, это позиция основана на идеи, что разработка внутри быстрее и эффективнее любого open source, когда компания в состоянии создать критическую массу опытных специалистов. С деталями инфраструктуры ВКонтакте не знаком, но она тоже проприетарная. Одноклассники точно пользуются Spark, почему их не видно в коммьюнити — не могу сказать.
Таким образом, будучи committer, выиграть по деньгам или возможностям в России на фоне простого contributor считаю очень сложным.
Отсутствие компаний в России, которые хотели бы держать committers (которым было бы выгодно), считаю основной проблемой низкого количества committers.
Как стать коммиттером и действительно ли вам это нужно
Привет! Меня зовут Дмитрий Павлов, я работаю в GridGain, а также являюсь коммиттером и участником PMC в Apache Ignite и контрибьютором в Apache Training. Недавно я выступал c докладом о работе коммиттера на митапе Сбербанка по open source. С развитием opensource-сообщества у многих все чаще стали возникать вопросы: как стать коммиттером, какие задачи брать и сколько строчек кода надо написать, чтобы получить эту роль. Когда мы думаем о коммиттерах, нам сразу представляются всемогущие и всезнающие люди с короной на голове и томиком «Чистый код» вместо скипетра. Так ли это? В своем посте я постараюсь ответить на все важные вопросы о коммиттерах, чтобы вы могли понять, действительно ли вам это нужно.
У всех новичков в opensource-сообществе проскакивают мысли о том, что им никогда не стать коммиттерами. Ведь для многих это престижная роль, которую можно получить только за особые заслуги, написав тонну кода. Но все не так просто. Взглянем на коммиттера со стороны коммьюнити.
Кто такой коммиттер и зачем он нужен?
При создании нового opensource-продукта мы всегда разрешаем пользователям использовать и исследовать его, а также модифицировать и распространять модифицированные копии. Но когда происходит неконтролируемое распространение копий ПО с внесенными изменениями, то мы не получаем контрибьюшенов в основную кодовую базу и проект не развивается. Вот тут уже необходим тот самый коммиттер, который имеет право собирать вклады пользователей в проект.
Зачем становиться коммиттером?
Начнем с того, что коммиттерство — это плюс к резюме, а для новичков в области программирования — еще больший плюс, ведь часто при устройстве на работу просят примеры кода.
Вторым несомненным преимуществом коммиттерства является возможность общаться с топовыми специалистами и тянуть какие-то крутые идеи из open source в свой проект. К тому же, если вы хорошо знаете некий продукт с открытым кодом, то можете устроиться в компанию, которая его поддерживает или использует. Существует даже мнение, что если не участвуешь в open source, то на высокие карьерные позиции не попасть.
Помимо плюшек в плане карьеры и трудоустройства, коммиттерство само по себе приятно. Тебя признает профессиональное сообщество, ты четко видишь результат своей работы. Не то что в какой-нибудь корпоративной разработке, где иногда вообще не понимаешь, зачем перекладываешь туда-сюда поля в XML.
В opensource-сообществах можно познакомиться с топовыми специалистами уровня Линуса Торвальдса. Но если вы не такой, не стоит думать, что там вам нечего делать — есть задачи разного уровня.
Ну и еще бывают дополнительные бонусы: коммиттеры Apache, например, получают бесплатно лицензию IntelliJ Idea Ultimate (хоть и с некоторыми ограничениями).
Что делать, чтобы стать коммиттером?
Все просто — нужно коммитить.
Если вы считаете, что на проектах для вас нет задач — вы ошибаетесь. Просто присоединяйтесь к интересующему вас сообществу и делайте то, что необходимо именно ему. В Apache Software Foundation есть отдельный гайд с требованиями к коммиттерам.
Какие задачи придется решать?
Самые разные — от разработки до написания тестов и документации. Да-да, вклад тестировщиков и документаторов в сообществе ценится наравне с вкладом разработчиков. Бывают нестандартные задачи — например, вести канал на YouTube и рассказывать другим пользователям, как вы используете opensource-продукт. Например в Apache Software Foundation есть отдельная страница, где указано, какая помощь требуется.
Надо ли написать большую фичу, чтобы стать коммиттером?
Нет. Это совсем не обязательно. Коммиттер не должен писать тонны кода. Но если вы написали большую фичу, комитету по управлению проектом легче будет оценить вас. Вклад в сообщество — это не только фичи, программирование и тестирование. Если вы пишите письмо и рассказываете о какой-то проблеме, предлагаете аргументированное решение — это тоже вклад.
Важно понимать, что коммиттерство — это доверие. Сделать вас коммиттером или нет, решают такие же люди как и вы на основании своих взглядов на вас, как на человека, который приносит пользу продукту. Поэтому вам, своими действиями и поступками в сообществе, надо завоевать это самое доверие.
Как себя вести?
Быть конструктивным, позитивным, вежливым и терпеливым. Помните, что в open source все волонтеры и никто никому ничего не должен. Вам не отвечают — подождите и напомните о своем вопросе через 3-4 дня. Вам постоянно не отвечают — что ж, open source дело добровольное.
Не просите что-то сделать для вас или за вас. У опытных участников сообщества есть чутье на таких «попрошаек» и тут же возникает аллергия на тех, кто хочет спихнуть им свою работу.
Если вам помогают, это здорово, но не злоупотребляйте. Не стоит писать: «Ребята, пофиксите это, а то я годовую премию теряю». Лучше спросите, куда вам двигаться дальше, и расскажите, что вы уже накопали по данному багу. А если пообещать по результатам решения проблемы обновить вики, то вероятность, что вам ответят, возрастет в разы.
Как внести вклад, если ты не коммиттер?
В проектах часто используется схема RTC, когда сначала все проходят ревью, а затем изменения сливаются в мастер. При такой схеме абсолютно все проходят ревью, даже коммиттеры. Поэтому в проект можно успешно контрибьютить, не являясь коммиттером. А для того чтобы легче быть выбранным в новые коммиттеры, можно заняться наставничеством над новыми участниками, делиться знаниями, создавать новые материалы.
Diversity — польза или вред?
Diversity — в понимании Apache Software Foundation, это, в том числе, аффилированность участников opensource-проекта несколькими компаниями. Если все аффилированы только одной организацией, то с потерей ее интереса к проекту все участники оттуда лихо сбегают. Diversity обеспечивает долгосрочность, стабильность проекта, разносторонний опыт и широкий спектр мнений участников.
По любви или по расчету?
В opensource-проектах встречается два типа людей: те, кто работает в организации, что контрибьютит в данный продукт, и те, кто трудятся здесь по любви, то есть волонтеры. Кто из них продуктивнее? Как правило, участники, которые поддерживают продукт со стороны организации-контрибьютора. У них попросту больше времени и есть явная мотивация докопаться до истины, они сфокусированы на задаче и ближе к пользователю.
Те, кто делает это «из любви», тоже мотивированы, но по-другому — они жаждут изучить проект, сделать мир лучше. И как раз именно такие участники более стабильны и ориентированы на долгосрочную перспективу, потому что тот, кто пришел в сообщество по собственной инициативе, вряд ли покинет его одним днем.
Как найти баланс между продуктивностью и стабильностью? Есть два варианта. Первый вариант: когда участник работает в компании, которая официально занимается этим opensource-проектом, и делает в нем что-то дополнительно, из собственного интереса — например, поддерживает новичков. Второй вариант — это компания, пережившая opensource-трансформацию. Например, когда сотрудники четыре дня в неделю пилят основной бизнес-проект, а остальное время занимаются open source.
Коммиттер — быть или не быть?
Коммиттерство — хорошая и полезная тема, но не стоит стремиться именно к тому, чтобы стать коммиттером. Данную роль можно получить не за код, и она не доказывает ваших знаний. Важна только экспертиза, то есть те знания и опыт, которые вы приобретете, изучая проект, копаясь в нем и помогая другим решать проблемы.
