Тази седмица в Санкт Петербург ще се проведе IT фестивал . Един от лекторите ще бъде Ричард Столман. също участва във фестивала, като разбира се нямаше как да подминем темата за свободния софтуер. Ето защо един от нашите репортажи се нарича . Тя ще бъде посветена на историята на развитието на Embox като проект с отворен код. В тази статия искам да говоря за основните идеи, които според мен влияят върху развитието на проекти с отворен код. Статията, както и докладът, се основава на личен опит.
Нека започнем с нещо просто, с определението на термина отворен код. Очевидно проект с отворен код е проект, който има един от лицензите, който позволява достъп до изходния код на проекта. В допълнение, отвореният проект означава, че разработчиците на трети страни могат да правят промени. Тоест, ако някоя компания или разработчик публикува кода на своя продукт, частично или изцяло, това все още не прави този продукт проект с отворен код. И накрая, всяка проектна дейност трябва да доведе до някакъв резултат, а отвореността на проекта предполага, че този резултат се използва не само от самите разработчици.
Няма да засягаме проблемите на отворените лицензи. Това е твърде голяма и сложна тема, която изисква задълбочено изследване. По тази тема са написани доста добри статии и материали. Но тъй като самият аз не съм експерт в областта на авторското право, ще кажа само, че лицензът трябва да отговаря на целите на проекта. Например за Embox изборът на BSD вместо GPL лиценз не беше случаен.
Фактът, че един проект с отворен код трябва да предоставя възможност за извършване на промени и влияние върху развитието на проекта с отворен код, предполага, че проектът е разпространен. Управлението му, поддържането на целостта и ефективността е много по-трудно в сравнение с проект с централизирано управление. Възниква разумен въпрос: защо изобщо се правят отворени проекти? Отговорът се крие в областта на търговската осъществимост; за определен клас проекти ползите от този подход надвишават разходите. Тоест не е подходящ за всички проекти и отвореният подход като цяло е приемлив. Например, трудно е да си представим разработването на система за управление на електроцентрала или самолет, базирана на отворен принцип. Не, разбира се, такива системи трябва да включват модули, базирани на отворени проекти, защото това ще осигури редица предимства. Но някой трябва да отговаря за крайния продукт. Дори ако системата е изцяло базирана на кода на отворени проекти, разработчикът, след като е пакетирал всичко в една система и е направил специфични компилации и настройки, по същество я затваря. Кодът може да е публично достъпен.
Има и много ползи за тези системи от създаването или приноса към проекти с отворен код. Както вече казах, кодът на крайната система може да остане публично достъпен. Защо, защото е очевидно, че едва ли някой ще има същия самолет, за да тества системата. Това е вярно, но може да има някой, който иска да провери определени части от кода или, например, някой може да открие, че използваната библиотека не е конфигурирана съвсем правилно.
Още по-голяма полза се появява, ако компанията отдели някаква основна част от системата в отделен проект. Например библиотека за поддържане на някакъв вид протокол за обмен на данни. В този случай, дори ако протоколът е специфичен за дадена предметна област, можете да споделите разходите за поддръжка на тази част от системата с други компании от тази област. В допълнение, специалистите, които могат да изучават тази част от системата в публичното пространство, изискват много по-малко време, за да я използват ефективно. И накрая, отделянето на част в независим обект, който разработчиците на трети страни използват, ни позволява да направим тази част по-добра, защото трябва да предложим ефективни API, да създадем документация и дори не говоря за подобряване на тестовото покритие.
Една компания може да получи търговски ползи, без да създава проекти с отворен код, достатъчно е нейните специалисти да участват в проекти на трети страни, използвани в компанията. В крайна сметка всички предимства остават: служителите познават проекта по-добре, следователно го използват по-ефективно, компанията може да повлияе на посоката на развитие на проекта, а използването на готов, дебъгван код очевидно намалява разходите на компанията.
Ползите от създаването на проекти с отворен код не свършват дотук. Да вземем такъв важен компонент на бизнеса като маркетинга. За него това е много добър пясъчник, който му позволява ефективно да оцени изискванията на пазара.
И разбира се, не трябва да забравяме, че проектът с отворен код е ефективен начин да се заявите като носител на всяка специализация. В някои случаи това е единственият начин за навлизане на пазара. Например Embox започна като проект за създаване на RTOS. Вероятно няма нужда да обяснявам, че има много конкуренти. Без създаването на общност ние просто нямаше да разполагаме с достатъчно ресурси, за да донесем проекта на крайния потребител, т.е. разработчиците от трети страни да започнат да използват проекта.
Общността е ключова в проект с отворен код. Тя ви позволява значително да намалите разходите за управление на проекти, да развиете и подкрепите проекта. Можем да кажем, че без общност изобщо няма проект с отворен код.
Изписани са много материали за това как да създадете и управлявате общност на проекти с отворен код. За да не преразказвам вече известни факти, ще се опитам да се спра на опита на Embox. Например, процесът на създаване на общност е много интересен въпрос. Тоест мнозина казват как да управляват съществуваща общност, но моментите на нейното създаване понякога се пренебрегват, считайки това за даденост.
Основното правило при създаване на общност за проекти с отворен код е, че няма правила. Искам да кажа, че няма универсални правила, точно както няма сребърен куршум, дори само защото проектите са много различни. Малко вероятно е да можете да използвате едни и същи правила, когато създавате общност за библиотека за регистриране на js и някакъв високоспециализиран драйвер. Освен това, на различни етапи от развитието на проекта (и следователно на общността), правилата се променят.
Embox започна като студентски проект, защото имаше достъп до студенти от отдела по системно програмиране. Всъщност навлизахме в някаква друга общност. Бихме могли да заинтересуваме участниците в тази общност, студенти, в добра промишлена практика по тяхната специалност, научна работа в областта на системното програмиране, курсови и дипломни работи. Тоест, следвахме едно от основните правила за организиране на общност: членовете на общността трябва да получат нещо и тази цена трябва да съответства на приноса на участника.
Следващият етап за Embox беше търсенето на потребители от трети страни. Много е важно да се разбере, че потребителите са пълноправни участници в общността с отворен код. Обикновено има повече потребители, отколкото разработчици. И за да искат да станат сътрудници на даден проект, те първо започват да го използват по един или друг начин.
Първите потребители на Embox бяха Департаментът по теоретична кибернетика. Те предложиха да се създаде алтернативен фърмуер за Lego Mindstorm. И въпреки че това все още бяха местни потребители (можехме да се срещнем с тях лично и да обсъдим какво искат). Но все пак беше много добро изживяване. Например разработихме демонстрации, които могат да се показват на други, защото роботите са забавни и привличат вниманието. В резултат на това получихме истински потребители от трети страни, които започнаха да питат какво е Embox и как да го използват.
На този етап трябваше да помислим за документация, за средства за комуникация с потребителите. Не, разбира се, мислихме за тези важни неща и преди, но беше преждевременно и не даде положителен ефект. Ефектът беше по-скоро негативен. Нека ви дам няколко примера. Използвахме googlecode, чието wiki поддържаше многоезичието. Създадохме страници на няколко езика, не само английски и руски, на които почти не можехме да общуваме, но и немски и испански. В резултат на това изглежда много нелепо, когато ни питат на тези езици, но изобщо не можем да отговорим. Или въведоха правила за писане на документация и коментиране, но тъй като API се променяше доста често и значително, се оказа, че нашата документация е остаряла и е по-скоро подвеждаща, отколкото помага.
В резултат на това всички наши усилия, дори грешните, доведоха до появата на външни потребители. И дори се появи търговски клиент, който искаше да му бъде разработена собствена RTOS. И ние го разработихме, защото имаме опит и някаква основа. Тук трябва да говорите както за хубавите моменти, така и за лошите. Ще започна с лошите. Тъй като много разработчици бяха включени в този проект на търговска основа, общността вече беше доста нестабилна и разделена, което разбира се не можеше да не повлияе на развитието на проекта. Допълнителен фактор беше, че посоката на проекта беше зададена от един търговски клиент и неговата цел не беше по-нататъшното развитие на проекта. Поне това не беше основната цел.
От друга страна, имаше редица положителни аспекти. Имаме наистина потребители от трети страни. Не беше само клиентът, но и тези, за които беше предназначена тази система. Повишена е мотивацията за участие в проекта. В края на краищата, ако можете да правите пари и от интересен бизнес, винаги е хубаво. И най-важното, чухме едно желание от страна на клиентите, което тогава ни изглеждаше налудничаво, но което сега е основната идея на Embox, а именно да използваме вече разработен код в системата. Сега основната идея на Embox е да използва Linux софтуер без Linux. Тоест основният положителен аспект, допринесъл за по-нататъшното развитие на проекта, беше осъзнаването, че проектът се използва от потребители на трети страни и трябва да реши някои от техните проблеми.
По това време Embox вече беше излязъл от рамките на студентски проект. Основният ограничаващ фактор при разработването на проекта по студентския модел е мотивацията на участниците. Студентите участват, докато учат, а когато завършат, трябва да има друга мотивация. Ако мотивацията не се появи, ученикът просто спира да участва в проекта. Ако вземем предвид, че студентите първо трябва да бъдат обучени, се оказва, че те стават добри специалисти, докато завършат, но техният принос към проекта, поради липса на опит, не е много голям.
Като цяло плавно преминаваме към основната точка, която ни позволява да говорим за създаване на проект с отворен код - създаване на продукт, който да реши проблемите на своите потребители. Както обясних по-горе, основното свойство на проект с отворен код е неговата общност. Освен това членовете на общността са предимно потребители. Но откъде идват, когато няма какво да се използва? Така се оказва, че точно както при проект без отворен код, трябва да се съсредоточите върху създаването на MVP (минимален жизнеспособен продукт) и ако това заинтересува потребителите, тогава ще се появи общност около проекта. Ако сте ангажирани със създаването на общност само чрез PR на общността, писане на wiki на всички езици на света или правилен работен процес на git в github, тогава това е малко вероятно да има значение в ранните етапи на проекта. Разбира се, на съответните етапи това са не само важни, но и необходими неща.
В заключение бих искал да отбележа , по мое мнение, отразяващ очакванията на потребителите от проект с отворен код:
Сериозно се замислям дали да не мина на тази ОС (поне опитайте. Те го гонят активно и правят готини неща).
PS Вкл Ще имаме цели три доклада. Една за отворен код и две за вградени (и една е практична). На щанда ще проведем майсторски клас по програмиране с помощта на микроконтролери . Както обикновено, ние ще донесем хардуера и ще ви позволим да го програмирате. Ще има също куест и други дейности. Заповядайте на фестивала и на нашия щанд, ще бъде забавно.
Източник: www.habr.com