Bu həftə Sankt-Peterburqda İT festivalı keçiriləcək . Natiqlərdən biri Riçard Stallman olacaq. festivalda da iştirak edir və təbii ki, pulsuz proqram mövzusunu da nəzərdən qaçıra bilməzdik. Buna görə də reportajlarımızdan biri belə adlanır . O, Emboxun açıq mənbə layihəsi kimi inkişaf tarixinə həsr olunacaq. Bu yazıda mən fikrimcə, açıq mənbəli layihələrin inkişafına təsir edən əsas fikirlərdən danışmaq istəyirəm. Məqalə, hesabat kimi, şəxsi təcrübəyə əsaslanır.
Açıq mənbə termininin tərifi ilə sadə bir şeylə başlayaq. Aydındır ki, açıq mənbəli layihə, layihənin mənbə koduna daxil olmağa imkan verən lisenziyalardan birinə malik olan layihədir. Bundan əlavə, açıq layihə o deməkdir ki, üçüncü tərəf tərtibatçıları dəyişiklik edə bilər. Yəni, əgər hansısa şirkət və ya tərtibatçı öz məhsulunun kodunu qismən və ya tamamilə dərc edirsə, bu, hələ bu məhsulu açıq mənbə layihəsinə çevirmir. Və nəhayət, hər hansı bir layihə fəaliyyəti bir növ nəticəyə gətirib çıxarmalıdır və layihənin açıqlığı bu nəticənin təkcə tərtibatçıların özləri tərəfindən istifadə edilməməsini nəzərdə tutur.
Açıq lisenziyaların problemlərinə toxunmayacağıq. Bu, çox böyük və mürəkkəb mövzudur və dərin araşdırma tələb edir. Bu mövzuda kifayət qədər yaxşı məqalələr və materiallar yazılmışdır. Amma mən özüm müəllif hüquqları sahəsində mütəxəssis olmadığım üçün sadəcə onu deyim ki, lisenziya layihənin məqsədlərinə cavab verməlidir. Məsələn, Embox üçün GPL lisenziyası əvəzinə BSD seçimi təsadüfi deyildi.
Açıq mənbə layihəsinin dəyişikliklər etmək və açıq mənbə layihəsinin inkişafına təsir etmək qabiliyyətini təmin etməli olması layihənin paylanmasını nəzərdə tutur. Mərkəzləşdirilmiş idarəetmə ilə bir layihə ilə müqayisədə onu idarə etmək, bütövlüyü və performansını qorumaq daha çətindir. Ağlabatan sual yaranır: niyə ümumiyyətlə layihələr açır? Cavab kommersiya məqsədəuyğunluğu sahəsindədir; müəyyən bir layihə sinfi üçün bu yanaşmanın faydaları xərclərdən üstündür. Yəni bütün layihələr üçün uyğun deyil və açıq yanaşma ümumiyyətlə məqbuldur. Məsələn, açıq prinsip əsasında elektrik stansiyası və ya təyyarə üçün idarəetmə sisteminin işlənib hazırlanmasını təsəvvür etmək çətindir. Xeyr, təbii ki, belə sistemlərə açıq layihələr əsasında modullar daxil edilməlidir, çünki bu, bir sıra üstünlüklər verəcək. Amma son məhsula görə kimsə cavabdeh olmalıdır. Sistem tamamilə açıq layihələrin koduna əsaslansa belə, tərtibatçı hər şeyi bir sistemə yığaraq, xüsusi quruluşlar və parametrlər edərək onu mahiyyətcə bağlayır. Kod ictimaiyyətə açıq ola bilər.
Bu sistemlər üçün açıq mənbə layihələri yaratmaq və ya onlara töhfə verməkdən də bir çox üstünlüklər var. Artıq dediyim kimi, son sistem kodu ictimaiyyətə açıq qala bilər. Niyə, çünki hər kəsin sistemi sınaqdan keçirmək üçün eyni təyyarəyə sahib olması ehtimalı azdır. Bu doğrudur, lakin kodun müəyyən bölmələrini yoxlamaq istəyənlər ola bilər və ya məsələn, kimsə istifadə olunan kitabxananın kifayət qədər düzgün konfiqurasiya edilmədiyini aşkar edə bilər.
Şirkət sistemin bəzi əsas hissəsini ayrıca bir layihəyə ayırsa, daha böyük fayda görünür. Məsələn, bir növ məlumat mübadiləsi protokolunu dəstəkləmək üçün bir kitabxana. Bu halda, protokol müəyyən bir mövzu sahəsinə xas olsa belə, sistemin bu hissəsinin saxlanması xərclərini bu sahədən olan digər şirkətlərlə bölüşə bilərsiniz. Bundan əlavə, sistemin bu hissəsini ictimai sahədə öyrənə bilən mütəxəssislər ondan səmərəli istifadə etmək üçün daha az vaxt tələb edir. Və nəhayət, bir parçanı üçüncü tərəf tərtibatçılarının istifadə etdiyi müstəqil bir quruma ayırmaq bizə bu hissəni daha da yaxşılaşdırmağa imkan verir, çünki biz effektiv API-lər təklif etməliyik, sənədlər yaratmalıyıq və mən hətta test əhatə dairəsini yaxşılaşdırmaqdan danışmıram.
Şirkət açıq mənbəli layihələr yaratmadan kommersiya faydaları əldə edə bilər, onun mütəxəssislərinin şirkətdə istifadə olunan üçüncü tərəf layihələrində iştirak etməsi kifayətdir. Axı, bütün üstünlüklər qalır: işçilər layihəni daha yaxşı bilirlər, buna görə də ondan daha səmərəli istifadə edirlər, şirkət layihənin inkişaf istiqamətinə təsir göstərə bilər və hazır, düzəldilmiş kodun istifadəsi şirkətin xərclərini açıq şəkildə azaldır.
Açıq mənbəli layihələr yaratmağın faydaları bununla bitmir. Biznesin marketinq kimi mühüm komponentini götürək. Onun üçün bu, bazar tələblərini effektiv şəkildə qiymətləndirməyə imkan verən çox yaxşı bir sandboxdır.
Və əlbəttə ki, unutmamalıyıq ki, açıq mənbə layihəsi özünüzü hər hansı bir ixtisasın daşıyıcısı kimi elan etməyin effektiv yoludur. Bəzi hallarda bu, bazara girməyin yeganə yoludur. Məsələn, Embox bir RTOS yaratmaq üçün bir layihə olaraq başladı. Rəqiblərin çox olduğunu izah etməyə yəqin ki, ehtiyac yoxdur. İcma yaratmadan, sadəcə olaraq, layihəni son istifadəçiyə çatdırmaq, yəni üçüncü tərəf tərtibatçılarının layihədən istifadə etməyə başlaması üçün kifayət qədər resursumuz olmazdı.
Açıq mənbə layihəsində icma əsas rol oynayır. Bu, layihənin idarə edilməsi xərclərini əhəmiyyətli dərəcədə azaltmağa, layihəni inkişaf etdirməyə və dəstəkləməyə imkan verir. Deyə bilərik ki, icma olmadan heç bir açıq mənbə layihəsi yoxdur.
Açıq mənbəli layihə icmasını necə yaratmaq və idarə etmək barədə çoxlu materiallar yazılıb. Artıq məlum olan faktları təkrarlamamaq üçün mən Embox təcrübəsinə diqqət yetirməyə çalışacağam. Məsələn, icmanın yaradılması prosesi çox maraqlı məsələdir. Yəni, çoxları mövcud icmanın necə idarə olunacağını söyləyir, lakin onun yaranma anları bəzən diqqətdən kənarda qalır, bunu verilmişdir.
Açıq mənbəli layihə icması yaratarkən əsas qayda heç bir qaydanın olmamasıdır. Mən demək istəyirəm ki, heç bir universal qaydalar yoxdur, eynilə gümüş güllə olmadığı kimi, yalnız layihələr çox fərqli olduğu üçün. Js logging kitabxanası və bəzi yüksək ixtisaslaşmış sürücü üçün icma yaratarkən eyni qaydalardan istifadə edə bilməyəcəyiniz ehtimalı azdır. Üstəlik, layihənin (və buna görə də cəmiyyətin) inkişafının müxtəlif mərhələlərində qaydalar dəyişir.
Embox sistem proqramlaşdırma departamentindən tələbələrə çıxışı olduğu üçün tələbə layihəsi kimi başladı. Əslində biz başqa bir cəmiyyətə girirdik. Biz bu icmanın iştirakçılarını, tələbələri öz ixtisasları üzrə qabaqcıl istehsalat təcrübəsi, sistem proqramlaşdırması sahəsində elmi iş, kurs işləri və diplomlarla maraqlandıra bilərdik. Yəni biz icmanın təşkilinin əsas qaydalarından birinə əməl etdik: icma üzvləri nəsə almalıdır və bu qiymət iştirakçının töhfəsinə uyğun olmalıdır.
Embox üçün növbəti mərhələ üçüncü tərəf istifadəçilərinin axtarışı idi. İstifadəçilərin açıq mənbə cəmiyyətinin tam iştirakçıları olduğunu başa düşmək çox vacibdir. Adətən tərtibatçılardan daha çox istifadəçi var. Və bir layihənin iştirakçısı olmaq istəmək üçün əvvəlcə ondan bu və ya digər şəkildə istifadə etməyə başlayırlar.
Embox-un ilk istifadəçiləri Nəzəri Kibernetika Departamenti olmuşdur. Onlar Lego Mindstorm üçün alternativ proqram təminatı yaratmağı təklif etdilər. Baxmayaraq ki, bunlar hələ də yerli istifadəçilərdir (onlarla şəxsən görüşə və istədiklərini müzakirə edə bilərdik). Amma yenə də çox yaxşı təcrübə idi. Məsələn, biz başqalarına göstərilə bilən demolar hazırladıq, çünki robotlar əyləncəlidir və diqqəti cəlb edir. Nəticədə, Emboxun nə olduğunu və ondan necə istifadə olunacağını soruşmağa başlayan həqiqətən üçüncü tərəf istifadəçiləri əldə etdik.
Bu mərhələdə biz sənədləşmə, istifadəçilərlə ünsiyyət vasitələri haqqında düşünməli olduq. Yox, təbii ki, biz bu vacib şeyləri əvvəllər düşündük, amma bu, vaxtından əvvəl idi və müsbət effekt vermədi. Təsiri olduqca mənfi idi. Sizə bir-iki misal deyim. Biz googlecode istifadə etdik, onun wiki çoxdilliliyi dəstəkləyir. Biz bir neçə dildə səhifələr yaratdıq, təkcə ingilis və rus dillərində çətinliklə danışdığımız, hətta alman və ispan dillərində də səhifələr yaratdıq. Nəticə etibarı ilə bu dillərdə soruşanda çox gülünc görünür, amma heç cür cavab verə bilmirik. Yaxud onlar sənədlərin yazılması və şərhlərin yazılması ilə bağlı qaydalar təqdim etdilər, lakin API tez-tez və əhəmiyyətli dərəcədə dəyişdiyindən, sənədlərimizin köhnəldiyi və kömək etdiyindən daha çox yanıltıcı olduğu ortaya çıxdı.
Nəticədə, bütün səylərimiz, hətta yanlış olanlar belə, kənar istifadəçilərin görünməsinə səbəb oldu. Hətta öz RTOS-unun onun üçün hazırlanmasını istəyən kommersiya müştərisi də peyda oldu. Və biz bunu inkişaf etdirdik, çünki təcrübəmiz və bəzi əsaslar var. Burada həm yaxşı, həm də pis məqamlardan danışmaq lazımdır. Mən pislərdən başlayacağam. Bir çox tərtibatçı bu layihəyə kommersiya əsasında cəlb olunduğundan, icma artıq kifayət qədər qeyri-sabit və bölünmüşdü, bu da təbii ki, layihənin inkişafına təsir göstərməyə bilməzdi. Əlavə faktor o idi ki, layihənin istiqamətini bir kommersiya müştərisi müəyyən edirdi və onun məqsədi layihənin sonrakı inkişafı deyildi. Ən azından əsas məqsəd bu deyildi.
Digər tərəfdən, bir sıra müsbət cəhətlər də var idi. Həqiqətən üçüncü tərəf istifadəçilərimiz var. Bu, təkcə müştəri deyil, həm də bu sistemin kimlər üçün nəzərdə tutulduğu idi. Layihədə iştirak etmək üçün motivasiya artıb. Axı, əgər siz də maraqlı bir işdən pul qazana bilirsinizsə, bu, həmişə xoşdur. Və ən əsası, müştərilərdən o vaxt bizə dəli görünən, lakin indi Embox-un əsas ideyası olan bir istəyi eşitdik, yəni sistemdə artıq işlənmiş kodu istifadə etmək. İndi Embox-un əsas ideyası Linux proqram təminatından Linux olmadan istifadə etməkdir. Yəni, layihənin gələcək inkişafına töhfə verən əsas müsbət cəhət layihənin üçüncü tərəf istifadəçiləri tərəfindən istifadə edildiyini və onların bəzi problemlərini həll etməli olduğunu başa düşmək idi.
O zaman Embox artıq tələbə layihəsi çərçivəsindən kənara çıxmışdı. Layihənin tələbə modelinə uyğun inkişaf etdirilməsində əsas məhdudlaşdırıcı amil iştirakçıların motivasiyasıdır. Tələbələr oxuyarkən iştirak edirlər və onlar məzun olduqda fərqli motivasiya olmalıdır. Motivasiya görünməzsə, tələbə sadəcə olaraq layihədə iştirakını dayandırır. Nəzərə alsaq ki, tələbələrə ilk növbədə təlim keçməlidirlər, belə çıxır ki, onlar məzun olanda yaxşı mütəxəssis olurlar, lakin təcrübəsizlik ucbatından onların layihəyə töhfəsi o qədər də böyük deyil.
Ümumiyyətlə, biz açıq mənbə layihəsinin yaradılması - istifadəçilərinin problemlərini həll edəcək məhsulun yaradılması haqqında danışmağa imkan verən əsas məqama rəvan keçirik. Yuxarıda izah etdiyim kimi, açıq mənbəli layihənin əsas xüsusiyyəti onun icmasıdır. Üstəlik, icma üzvləri ilk növbədə istifadəçilərdir. Bəs istifadə etmək üçün heç bir şey olmadığı halda onlar haradan gəlirlər? Belə çıxır ki, qeyri-açıq mənbəli layihədə olduğu kimi, diqqətinizi MVP (minimum həyat qabiliyyətli məhsul) yaratmağa yönəltməlisiniz və bu, istifadəçiləri maraqlandırırsa, o zaman layihə ətrafında icma yaranacaq. Əgər siz yalnız icma PR vasitəsilə icma yaratmaq, dünyanın bütün dillərində viki yazmaq və ya github-da git iş prosesini düzəltməklə məşğul olursunuzsa, layihənin ilkin mərhələlərində bunun əhəmiyyəti azdır. Təbii ki, müvafiq mərhələlərdə bunlar təkcə vacib deyil, həm də zəruri şeylərdir.
Sonda qeyd etmək istərdim , mənim fikrimcə, açıq mənbə layihəsindən istifadəçi gözləntilərini əks etdirir:
Mən ciddi şəkildə bu ƏS-ə keçmək barədə düşünürəm (heç olmasa cəhd edin. Onlar onu fəal şəkildə təqib edir və gözəl işlər görürlər).
PS Aktivdir Üç hesabatımız olacaq. Biri açıq mənbə haqqında, ikisi isə daxili (və biri praktikdir). Stenddə mikrokontrollerlərdən istifadə etməklə proqramlaşdırma üzrə master-klass keçirəcəyik . Həmişə olduğu kimi, biz aparatı gətirəcəyik və onu proqramlaşdırmanıza icazə verəcəyik. Axtarış və digər fəaliyyətlər də olacaq. Festivala və stendimizə gəlin, əyləncəli olacaq.
Mənbə: www.habr.com