Festival IT bakal dianakake ing St. Petersburg minggu iki . Salah sawijining pamicara yaiku Richard Stallman. uga melu ing festival, lan mesthi kita ora bisa nglirwakake topik free software. Mulane salah siji saka laporan kita diarani . Iku bakal darmabakti kanggo sajarah pangembangan Embox minangka proyek open source. Ing artikel iki aku pengin ngomong babagan gagasan utama sing, miturut pendapatku, mengaruhi pangembangan proyek opensource. Artikel, kaya laporan, adhedhasar pengalaman pribadi.
Ayo diwiwiti kanthi prasaja, kanthi definisi istilah opensource. Temenan, proyek sumber terbuka minangka proyek sing duwe salah sawijining lisensi sing ngidini akses menyang kode sumber proyek kasebut. Kajaba iku, proyek mbukak tegese pangembang pihak katelu bisa nggawe owah-owahan. Yaiku, yen sawetara perusahaan utawa pangembang nerbitake kode produke, sebagian utawa lengkap, iki durung nggawe produk iki minangka proyek opensource. Lan pungkasane, kegiatan proyek apa wae kudu ngasilake sawetara asil, lan keterbukaan proyek kasebut nuduhake manawa asil iki digunakake ora mung dening pangembang dhewe.
Kita ora bakal ndemek masalah lisensi mbukak. Iki topik sing gedhe banget lan rumit sing mbutuhake penyelidikan sing jero. Cukup akeh artikel lan materi sing apik sing wis ditulis babagan topik iki. Nanging amarga aku dhewe ora ahli ing babagan hak cipta, aku mung bakal ujar manawa lisensi kasebut kudu nyukupi tujuan proyek kasebut. Contone, kanggo Embox pilihan saka BSD tinimbang lisensi GPL ora sengaja.
Kasunyatan manawa proyek sumber terbuka kudu menehi kemampuan kanggo nggawe owah-owahan lan pengaruhe pangembangan proyek sumber terbuka nuduhake manawa proyek kasebut disebarake. Ngatur, njaga integritas lan kinerja luwih angel dibandhingake karo proyek kanthi manajemen terpusat. Pitakonan sing cukup muncul: kenapa proyek mbukak kabeh? Jawaban kasebut ana ing babagan kelayakan komersial; kanggo kelas proyek tartamtu, keuntungan saka pendekatan iki luwih gedhe tinimbang biaya. Yaiku, ora cocog kanggo kabeh proyek lan pendekatan sing mbukak umume bisa ditampa. Contone, angel mbayangno ngembangake sistem kontrol kanggo pembangkit listrik utawa pesawat sing adhedhasar prinsip mbukak. Ora, mesthi, sistem kasebut kudu kalebu modul adhedhasar proyek mbukak, amarga iki bakal menehi sawetara kaluwihan. Nanging wong kudu tanggung jawab kanggo produk pungkasan. Sanajan sistem kasebut adhedhasar kode proyek sing mbukak, pangembang, sing wis ngrangkep kabeh dadi siji sistem lan nggawe bangunan lan setelan tartamtu, mesthine nutup. Kode kasebut bisa uga kasedhiya kanggo umum.
Ana uga akeh keuntungan kanggo sistem kasebut saka nggawe utawa nyumbang kanggo proyek open source. Kaya sing wis dakkandhakake, kode sistem pungkasan bisa uga kasedhiya kanggo umum. Yagene, amarga jelas manawa ora ana sing duwe pesawat sing padha kanggo nyoba sistem kasebut. Iki bener, nanging bisa uga ana wong sing pengin mriksa bagean tartamtu saka kode kasebut, utawa, contone, ana sing nemokake manawa perpustakaan sing digunakake ora dikonfigurasi kanthi bener.
Keuntungan sing luwih gedhe katon yen perusahaan nyedhiyakake sawetara bagean dhasar saka sistem kasebut menyang proyek sing kapisah. Contone, perpustakaan kanggo ndhukung sawetara jenis protokol exchange data. Ing kasus iki, sanajan protokol kasebut khusus kanggo area subyek tartamtu, sampeyan bisa nuduhake biaya kanggo njaga bagean sistem iki karo perusahaan liyane saka wilayah iki. Kajaba iku, spesialis sing bisa nyinaoni bagean sistem iki ing domain umum mbutuhake wektu sing luwih sithik kanggo nggunakake kanthi efektif. Lan pungkasane, misahake potongan dadi entitas independen sing digunakake pangembang pihak katelu ngidini kita nggawe bagean iki luwih apik, amarga kita kudu menehi API sing efektif, nggawe dokumentasi, lan aku ora ngomong babagan nambah jangkoan tes.
Perusahaan bisa nampa keuntungan komersial tanpa nggawe proyek sumber terbuka, cukup kanggo spesialis kanggo melu proyek pihak katelu sing digunakake ing perusahaan kasebut. Sawise kabeh, kabeh keuntungan tetep: karyawan luwih ngerti proyek kasebut, mula dheweke nggunakake kanthi luwih efektif, perusahaan bisa mengaruhi arah pangembangan proyek kasebut, lan nggunakake kode debugged sing siap digawe kanthi jelas nyuda biaya perusahaan.
Keuntungan nggawe proyek opensource ora mungkasi ana. Ayo njupuk komponen penting saka bisnis minangka marketing. Kanggo dheweke, iki minangka kothak wedhi sing apik banget sing ngidini dheweke ngevaluasi syarat pasar kanthi efektif.
Lan mesthi, kita ora kudu lali manawa proyek opensource minangka cara sing efektif kanggo nyatakake dhewe minangka operator spesialisasi apa wae. Ing sawetara kasus, iki mung cara kanggo mlebu pasar. Contone, Embox wiwit minangka proyek kanggo nggawe RTOS. Mesthine ora perlu nerangake manawa ana akeh pesaing. Tanpa nggawe komunitas, kita ora bakal duwe sumber daya sing cukup kanggo nggawa proyek kasebut menyang pangguna pungkasan, yaiku, kanggo pangembang pihak katelu wiwit nggunakake proyek kasebut.
Komunitas minangka kunci ing proyek opensource. Iki ngidini sampeyan nyuda biaya manajemen proyek, ngembangake lan ndhukung proyek kasebut. Kita bisa ngomong yen tanpa komunitas ora ana proyek opensource.
Akeh materi sing wis ditulis babagan carane nggawe lan ngatur komunitas proyek open source. Supaya ora nyritakake maneh fakta sing wis dingerteni, aku bakal nyoba fokus ing pengalaman Embox. Contone, proses nggawe komunitas minangka masalah sing menarik banget. Tegese, akeh sing nyritakake carane ngatur komunitas sing wis ana, nanging momen-momen penciptaan kasebut kadhangkala diabaikan, amarga iki diwenehake.
Aturan utama nalika nggawe komunitas proyek opensource yaiku ora ana aturan. Maksudku ora ana aturan universal, kaya ora ana peluru perak, yen mung amarga proyeke beda banget. Ora mungkin sampeyan bisa nggunakake aturan sing padha nalika nggawe komunitas kanggo perpustakaan log js lan sawetara pembalap khusus. Kajaba iku, ing macem-macem tahap pangembangan proyek (lan masyarakat), aturan kasebut ganti.
Embox diwiwiti minangka proyek siswa amarga nduweni akses menyang siswa saka departemen pemrograman sistem. Nyatane, kita mlebu sawetara komunitas liyane. Kita bisa narik kawigaten para peserta komunitas iki, siswa, ing praktik industri sing apik ing spesialisasi, karya ilmiah ing bidang pemrograman sistem, kursus lan diploma. Yaiku, kita ngetutake salah sawijining aturan dhasar kanggo ngatur komunitas: anggota komunitas kudu nampa apa-apa, lan rega iki kudu cocog karo kontribusi peserta.
Tahap sabanjure kanggo Embox yaiku nggoleki pangguna pihak katelu. Penting banget kanggo mangerteni manawa pangguna minangka peserta lengkap ing komunitas opensource. Biasane pangguna luwih akeh tinimbang pangembang. Lan supaya pengin dadi kontributor kanggo proyek, padha miwiti nggunakake ing siji utawa liyane cara.
Pangguna pisanan Embox yaiku Departemen Sibernetika Teoritis. Dheweke nyaranake nggawe perangkat kukuh alternatif kanggo Lego Mindstorm. Lan sanajan iki isih pangguna lokal (kita bisa ketemu karo wong-wong mau lan ngrembug apa sing dikarepake). Nanging iku isih pengalaman apik banget. Contone, kita ngembangake demo sing bisa ditampilake kanggo wong liya, amarga robot nyenengake lan narik kawigaten. Akibaté, kita entuk pangguna pihak katelu sing wiwit takon apa Embox lan cara nggunakake.
Ing tahap iki, kita kudu mikir babagan dokumentasi, babagan cara komunikasi karo pangguna. Ora, mesthi, kita mikir babagan perkara-perkara penting kasebut sadurunge, nanging durung wayahe lan ora menehi efek positif. Efek kasebut rada negatif. Ayo kula menehi sawetara conto. Kita nggunakake googlecode, sing wiki ndhukung multibasa. Kita nggawe kaca ing sawetara basa, ora mung Inggris lan Rusia, sing meh ora bisa komunikasi, nanging uga Jerman lan Spanyol. Akibaté, katon konyol banget nalika ditakoni nganggo basa-basa kasebut, nanging kita ora bisa mangsuli babar pisan. Utawa padha ngenalaken aturan babagan nulis dokumentasi lan komentar, nanging wiwit API diganti cukup kerep lan Ngartekno, pranyata dokumentasi kita wis outdated lan luwih mblusukake saka mbantu.
Akibaté, kabeh upaya kita, sanajan sing salah, nyebabake pangguna eksternal. Lan malah pelanggan komersial muncul sing pengin RTOS dhewe dikembangake kanggo dheweke. Lan kita ngembangake amarga kita duwe pengalaman lan sawetara dhasar. Ing kene sampeyan kudu ngomong babagan wektu sing apik lan sing ala. Aku bakal miwiti karo sing ala. Amarga akeh pangembang sing melu proyek iki kanthi komersial, masyarakat wis ora stabil lan dibagi, sing mesthi ora bisa mengaruhi pangembangan proyek kasebut. Faktor tambahan yaiku arah proyek kasebut disetel dening siji pelanggan komersial, lan tujuane ora dadi pangembangan proyek kasebut. Paling ora iki dudu tujuan utama.
Ing sisih liya, ana sawetara aspek positif. Kita entuk pangguna pihak katelu sing sejatine. Iku ora mung customer, nanging uga kanggo kang sistem iki dimaksudaké. Motivasi kanggo melu proyek kasebut tambah akeh. Sawise kabeh, yen sampeyan uga bisa nggawe dhuwit saka bisnis menarik, iku tansah becik. Lan sing paling Jahwéh, kita krungu siji kepinginan saka pelanggan, kang ing wektu sing ketoke edan kanggo kita, nanging kang saiki idea utama Embox, yaiku, nggunakake kode wis dikembangaké ing sistem. Saiki ide utama Embox yaiku nggunakake piranti lunak Linux tanpa Linux. Yaiku, aspek positif utama sing nyumbang kanggo pangembangan luwih lanjut saka proyek kasebut yaiku kesadaran yen proyek kasebut digunakake dening pangguna pihak katelu, lan kudu ngrampungake sawetara masalah kasebut.
Ing wektu iku, Embox wis ngluwihi ruang lingkup proyek mahasiswa. Faktor watesan utama ing pangembangan proyek miturut model siswa yaiku motivasi para peserta. Siswa melu nalika lagi sinau, lan nalika lulus kudu ana motivasi sing beda. Yen motivasi ora katon, siswa mung mandheg melu proyek kasebut. Yen digatekake yen para siswa kudu dilatih dhisik, pranyata dheweke dadi spesialis sing apik nalika lulus, nanging kontribusi kanggo proyek kasebut, amarga ora duwe pengalaman, ora gedhe banget.
Umumé, kita lancar pindhah menyang titik utama sing ngidini kita ngomong babagan nggawe proyek opensource - nggawe produk sing bakal ngatasi masalah pangguna. Kaya sing dak jelasake ing ndhuwur, properti utama proyek opensource yaiku komunitas. Kajaba iku, anggota komunitas utamane pangguna. Nanging saka ngendi asale nalika ora ana sing bisa digunakake? Dadi, kaya proyek non-opensource, sampeyan kudu fokus nggawe MVP (produk minimal sing bisa ditindakake), lan yen narik minat pangguna, banjur komunitas bakal katon ing sekitar proyek kasebut. Yen sampeyan melu nggawe komunitas mung liwat PR komunitas, nulis wiki ing kabeh basa ing donya, utawa alur kerja git sing bener ing github, mula iki ora bakal dadi masalah ing tahap awal proyek kasebut. Mesthi, ing tahap sing cocog iki ora mung penting, nanging uga prelu.
Ing kesimpulan, aku pengin nuduhake , miturut pendapatku, nggambarake pangarepan pangguna saka proyek opensource:
Aku serius mikir babagan ngalih menyang OS iki (paling ora nyoba. Lagi aktif nguber lan nindakake kelangan).
PS ing Kita bakal duwe telung laporan. Siji babagan open source lan loro babagan embedded (lan siji praktis). Ing stand kita bakal nganakake kelas master babagan pemrograman mikrokontroler nggunakake . Kaya biasane, kita bakal nggawa hardware lan ngidini sampeyan program. Ana uga nggoleki lan kegiatan liyane. Ayo menyang festival lan stand kita, bakal nyenengake.
Source: www.habr.com