Ушул аптада Санкт-Петербургда IT фестивалы өтөт . Баяндамачылардын бири Ричард Сталлман болот. ошондой эле фестивалга катышат, албетте, биз эркин программалык камсыздоо темасын көз жаздымда калтыра алган жокпуз. Ошон үчүн биздин отчетторубуздун бири деп аталат . Ал ачык булактуу долбоор катары Emboxтун өнүгүү тарыхына арналат. Бул макалада мен, менин оюмча, ачык долбоорлорду өнүктүрүүгө таасир этүүчү негизги идеялар жөнүндө айткым келет. Макала, доклад сыяктуу эле, жеке тажрыйбага негизделген.
Келгиле, ачык булак термининин аныктамасы менен жөнөкөй нерседен баштайлы. Албетте, ачык булак долбоору - бул долбоордун баштапкы кодуна кирүүгө мүмкүндүк берген лицензиялардын бирине ээ болгон долбоор. Мындан тышкары, ачык долбоор үчүнчү тараптын иштеп чыгуучулары өзгөртүүлөрдү киргизе алат дегенди билдирет. Башкача айтканда, кандайдыр бир компания же иштеп чыгуучу өзүнүн продуктунун кодун жарым-жартылай же толугу менен жарыяласа, бул азырынча бул продуктуну ачык булактуу долбоор кыла албайт. Акыр-аягы, ар кандай долбоордук иш кандайдыр бир натыйжага алып келиши керек, ал эми долбоордун ачыктыгы бул натыйжаны иштеп чыгуучулардын өздөрү гана эмес, колдонорун билдирет.
Биз ачык лицензиялардын көйгөйлөрүнө токтолбойбуз. Бул өтө чоң жана татаал тема, терең изилдөөнү талап кылат. Бул темада бир топ жакшы макалалар жана материалдар жазылган. Бирок мен өзүм автордук укук жаатында адис болбогондуктан, лицензия долбоордун максаттарына жооп бериши керек деп гана айтам. Мисалы, Embox үчүн GPL лицензиясынын ордуна BSDди тандоо кокусунан болгон эмес.
Ачык булак долбоору өзгөртүүлөрдү киргизүү жана ачык булак долбоорунун өнүгүшүнө таасир берүү мүмкүнчүлүгүн камсыз кылуу керек экендиги долбоордун бөлүштүрүлгөндүгүн билдирет. Аны башкаруу, бүтүндүгүн жана натыйжалуулугун сактоо борборлоштурулган башкаруу менен долбоорго салыштырмалуу бир топ кыйын. Акылга сыярлык суроо туулат: эмне үчүн долбоорлорду ачышат? Жооп коммерциялык максатка ылайыктуулук чөйрөсүндө жатат; долбоорлордун белгилүү бир классы үчүн бул ыкманын пайдасы чыгымдардан жогору. Башкача айтканда, ал бардык долбоорлорго ылайыктуу эмес жана ачык мамиле жалпысынан алгылыктуу. Мисалы, ачык принципке негизделген электр станциясын же учакты башкаруу системасын иштеп чыгууну элестетүү кыйын. Жок, албетте, мындай системалар ачык долбоорлорго негизделген модулдарды камтышы керек, анткени бул бир катар артыкчылыктарды берет. Бирок акыркы продукт үчүн кимдир бирөө жооп бериши керек. Система толугу менен ачык долбоорлордун кодуна негизделген болсо да, иштеп чыгуучу бардыгын бир системага топтоп, конкреттүү түзүлүштөрдү жана орнотууларды жасап, аны негизинен жаап салат. Код жалпыга жеткиликтүү болушу мүмкүн.
Бул системалар үчүн ачык булак долбоорлорун түзүүдөн же салым кошуудан көптөгөн артыкчылыктар бар. Мен буга чейин айткандай, акыркы система коду жалпыга жеткиликтүү бойдон калышы мүмкүн. Эмне үчүн, анткени системаны сыноо үчүн кимдир бирөө бир эле учакка ээ болушу күмөн экени айдан ачык. Бул туура, бирок коддун кээ бир бөлүмдөрүн текшергиси келген бирөө болушу мүмкүн, же, мисалы, кимдир бирөө колдонулуп жаткан китепкананын туура конфигурацияланбаганын билиши мүмкүн.
Эгер компания системанын кээ бир негизги бөлүгүн өзүнчө долбоорго бөлсө, андан да чоң пайда пайда болот. Мисалы, кандайдыр бир маалымат алмашуу протоколун колдоо үчүн китепкана. Бул учурда, протокол берилген предметтик чөйрөгө тиешелүү болсо да, сиз системанын бул бөлүгүн тейлөөгө кеткен чыгымдарды ушул аймактагы башка компаниялар менен бөлүшө аласыз. Мындан тышкары, системанын бул бөлүгүн коомдук доменде изилдей алган адистер аны натыйжалуу колдонуу үчүн бир топ аз убакытты талап кылат. Акыр-аягы, үчүнчү тараптын иштеп чыгуучулары колдонгон көз карандысыз объектке бөлүү бизге бул бөлүктү жакшыртууга мүмкүндүк берет, анткени биз эффективдүү API'лерди сунушташыбыз керек, документтерди түзүшүбүз керек жана мен тесттин камтылышын жакшыртуу жөнүндө айтпай эле коёюн.
Компания ачык булактуу долбоорлорду түзбөстөн коммерциялык пайда ала алат, анын адистери компанияда колдонулган үчүнчү тараптын долбоорлоруна катышуу үчүн жетиштүү. Анткени, бардык артыкчылыктар сакталып турат: кызматкерлер долбоорду жакшыраак билишет, ошондуктан алар аны натыйжалуураак колдонушат, компания долбоордун өнүгүү багытына таасир эте алат, ал эми даяр, катасыздандырылган кодду колдонуу компаниянын чыгымдарын азайтат.
Ачык долбоорлорду түзүүнүн артыкчылыктары муну менен эле бүтпөйт. Бизнестин маркетинг сыяктуу маанилүү компонентин алалы. Ал үчүн, бул рыноктун талаптарын натыйжалуу баалоого мүмкүндүк берген абдан жакшы кум чөйрөсү.
Анан, албетте, ачык булактуу долбоор өзүңүздү кандайдыр бир адистиктин алып жүрүүчүсү катары жарыялоонун эффективдүү жолу экенин унутпашыбыз керек. Кээ бир учурларда бул рынокко кирүүнүн жалгыз жолу. Мисалы, Embox RTOS түзүү долбоору катары башталган. Атаандаштар көп экенин түшүндүрүүнүн кереги жок болсо керек. Коомчулукту түзбөсөк, биз долбоорду акыркы колдонуучуга жеткирүү үчүн, башкача айтканда, үчүнчү тараптын иштеп чыгуучулары долбоорду колдоно башташ үчүн жетиштүү ресурстарга ээ болмок эмес.
Коомчулук ачык булактуу долбоордун ачкычы болуп саналат. Долбоорду башкаруу боюнча чыгымдарды олуттуу кыскартууга, долбоорду иштеп чыгууга жана колдоого мүмкүндүк берет. Коомчулуксуз эч кандай ачык булактуу долбоор жок деп айта алабыз.
Ачык булактуу долбоордун коомчулугун кантип түзүү жана башкаруу жөнүндө көп материалдар жазылган. Буга чейин белгилүү болгон фактыларды кайталабоо үчүн, мен Embox тажрыйбасына басым жасоого аракет кылам. Мисалы, коомчулукту түзүү процесси абдан кызыктуу маселе. Башкача айтканда, көптөр бар коомду кантип башкаруу керектигин айтышат, бирок аны түзүүнүн учурлары кээде көз жаздымда калып, бул берилгендикти эске алуу менен.
Ачык булактуу долбоордун коомчулугун түзүүдө негизги эреже - бул эрежелердин жоктугу. Мен эч кандай универсалдуу эрежелер жок дегеним, күмүш ок жок сыяктуу, долбоорлор абдан ар башка болгондуктан. Js logging китепканасы жана кээ бир жогорку адистештирилген драйвер үчүн коомчулукту түзүүдө бир эле эрежелерди колдонуу мүмкүн эмес. Анын үстүнө, долбоордун (демек, коомчулуктун) өнүгүүсүнүн ар кандай этаптарында эрежелер өзгөрөт.
Embox студенттик долбоор катары башталган, анткени ал системалык программалоо бөлүмүнүн студенттерине мүмкүнчүлүк алган. Чынында, биз башка коомго кирип жатканбыз. Биз бул жамааттын катышуучуларын, студенттерди өз адистиги боюнча жакшы өндүрүштүк практикага, системалык программалоо жаатындагы илимий иштерге, курстук иштерге жана дипломдорго кызыктырмакпыз. Башкача айтканда, биз жамаатты уюштуруунун негизги эрежелеринин бирин кармандык: жамааттын мүчөлөрү бир нерсе алышы керек жана бул баа катышуучунун салымына туура келиши керек.
Embox үчүн кийинки этап үчүнчү тараптын колдонуучуларын издөө болду. Колдонуучулар ачык булак коомчулугунун толук катышуучулары экенин түшүнүү абдан маанилүү. Адатта иштеп чыгуучуларга караганда колдонуучулар көп. Ал эми кайсы бир долбоордун салымчысы болууну каалаш үчүн, алар алгач аны тигил же бул жол менен колдоно башташат.
Embox биринчи колдонуучулары Теориялык кибернетика бөлүмү болгон. Алар Lego Mindstorm үчүн альтернативдүү микропрограмманы түзүүнү сунушташты. Булар дагы эле жергиликтүү колдонуучулар болгонуна карабастан (биз алар менен жеке жолугуп, алар эмнени каалашарын талкуулай алдык). Бирок бул дагы эле абдан жакшы тажрыйба болду. Мисалы, биз башкаларга көрсөтө турган демонстрацияларды иштеп чыктык, анткени роботтор кызыктуу жана көңүл бурат. Натыйжада, биз чындап эле үчүнчү тараптын колдонуучуларын алдык, алар Embox деген эмне экенин жана аны кантип колдонууну сурай башташты.
Бул этапта биз документация, колдонуучулар менен байланыш каражаттары жөнүндө ойлонууга туура келди. Жок, албетте, биз бул маанилүү нерселер жөнүндө мурда ойлонгонбуз, бирок ал эрте болуп, оң натыйжа берген жок. Таасири тескерисинче терс болду. Мен бир-эки мисал келтирейин. Биз googlecode колдондук, анын викиси көп тилдүүлүктү колдойт. Биз бир нече тилде, бир гана англис жана орус тилдеринде эмес, биз араң сүйлөшө турган баракчаларды түздүк, ал эми немис жана испан тилдеринде. Натыйжада, бул тилдерде сураганда абдан күлкүлүү көрүнөт, бирок биз такыр жооп бере албайбыз. Же алар документтерди жазуу жана комментарий берүү эрежелерин киргизишти, бирок API тез-тез жана олуттуу өзгөргөндүктөн, биздин документтер эскирип, жардам бергенге караганда алдамчы болуп чыкты.
Натыйжада, биздин бардык аракеттерибиз, жада калса туура эмес аракеттерибиз, тышкы колдонуучулардын пайда болушуна алып келди. Ал тургай, ал үчүн өзүнүн RTOS иштелип чыгышын каалаган коммерциялык кардар пайда болду. А биз аны иштеп чыкканбыз, анткени бизде тажрыйба жана кандайдыр бир негиз бар. Бул жерде жакшы учурларды да, жамандарды да айтуу керек. Мен жамандардан баштайын. Көптөгөн иштеп чыгуучулар бул долбоорго коммерциялык негизде тартылгандыктан, коомчулук буга чейин бир топ туруксуз жана бөлүнгөн болчу, бул албетте долбоордун өнүгүшүнө таасир эте албайт. Долбоордун багытын бир коммерциялык кардар койгону жана анын максаты долбоорду андан ары өнүктүрүү эмес экендиги кошумча фактор болгон. Жок дегенде бул негизги максат эмес болчу.
Экинчи жагынан бир катар жакшы жактары да болду. Бизде чындап эле үчүнчү тараптын колдонуучулары бар. Бул кардар гана эмес, ошондой эле бул система кимге арналган. Долбоорго катышууга мотивация жогорулады. Анткени, сиз да кызыктуу бизнестен акча таба алсаңыз, бул ар дайым жакшы. Эң негизгиси, биз кардарлардын бир каалоосун уктук, ал ошол учурда бизге жиндидей көрүнгөн, бирок азыр Emboxтун негизги идеясы болуп саналат, тактап айтканда, системада иштелип чыккан кодду колдонуу. Эми Emboxтун негизги идеясы - Linux программасын Linuxсуз колдонуу. Башкача айтканда, долбоордун андан ары өнүгүшүнө өбөлгө түзгөн негизги позитивдүү аспект бул долбоор үчүнчү тараптын колдонуучулары тарабынан колдонулуп жаткандыгын жана ал алардын айрым көйгөйлөрүн чечиши керек экендигин түшүнүү болду.
Ал кезде Эмбокс студенттик долбоордун чегинен чыгып кеткен. Студенттик моделге ылайык долбоорду иштеп чыгууда негизги чектөөчү фактор катышуучулардын мотивациясы болуп саналат. Студенттер окуп жатканда катышат, окууну бүткөндө башка мотивация болушу керек. Мотивация жок болсо, студент жөн гана долбоорго катышууну токтотот. Студенттер алгач окуудан өтүшү керек экенин эске алсак, алар окууну бүткөндө жакшы адис болуп чыга келишет, бирок тажрыйбасыздыктан долбоорго кошкон салымы анча деле чоң эмес.
Жалпысынан алганда, биз ачык булак долбоорун түзүү жөнүндө сүйлөшүүгө мүмкүндүк берген негизги пунктка жылмакай өтөбүз - анын колдонуучуларынын көйгөйлөрүн чече турган продуктуну түзүү. Мен жогоруда түшүндүргөндөй, ачык булак долбоорунун негизги менчиги анын коомчулугу болуп саналат. Мындан тышкары, коомчулуктун мүчөлөрү биринчи кезекте колдонуучулар болуп саналат. Бирок колдонууга эч нерсеси жок болгондо алар кайдан келет? Демек, ачык эмес долбоор сыяктуу эле, сиз MVP (минималдуу жашоого жөндөмдүү продукт) түзүүгө басым жасашыңыз керек жана ал колдонуучуларды кызыктырса, анда долбоордун тегерегинде коомчулук пайда болот. Эгер сиз коомчулуктун пиары аркылуу гана коомчулукту түзүү, дүйнөнүн бардык тилдеринде вики жазуу же githubда git иш процессин тууралоо менен алектенсеңиз, анда бул долбоордун алгачкы этаптарында маанилүү эмес. Албетте, тиешелүү этаптарда бул маанилүү гана эмес, ошондой эле зарыл нерселер.
Жыйынтыктап айтканда, белгилеп кетким келет , менин оюмча, ачык булак долбоорунан колдонуучулардын күтүүлөрүн чагылдырат:
Мен бул ОСке өтүү жөнүндө олуттуу ойлонуп жатам (жок дегенде аракет кылып көргүлө. Алар аны активдүү жүргүзүп, сонун иштерди жасап жатышат).
PS On Бизде үч отчет болот. Бири ачык булак жөнүндө жана экөө кыналган (жана бири практикалык). Стендде микроконтроллерлерди колдонуу менен программалоо боюнча мастер-класс өткөрөбүз . Адаттагыдай эле, биз аппараттык жабдыктарды алып келип, аны программалоого уруксат беребиз. Ошондой эле квест жана башка иш-чаралар болот. Фестивалга жана биздин стендге келиңиз, бул кызыктуу болот.
Source: www.habr.com