Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Open source: що це, для чого і як розпочати

Понад 8 років я працюю у сфері розробки програмного забезпечення, переважно з JavaScript і RoR, і всі 8 років беру участь в open source. Серед проєктів, участю в яких пишаюся найбільше — Botpress та Spree.

Уперше з open source мені довелося мати справу ще в школі, коли я пробував запускати Linux замість чергового «перевстановлення Windows» у себе й своїх близьких. Згодом почав використовувати його й у роботі, проте не наважувався брати участь. Свій перший PR я відкрив до Spree, з яким саме тоді працював і якому бракувало перекладу українською. Його прийняли, і ось тоді я зрозумів, що, виявляється, це не лише не так і складно, а й можна поєднувати роботу із задоволенням.

Але цю статтю пишу не для того, щоб розповісти, що в Open Source робив я. Моя мета — пояснити, чому open source потрібні ви. Чи можна заробити на open source, як почати й для чого це все треба?

Що таке open source і community

Open source — це рух, що підтримує розробку й просування відкритого програмного забезпечення. Простіше кажучи, open source — це, наприклад, безліч проєктів на GitHub, куди ви точно не раз заходили, щоб знайти потрібне вам рішення. Open source — це ще й Linux, улюблена ОС більшості розробників програмного забезпечення.

За кожним проєктом open source стоїть спільнота, тобто community, яка його розробляє, підтримує і просуває. Community — це різні люди з різними намірами: хтось хоче розвинути програмний продукт, наприклад тому, що використовує його в роботі або навіть виконує завдання, яке оплачує кінцевий замовник; хтось хоче вдосконалити власні навички — так люди, які тривалий час працюють в одному проєкті, хочуть урізноманітнити свій досвід, перевірити знання й уміння та отримати фідбек від ком’юніті; хтось робить внесок в open source заради різних community-заходів — вони й додають фану в роботу; а комусь просто цікаво, можна сказати з дослідницького погляду, зрозуміти, як працює щось складне (той самий Virtual DOM у реакті).

Неважливо, які цілі ці люди мають на прикметі. Важливо те, що, з одного боку, без спільноти проєкт Open Source не зможе довго існувати, а з іншого, для реалізації цих цілей, нам і самим потрібен open source!

Учасники Lviv Hacktoberfest

Як community може вести розробку продукту

Ми вже з’ясували, що за розробку, підтримку, документацію і просування проєктів відповідає спільнота. Але як? Кому належить проєкт? Хто ним керує?

Є два способи, за допомогою яких можна зорганізувати роботу над проєктом open source.

1. Проєкт повністю контролює спільнота

Тут принцип простий: кожен учасник спільноти може повідомити про проблему або розв’язати її, створити pull request і з’єднати його з певною гілкою. У таких проєктах open source є один або кілька адміністраторів, що переглядають кожен pull request, кожне зареєстроване issue і наводять лад.

Адміністратори — це розробники програмного забезпечення, зазвичай засновники тих проєктів, які вони адмініструють. Наприклад, Стів Клабнік (Steve Klabnik) — це один з авторів мов програмування Ruby on Rails і Rust. Більшість з вас знають його як надактивного користувача твіттеру, але, крім того, він ще й адміністратор такого проєкту open source як Rust. Колись він писав, що понад місяць займався лише тим, щоб навести лад у списку issues, про які повідомляли учасники спільноти — видалити повторювані, закрити розв’язані або зібрати вимоги до незрозуміло пояснених проблем. Уже згаданий раніше Linux — це також проєкт, який повністю контролює спільнота. Лінус Торвальдс (Linus Torvalds), засновник цього проєкту, віддав його на повну опіку спільноті open source, хоча він і досі лишається тією людиною, що найактивніше розробляє, підтримує й адмініструє Linux.

2. Спільнота контролює проєкт лише частково

Над проєктом працює спільнота розробників, але є певна команда — центр спільноти, core, який ухвалює основні рішення щодо проєктів. Наприклад, популярний JavaScript-фреймворк React підтримує спільнота, але керують ним розробники з компанії Facebook. Інший приклад — платформа для створення чатботів Botpress. Чимало людей працюють над цим проєктом, і я пишаюся бути серед них. Проте керівник проєкту — компанія Botpress.

Чи можна заробити на open source

Заробити реально, але невиправдано важко. Як звичайний малоактивний учасник певної спільноти ви не зможете одержати прибуток. Як власник проєкту або ентузіаст open source — можливо, хоча й малоймовірно. Ось кілька способів, щоб монетизувати цю ініціативу:

Для власників проєктів можна одержати прибуток з підтримки й консультацій корпоративних користувачів продукту. Повертаючись до прикладу з Linux, ми вже з’ясували, що ця ОС безплатна. Однак уявіть, що є велика компанія, яка хоче перевести всі свої комп’ютери на Linux. Налаштувати десятки й сотні пристроїв — це робота не для однієї людини й не на один день. Компанія Linux пропонує таким клієнтам платну послугу зі встановлення й налаштування свого програмного забезпечення на всіх комп’ютерах замовника. Якщо замовник згоден, компанія Linux одержує прибуток.

Для власників проєктів і деяких учасників спільноти:

  • Bug Bounty — це ініціатива, яка дає змогу розробникам програмного забезпечення отримати нагороду від власника проєкту за знаходження і розв’язання помилок у коді. Таку ініціативу підтримують, наприклад, Google, Microsoft, Reddit, Yahoo й Facebook. Доволі часто такі ініціативи перетинаються з проєктами open source.
  • Bountysource — це платформа, де люди пропонують грошову винагороду, якщо ви розв’язуєте певну програмну проблему. Як це пов’язано з open source? У деяких GitHub-проєктах ви можете зауважити таке речення: «Want to back this issue? Post a bounty on it! We accept bounties via Bountysource». Ось це і є ваш шанс заробити!
  • Крім того, можна спробувати знайти спонсорів, які підтримуватимуть власників проєкту, найактивніших учасників спільноти або програмістів, які розв’язуватимуть найскладніші проблеми.

Хай там як, а заробіток — не основна мета участі в open source. Тоді виникає запитання: навіщо?

Для чого брати участь в open source

Усі знають, як важко знайти роботу людині без досвіду. Open source — це досвід, який ви можете сміливо згадати у своєму CV. Якщо HR запитає вас, чи знаєте ви React, то вразьте його й скажіть, що належите до спільноти розробників цього фреймворку! Або ж реалістичніший приклад: сконтактуйтеся з кимось з community й прилучіться до підтримки менш розкрученого проєкту (наприклад, Svelte) на місяць. Ви й користь зможете принести проєкту, й цікаві знайомства здобути, і, звісно, у резюме зможете це згадати.

Open source — це чудова нагода вдосконалити свої знання й навички програмування без курсів і без книжок. Коли ваш pull request перевіряє Ден Абрамов (Dan Abramov) або той самий Стів Клабнік (Steve Klabnik), то ви думаєте про якість коду й про зауваження до нього куди більше, ніж коли пишете код для себе або на курсах. І повірте, ці хлопці знають «трохи» більше за пересічного тимліда з вашого міста, а отже, є і більше речей, яких можна й повчитися в них.

Open source — це соціальна відповідальність. Ви розв’язуєте один баг в проєкті open source й автоматично розв’язуєте його для всіх, хто використовує цей продукт. Наприклад, розв’язуючи одну проблему в Botpress, я ще додав підтримку української мови на платформі.

Як можна долучитися до Open Source

Прилучитися до open source просто. Зробити це добре — трохи важче, але цілком реально. Правила гри доволі прості:

  1. Якщо ви використовуєте певний продукт open source (бібліотеку, фреймворк, операційну систему, програму...), підтримайте мотивацію людей, які до нього докладають зусилля. Поставте їм зірочку, лишіть декілька дописів до наявних issue, висловіть подяку комусь із розробників. Не уявляєте, скільки відкритих проєктів це могло б урятувати від занепаду.
  2. Якщо ви знаходите помилку в проєкті open source, що його ви використовуєте, — відкрийте GitHub проєкту й повідомте про проблему. Повідомити про проблему можна добре, а можна погано. Щоб повідомити погано, напишіть, що проблема є, але не описуйте її, не розповідайте деталі й не додавайте зображень. Ба більше, напишіть це «на емоціях» і звинуватьте адміністратора в поганій підтримці проєкту: «ВАША ПРОГРАМА НЕ ПРАЦЮЄ!!! ЗРОБІТЬ ЩОСЬ!!!» Так ви, звісно ж, «підвищите» мотивацію людей, які працюють над проєктом (зазвичай у вільний від роботи час на безоплатній основі) й змусите їх потренувати свої детективні навички в розумінні ваших натяків на існування проблеми. Щоб повідомити про помилку добре, зробіть навпаки — додайте ідеальний опис того, що сталося та за яких умов, а ще ліпше, зробіть знімки екрана, на яких проблему буде видно. Ось гарний приклад того, як створювати опис помилок, з якими розробниками приємно працювати:

  3. Якщо можете розв’язати проблему, яку знайшли ви або хтось інший, то розв’яжіть її і зробіть pull request. Pull request теж можна зробити добре й погано. Щоб виконати його погано, проігноруйте всі інструкції та гайди, зробіть багато невмотивованих або непояснених змін, ігноруйте стиль коду, не пишіть тестів і не ведіть документацію. У результаті ваш PR висітиме місяцями й відбиратиме енергію на спілкування й пояснення потреби в дотриманні стандартів у команді. І, можливо, так і не буде прийнятий. Щоб зробити pull request добре, уважно прочитайте й використайте Contribution Guidelines — опис основних принципів і правил роботи з певним проєктом, а також зважайте на те, у яку гілку ви мерджите свій pull request.

