GitLab про політику управління проектами open source

Деякі скептично висловлюються щодо ГитЛаба — мовляв ось ви перестанете підтримувати безкоштовний Community Edition(CE), і що ми будемо робити? Не перестанемо. Публікуємо для вас переклад статті на цю тему.


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

Складності управління open source проектом
Маттіас Штюрмер (Matthias Stürmer) з сайту Opensource.com визначив чотири типу open source спільнот:
  1. Проекти з єдиним куратором (single-vendor projects)
  2. Співтовариства розробників (development communities)
  3. Спільноти користувачів (user communities)
  4. Центри взаємодії (open source competence centers)
Останні три типу характеризуються розподіленими процесами розробки. У деяких випадках розробка координується некомерційними організаціями, що виникли на базі співтовариства, але, в будь-якому випадку, у спільноти такого типу немає якогось одного джерела фінансування. Прикладами таких спільнот є Apache, Rails і Linux.
Навпаки, перший тип, «проекти з єдиним куратором» характеризується фінансовою підтримкою конкретної комерційної організації, яка контролює напрямок розвитку проекту і фінансує більшість основних розробників. Прикладами спільнот такого типу є Wordpress і Automattic; Hadoop і Cloudera; Elasticsearch і Elastic.
щоразу, коли розвитком open source проекту займається компанія-куратор, виникає питання — яку модель розвитку вона обере? Компанія повинна балансувати між потребами бізнесу, підтримкою розробки і тим, щоб проект залишався на плаву. Більше того, компанія повинна отримувати прибуток з проекту, адже сам проект і його спільнота фінансуються саме на її гроші. Однак, на відміну від, з закритим вихідним кодом, open source проекти можуть бути форкнуты і продовжувати свій розвиток за межами компанії-куратора.
Для нас open source — це набір етичних зобов'язань, а не просто ліцензія
Open source з'явився як наслідок руху Free Software. Коли термін 'open source' зародився наприкінці 90х, з його допомогою підкреслювався той факт, що вихідний код можна було переглянути і навіть модифікувати. Також за допомогою цього терміна вдалося позбутися від порівнянь з пивом («free as in beer»), які натякали на низьку якість продукту. У той же час, введення терміна open source заклало фундамент для фінансування таких проектів комерційними організаціями. З 1998 року open source став стандартом де-факто, показником якості та гарантією того, що проект не буде монополізований куратором (vendor lock-in).
Проте запровадження терміна 'open source' був і зворотний ефект — втратили чинність активістські коріння руху Free Software («free as in freedom»). В основі руху open source лежить колаборація, для якої потрібна взаємна довіра. Коли комерційні компанії, що здійснюють підтримку open source проектів, нехтують цими принципами, взаємна довіра втрачається, а без нього вся концепція open source перестає працювати.
Будь-яка компанія, яка робить код відкритим в гонитві за конкурентними перевагами, повинна враховувати етичні питання, які негайно виникнуть при цьому. Open source це не просто тип ліцензії, а ще і набір етичних зобов'язань. Наша компанія взяла на себе ці зобов'язання, сформулювавши політику гарного керуючого open source проектом.
Що значить бути хорошим керівником open source проекту?
Я не хотів створювати політику керуючого до тих пір, поки у нас не було абсолютного розуміння всіх умов і контексту нашого проекту і компанії. Тепер, після декількох років, ми краще розуміємо ситуацію і відповідні їй вимоги.
Перш за все, потрібно думати в інтересах проекту, при цьому не забуваючи про реалії бізнесу, який цей проект підтримує. При створенні нашої політики ми врахували досвід інших громад і проектів, у яких були з цим проблеми. Компанії з open source проектами часто критикують за наступними пунктами:
  • Прозорий процес прийняття рішень щодо напрямку розвитку проекту.
  • Участь компанії у відкритих каналах комунікації.
  • Турбота про інтереси компанії в збиток інтересам проекту.
