Що таке open source та навіщо він потрібен

Отже ви роздумуєте над початком роботи з open source? Вітаємо! Світ цінує ваш внесок. Давайте поговоримо про те, що таке open source та чому люди цим займаються.

Шо означає “open source”?

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

Open source є потужним, бо він знижує перешкоди на шляху впровадження, дозволяючи ідеям поширюватись швидше.

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

  • Кожен пробує пиріг (використання)
  • Пиріг стає хітом! Друзі просять у вас рецепт і ви його даєте (перегляд)
  • Один з друзів, кондитер, пропонує зменшити кількість цукру (зміна)
  • Інший товариш просить дозволу використати це для обіду на наступному тижні (поширення)

Для порівняння, цей процес з closed source проектом виглядав би як похід у ресторан та замовлення шматочку вишневого пирога. Ви маєте платити за те щоб скуштувати пирога і ресторан навряд чи дасть вам свій рецепт. Якщо ви повністю скопіювали їхній пиріг і продали його під своїм іменем, то ресторан може вжити заходів проти вас.

Чому люди роблять свою роботу open source?

Існує чимало причин, через які особа чи організація можуть захотіти зробити свій проект open source. Ось деякі приклади:

  • Співпраця: Open source проекти можуть приймати зміни від будь-кого у світі. Наприклад, Exercism, це платформа для вправляння у програмуванні з більш, ніж 350 учасниками.

  • Запозичення та переосмислення: Open source проекти можуть бути використані будь-ким і майже з будь-якою метою. Люди можуть навіть використовувати ці проекти для побудови інших. Наприклад, WordPress, був створений як відгалуження існуючого проекту під назвою b2.

  • Прозорість: Кожен може оглядати open source проект для пошуку помилок чи невідповідностей. Прозорість має значання для урядів таких країн, як от Болгарія чи Сполучені Штати Америки, регульованих галузей на кшталт банківської сфери та охорони здоров’я, або програмного забезпечення для безпеки на зразок Let’s Encrypt.

Варто зазначити, що Open source це не тільки для програмного забезпечення. Ви можете зробити open source усе що завгодно, від наборів даних до книжок. Ознайомтесь з GitHub Explore для ідей щодо того, що ще ви можете зробити open source.

Чи означає open source — “безкоштовно”?

Одна з найбільших принад open source полягає у тому, що це не коштує грошей. Втім, “безкоштовність” є побічним продуктом загальної вартості open source.

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

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

Чи слід мені запускати власний open source проект?

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

Якщо ви ніколи не мали open source проекта до цього, то можете нервувати з приводу того що скажуть інші, або чи взагалі хтось це помітить. Якщо звучить знайомо, ви не одні!

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

Якщо ви ще не переконались, присвятіть хвильку роздумам про свої цілі. Якими вони могли б бути?

Визначення ваших цілей

Цілі можуть допомогти вам усвідомити над чим працювати, чому сказати «ні», або де вам знадобиться стороння допомога. Почніть з запитання до себе: чому я роблю цей проект open source?

Не існує єдиної вірної відповіді на це питання. Ви можете мати багато цілей для одного проекту, або різні проекти з різними цілями.

Якщо вашою метою є лише показати результати своєї роботи, вам мабуть не знадобиться співпраця з іншими і ви навіть можете вказати це у файлі README. З іншого боку, якщо ви бажаєте залучити до проекту інших учасників, то варто попрацювати над документацією, щоб новачки почувались «бажаними гостями».

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

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

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

У випадку, коли для просування та підтримки проекту необхідні спеціальний бюджет чи додатковий персонал, всі ці питання мають обговорюватись заздалегідь.

Внески в інші проекти

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

Якщо ж ви не впевнені як приєднатись до чужого проекту і з чого почати, ознайомтесь із нашим матеріалом на цю тему — Як зробити внесок в Open Source.

Запуск вашого власного open source проекту

Не буває якогось ідеального часу для перетворення своєї роботи в open source проект. Ви можете робити це з ідеєю, роботою в процесі чи після років існування проекту в якості closed source.

