Вже цього тижня у Санкт-Петербурзі пройде IT-фестиваль . Одним із спікерів буде Річард Столлман. теж бере участь у фестивалі, і звичайно ми не могли залишити без уваги тему СПО. Тому одна з наших доповідей називається . Він буде присвячений історії розвитку Embox як проекту із відкритим кодом. У цій статті я хочу розповісти про основні ідеї, які на мою думку впливають на розвиток Opensource проектів. Стаття, як і доповідь, ґрунтується на особистому досвіді.
Почнемо з простого, з визначення терміну Opensource. Очевидно, що проект з відкритим кодом є проектом, який має одну з ліцензій, які дозволяють отримувати доступ до вихідного коду проекту. Крім того, відкритий проект передбачає можливість внесення змін сторонніми розробниками. Тобто, якщо якась компанія або розробник, опублікує код свого продукту, частково або повністю, то це ще не робить цей продукт Opensource проектом. І нарешті, будь-яка проектна діяльність має призводити до появи якогось результату, причому відкритість проекту передбачає, що цей результат використовують не лише самі розробники.
Проблеми відкритих ліцензій чіпати не будемо. Це дуже велика і складна тема, яка потребує глибокого розгляду. На цю тему написано чимало хороших статей і матеріалів. Але оскільки сам я не фахівець у галузі авторського права, то скажу тільки, що ліцензія повинна відповідати цілям проекту. Наприклад, для Embox вибір BSD, а не ліцензії GPL не був випадковим.
Той факт, що відкритий проект має давати можливість вносити зміни та впливати на розвиток відкритого проекту, передбачає, що проект розподілений. Керувати ним, зберігати цілісність і працездатність набагато складніше, порівняно з проектом, що має централізоване управління. Виникає резонне питання, навіщо взагалі робити відкриті проекти. Відповідь лежить у галузі комерційної доцільності, для певного класу проектів вигода від такого підходу переважує витрати. Тобто не для всіх проектів підходить і взагалі допустимо відкритий підхід. Наприклад, важко уявити розробку системи керування електростанцією або літаком, засновану на відкритому принципі. Ні, звичайно до складу подібних систем варто включати модулі на основі відкритих проектів, адже це дасть низку переваг. Але за кінцевий продукт має хтось відповідати. Навіть якщо система повністю заснована на коді відкритих проектів, розробник, запакувавши все в одну систему і зробивши конкретні складання та налаштування, по суті закриває її. Код у своїй може бути у публічному доступі.
Для цих систем також існує безліч переваг від створення відкритих проектів або участі в них. Як я вже сказав, код кінцевої системи може залишитись у публічному доступі. Навіщо, очевидно, навряд чи в когось знайдеться такий самий літак, щоб протестувати систему. Це правда, але цілком може знайтися бажаючий перевірити окремі ділянки коду, або, наприклад, хтось може виявити, що бібліотека не зовсім коректно налаштована.
Ще більша вигода з'являється, якщо компанія виділяє деяку базову частину системи в окремий проект. Наприклад, бібліотеку з підтримки якогось протоколу обміну даними. У цьому випадку, навіть якщо протокол специфічний для даної предметної області, можна розділити витрати на підтримку даного шматка системи з іншими компаніями цієї галузі. Крім того, фахівцям, які можуть вивчити цей шматок системи у відкритому доступі, потрібно набагато менше часу для ефективного використання. Ну і нарешті, виділення шматка в самостійну сутність, яку використовують сторонні розробники, дозволяє зробити цю частину якіснішою, адже потрібно запропонувати ефективні API, зробити документацію, я навіть не говорю про покращення тестового покриття.
Комерційну вигоду компанія може отримати і не створюючи відкритих проектів, достатньо, щоб її фахівці брали участь у сторонніх проектах, що застосовуються в компанії. Адже всі вигоди залишаються: співробітники краще знають проект, отже ефективніше його використовують, компанія може впливати на напрямок розвитку проекту, та й використання готового налагодженого коду, явно скорочує витрати компанії.
На цьому переваги від створення Opensource проектів не закінчуються. Візьмемо таку важливу складову бізнесу, як маркетинг. Для нього це дуже гарна пісочниця, що дозволяє ефективно оцінити вимоги ринку.
І звичайно, не потрібно забувати, що Opensource проект є ефективним шляхом заявити про себе як носії будь-якої спеціалізації. У деяких випадках це взагалі єдиний шлях виходу ринку. Наприклад, Embox починався як проект створення ОСРВ. Напевно, не треба пояснювати, що існує купа конкурентів. Без створення спільноти, у нас просто не вистачило б ресурсів довести проект до кінцевого користувача, тобто щоб проектом стали користуватися сторонні розробники.
Спільнота є ключовим в Opensource проекті. Воно дозволяє суттєво скоротити витрати на управління проектом, розвиває та підтримує проект. Можна сказати, що без спільноти взагалі немає Opensource проекту.
Про те, як створити та керувати спільнотою проекту з відкритим кодом, написано безліч матеріалів. Я, щоб не переказувати вже відомі факти, постараюся наголосити на досвіді Embox. Наприклад, дуже цікавим питанням є процес створення спільноти. Тобто, багато хто розповідає як управляти існуючим співтовариством, але ось моменти його створення, часом упускають з уваги, вважаючи це даністю.
Головне правило при створенні спільноти Opensource проекту - немає жодних правил. Я маю на увазі універсальних правил не існує, так само як срібної кулі, хоча б тому, що проекти дуже різні. Навряд чи можна одними і тими ж правилами користуватися при створенні спільноти для бібліотеки логування на js і якась вузькоспеціалізований драйвер. Більше того, на різних стадіях розвитку проекту (а отже і спільноти) правила змінюються.
Embox розпочинався як студентський проект, оскільки був доступ до студентів кафедри системного програмування. По суті, ми заходили в якусь іншу спільноту. Учасників цієї спільноти, студентів, ми могли зацікавити гарною промисловою практикою за їхньою спеціальністю, науковими роботами в галузі системного програмування, курсовими та дипломами. Тобто ми виконували одне з основних правил організації спільноти, учасники спільноти повинні щось отримати, причому ця ціна має відповідати вкладу учасника.
Наступною стадією Embox став пошук сторонніх користувачів. Дуже важливо розуміти, що користувачі це повноцінні учасники Opensource спільноти. Користувачів зазвичай більше, ніж розробників. І щоб захотіти стати контриб'ютером проекту, спочатку так чи інакше його починають використовувати.
Першими користувачами Embox стала кафедра Теоретичної Кібернетики. Вони запропонували створити альтернативну прошивку для Lego Mindstorm. Та хоч це досі локальні користувачі (ми з ними могли зустрітися особисто, та обговорити що вони захочуть). Але все одно це був дуже добрий досвід. Наприклад, ми розробили демки, які можна було показати іншим, адже роботи це весело та привертає увагу. У результаті у нас з'явилися по-справжньому сторонні користувачі, які стали запитувати, що Embox і як цим користуватися.
На цій стадії нам довелося замислюватися про документацію, про засоби комунікації з користувачами. Ні звичайно ми замислювалися про ці важливі речі і раніше, але це було передчасно та не давало позитивного ефекту. Ефект був швидше негативний. Наведу кілька прикладів. Ми використовували googlecode, wiki якого підтримувало мультимовність. Ми зробили сторінки кількома мовами, причому не тільки англійську та російську, якими погано бідно могли комунікувати, а й німецьку та іспанську. В результаті дуже безглуздо виглядало, коли запитують цими мовами, але ми взагалі не можемо відповісти. Або вводили правила про написання документації та коментування, але оскільки API змінювалося досить часто і суттєво, виходило, що наша документація застаріла, і вводила в оману більше, ніж допомагала.
У результаті всі наші зусилля, навіть не правильні, призвели до того, що з'явилися зовнішні користувачі. І навіть з'явився комерційний замовник, який хотів, щоби для нього розробили власну ОСРВ. І розробили ми, оскільки у нас є досвід і якісь напрацювання. Тут треба розповісти і про гарні моменти та про погані. Почну з поганих. Оскільки багато розробників було залучено до даного проекту на комерційній основі, співтовариство і так досить нестійке, розділилося, що звичайно не могло не позначитися на розвитку проекту. Додатковим чинником, було те, що напрям проекту ставилося, одним комерційним замовником, яке метою було подальший розвиток проекту. Принаймні ця мета не була основною.
З іншого боку, була низка позитивних моментів. Ми отримали дійсно сторонніх користувачів. Це був не тільки замовник, а й ті, для кого ця система призначалася. Мотивація брати участь у проекті зросла. Адже, якщо на цікавій справі можна ще й заробити, це завжди приємно. І головне, ми почули одне бажання замовників, яке на той момент, здавалося нам маячним, але яке зараз є основною ідеєю Embox, а саме використовувати в системі вже розроблений код. Зараз основна ідея Embox це використання Linux без Linux. Тобто, основним позитивним моментом, що сприяє подальшому розвитку проекту було усвідомлення, що проект використовують сторонні користувачі, і він повинен вирішувати якісь їхні проблеми.
На той момент Embox вже вийшов за рамки студентського проекту. Основним стримуючим фактором розвитку проекту за студентською моделлю є мотивація учасників. Студенти беруть участь, поки вони навчаються, а коли вони випустилися, має з'явитися інша мотивація. Якщо мотивація не з'являється, студент просто перестає брати участь у проекті. Якщо взяти до уваги, що студентів спочатку потрібно навчити, то виходить, що хорошими фахівцями вони стають на момент випуску, але внесок у проект, через недосвідченість, не дуже великий.
Загалом ми плавно переходимо до основного моменту, що дозволяє говорити про створення opensource проекту, — створення продукту, який вирішував би проблеми його користувачів. Як я вже пояснив вище, основна властивість Opensource проекту, це його співтовариство. Причому учасники спільноти – це насамперед користувачі. Але звідки їм взятися поки нема чим користуватися? Ось і виходить, що так само як і з неоpensource проектом, потрібно зосередитися на створенні MVP (мінімальний життєздатний продукт), і якщо він зацікавить користувачів, то навколо проекту з'явиться співтовариство. Якщо ж займатися створенням спільноти тільки через піар спільноти, написанням wiki на всіх мовах світу, або правильним git workflow на github, то навряд це буде мати значення, на ранніх стадіях проекту. Звісно, на відповідних стадіях це не лише важливі, а й необхідні речі.
На закінчення хочу навести , На мій погляд відображає очікування користувача від Opensource проекту:
Я всерйоз замислююся про перехід на цю ОС (принаймні, спробувати. Дуже вже її активно пиляють і круті штуки роблять).
PS На у нас буде аж три доповіді. Один про open source і два про embedded (причому один практичний). На стенді проведемо майстер клас із програмування мікроконтролерів за допомогою . Традиційно привеземо залізниці та дамо їх попрограмувати. Буде ще квест та інші активності. Приходьте на фестиваль та на наш стенд, буде весело.
Джерело: habr.com