Вітання! Мене звуть Дмитро Павлов, я працюю в , а також є комітером та учасником PMC в Apache Ignite та контриб'ютором в Apache Training. Нещодавно я виступав з доповіддю про роботу комітера на мітапі Ощадбанку з 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.
Комітер — бути чи не бути?
Комітерство — гарна та корисна тема, але не варто прагнути саме того, щоб стати комітером. Цю роль можна отримати не за код, і вона не доводить ваших знань. Важлива лише експертиза, тобто ті знання та досвід, які ви набудете, вивчаючи проект, копаючись у ньому та допомагаючи іншим вирішувати проблеми.
Джерело: habr.com