Загалом, ви маєте відкривати свій проект коли почуваєтесь готовими до перегляду вашої роботи іншими людьми та їхнії відгуків.

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

Ці компоненти допоможуть вам, як модераторові, повідомляти про очікування, керувати внесками ти захищати юридичні права кожного (в тому числі й ваші власні). Вони істотно підвищують ваші шанси на отримання позитивного досвіду.

Як ваш проект знаходиться на GitHub, то розміщення цих файлів у кореневій директорії з рекомендованими назвами допоможе сервісу розпізнати їх та автоматично надати вашим читачам.

Вибір ліцензії

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

Юридична робота не цікава. Але хороші новини полягають у тому, що ви можете просто скопіювати та вставити існуючу ліцензію у свій репозиторій. Захист плодів вашої праці займе лише хвилину.

Найбільш розповсюдженими open source ліцензіями є MIT, Apache 2.0, та GPLv3, але існують й інші.

Під час створення нового проекту на GitHub, ви маєте опцію вибору ліцензії. Вибір open source ліцензії робить ваш GitHub проект теж open source.

оберіть ліцензію

Якщо у вас є інші запитання чи сумніви щодо юридичної сторони open source проекту, ми про все подбали.

Написання README

Файл README робить дещо більше, ніж просто розтлумачує як користуватись проектом. Він також пояснює чому ваш проект має значення та які можливості він дає користувачам.

У своєму README, постарайтесь відповісти на такі запитання:

  • Які задачі вирішує цей проект?
  • Чому цей проект корисний?
  • З чого почати?
  • Де, у разі потреби, можна знайти додаткову інформацію?

Ви можете використати ваш README для відповідей на інші запитання, наприклад: як ви чините з внесками, що проект має на меті та інформацію про ліцензію. Якщо ви не бажаєте приймати внески інших людей, або ваш проект ще не повністю готовий, опублікуйте цю інформацію також.

Іноді, люди уникають написання README, бо вважають проект незавершеним, або не бажають отримувати внески інших. Це, натомість, дуже хороші приводи написати його.

Для більшого натхнення, спробуйте скористатись інструментами для створення повноцінних README. Наприклад, “Створення читабельних READMEs” від @18F чи Шаблон README від @PurpleBooth.

Коли ви вставляєте файл README у кореневу директорію проекту, GitHub автоматично покаже його на домашній сторінці репозиторію.

Написання вказівок до співпраці

Файл CONTRIBUTING розповідає вашій аудиторії як прийняти участь в проекті. Наприклад, ви можете включити таку інформацію:

  • Як надіслати звіт про помилку (спробуйте відповідні шаблони)
  • Як запропонувати новий функціонал
  • Як налаштувати середовище та запустити тести

На додачу до технічних деталей, файл CONTRIBUTING це можливість донести свої побажання щодо внесків, такі як:

  • Для яких частин проекту ви не відмовились би від допомоги
  • Ваш план чи бачення проекту
  • Як учасники мають (або не мають) взаємодіяти з вами

Використання дружнього, лагідного тону та конкретні пропозиції щодо можливих внесків (як наприклад, написання документації чи створення сайту) можуть послужити гарну службу у плані заохочення до участі в проекті нових людей.

Наприклад, Active Admin починає свої вказівки щодо внесків так:

Перш за все, дякуємо за ваше рішення долучитись до проекту Active Admin. Це такі ж люди, як і ви, зробили Active Admin настільки гарним інструментом.

На ранніх стадіях проекту, файл CONTRIBUTING може бути простим. Вам варто завжди мати пояснення що до того, як надсилати звіти про помилки, створювати запити на підтримку та опис різноманітних технічних вимог (на зразок тестів) для створення внеску.

З часом можна додати туди й інші часті запитання. Розміщення цієї інформації означає, що все менше й менше людей будуть задавати вам одне й теж саме питання знову і знову.

Більше інформації по написанню файлу CONTRIBUTING шукайте у шаблоні від @nayafia чи статті “How to Build a CONTRIBUTING.md” від @mozilla.

