Още тази седмица в Санкт Петербург ще се проведе 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, чиято вики поддържаше многоезичност. Направихме страници на няколко езика, не само на английски и руски, на които във всяко отношение можехме да комуникираме, а също и на немски и испански. В резултат беше много нелепо, когато питаха на тези езици, а ние изобщо не можем да отговорим. Или въвеждахме правила за написване на документация и коментиране, но тъй като API-то наистина се променяше доста често и съществено, нашата документация остаряваше и повече заблуждаваше, отколкото помагаше.
В крайна сметка, всичките ни усилия, дори и неправилните, доведоха до появата на външни потребители. И дори се появи търговски клиент, който искаше да му разработим собствена ОСРВ. И ние разработихме, защото имаме опит и някакви разработки. Тук трябва да спомена както добрите, така и лошите моменти. Ще започна с лошите. Тъй като много от разработчиците бяха привлечени за този проект на търговска основа, общността, и така доста нестабилна, се раздели, което разбира се не можеше да не се отрази на развитието на проекта. Допълнителен фактор беше, че посоката на проекта бе определяна от един търговски клиент, а целта му не беше последващо развитие на проекта. Най-малкото тази цел не беше основна.
От друга страна, имаше редица положителни моменти. Получихме наистина странични потребители. Това не беше само клиентът, а и тези, за които системата беше предназначена. Мотивацията да участват в проекта нарасна. Все пак, ако можеш да спечелиш от интересно занимание, винаги е приятно. И най-важното, чухме едно желание на клиентите, което в онзи момент ни се струваше абсурдно, но сега е основната идея на Embox, а именно, да използваме вече разработен код в системата. Сега основната идея на Embox е използване на софтуер с Linux без Linux. Тоест, основният положителен момент, който способства за по-нататъшното развитие на проекта, беше осъзнаването, че проектът се използва от странични потребители и той трябва да решава техните проблеми.
В онзи момент Embox вече беше излязъл извън рамките на студентски проект. Основният задържащ фактор за развитието на проекта по студентски модел е мотивацията на участниците. Студентите участват, докато учат, а когато завършат, трябва да се появи друга мотивация. Ако мотивацията не се появи, студентът просто спира да участва в проекта. Ако вземем предвид, че студентите първо трябва да бъдат обучени, то се получава, че добри специалисти стават в момента на завършването си, но приносът им в проекта, поради неопитността, не е много голям.
В общи линии, плавно преминаваме към основния момент, който позволява да се говори за създаването на opensource проект - създаването на продукт, който решава проблемите на потребителите. Както вече поясних по-горе, основното свойство на opensource проекта е неговата общност. И участниците в общността са преди всичко потребителите. Но откъде да се вземат, стига да няма какво да се използва? И така, се получава, че както при не opensource проекта, трябва да се съсредоточим върху създаването на MVP (минимално жизнеспособен продукт), и ако той заинтересува потребителите, ще се появи общност около проекта. Ако обаче се занимаваме със създаването на общност само чрез PR на общността, написването на wiki на всички езици на света или правилния git workflow на github, то едва ли това ще има значение в ранните фази на проекта. Разбира се, на съответстващите етапи, това не само че е важно, но и необходимо.
В заключение искам да подчертая , който, според мен, отразява очакванията на потребителите от opensource проект:
Сериозно обмислям преминаване на тази ОС (поне да я пробвам. Толкова активно я развиват и правят страхотни неща).
P. S. На имаме цели три лекции. Едната за open source и две за embedded (като единият е практически). На щанда ще проведем майсторски клас по програмиране на микроконтролери с помощта на . Традиционно ще донесем оборудване и ще позволим да се програмира. Ще има и куест и други активности. Заповядайте на фестивала и на нашия щанд, ще бъде забавно.
Източник: habr.com
