Sudah minggu ini di St. Petersburg akan menjadi tuan rumah
festival IT
TechTrain . Salah satu pembicara adalah Richard Stallman.
Embox juga berpartisipasi dalam festival, dan tentu saja kami tidak bisa mengabaikan topik perangkat lunak open source. Oleh karena itu, salah satu laporan kami disebut
“Dari kerajinan siswa hingga proyek opensource. Pengalaman Embox .
" Ini akan didedikasikan untuk sejarah Embox sebagai proyek sumber terbuka. Pada artikel ini saya ingin berbicara tentang ide-ide utama yang menurut saya mempengaruhi pengembangan proyek opensource. Artikel, seperti laporan, didasarkan pada pengalaman pribadi.
Mari kita mulai dengan definisi sederhana dari istilah opensource. Jelas, proyek sumber terbuka adalah proyek yang memiliki salah satu lisensi yang memungkinkan Anda untuk mengakses kode sumber proyek. Selain itu, proyek terbuka menyiratkan kemungkinan perubahan oleh pengembang pihak ketiga. Artinya, jika beberapa perusahaan atau pengembang menerbitkan kode produknya, sebagian atau seluruhnya, maka ini tidak menjadikan produk ini proyek sumber terbuka. Dan akhirnya, setiap kegiatan proyek harus mengarah pada munculnya semacam hasil, dan keterbukaan proyek menyiratkan bahwa tidak hanya pengembang sendiri yang menggunakan hasil ini.
Kami tidak akan menyentuh masalah lisensi terbuka. Ini terlalu besar dan rumit topik yang membutuhkan penyelidikan mendalam. Banyak artikel dan materi bagus telah ditulis tentang topik ini. Tetapi karena saya sendiri bukan spesialis dalam bidang hak cipta, saya hanya dapat mengatakan bahwa lisensi tersebut harus memenuhi tujuan proyek. Untuk Embox, misalnya, memilih BSD daripada lisensi GPL tidak acak.
Fakta bahwa proyek terbuka harus memungkinkan untuk membuat perubahan dan memengaruhi pengembangan proyek terbuka menyiratkan bahwa proyek tersebut didistribusikan. Mengelolanya, menjaga integritas dan efisiensi jauh lebih sulit dibandingkan dengan proyek dengan manajemen terpusat. Sebuah pertanyaan yang masuk akal muncul: mengapa proyek open source sama sekali? Jawabannya terletak di bidang kelayakan komersial, untuk kelas proyek tertentu, manfaat dari pendekatan ini lebih besar daripada biaya. Artinya, tidak untuk semua proyek, pendekatan terbuka umumnya dapat diterima. Misalnya, sulit membayangkan pengembangan pembangkit listrik atau sistem kontrol pesawat berdasarkan prinsip terbuka. Tidak, tentu saja, ada baiknya memasukkan modul berdasarkan proyek terbuka dalam komposisi sistem seperti itu, karena ini akan memberikan sejumlah keuntungan. Tetapi seseorang harus menjawab untuk produk akhir. Bahkan jika sistem ini sepenuhnya didasarkan pada kode sumber terbuka, pengembang, mengemas semuanya menjadi satu sistem dan membuat rakitan dan pengaturan tertentu, pada dasarnya menutupnya. Kode mungkin tersedia untuk umum.
Untuk sistem ini, ada juga banyak manfaat dari membuat proyek sumber terbuka atau berpartisipasi di dalamnya. Seperti yang saya katakan, kode sistem akhir dapat tetap berada di domain publik. Mengapa, karena jelas bahwa tidak mungkin ada orang yang memiliki pesawat yang sama untuk menguji sistem. Ini benar, tetapi mungkin ada seseorang yang ingin memeriksa setiap bagian dari kode, atau misalnya, seseorang mungkin menemukan bahwa perpustakaan yang digunakan tidak dikonfigurasi dengan benar.
Manfaat yang lebih besar muncul jika perusahaan mengalokasikan beberapa bagian dasar dari sistem ke proyek yang terpisah. Misalnya, perpustakaan untuk mendukung semacam protokol pertukaran data. Dalam hal ini, bahkan jika protokol khusus untuk area subjek tertentu, dimungkinkan untuk berbagi biaya mempertahankan bagian sistem ini dengan perusahaan lain dari area ini. Selain itu, spesialis yang dapat mempelajari bagian dari sistem ini dalam domain publik memerlukan waktu jauh lebih sedikit untuk menggunakannya secara efektif. Dan akhirnya, menyoroti bagian sebagai entitas independen, yang digunakan oleh pengembang pihak ketiga, memungkinkan Anda untuk membuat bagian ini lebih baik, karena Anda perlu menawarkan API yang efektif, membuat dokumentasi, saya bahkan tidak berbicara tentang meningkatkan cakupan pengujian.
Sebuah perusahaan dapat memperoleh manfaat komersial tanpa membuat proyek terbuka, itu sudah cukup bagi spesialisnya untuk berpartisipasi dalam proyek pihak ketiga yang digunakan oleh perusahaan. Bagaimanapun, semua manfaatnya tetap ada: karyawan mengetahui proyek dengan lebih baik, oleh karena itu mereka menggunakannya secara lebih efisien, perusahaan dapat mempengaruhi arah pengembangan proyek, dan penggunaan kode debug yang sudah jadi jelas mengurangi biaya perusahaan.
Manfaat membuat proyek opensource tidak berakhir di situ. Mari kita ambil komponen penting dari bisnis seperti pemasaran. Baginya, ini adalah kotak pasir yang sangat baik, yang memungkinkan Anda untuk secara efektif menilai persyaratan pasar.
Dan tentu saja, kita tidak boleh lupa bahwa proyek opensource adalah cara yang efektif untuk menyatakan dirinya sebagai pembawa spesialisasi apa pun. Dalam beberapa kasus, ini biasanya satu-satunya cara untuk memasuki pasar. Misalnya, Embox dimulai sebagai proyek untuk membuat RTOS. Mungkin tidak perlu menjelaskan bahwa ada banyak pesaing. Tanpa membuat komunitas, kami tidak akan memiliki sumber daya yang cukup untuk membawa proyek ke pengguna akhir, yaitu, bagi pengembang pihak ketiga untuk menggunakan proyek.
Komunitas adalah kunci dalam proyek opensource. Ini memungkinkan Anda untuk secara signifikan mengurangi biaya manajemen proyek, mengembangkan dan mendukung proyek. Kita dapat mengatakan bahwa tanpa komunitas tidak ada proyek opensource sama sekali.
Banyak bahan telah ditulis tentang cara membuat dan mengelola komunitas proyek sumber terbuka. Agar tidak menceritakan kembali fakta yang sudah diketahui, saya akan mencoba untuk fokus pada pengalaman Embox. Misalnya, masalah yang sangat menarik adalah proses menciptakan komunitas. Artinya, banyak yang mengatakan bagaimana mengelola komunitas yang ada, tetapi saat-saat penciptaannya kadang-kadang diabaikan, mengingat itu diberikan.
Aturan utama saat membuat proyek opensource komunitas - tidak ada aturan. Maksud saya, tidak ada aturan universal, seperti peluru perak, kalau saja karena proyeknya sangat berbeda. Sangat tidak mungkin untuk menggunakan aturan yang sama ketika membuat komunitas untuk perpustakaan js logging dan beberapa driver yang sangat khusus. Selain itu, pada berbagai tahap pengembangan proyek (dan karena itu komunitas), aturannya berubah.
Embox dimulai sebagai proyek siswa, karena ada akses ke siswa di Departemen Pemrograman Sistem. Bahkan, kami pergi ke komunitas lain. Peserta komunitas ini, para siswa, kami dapat tertarik pada praktik industri yang baik dalam bidang keahlian mereka, karya ilmiah di bidang pemrograman sistem, makalah, dan diploma. Artinya, kami mematuhi salah satu aturan dasar organisasi masyarakat, anggota masyarakat harus mendapatkan sesuatu, dan harga ini harus sesuai dengan kontribusi peserta.
Tahap selanjutnya untuk Embox adalah mencari pengguna pihak ketiga. Sangat penting untuk memahami bahwa pengguna adalah anggota penuh komunitas opensource. Biasanya ada lebih banyak pengguna daripada pengembang. Dan untuk ingin menjadi kontributor proyek, mereka pertama-tama mulai menggunakannya dengan satu atau lain cara.
Pengguna pertama untuk Embox adalah Department of Theoretical Cybernetics. Mereka menyarankan untuk membuat firmware alternatif untuk Lego Mindstorm. Dan meskipun itu masih pengguna lokal (kami bisa bertemu langsung dan mendiskusikan apa yang mereka inginkan). Tapi tetap saja itu pengalaman yang sangat bagus. Misalnya, kami mengembangkan demo yang dapat diperlihatkan kepada orang lain, karena robot itu menyenangkan dan menarik perhatian. Akibatnya, kami memiliki pengguna pihak ketiga yang mulai bertanya apa itu Embox dan bagaimana menggunakannya.
Pada tahap ini, kami harus berpikir tentang dokumentasi, tentang alat komunikasi dengan pengguna. Tidak, tentu saja, kami memikirkan hal-hal penting ini sebelumnya, tetapi itu terlalu dini dan tidak memberikan efek positif. Efeknya agak negatif. Biarkan saya memberi Anda beberapa contoh. Kami menggunakan googlecode, wiki yang mendukung multibahasa. Kami membuat halaman dalam beberapa bahasa, tidak hanya bahasa Inggris dan Rusia, yang komunikasi buruk, tetapi juga Jerman dan Spanyol. Akibatnya, itu tampak sangat konyol ketika ditanya dalam bahasa-bahasa ini, tetapi kami tidak bisa menjawab sama sekali. Atau mereka memperkenalkan aturan untuk menulis dokumentasi dan mengomentari, tetapi karena API berubah cukup sering dan signifikan, ternyata dokumentasi kami sudah ketinggalan zaman dan menyesatkan lebih daripada membantu.
Akibatnya, semua upaya kami, bahkan yang tidak benar, menyebabkan munculnya pengguna eksternal. Dan bahkan seorang pelanggan komersial muncul yang menginginkannya untuk mengembangkan RTOS sendiri. Dan kami mengembangkannya karena kami memiliki pengalaman dan beberapa perkembangan. Di sini Anda perlu berbicara tentang poin baik dan buruk. Saya akan mulai dengan yang buruk. Karena banyak pengembang yang terlibat dalam proyek ini berdasarkan komersial, komunitas, dan karena itu agak tidak stabil, berpisah, yang tentu saja tidak dapat memengaruhi pengembangan proyek. Faktor tambahan adalah bahwa arah proyek ditetapkan oleh satu pelanggan komersial, dan tujuannya bukan pengembangan lebih lanjut dari proyek. Setidaknya tujuan ini bukan yang utama.
Di sisi lain, ada sejumlah poin positif. Kami benar-benar memiliki pengguna pihak ketiga. Bukan hanya pelanggan, tetapi juga mereka yang menjadi sasaran sistem ini. Motivasi untuk berpartisipasi dalam proyek telah berkembang. Lagipula, jika Anda juga bisa menghasilkan uang untuk masalah yang menarik, itu selalu menyenangkan. Dan yang paling penting, kami mendengar satu keinginan pelanggan, yang pada saat itu tampak gila bagi kami, tetapi yang sekarang menjadi ide utama Embox, yaitu, untuk menggunakan kode yang sudah dikembangkan dalam sistem. Gagasan utama Embox sekarang adalah menggunakan perangkat lunak Linux tanpa Linux. Artinya, faktor positif utama yang berkontribusi pada pengembangan proyek lebih lanjut adalah kesadaran bahwa proyek tersebut digunakan oleh pengguna pihak ketiga, dan itu harus menyelesaikan beberapa masalah mereka.
Pada saat itu, Embox sudah berada di luar cakupan proyek siswa. Kendala utama untuk pengembangan proyek menurut model siswa adalah motivasi peserta. Siswa berpartisipasi ketika mereka belajar, dan ketika mereka lulus, motivasi yang berbeda akan muncul. Jika motivasi tidak muncul, siswa tidak lagi berpartisipasi dalam proyek. Jika kita memperhitungkan bahwa siswa harus terlebih dahulu dilatih, ternyata mereka menjadi spesialis yang baik pada saat kelulusan, tetapi kontribusi untuk proyek, karena kurangnya pengalaman, tidak terlalu besar.
Secara umum, kami bergerak dengan lancar ke poin utama, yang memungkinkan kami berbicara tentang membuat proyek opensource - menciptakan produk yang akan menyelesaikan masalah penggunanya. Seperti yang saya jelaskan di atas, properti utama dari proyek opensource adalah komunitasnya. Selain itu, anggota masyarakat terutama adalah pengguna. Tapi dari mana mereka datang sampai apa yang harus digunakan? Jadi ternyata seperti halnya dengan proyek non-opensource, Anda perlu fokus untuk membuat MVP (produk minimum yang layak), dan jika itu menarik minat pengguna, maka komunitas akan muncul di sekitar proyek. Jika Anda hanya terlibat dalam menciptakan komunitas melalui PR komunitas, menulis wiki dalam semua bahasa di dunia, atau alur kerja git yang tepat di github, maka ini tidak mungkin menjadi masalah pada tahap awal proyek. Tentu saja, pada tahap yang tepat, ini tidak hanya penting, tetapi juga hal-hal yang perlu.
Sebagai kesimpulan, saya ingin memberikan
komentar , menurut pendapat saya yang mencerminkan harapan pengguna dari proyek opensource:
Saya serius berpikir untuk beralih ke OS ini (setidaknya mencobanya. Mereka sangat aktif dalam menggergaji dan melakukan hal-hal keren).
PS Di
TechTrain kita akan memiliki sebanyak tiga laporan. Satu tentang open source dan dua tentang embedded (dan satu praktis). Di stand, kami akan melakukan kelas master pada pemrograman mikrokontroler menggunakan
Embox . Secara tradisional, kami akan membawa kelenjar dan membiarkan mereka memprogram. Juga akan ada pencarian dan kegiatan lainnya. Datang ke festival dan stan kami, itu akan menyenangkan.