Энэ долоо хоногт Санкт-Петербургт мэдээллийн технологийн фестиваль болно . Илтгэгчдийн нэг нь Ричард Сталлман байх болно. Мөн наадамд оролцдог бөгөөд мэдээжийн хэрэг бид үнэгүй програм хангамжийн сэдвийг үл тоомсорлож болохгүй. Тийм ч учраас манай нэг сурвалжлагыг нэрлэсэн . Энэ нь нээлттэй эхийн төсөл болох Embox-ийн хөгжлийн түүхэнд зориулагдсан болно. Энэ нийтлэлд би нээлттэй эхийн төслүүдийг хөгжүүлэхэд нөлөөлдөг гол санаануудын талаар ярихыг хүсч байна. Уг нийтлэл нь тайлангийн нэгэн адил хувийн туршлага дээр үндэслэсэн болно.
Нээлттэй эх гэдэг нэр томъёоны тодорхойлолтоос эхлээд энгийн зүйлээс эхэлье. Мэдээжийн хэрэг, нээлттэй эхийн төсөл нь төслийн эх код руу нэвтрэх боломжийг олгодог лицензүүдийн аль нэгийг агуулсан төсөл юм. Нэмж дурдахад, нээлттэй төсөл нь гуравдагч талын хөгжүүлэгчид өөрчлөлт хийх боломжтой гэсэн үг юм. Өөрөөр хэлбэл, хэрэв зарим компани эсвэл хөгжүүлэгч бүтээгдэхүүнийхээ кодыг хэсэгчлэн эсвэл бүрэн нийтэлсэн бол энэ нь энэ бүтээгдэхүүнийг нээлттэй эхийн төсөл болгож чадахгүй байна. Эцэст нь, төслийн аливаа үйл ажиллагаа нь ямар нэгэн үр дүнд хүргэх ёстой бөгөөд төслийн нээлттэй байдал нь энэ үр дүнг зөвхөн хөгжүүлэгчид өөрсдөө ашигладаггүй гэсэн үг юм.
Бид нээлттэй лицензийн асуудлыг хөндөхгүй. Энэ бол хэтэрхий том бөгөөд нарийн судалгаа шаарддаг сэдэв юм. Энэ сэдвээр маш олон сайн нийтлэл, материал бичсэн. Гэхдээ би өөрөө зохиогчийн эрхийн чиглэлээр мэргэшсэн мэргэжилтэн биш учраас лиценз нь төслийн зорилгод нийцэх ёстой гэж л хэлэх болно. Жишээлбэл, Embox-ын хувьд GPL лиценз биш BSD-г сонгосон нь санамсаргүй хэрэг биш юм.
Нээлттэй эхийн төсөл нь өөрчлөлт хийх, нээлттэй эхийн төслийн хөгжилд нөлөөлөх чадварыг хангах ёстой гэдэг нь төслийг тарааж байна гэсэн үг юм. Үүнийг удирдах, бүрэн бүтэн байдал, гүйцэтгэлийг хадгалах нь төвлөрсөн удирдлагатай төсөлтэй харьцуулахад хамаагүй хэцүү байдаг. Үндэслэлтэй асуулт гарч ирнэ: яагаад төслүүдийг нээх вэ? Хариулт нь арилжааны боломжийн талбарт оршдог; тодорхой ангиллын төслүүдийн хувьд энэ аргын ашиг нь зардлаас давж гардаг. Энэ нь бүх төслүүдэд тохиромжгүй бөгөөд нээлттэй хандлагыг ерөнхийд нь хүлээн зөвшөөрдөг. Тухайлбал, цахилгаан станц, нисэх онгоцны удирдлагын системийг нээлттэй зарчимд тулгуурлан хөгжүүлнэ гэж төсөөлөхөд бэрх. Үгүй, мэдээжийн хэрэг, ийм системүүд нь нээлттэй төслүүдэд суурилсан модулиудыг багтаах ёстой, учир нь энэ нь олон давуу талыг өгөх болно. Гэхдээ эцсийн бүтээгдэхүүнд хэн нэгэн хариуцлага хүлээх ёстой. Систем нь нээлттэй төслүүдийн код дээр бүрэн суурилсан байсан ч бүх зүйлийг нэг системд багцалж, тодорхой бүтэц, тохиргоог хийсний дараа хөгжүүлэгч үүнийг үндсэндээ хаадаг. Код нь олон нийтэд нээлттэй байж болно.
Нээлттэй эхийн төслүүдийг бий болгох, хувь нэмрээ оруулах нь эдгээр системүүдэд маш их ашиг тустай байдаг. Би аль хэдийн хэлсэнчлэн, системийн төгсгөлийн код олон нийтэд нээлттэй хэвээр байж магадгүй юм. Яагаад гэвэл системийг туршихын тулд хэн нэгэн ижил онгоцтой байх магадлал багатай нь ойлгомжтой. Энэ нь үнэн, гэхдээ кодын зарим хэсгийг шалгахыг хүссэн хэн нэгэн байж магадгүй, эсвэл жишээлбэл, хэн нэгэн ашиглаж байгаа номын сан зөв тохируулагдаагүй байгааг олж мэдэх боломжтой.
Хэрэв компани системийн зарим хэсгийг тусдаа төсөл болгон хуваарилвал илүү их ашиг тустай байх болно. Жишээлбэл, зарим төрлийн өгөгдөл солилцох протоколыг дэмжих номын сан. Энэ тохиолдолд протокол нь тухайн сэдвийн талбарт зориулагдсан байсан ч та системийн энэ хэсгийг хадгалах зардлыг энэ бүсийн бусад компаниудтай хуваалцаж болно. Нэмж дурдахад системийн энэ хэсгийг олон нийтийн эзэмшилд судалж чадах мэргэжилтнүүд үүнийг үр дүнтэй ашиглахад хамаагүй бага хугацаа шаарддаг. Эцэст нь, гуравдагч талын хөгжүүлэгчдийн ашигладаг бие даасан байгууллага болгон хуваах нь бидэнд энэ хэсгийг илүү сайн болгох боломжийг олгодог, учир нь бид үр дүнтэй API-г санал болгож, баримт бичгийг бий болгох хэрэгтэй бөгөөд би туршилтын хамрах хүрээг сайжруулах талаар огт ярихгүй байна.
Компани нь нээлттэй эхийн төсөл үүсгэхгүйгээр арилжааны ашиг тус хүртэх боломжтой бөгөөд түүний мэргэжилтнүүд компанид ашиглагдаж буй гуравдагч этгээдийн төслүүдэд оролцоход хангалттай. Эцсийн эцэст бүх ашиг тус хэвээр байна: ажилчид төслийг илүү сайн мэддэг, тиймээс тэд үүнийг илүү үр дүнтэй ашигладаг, компани нь төслийн хөгжлийн чиглэлд нөлөөлж чаддаг, бэлэн, дибаг хийсэн кодыг ашиглах нь компанийн зардлыг бууруулдаг.
Нээлттэй эхийн төслүүдийг бий болгохын ашиг тус үүгээр дуусахгүй. Бизнесийн маркетинг гэх мэт чухал бүрэлдэхүүн хэсгийг авч үзье. Түүний хувьд энэ нь зах зээлийн шаардлагыг үр дүнтэй үнэлэх боломжийг олгодог маш сайн хамгаалагдсан хязгаарлагдмал орчин юм.
Мэдээжийн хэрэг, нээлттэй эхийн төсөл нь өөрийгөө аливаа мэргэшлийн тээгч гэдгээ зарлах үр дүнтэй арга гэдгийг мартаж болохгүй. Зарим тохиолдолд энэ нь зах зээлд нэвтрэх цорын ганц арга зам юм. Жишээлбэл, Embox нь RTOS үүсгэх төслөөр эхэлсэн. Өрсөлдөгчид олон байна гэж тайлбарлах шаардлагагүй болов уу. Нийгэмлэг үүсгэхгүйгээр бид төслийг эцсийн хэрэглэгчдэд хүргэх, өөрөөр хэлбэл гуравдагч талын хөгжүүлэгчид төслийг ашиглаж эхлэх хангалттай нөөц байхгүй байх байсан.
Нийгэмлэг нь нээлттэй эхийн төслийн гол түлхүүр юм. Энэ нь төслийн менежментийн зардлыг мэдэгдэхүйц бууруулах, төслийг боловсруулах, дэмжих боломжийг олгодог. Нийгэмлэггүйгээр нээлттэй эхийн төсөл огт байхгүй гэж бид хэлж чадна.
Нээлттэй эхийн төслийн нийгэмлэгийг хэрхэн бий болгох, удирдах талаар маш их материал бичсэн. Өмнө нь мэдэгдэж байсан баримтуудыг дахин хэлэхгүйн тулд би Embox-ын туршлага дээр анхаарлаа хандуулахыг хичээх болно. Жишээлбэл, нийгэмлэг байгуулах үйл явц нь маш сонирхолтой асуудал юм. Өөрөөр хэлбэл, олон хүн одоо байгаа нийгэмлэгийг хэрхэн удирдахыг хэлдэг боловч үүнийг бий болгосон мөчүүдийг заримдаа үл тоомсорлодог.
Нээлттэй эхийн төслийн нийгэмлэгийг бий болгох гол дүрэм бол дүрэм байхгүй байх явдал юм. Төсөл нь маш өөр учраас мөнгөн сум байдаггүйтэй адил бүх нийтийн дүрэм байдаггүй гэж би хэлэх гэсэн юм. Та js бүртгэлийн номын сан болон өндөр мэргэшсэн драйверын нийгэмлэг үүсгэхдээ ижил дүрмийг ашиглах боломжгүй юм. Түүгээр ч барахгүй төслийн хөгжлийн янз бүрийн үе шатанд (тиймээс хамт олон) дүрэм өөрчлөгддөг.
Embox нь системийн програмчлалын тэнхимийн оюутнуудад хандах боломжтой байсан тул оюутны төслөөр эхэлсэн. Үнэндээ бид өөр нийгэм рүү орж байсан. Бид энэ нийгэмлэгийн оролцогчид болох оюутнуудыг өөрсдийн мэргэжлээрээ үйлдвэрлэлийн сайн туршлага, системийн програмчлалын чиглэлээр шинжлэх ухааны ажил, курсын ажил, дипломыг сонирхож болно. Өөрөөр хэлбэл, бид нийгэмлэгийг зохион байгуулах үндсэн дүрмүүдийн нэгийг дагаж мөрдсөн: нийгэмлэгийн гишүүд ямар нэг зүйлийг авах ёстой бөгөөд энэ үнэ нь оролцогчийн оруулсан хувь нэмэртэй тохирч байх ёстой.
Embox-ын дараагийн шат бол гуравдагч этгээдийн хэрэглэгчдийг хайх явдал байв. Хэрэглэгчид нь нээлттэй эх сурвалжийн нийгэмлэгийн бүрэн оролцогч гэдгийг ойлгох нь маш чухал юм. Ихэвчлэн хөгжүүлэгчдээс илүү олон хэрэглэгчид байдаг. Мөн төсөлд хувь нэмэр оруулагч болохыг хүсэхийн тулд тэд эхлээд үүнийг ямар нэг байдлаар ашиглаж эхэлдэг.
Embox-ийн анхны хэрэглэгчид нь онолын кибернетикийн тэнхим юм. Тэд Lego Mindstorm-д зориулсан өөр програм хангамжийг бий болгохыг санал болгов. Хэдийгээр эдгээр нь орон нутгийн хэрэглэгчид хэвээр байсан ч (бид тэдэнтэй биечлэн уулзаж, тэдний хүссэн зүйлийг ярилцаж болно). Гэхдээ энэ нь маш сайн туршлага хэвээр байсан. Жишээлбэл, роботууд хөгжилтэй, олны анхаарлыг татдаг учраас бусдад үзүүлж болохуйц үзүүлэн хөгжүүлсэн. Үүний үр дүнд бид Embox гэж юу болох, түүнийг хэрхэн ашиглах талаар асууж эхэлсэн жинхэнэ гуравдагч талын хэрэглэгчидтэй болсон.
Энэ үе шатанд бид баримт бичиг, хэрэглэгчидтэй харилцах хэрэгслийн талаар бодох хэрэгтэй болсон. Үгүй ээ, мэдээжийн хэрэг, бид эдгээр чухал зүйлийн талаар өмнө нь бодож байсан ч энэ нь эрт байсан бөгөөд эерэг нөлөө үзүүлээгүй. Үр нөлөө нь харьцангуй сөрөг байсан. Би танд хэдэн жишээ хэлье. Бид вики нь олон хэлийг дэмждэг googlecode ашигласан. Бид англи, орос хэлээр бараг харилцдаггүй хэд хэдэн хэл дээр хуудаснууд үүсгэсэн, бас герман, испани хэлээр. Үүний үр дүнд эдгээр хэлээр асуухад энэ нь маш инээдтэй харагддаг боловч бид огт хариулж чадахгүй. Эсвэл тэд баримт бичиг бичих, тайлбар бичих дүрмийг нэвтрүүлсэн боловч API нь нэлээд олон удаа, мэдэгдэхүйц өөрчлөгддөг тул бидний баримт бичиг хуучирсан бөгөөд энэ нь туслахаасаа илүү төөрөгдүүлсэн байсан.
Үүний үр дүнд бидний бүх хүчин чармайлт, тэр ч байтугай буруу байсан ч гадны хэрэглэгчид харагдахад хүргэсэн. Түүнд зориулж өөрийн RTOS-ийг хөгжүүлэхийг хүссэн арилжааны үйлчлүүлэгч хүртэл гарч ирэв. Мөн бид туршлага, үндэслэлтэй учраас үүнийг хөгжүүлсэн. Энд та сайн, муу хоёрын аль алиныг нь ярих хэрэгтэй. Би муу зүйлээс эхэлье. Энэхүү төсөлд олон хөгжүүлэгчид арилжааны үндсэн дээр оролцож байсан тул нийгэм аль хэдийн тогтворгүй, хуваагдсан байсан нь төслийн хөгжилд нөлөөлөхгүй байх нь гарцаагүй. Нэмэлт хүчин зүйл бол төслийн чиглэлийг нэг арилжааны үйлчлүүлэгч тодорхойлсон бөгөөд түүний зорилго нь төслийн цаашдын хөгжил биш байв. Наад зах нь энэ нь гол зорилго биш байсан.
Нөгөө талаар хэд хэдэн эерэг талууд байсан. Бид үнэхээр гуравдагч талын хэрэглэгчидтэй болсон. Энэ нь зөвхөн үйлчлүүлэгчид төдийгүй энэ системийг ашиглах зорилготой байсан хүмүүс юм. Төсөлд оролцох хүсэл эрмэлзэл нэмэгдсэн. Эцсийн эцэст, хэрэв та сонирхолтой бизнесээс мөнгө олох боломжтой бол энэ нь үргэлж сайхан байдаг. Хамгийн гол нь бид үйлчлүүлэгчдээс тэр үед бидний хувьд галзуу мэт санагдаж байсан ч одоо Embox-ын гол санаа болсон нэг хүсэл, тухайлбал системд аль хэдийн боловсруулсан кодыг ашиглахыг сонссон. Одоо Embox-ийн гол санаа бол Линукс програм хангамжийг Линуксгүйгээр ашиглах явдал юм. Өөрөөр хэлбэл, төслийн цаашдын хөгжилд хувь нэмэр оруулсан гол эерэг тал бол төслийг гуравдагч этгээдийн хэрэглэгчид ашиглаж байгаа бөгөөд энэ нь тэдний зарим асуудлыг шийдвэрлэх ёстой гэдгийг ойлгох явдал байв.
Тэр үед Эмбокс аль хэдийн оюутны төслийн хүрээнээс хэтэрсэн байв. Оюутны загварын дагуу төслийг хөгжүүлэх гол хязгаарлагч хүчин зүйл бол оролцогчдын урам зориг юм. Оюутнууд сурч байх хугацаандаа оролцдог, төгсөхөд өөр сэдэл байх ёстой. Хэрэв урам зориг гарч ирэхгүй бол оюутан зүгээр л төсөлд оролцохоо зогсооно. Оюутнуудыг эхлээд сургах хэрэгтэйг харгалзан үзвэл төгсөхдөө сайн мэргэжилтэн болдог ч туршлагагүйн улмаас төсөлд оруулсан хувь нэмэр тийм ч их биш юм.
Ерөнхийдөө бид нээлттэй эхийн төслийг бий болгох тухай ярих боломжийг олгодог гол зүйл рүү шилжих болно - хэрэглэгчдийнхээ асуудлыг шийдэх бүтээгдэхүүн бий болгох. Би дээр тайлбарласанчлан, нээлттэй эхийн төслийн гол өмч нь түүний нийгэмлэг юм. Түүгээр ч барахгүй олон нийтийн гишүүд голчлон хэрэглэгчид байдаг. Гэхдээ ашиглах зүйлгүй байхад тэд хаанаас ирдэг вэ? Тэгэхээр нээлттэй эх үүсвэргүй төслийн нэгэн адил та MVP (хамгийн бага амьдрах чадвартай бүтээгдэхүүн) бий болгоход анхаарлаа хандуулах хэрэгтэй бөгөөд хэрвээ энэ нь хэрэглэгчдийн сонирхлыг татвал төслийн эргэн тойронд нийгэмлэг гарч ирэх болно. Хэрэв та зөвхөн олон нийтийн PR-аар дамжуулан нийгэмлэг байгуулах, дэлхийн бүх хэлээр вики бичих, эсвэл github дээр git-ийн ажлын урсгалыг засах зэрэг ажлыг хийж байгаа бол энэ нь төслийн эхний шатанд хамаагүй байх болно. Мэдээжийн хэрэг, зохих үе шатанд эдгээр нь зөвхөн чухал төдийгүй шаардлагатай зүйл юм.
Эцэст нь хэлэхэд би онцлон тэмдэглэхийг хүсч байна , миний бодлоор, нээлттэй эхийн төслөөс хэрэглэгчийн хүлээлтийг тусгасан:
Би энэ үйлдлийн систем рүү шилжих талаар нухацтай бодож байна (ядаж оролдоод үзээрэй. Тэд үүнийг идэвхтэй хөөцөлдөж, гайхалтай зүйл хийж байна).
Жич асаалттай Бид гурван тайлантай байх болно. Нэг нь нээлттэй эхийн тухай, хоёр нь суулгагдсан тухай (мөн нэг нь практик). Стенд дээр бид микроконтроллер ашиглан програмчлах мастер анги явуулна . Ердийнх шигээ бид техник хангамжийг авчирч программчлах болно. Мөн эрэл хайгуул болон бусад үйл ажиллагаа явагдана. Наадам болон манай стенд дээр ирээрэй, хөгжилтэй байх болно.
Эх сурвалж: www.habr.com