Ще один спосіб стати частиною спільноти open source — це відвідувати заходи, що вона проводить. Наприклад, Hacktoberfest — це рух, що підтримує open source й щороку проводить жовтневі хакатони в усьому світі. У Львові ця подія вже відбувалася 2018 і 2019 роках за підтримки компанії KeenEthics. Читайте в пресрелізі про те, як це було.

Як розпочати

Багато хто думає: «Я не такий кваліфікований, щоб викладати щось на GitHub». З чого ж розпочати в такому разі?

Найперше, як описано вище, спробуйте відвідувати заходи, що організовує спільнота. Коли ви подивитеся на учасників open source, то зрозумієте, що не святі горшки ліплять. Колеги й однодумці допоможуть вам здобути впевненість у собі та ліпше збагнути філософію open source.

Крім того, можете зорганізувати собі імпровізовану менторську програму. Серед друзів або колег знайдіть когось досвідченішого, хто вже підтримує open source, і попросіть його поділитися досвідом. Попросіть оцінити ваші технічні навички, попрацюйте пліч-о-пліч з ними й разом зробіть ваш перший pull request на GitHub.

Уже згадував, що своїм першим PR я всього-на-всього поправив українську локалізацію. Це хороший варіант для старту: це зазвичай нескладні зміни для носія мови, до того ж може статися, що носіїв української в ком’юніті певних проєктів мало або тільки ви і є.

Підсумуємо

Участь в open source навряд принесе вам фінансову вигоду. Однак вона подарує щось більше — задоволення собою, нестандартні головоломки для тренування мозку, спілкування з цікавими людьми й безцінний досвід. Якщо хочете дізнатися більше про те, як і навіщо ставати учасником цієї спільноти, пишіть на oleksiy.pletnov@keenethics.com. Якщо переконувати вас більше не треба, відкривайте GitHub, повідомляйте про issue і робіть ваш перший pull request.

LinkedIn

Похожие статьи

4 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Усі знають, як важко знайти роботу людині без досвіду. Open source — це досвід, який ви можете сміливо згадати у своєму CV. Якщо HR запитає вас, чи знаєте ви React, то вразьте його й скажіть, що належите до спільноти розробників цього фреймворку!

Ага, я вот прям вижу, как абсолютные новички без опыта контрибьютят в реакт и их пулл реквесты принимаются. Максимум, это скорее всего фиксить что-то очень минорное. Например, опечатки в документации, что конечно тоже важно. Но потом на собеседованиях говорить, что принадлежишь к сообществу разработчиков это то же самое как после блог-туториала по джанго идти говорить, что ты middle backend engineer
Я к тому, что в большей части случаев, open-source — это не для новичков. Потому что 1)Большая кодобаза. 2) Требует оч хорошее знание предметной области и больших временных затрат

Постійно бачу цей бредовий комент після поради «контрібуть в опен-сорс».

1. Опен-сорс різний. Є ліби на 100 строчок. Є мастадонти як реакт.
2. Не обов’язково контрібутити зразу в реакт. Ваш кеп.
3. Почати можна з малих, але корисних штук, наприклад — я ще не бачив жодного опен-сорс проекту де б не було сотень хайлайтів від IDE про проблеми в коді. Не кажучи вже про всякі аналізатори.
4. Любий контрібюшн важливий, навіть typo fix. Бо вклинює людину в процеси, спілкування і тд.

Не можу підтримати твій допис, звісно частка істини є але..
Ось ми проводили хактобер, прийшло пів сотні людей, були без досвіду і вовки ))
Поговорив майже с кожним, не всі попали в ці п’ять хвилин, але основні думки зафіксовані www.youtube.com/...​watch?v=2MR55r-a_XA&t=11s

Ну, я таки поменял свое мнение после коммента выше. Все-таки да, опенсорс бывает разный

Подписаться на комментарии