Այս շաբաթ Սանկտ Պետերբուրգում կանցկացվի ՏՏ փառատոն . Բանախոսներից մեկը կլինի Ռիչարդ Սթոլմանը։ նույնպես մասնակցում է փառատոնին, և իհարկե չէինք կարող անտեսել ազատ ծրագրային ապահովման թեման։ Դրա համար էլ մեր զեկույցներից մեկը կոչվում է . Այն նվիրված կլինի Embox-ի՝ որպես բաց կոդով նախագծի զարգացման պատմությանը։ Այս հոդվածում ես ուզում եմ խոսել այն հիմնական գաղափարների մասին, որոնք, իմ կարծիքով, ազդում են opensource նախագծերի զարգացման վրա։ Հոդվածը, ինչպես և զեկույցը, հիմնված է անձնական փորձի վրա:
Սկսենք մի պարզ բանից՝ opensource տերմինի սահմանումից։ Ակնհայտ է, որ բաց կոդով նախագիծը նախագիծ է, որն ունի լիցենզիաներից մեկը, որը թույլ է տալիս մուտք գործել նախագծի սկզբնական կոդը: Բացի այդ, բաց նախագիծը նշանակում է, որ երրորդ կողմի մշակողները կարող են փոփոխություններ կատարել: Այսինքն, եթե ինչ-որ ընկերություն կամ ծրագրավորող հրապարակում է իր արտադրանքի կոդը, մասամբ կամ ամբողջությամբ, դա դեռ չի դարձնում այս ապրանքը բաց կոդով նախագիծ: Եվ վերջապես, ցանկացած նախագծային գործունեություն պետք է հանգեցնի ինչ-որ արդյունքի, իսկ նախագծի բաց լինելը ենթադրում է, որ այդ արդյունքն օգտագործվում է ոչ միայն իրենք մշակողների կողմից։
Բաց լիցենզիաների խնդիրներին չենք անդրադառնա. Սա չափազանց մեծ և բարդ թեմա է, որը պահանջում է խորը ուսումնասիրություն: Այս թեմայով բավականին լավ հոդվածներ ու նյութեր են գրվել։ Բայց քանի որ ես ինքս հեղինակային իրավունքի ոլորտի մասնագետ չեմ, միայն կասեմ, որ լիցենզիան պետք է համապատասխանի նախագծի նպատակներին։ Օրինակ, Embox-ի համար BSD-ի, այլ ոչ թե GPL լիցենզիայի ընտրությունը պատահական չէր:
Այն փաստը, որ բաց կոդով նախագիծը պետք է հնարավորություն տա փոփոխություններ կատարելու և ազդելու բաց կոդով նախագծի զարգացման վրա, ենթադրում է, որ նախագիծը բաշխված է: Դրա կառավարումը, ամբողջականության և կատարողականի պահպանումը շատ ավելի դժվար է կենտրոնացված կառավարմամբ նախագծի համեմատ: Խելամիտ հարց է առաջանում՝ ինչո՞ւ են ընդհանրապես բաց նախագծերը։ Պատասխանը կայանում է առևտրային իրագործելիության ոլորտում; նախագծերի որոշակի դասի համար այս մոտեցման օգուտները գերազանցում են ծախսերը: Այսինքն՝ այն հարմար չէ բոլոր նախագծերի համար, և բաց մոտեցումն ընդհանուր առմամբ ընդունելի է։ Օրինակ, դժվար է պատկերացնել բաց սկզբունքով էլեկտրակայանի կամ ինքնաթիռի կառավարման համակարգ մշակելը։ Ոչ, իհարկե, նման համակարգերը պետք է ներառեն բաց նախագծերի վրա հիմնված մոդուլներ, քանի որ դա մի շարք առավելություններ կտա։ Բայց վերջնական արտադրանքի համար ինչ-որ մեկը պետք է պատասխանատու լինի։ Նույնիսկ եթե համակարգը ամբողջությամբ հիմնված է բաց նախագծերի կոդի վրա, ծրագրավորողը, ամեն ինչ փաթեթավորելով մեկ համակարգի մեջ և կատարելով հատուկ կառուցումներ և կարգավորումներ, ըստ էության փակում է այն: Կոդը կարող է հանրությանը հասանելի լինել:
Այս համակարգերի համար կան նաև շատ օգուտներ՝ բաց կոդով նախագծեր ստեղծելուց կամ դրանց ներդրումից: Ինչպես արդեն ասացի, վերջնական համակարգի կոդը կարող է հանրությանը հասանելի մնալ: Ինչու, քանի որ ակնհայտ է, որ դժվար թե որևէ մեկը ունենա նույն ինքնաթիռը համակարգը փորձարկելու համար: Սա ճիշտ է, բայց կարող է լինել մեկը, ով ցանկանում է ստուգել կոդի որոշ բաժիններ, կամ, օրինակ, ինչ-որ մեկը կարող է հայտնաբերել, որ օգտագործվող գրադարանը ճիշտ կազմաձևված չէ:
Նույնիսկ ավելի մեծ օգուտ է հայտնվում, եթե ընկերությունը տրամադրում է համակարգի որոշ հիմնական մաս առանձին նախագծի: Օրինակ՝ գրադարան, որն աջակցում է տվյալների փոխանակման ինչ-որ արձանագրությանը: Այս դեպքում, նույնիսկ եթե արձանագրությունը հատուկ է տվյալ առարկայի համար, դուք կարող եք կիսել համակարգի այս հատվածի պահպանման ծախսերը այս ոլորտի այլ ընկերությունների հետ: Բացի այդ, մասնագետները, ովքեր կարող են ուսումնասիրել համակարգի այս հատվածը հանրային սեփականությունում, շատ ավելի քիչ ժամանակ են պահանջում այն արդյունավետ օգտագործելու համար: Եվ վերջապես, մի կտոր բաժանելը անկախ միավորի մեջ, որն օգտագործում են երրորդ կողմի մշակողները, թույլ է տալիս մեզ ավելի լավ դարձնել այս մասը, քանի որ մենք պետք է առաջարկենք արդյունավետ API, ստեղծենք փաստաթղթեր, և ես նույնիսկ չեմ խոսում թեստային ծածկույթի բարելավման մասին:
Ընկերությունը կարող է առևտրային օգուտներ ստանալ առանց բաց կոդով նախագծեր ստեղծելու, բավական է, որ նրա մասնագետները մասնակցեն ընկերությունում օգտագործվող երրորդ կողմի նախագծերին: Ի վերջո, բոլոր առավելությունները մնում են. աշխատակիցներն ավելի լավ գիտեն նախագիծը, հետևաբար նրանք ավելի արդյունավետ են օգտագործում այն, ընկերությունը կարող է ազդել նախագծի զարգացման ուղղության վրա, իսկ պատրաստի, կարգաբերված կոդի օգտագործումը ակնհայտորեն նվազեցնում է ընկերության ծախսերը:
Opensource նախագծերի ստեղծման առավելություններն այսքանով չեն ավարտվում: Վերցնենք բիզնեսի այնպիսի կարևոր բաղադրիչ, ինչպիսին է մարքեթինգը։ Նրա համար սա շատ լավ ավազատուփ է, որը թույլ է տալիս արդյունավետորեն գնահատել շուկայի պահանջները:
Եվ իհարկե, չպետք է մոռանալ, որ opensource նախագիծը արդյունավետ միջոց է ինքներդ ձեզ որպես մասնագիտացման կրող հռչակելու համար։ Որոշ դեպքերում սա շուկա մուտք գործելու միակ միջոցն է։ Օրինակ, Embox-ը սկսվեց որպես RTOS-ի ստեղծման նախագիծ: Երեւի կարիք չկա բացատրելու, որ մրցակիցները շատ են։ Առանց համայնք ստեղծելու, մենք պարզապես բավարար ռեսուրսներ չէինք ունենա նախագիծը վերջնական օգտագործողին հասցնելու համար, այսինքն՝ երրորդ կողմի մշակողները սկսեին օգտագործել նախագիծը:
Համայնքը առանցքային է opensource նախագծում: Այն թույլ է տալիս զգալիորեն նվազեցնել ծրագրի կառավարման ծախսերը, մշակել և աջակցել նախագծին: Կարելի է ասել, որ առանց համայնքի բացարձակ նախագիծ բացարձակապես գոյություն չունի։
Շատ նյութեր են գրվել այն մասին, թե ինչպես ստեղծել և կառավարել բաց կոդով նախագծային համայնք: Արդեն հայտնի փաստերը չվերապատմելու համար կփորձեմ կենտրոնանալ Embox-ի փորձի վրա։ Օրինակ, համայնք ստեղծելու գործընթացը շատ հետաքրքիր խնդիր է։ Այսինքն՝ շատերն են պատմում, թե ինչպես կառավարել գոյություն ունեցող համայնքը, բայց դրա ստեղծման պահերը երբեմն անտեսվում են՝ դա համարելով տրված։
Բաց կոդով նախագծի համայնք ստեղծելու հիմնական կանոնն այն է, որ կանոններ չկան: Ես նկատի ունեմ, որ չկան ունիվերսալ կանոններ, ինչպես որ չկա արծաթե փամփուշտ, թեկուզ միայն այն պատճառով, որ նախագծերը շատ տարբեր են: Քիչ հավանական է, որ դուք կարողանաք օգտագործել նույն կանոնները js logging գրադարանի և որոշ բարձր մասնագիտացված դրայվերի համար համայնք ստեղծելիս: Ավելին, նախագծի (հետևաբար՝ համայնքի) զարգացման տարբեր փուլերում կանոնները փոխվում են։
Embox-ը սկսեց որպես ուսանողական նախագիծ, քանի որ այն մուտք ուներ համակարգերի ծրագրավորման բաժնի ուսանողներին: Փաստորեն, մենք այլ համայնք էինք մտնում։ Մենք կարող էինք հետաքրքրել այս համայնքի մասնակիցներին՝ ուսանողներին, իրենց մասնագիտությամբ լավ արդյունաբերական պրակտիկայով, համակարգային ծրագրավորման ոլորտում գիտական աշխատանքով, կուրսային աշխատանքով և դիպլոմներով: Այսինքն՝ մենք հետևել ենք համայնքի կազմակերպման հիմնական կանոններից մեկին՝ համայնքի անդամները պետք է ինչ-որ բան ստանան, և այդ գինը պետք է համապատասխանի մասնակցի ներդրմանը։
Embox-ի հաջորդ փուլը երրորդ կողմի օգտատերերի որոնումն էր: Շատ կարևոր է հասկանալ, որ օգտվողները բաց կոդով համայնքի լիարժեք մասնակիցներ են: Սովորաբար ավելի շատ օգտվողներ կան, քան մշակողներ: Եվ որպեսզի ցանկանան դառնալ նախագծի մասնակից, նախ սկսում են այն օգտագործել այս կամ այն կերպ։
Embox-ի առաջին օգտատերերը տեսական կիբեռնետիկայի բաժինն էր։ Նրանք առաջարկեցին ստեղծել այլընտրանքային որոնվածը Lego Mindstorm-ի համար։ Եվ չնայած սրանք դեռ տեղացի օգտատերեր էին (մենք կարող էինք անձամբ հանդիպել նրանց հետ և քննարկել նրանց ուզածը): Բայց դա դեռ շատ լավ փորձ էր: Օրինակ, մենք մշակել ենք ցուցադրություններ, որոնք կարող են ցուցադրվել ուրիշներին, քանի որ ռոբոտները զվարճալի են և ուշադրություն են գրավում: Արդյունքում մենք ստացանք իսկապես երրորդ կողմի օգտատերեր, ովքեր սկսեցին հարցնել, թե ինչ է Embox-ը և ինչպես օգտագործել այն:
Այս փուլում մենք պետք է մտածեինք փաստաթղթավորման, օգտատերերի հետ կապի միջոցների մասին։ Չէ, իհարկե, մենք նախկինում մտածել ենք այս կարևոր բաների մասին, բայց դա ժամանակավրեպ էր և դրական արդյունք չտվեց։ Էֆեկտը բավականին բացասական էր։ Մի երկու օրինակ բերեմ։ Մենք օգտագործեցինք googlecode-ը, որի վիքին աջակցում էր բազմալեզվությանը։ Ստեղծեցինք էջեր մի քանի լեզուներով, ոչ միայն անգլերեն և ռուսերեն, որոնցով մենք դժվարությամբ էինք շփվում, այլ նաև գերմաներեն և իսպաներեն։ Արդյունքում շատ ծիծաղելի է թվում, երբ հարցնում են այս լեզուներով, բայց մենք ընդհանրապես չենք կարող պատասխանել։ Կամ մտցրեցին փաստաթղթեր գրելու և մեկնաբանելու կանոններ, բայց քանի որ API-ն բավականին հաճախ և զգալիորեն փոխվում էր, պարզվեց, որ մեր փաստաթղթերը հնացած էին և ավելի շատ ապակողմնորոշիչ էին, քան օգնում էին:
Արդյունքում մեր բոլոր ջանքերը, նույնիսկ սխալները, հանգեցրին արտաքին օգտատերերի հայտնվելուն։ Եվ նույնիսկ առևտրային հաճախորդ հայտնվեց, ով ցանկանում էր, որ իր համար մշակվի իր սեփական RTOS-ը: Եվ մենք զարգացրել ենք այն, քանի որ ունենք փորձ և որոշակի հիմքեր: Այստեղ պետք է խոսել ինչպես լավ պահերի, այնպես էլ վատի մասին։ Սկսեմ վատերից. Քանի որ շատ ծրագրավորողներ ներգրավված էին այս նախագծում կոմերցիոն հիմունքներով, համայնքն արդեն բավականին անկայուն էր և պառակտված, ինչը, իհարկե, չէր կարող չազդել նախագծի զարգացման վրա: Լրացուցիչ գործոնն այն էր, որ նախագծի ուղղությունը սահմանել էր մեկ կոմերցիոն հաճախորդ, և նրա նպատակը նախագծի հետագա զարգացումը չէր։ Գոնե սա չէր հիմնական նպատակը։
Մյուս կողմից, կային մի շարք դրական կողմեր. Մենք ստացել ենք իսկապես երրորդ կողմի օգտվողներ: Դա ոչ միայն հաճախորդն էր, այլեւ նրանք, ում համար նախատեսված էր այս համակարգը։ Նախագծին մասնակցելու մոտիվացիան մեծացել է. Ի վերջո, եթե դուք կարող եք նաև գումար աշխատել հետաքրքիր բիզնեսից, դա միշտ էլ հաճելի է: Եվ ամենակարևորը, մենք լսեցինք հաճախորդներից մեկ ցանկություն, որն այն ժամանակ մեզ խենթ էր թվում, բայց որն այժմ Embox-ի հիմնական գաղափարն է, այն է՝ օգտագործել արդեն մշակված կոդը համակարգում։ Այժմ Embox-ի հիմնական գաղափարն է օգտագործել Linux ծրագրակազմն առանց Linux-ի: Այսինքն՝ ծրագրի հետագա զարգացմանը նպաստող հիմնական դրական կողմը եղել է այն գիտակցումը, որ նախագիծն օգտագործվում է երրորդ կողմի օգտատերերի կողմից, և այն պետք է լուծի նրանց որոշ խնդիրներ։
Այն ժամանակ Embox-ն արդեն դուրս էր եկել ուսանողական նախագծի շրջանակներից։ Նախագծի մշակման հիմնական սահմանափակող գործոնն ըստ ուսանողական մոդելի մասնակիցների մոտիվացիան է։ Ուսանողները սովորում են, իսկ երբ ավարտում են, պետք է այլ մոտիվացիա լինի։ Եթե մոտիվացիան չի հայտնվում, ուսանողը պարզապես դադարում է մասնակցել նախագծին: Եթե հաշվի առնենք, որ ուսանողները նախ վերապատրաստման կարիք ունեն, ապա կստացվի, որ նրանք լավ մասնագետ են դառնում ավարտելու պահին, բայց նրանց ներդրումը նախագծում, անփորձության պատճառով, այնքան էլ մեծ չէ։
Ընդհանրապես, մենք սահուն անցնում ենք այն հիմնական կետին, որը թույլ է տալիս խոսել բաց կոդով նախագիծ ստեղծելու մասին՝ ստեղծելով արտադրանք, որը կլուծեր իր օգտագործողների խնդիրները: Ինչպես վերը բացատրեցի, բաց կոդով նախագծի հիմնական հատկությունը նրա համայնքն է: Ավելին, համայնքի անդամները հիմնականում օգտվողներ են: Բայց որտեղի՞ց են դրանք գալիս, երբ օգտագործելու ոչինչ չկա: Այսպիսով, պարզվում է, որ, ինչպես ոչ բաց կոդով նախագծի դեպքում, դուք պետք է կենտրոնանաք MVP (նվազագույն կենսունակ արտադրանք) ստեղծելու վրա, և եթե դա հետաքրքրում է օգտատերերին, ապա համայնք կհայտնվի նախագծի շուրջ: Եթե դուք զբաղվում եք համայնք ստեղծելով միայն համայնքային PR-ի միջոցով, գրելով վիքի աշխարհի բոլոր լեզուներով կամ ճիշտ git-ի աշխատանքի հոսքը github-ում, ապա դա դժվար թե կարևոր լինի նախագծի վաղ փուլերում: Իհարկե, համապատասխան փուլերում դրանք ոչ միայն կարևոր են, այլև անհրաժեշտ բաներ։
Եզրափակելով, ես կցանկանայի նշել , իմ կարծիքով, արտացոլում է օգտատերերի ակնկալիքները opensource նախագծից.
Ես լրջորեն մտածում եմ այս ՕՀ-ին անցնելու մասին (գոնե փորձեք. ակտիվորեն հետամուտ են դրան ու թույն բաներ են անում):
PS Միացված է Մենք կունենանք երեք զեկույց։ Մեկը բաց կոդով և երկուսը ներկառուցվածի մասին (և մեկը գործնական է): Ստենդում մենք վարպետության դաս կանցկացնենք ծրագրավորման միկրոկոնտրոլերների օգտագործմամբ . Ինչպես միշտ, մենք կբերենք սարքավորումը և թույլ կտանք ծրագրավորել այն: Կլինեն նաև քվեստ և այլ գործողություններ։ Եկեք փառատոնին և մեր ստենդին, զվարճալի կլինի:
Source: www.habr.com