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