Додайте посилання на файл CONTRIBUTING зі свого README, щоб більше людей могли з ним ознайомитись. Якщо ви розмістите файл CONTRIBUTING у репозиторії свого проекту, GitHub автоматично звертатиметься до нього коли учасник задає питання чи створює запит на злиття.

вказівки до внесків

Впровадження кодексу честі

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

Більше інформації дивіться у нашому путівнику по кодексу честі.

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

Як і у випадку з open source ліцензіями, існують також певні стандарти для кодексу честі, тож вам не потрібно писати все з нуля. Contributor Covenant це кодекс честі, що використовується більше, ніж 40,000 open source проектів, включаючи Kubernetes, Rails та Swift. Не має значення який текст ви використовуєте, треба бути готовим застосувати ваш кодекс честі за потреби.

Вставляйте текст прямо у файл з назвою CODE_OF_CONDUCT у своєму репозиторії. Тримайте його у кореневій директорії проекту, щоб його було легко знайти та зробити посилання з файлу README.

Назва та бренд вашого проекту

Брендинг це більше, ніж помітний логотип та вдала назва проекту. Це щось на кшталт того, що ви хочете сказати про свій проект та до кого ви хочете донести свою розповідь.

Вибір правильної назви

Оберіть назву, яку легко запам’ятати. В ідеалі вона має давати уявлення про те, що проект робить. Наприклад:

  • Sentry моніторить програми для звітів про крах
  • Thin це швидки та простий веб-сервер на Ruby

Якщо ви робите щось на базі існуючого проекту, використання його назви допоможе розтлумачити призначення вашого проекту (напр. node-fetch додає window.fetch до Node.js).

Приділіть увагу внесенню ясності. Каламбури це весело, але пам’ятайте що деякі жарти можуть бути неприйнятними в інших культурах чи для людей з іншим досвідом. Деякі з ваших потенційних користувачів можуть бути працівниками компаній: не змушуйте їх почуватись некомфортно, коли їм доведеться розповідати про ваш проект на роботі!

Уникнення конфліктів

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

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

Перевірте щоб назва вашого проекту не перетиналась з назвою жодної торгової марки. Інакше, згодом та компанія може вимагати від вас закрити проект або застосувати проти вас дії юридичного характеру. Воно того не варте.

Наявність конфліктів з торговими марками можна перевірити на WIPO Global Brand Database. Якщо ви представник компанії, то з цим вам може допомогти юридичний відділ.

Насамкінець, зробіть пошук у Google з назвою свого проекту. Чи зможуть люди легко знайти ваш проект? Можливо, у результатах пошуку з’являється щось, чого ви не хотіли б там бачити?

Те, що ви пишете, впливає на ваш бренд теж!

Протягом існування проекту ви виконуватимете багато письмової роботи: файли README, посібники, документи спільноти, відповіді на запитання, можливо навіть новинні розсилки.

Хай це офіційна документація чи неформальний лист, ваш текст це частина вашого бренду. Подумайте як вам звертатись до своєї аудиторії та якого тону дотримуватись.

Чемна манера спілкування (наприклад, використання «ви» при зверненні до однієї особи) здатна позитивно вплинути на бажання інших людей приєднатися до проекту. Дотримуйтесь простих слів та виразів, оскільки для багатьох з ваших читачів англійська мова може не бути рідною.

Окрім написання текстів, стиль написання коду також може стати частиною бренду вашого проекту. Angular та jQuery це два приклади проектів зі строгими стилями коду та посібниками.

Не обов’язково створювати довідку щодо стилю на самому початку. Вам може сподобатись поєднувати у своєму проекті різні стилі написання коду. Але ви маєте зважати на те, яке враження ваші стилі написання тексту та коду можуть справити на різні групи людей. Ранні стадії проекту це можливість запровадити бажані стандарти.

Ваш передстартовий контрольний список

Готові відкрити свій open source проект? Тут наведено контрольний список у поміч. Виконали та врахували усі пункти? Ви готов розпочати! Натисніть “publish” та відкиньтесь на спинку.

Документація

Код

Люди

Якщо ви виступаєте від свого імені:

Якщо ви дієте від імені компанії чи організації:

Ви зробили це!

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