Осы аптада Санкт-Петербургте IT фестивалі өтеді . Спикерлердің бірі Ричард Сталлман болады. фестивальге де қатысады, және біз, әрине, тегін бағдарламалық қамтамасыз ету тақырыбын назардан тыс қалдыра алмадық. Сондықтан бір баяндамамыз осылай аталады . Ол ашық бастапқы жоба ретінде Embox-тың даму тарихына арналады. Бұл мақалада мен, менің ойымша, ашық жобалардың дамуына әсер ететін негізгі идеялар туралы айтқым келеді. Мақала баяндама сияқты жеке тәжірибеге негізделген.
Қарапайым нәрседен бастайық, ашық көздер терминінің анықтамасымен. Әлбетте, ашық бастапқы жоба - бұл жобаның бастапқы кодына қол жеткізуге мүмкіндік беретін лицензиялардың біріне ие жоба. Сонымен қатар, ашық жоба үшінші тарап әзірлеушілері өзгерістер енгізе алатынын білдіреді. Яғни, егер қандай да бір компания немесе әзірлеуші өз өнімінің кодын ішінара немесе толығымен жарияласа, бұл әлі бұл өнімді ашық бастапқы жобаға айналдырмайды. Ақырында, кез келген жобалық әрекет қандай да бір нәтижеге әкелуі керек, ал жобаның ашықтығы бұл нәтижені әзірлеушілердің өздері ғана пайдаланбайтындығын білдіреді.
Біз ашық лицензиялар мәселесін қозғамаймыз. Бұл терең зерттеуді қажет ететін тым үлкен және күрделі тақырып. Бұл тақырыпта көптеген жақсы мақалалар мен материалдар жазылды. Бірақ мен өзім авторлық құқық саласының маманы болмағандықтан, лицензия жобаның мақсатына сай болуы керек екенін ғана айтайын. Мысалы, Embox үшін GPL лицензиясының орнына BSD таңдауы кездейсоқ емес.
Ашық бастапқы жобаның өзгерістер енгізу мүмкіндігін қамтамасыз етуі және ашық бастапқы жобаның дамуына әсер етуі жобаның таратылғанын білдіреді. Оны басқару, тұтастық пен өнімділікті сақтау орталықтандырылған басқаруы бар жобамен салыстырғанда әлдеқайда қиын. Ақылға қонымды сұрақ туындайды: неге жобаларды ашады? Жауап коммерциялық негізділік саласында жатыр; жобалардың белгілі бір класы үшін бұл тәсілдің пайдасы шығындардан асып түседі. Яғни, ол барлық жобаларға жарамайды және ашық тәсіл жалпыға бірдей қолайлы. Мысалы, ашық принципке негізделген электр станциясын немесе ұшақты басқару жүйесін әзірлеуді елестету қиын. Жоқ, әрине, мұндай жүйелер ашық жобаларға негізделген модульдерді қамтуы керек, өйткені бұл бірқатар артықшылықтарды қамтамасыз етеді. Бірақ соңғы өнімге біреу жауапты болуы керек. Жүйе толығымен ашық жобалардың кодына негізделген болса да, әзірлеуші барлығын бір жүйеге жинап, нақты құрастырулар мен параметрлерді жасағаннан кейін оны іс жүзінде жабады. Код жалпыға қолжетімді болуы мүмкін.
Сондай-ақ бұл жүйелер үшін ашық бастапқы жобаларды жасаудан немесе оларға үлес қосудан көптеген артықшылықтар бар. Жоғарыда айтқанымдай, соңғы жүйе коды жалпыға қолжетімді болып қалуы мүмкін. Неліктен, өйткені жүйені сынау үшін ешкімде бірдей ұшақ болуы екіталай екені анық. Бұл дұрыс, бірақ кодтың белгілі бір бөлімдерін тексергісі келетін біреу болуы мүмкін немесе, мысалы, біреу пайдаланылып жатқан кітапхананың дұрыс конфигурацияланбағанын анықтауы мүмкін.
Егер компания жүйенің кейбір негізгі бөлігін бөлек жобаға бөлсе, одан да үлкен пайда болады. Мысалы, деректер алмасу протоколының қандай да бір түрін қолдауға арналған кітапхана. Бұл жағдайда, хаттама берілген пәндік аймаққа тән болса да, жүйенің осы бөлігін ұстау шығындарын осы аймақтағы басқа компаниялармен бөлісе аласыз. Сонымен қатар, жүйенің бұл бөлігін қоғамдық игіліктерде зерттей алатын мамандар оны тиімді пайдалану үшін әлдеқайда аз уақытты қажет етеді. Ақырында, бөлікті үшінші тарап әзірлеушілері пайдаланатын тәуелсіз нысанға бөлу бізге бұл бөлікті жақсартуға мүмкіндік береді, өйткені бізге тиімді API ұсыну, құжаттама жасау керек және мен тіпті сынақ қамтуды жақсарту туралы айтпаймын.
Компания ашық бастапқы жобаларды жасамай-ақ коммерциялық пайда ала алады, оның мамандары компанияда қолданылатын үшінші тарап жобаларына қатысуы жеткілікті. Өйткені, барлық артықшылықтар қалады: қызметкерлер жобаны жақсы біледі, сондықтан олар оны тиімдірек пайдаланады, компания жобаның даму бағытына әсер ете алады, ал дайын, жөндеуден өткен кодты пайдалану компанияның шығындарын азайтады.
Ашық бастапқы жобаларды жасаудың артықшылықтары мұнымен бітпейді. Бизнестің маркетинг сияқты маңызды құрамдас бөлігін алайық. Ол үшін бұл нарық талаптарын тиімді бағалауға мүмкіндік беретін өте жақсы құмсалғыш.
Және, әрине, ашық бастапқы жоба өзіңізді кез келген мамандықтың тасымалдаушысы ретінде жариялаудың тиімді жолы екенін ұмытпауымыз керек. Кейбір жағдайларда бұл нарыққа шығудың жалғыз жолы. Мысалы, Embox RTOS жасау жобасы ретінде басталды. Бәсекелестер көп деп түсіндірудің қажеті жоқ шығар. Қауымдастықты құрмай, бізде жобаны соңғы пайдаланушыға жеткізу үшін жеткілікті ресурстар болмас еді, яғни үшінші тарап әзірлеушілері жобаны пайдалана бастауы үшін.
Қауымдастық ашық бастапқы жобаның кілті болып табылады. Ол жобаны басқару шығындарын айтарлықтай азайтуға, жобаны әзірлеуге және қолдауға мүмкіндік береді. Қауымдастықсыз ашық жоба мүлдем жоқ деп айта аламыз.
Ашық бастапқы жоба қауымдастығын құру және басқару туралы көптеген материалдар жазылған. Бұрыннан белгілі фактілерді қайталамау үшін мен Embox тәжірибесіне назар аударуға тырысамын. Мысалы, қауымдастық құру процесі өте қызықты мәселе. Яғни, көп адамдар бар қауымдастықты қалай басқару керектігін айтады, бірақ оны құру сәттері кейде бұл берілген деп есептелмейді.
Ашық бастапқы жоба қауымдастығын құрудағы негізгі ереже - бұл ережелер жоқ. Менің айтайын дегенім, жобалар өте әртүрлі болғандықтан, күміс оқ жоқ сияқты әмбебап ережелер жоқ. Js журналдар кітапханасы және кейбір жоғары мамандандырылған драйвер үшін қауымдастық құру кезінде бірдей ережелерді пайдалану екіталай. Оның үстіне жобаның (демек қоғамдастық) дамуының әртүрлі кезеңдерінде ережелер өзгереді.
Embox студенттік жоба ретінде басталды, себебі оның жүйелік бағдарламалау бөлімінің студенттеріне кіру мүмкіндігі болды. Шын мәнінде, біз басқа қоғамдастыққа кірдік. Біз осы қауымдастыққа қатысушыларды, студенттерді өз мамандығы бойынша жақсы өндірістік тәжірибеге, жүйелік бағдарламалау саласындағы ғылыми жұмыстарға, курстық жұмыстарға және дипломдарға қызықтыра аламыз. Яғни, біз қауымдастықты ұйымдастырудың негізгі ережелерінің бірін ұстандық: қауымдастық мүшелері бірдеңе алуы керек және бұл баға қатысушының қосқан үлесіне сәйкес болуы керек.
Embox үшін келесі кезең үшінші тарап пайдаланушыларын іздеу болды. Пайдаланушылар ашық бастапқы қауымдастықтың толық қатысушылары екенін түсіну өте маңызды. Әдетте әзірлеушілерге қарағанда пайдаланушылар көп. Және жобаға үлес қосушы болу үшін олар алдымен оны бір немесе басқа жолмен пайдалана бастайды.
Embox-тың алғашқы пайдаланушылары теориялық кибернетика кафедрасы болды. Олар Lego Mindstorm үшін балама микробағдарлама жасауды ұсынды. Бұл әлі де жергілікті пайдаланушылар болса да (біз олармен жеке кездесіп, олардың не қалайтынын талқылай аламыз). Бірақ бұл өте жақсы тәжірибе болды. Мысалы, біз басқаларға көрсетуге болатын демонстрацияларды әзірледік, өйткені роботтар көңілді және назар аудартады. Нәтижесінде бізде Embox деген не және оны қалай пайдалану керектігін сұрай бастаған шынымен үшінші тарап пайдаланушылары алдық.
Бұл кезеңде бізге құжаттама, пайдаланушылармен байланыс құралдары туралы ойлануға тура келді. Жоқ, әрине, біз бұл маңызды нәрселерді бұрын ойластырдық, бірақ ол мерзімінен бұрын болды және оң нәтиже бермеді. Әсері біршама теріс болды. Бір-екі мысал келтірейін. Біз вики көптілділікті қолдайтын googlecode қолдандық. Біз әрең сөйлесетін ағылшын және орыс тілдерінде ғана емес, неміс және испан тілдерінде де бірнеше тілде беттер жасадық. Нәтижесінде бұл тілдерде сұрағанда өте күлкілі көрінеді, бірақ біз мүлдем жауап бере алмаймыз. Немесе олар құжаттама жазу және түсініктеме беру ережелерін енгізді, бірақ API жиі және айтарлықтай өзгергендіктен, біздің құжаттама ескірген және ол көмектескеннен гөрі жаңылыстыратын болып шықты.
Нәтижесінде біздің барлық күш-жігеріміз, тіпті дұрыс емес әрекеттеріміз сыртқы пайдаланушылардың пайда болуына әкелді. Тіпті коммерциялық тұтынушы да пайда болды, ол ол үшін өзінің жеке RTOS әзірленгенін қалайды. Ал біз оны дамыттық, өйткені бізде тәжірибе мен негіз бар. Бұл жерде жақсы сәттерді де, жамандықты да айту керек. Мен жамандардан бастайын. Көптеген әзірлеушілер бұл жобаға коммерциялық негізде қатысқандықтан, қауымдастық қазірдің өзінде тұрақсыз және бөлінген болатын, бұл, әрине, жобаның дамуына әсер етпеуі мүмкін емес еді. Қосымша фактор жобаның бағытын бір коммерциялық тапсырыс беруші белгіледі және оның мақсаты жобаны одан әрі дамыту емес еді. Кем дегенде, бұл басты мақсат емес еді.
Екінші жағынан, бірқатар оң жақтары болды. Бізде шынымен үшінші тарап пайдаланушылары бар. Бұл тек тапсырыс беруші ғана емес, сонымен қатар бұл жүйе кімге арналған болатын. Жобаға қатысуға мотивация артты. Ақыр соңында, егер сіз қызықты бизнестен ақша таба алсаңыз, бұл әрқашан жақсы. Ең бастысы, біз тұтынушылардан сол кезде бізге ақылсыз болып көрінген, бірақ қазір Embox-тың негізгі идеясы болып табылатын бір тілекті естідік, атап айтқанда жүйеде бұрыннан әзірленген кодты пайдалану. Енді Embox-тың негізгі идеясы - Linux бағдарламалық жасақтамасын Linuxсіз пайдалану. Яғни, жобаның одан әрі дамуына ықпал ететін негізгі оң аспект жобаны үшінші тарап пайдаланушылары қолданатынын және бұл олардың кейбір мәселелерін шешуі керек екенін түсіну болды.
Ол кезде Эмбокс студенттік жобаның шеңберінен шығып кеткен болатын. Студенттік үлгі бойынша жобаны әзірлеуде негізгі шектеуші фактор қатысушылардың мотивациясы болып табылады. Студенттер оқу кезінде қатысады, ал олар бітірген кезде басқа мотивация болуы керек. Егер мотивация болмаса, студент жобаға қатысуды тоқтатады. Студенттердің ең алдымен білім алуы қажет екенін ескерсек, олар оқуды бітіргенше жақсы маман болып шығады, бірақ тәжірибесіздіктен жобаға қосқан үлесі көп емес.
Тұтастай алғанда, біз ашық бастапқы жобаны құру туралы айтуға мүмкіндік беретін негізгі тармаққа біртіндеп көшеміз - оның пайдаланушыларының мәселелерін шешетін өнімді жасау. Жоғарыда түсіндіргендей, ашық бастапқы жобаның негізгі қасиеті оның қауымдастығы болып табылады. Сонымен қатар, қауымдастық мүшелері негізінен пайдаланушылар. Бірақ пайдалануға ештеңе болмаған кезде олар қайдан келеді? Осылайша, ашық емес жоба сияқты, сіз MVP (ең төменгі өміршең өнім) құруға назар аударуыңыз керек және ол пайдаланушыларды қызықтырса, жобаның айналасында қауымдастық пайда болады. Егер сіз қауымдастық құрумен тек қауымдастықтың PR арқылы, әлемнің барлық тілдерінде вики жазумен немесе github-та git жұмыс процесін түзетумен айналыссаңыз, онда бұл жобаның бастапқы кезеңдерінде маңызды болуы екіталай. Әрине, тиісті кезеңдерде бұл маңызды ғана емес, сонымен қатар қажетті нәрселер.
Қорытындылай келе мен атап өткім келеді , менің ойымша, ашық бастапқы жобадан пайдаланушы күтулерін көрсетеді:
Мен осы ОЖ-ға ауысу туралы шындап ойлап жүрмін (кем дегенде тырысып көріңіз. Олар оны белсенді түрде іздейді және керемет істермен айналысады).
PS Қосулы Бізде үш есеп болады. Біреуі ашық дереккөз туралы және екеуі ендірілген (және біреуі практикалық). Стендте біз микроконтроллерлер көмегімен бағдарламалау бойынша мастер-класс өткіземіз . Әдеттегідей, біз жабдықты әкелеміз және оны бағдарламалауға рұқсат етеміз. Сондай-ақ квест және басқа да іс-шаралар болады. Фестивальге және біздің стендке келіңіз, бұл қызықты болады.
Ақпарат көзі: www.habr.com