Всі ці пункти повинні бути прийняті до уваги, якщо ми хочемо домогтися повної підтримки проекту, коду, спільноти і користувачів.
З іншого боку, не можна фокусувати увагу виключно на потреби проекту, забувши про комерційні питання. Зрештою, комерційна успішність — необхідна умова існування проекту.
наприклад, наша досвідчена команда продажників поділилася з нами своїми бідами: «Чому має бути абсолютно безкоштовним для всіх користувачів? Чому користувачі, які працюють з командами з більш ніж 10000 розробників, не платять нам ні копійки?» Адже при продажу інтелектуальної власності можна встановлювати ліміт на безкоштовне використання. Продажники запитують: «Чому б не встановити ліміт на кількість користувачів у безкоштовній версії? Поки у вас менше 1000 розробників, ви можете користуватися Community Edition, але для більш великої команди вам доведеться купити enterprise edition.» З економічної точки зору таке рішення виправдане, але в контексті open source воно втрачає всякий сенс.
Open source — це не умовно-безкоштовна модель, де ми можемо закрити доступ до продукту через 30 днів. Продукт безкоштовний цілком і повністю. Назавжди.
Ми не єдина компанія, що зіткнулася з такими проблемами. Рік тому Адам Джейкоб (Adam Jacob) з Chef сказав: «Ми намагаємося зрозуміти, яку функціональність потрібно включати в різні пакети послуг, і як знайти баланс між нашим прагненням до ведення успішного бізнесу і нашої щиру віру в те, що open source є майбутнім інфраструктури.» Це було рік тому, з тих пір Chef помітно просунулися як керуючі свого проекту.
Нейтен Харві (Nathen Harvey), нині віце-президент з розвитку спільноти (VP of Community Development) Chef у своєму інтерв'ю на цю тему сказав наступне: «На перетині open source і комерційних інтересів піднімаються питання повноважень, автентичності та культури.» Що виявиться важливішим — комерційні інтереси або розвиток проекту? Це дуже важливе питання, над відповіддю на який повинні задуматися в будь-якому open source проект з єдиним куратором. Нейтен призводить свій головний принцип з цього питання: «прозорість найважливіше» — ми з ним повністю в цьому згодні.
У чому полягає наша політика?
Наші погляди на open source не просто закріплені в нашій політиці — вони простежуються в кожному аспекті нашої роботи. Ми вважаємо, що не можна отримати конкурентну перевагу, закрившись від зовнішнього світу. Навпаки, ми прагнемо підтримувати рівень комунікації та колаборації з спільнотою як можна більш високим.
  • Відкрита розробка. Ви можете відправляти тікети в публічний трекер, це не read-only інтерфейс.
  • Відкрите ведення бізнесу. Політики та основні правила ведення нашого бізнесу відкриті для всіх бажаючих.
  • Чітка стратегія розвитку. У нашому документі «Стратегія» (Direction) містяться поточні пріоритети розвитку проекту, а також приблизний зміст майбутніх релізів.
Такий рівень прозорості є небувалим для з закритим кодом, рідкісним для open source проектів з єдиним куратором і нетиповим навіть серед інших платформ керування репозиторіями (неважливо, open source чи ні). По правді кажучи, історія управління вихідним кодом і роботи з спільнотою сповнена навмисного заплутування і історій порушеного довіри. Ми не хочемо повторювати цих помилок і вважаємо, що для того, щоб GitLab став місцем для безпечної і відкритої спільної розробки, він сам зобов'язаний бути open source платформою.
В нашій політиці ми звертаємо увагу на ті речі, які ми обіцяли не робити. Ми чітко окреслили різницю між GitLab CE (Community Edition) і EE (Enterprise Edition), і ми враховуємо вимоги співтовариства чітко вказуючи всі наші зобов'язання.
Ми закликаємо вас ознайомитися з нашою політикою. Тепер, коли вона опублікована, ви можете вимагати від нас її виконання.
будь Ласка, прочитайте «Принципи управління GitLab CE».
Переклад з англійської виконаний перекладацької артіллю «Надмозг і партнери», http://nadmosq.ru, головний перекладач — sgnl_05
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.