Festival IT akan diadakan di St. Petersburg minggu ini . Salah satu pembicaranya adalah Richard Stallman. juga berpartisipasi dalam festival tersebut, dan tentu saja kami tidak dapat mengabaikan topik perangkat lunak bebas. Itu sebabnya salah satu laporan kami disebut . Ini akan didedikasikan untuk sejarah pengembangan Embox sebagai proyek open source. Pada artikel ini saya ingin berbicara tentang ide-ide utama yang menurut saya mempengaruhi perkembangan proyek opensource. Artikel tersebut, seperti laporannya, didasarkan pada pengalaman pribadi.
Mari kita mulai dengan sesuatu yang sederhana, dengan definisi istilah opensource. Jelasnya, proyek sumber terbuka adalah proyek yang memiliki salah satu lisensi yang mengizinkan akses ke kode sumber proyek tersebut. Selain itu, proyek terbuka berarti pengembang pihak ketiga dapat melakukan perubahan. Artinya, jika suatu perusahaan atau pengembang menerbitkan kode produknya, sebagian atau seluruhnya, hal ini belum menjadikan produk tersebut sebagai proyek sumber terbuka. Dan terakhir, setiap kegiatan proyek harus membuahkan hasil, dan keterbukaan proyek menyiratkan bahwa hasil ini tidak hanya digunakan oleh pengembang itu sendiri.
Kami tidak akan membahas masalah lisensi terbuka. Ini adalah topik yang terlalu besar dan rumit sehingga memerlukan penyelidikan mendalam. Cukup banyak artikel dan materi bagus yang telah ditulis tentang topik ini. Namun karena saya sendiri bukan ahli di bidang hak cipta, saya hanya akan mengatakan bahwa lisensi harus memenuhi tujuan proyek. Misalnya, untuk Embox, pemilihan BSD daripada lisensi GPL bukanlah suatu kebetulan.
Fakta bahwa proyek sumber terbuka harus memberikan kemampuan untuk membuat perubahan dan mempengaruhi perkembangan proyek sumber terbuka menyiratkan bahwa proyek tersebut didistribusikan. Mengelolanya, menjaga integritas dan kinerja jauh lebih sulit dibandingkan proyek dengan manajemen terpusat. Sebuah pertanyaan yang masuk akal muncul: mengapa proyek terbuka? Jawabannya terletak pada bidang kelayakan komersial, untuk kelas proyek tertentu, manfaat pendekatan ini lebih besar daripada biayanya. Artinya, pendekatan ini tidak cocok untuk semua proyek dan pendekatan terbuka secara umum dapat diterima. Misalnya, sulit membayangkan mengembangkan sistem kendali pembangkit listrik atau pesawat terbang berdasarkan prinsip terbuka. Tidak, tentu saja, sistem seperti itu harus menyertakan modul berdasarkan proyek terbuka, karena ini akan memberikan sejumlah keuntungan. Tetapi seseorang harus bertanggung jawab atas produk akhirnya. Bahkan jika sistem sepenuhnya didasarkan pada kode proyek terbuka, pengembang, setelah mengemas semuanya ke dalam satu sistem dan membuat build dan pengaturan tertentu, pada dasarnya menutupnya. Kode ini mungkin tersedia untuk umum.
Ada juga banyak manfaat bagi sistem ini dengan membuat atau berkontribusi pada proyek sumber terbuka. Seperti yang sudah saya katakan, kode sistem akhir mungkin tetap tersedia untuk umum. Mengapa, karena jelas bahwa tidak mungkin ada orang yang memiliki pesawat yang sama untuk menguji sistem tersebut. Ini benar, tetapi mungkin ada seseorang yang ingin memeriksa bagian tertentu 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 sistem ke dalam proyek terpisah. Misalnya perpustakaan untuk mendukung beberapa jenis protokol pertukaran data. Dalam hal ini, meskipun protokolnya khusus untuk bidang subjek tertentu, Anda dapat berbagi biaya pemeliharaan bagian sistem ini dengan perusahaan lain dari bidang ini. Selain itu, spesialis yang dapat mempelajari bagian sistem ini di domain publik memerlukan lebih sedikit waktu untuk menggunakannya secara efektif. Dan terakhir, memisahkan suatu bagian menjadi entitas independen yang digunakan oleh pengembang pihak ketiga memungkinkan kami menjadikan bagian ini lebih baik, karena kami perlu menawarkan API yang efektif, membuat dokumentasi, dan saya bahkan tidak berbicara tentang peningkatan cakupan pengujian.
Sebuah perusahaan dapat menerima keuntungan komersial tanpa membuat proyek sumber terbuka, cukup bagi spesialisnya untuk berpartisipasi dalam proyek pihak ketiga yang digunakan di perusahaan. Bagaimanapun, semua manfaatnya tetap ada: karyawan mengetahui proyek dengan lebih baik, oleh karena itu mereka menggunakannya dengan lebih efektif, perusahaan dapat mempengaruhi arah pengembangan proyek, dan penggunaan kode yang sudah jadi dan di-debug jelas mengurangi biaya perusahaan.
Manfaat membuat proyek sumber terbuka tidak hanya sampai disitu. Mari kita ambil komponen bisnis yang penting seperti pemasaran. Baginya, ini adalah kotak pasir yang sangat bagus yang memungkinkan dia mengevaluasi kebutuhan pasar secara efektif.
Dan tentu saja, kita tidak boleh lupa bahwa proyek sumber terbuka adalah cara efektif untuk menyatakan diri Anda sebagai pembawa spesialisasi apa pun. Dalam beberapa kasus, ini adalah satu-satunya cara untuk memasuki pasar. Misalnya, Embox dimulai sebagai proyek untuk membuat RTOS. Mungkin tidak perlu dijelaskan bahwa ada banyak pesaing. Tanpa menciptakan komunitas, kami tidak akan memiliki sumber daya yang cukup untuk membawa proyek ke pengguna akhir, yaitu pengembang pihak ketiga untuk mulai menggunakan proyek tersebut.
Komunitas adalah kunci dalam proyek sumber terbuka. Hal ini memungkinkan Anda untuk secara signifikan mengurangi biaya manajemen proyek, mengembangkan dan mendukung proyek. Kita dapat mengatakan bahwa tanpa komunitas tidak ada proyek open source sama sekali.
Banyak materi telah ditulis tentang cara membuat dan mengelola komunitas proyek sumber terbuka. Agar tidak menceritakan kembali fakta yang sudah diketahui, saya akan mencoba fokus pada pengalaman Embox. Misalnya, proses pembentukan komunitas merupakan isu yang sangat menarik. Artinya, banyak yang menceritakan bagaimana mengelola komunitas yang sudah ada, namun momen-momen pembentukannya terkadang terabaikan, mengingat hal tersebut lumrah.
Aturan utama saat membuat komunitas proyek sumber terbuka adalah tidak ada aturan. Maksud saya, tidak ada aturan universal, sama seperti tidak ada solusi jitu, hanya karena proyeknya sangat berbeda. Kecil kemungkinan Anda dapat menggunakan aturan yang sama saat membuat komunitas untuk perpustakaan logging js dan beberapa driver yang sangat terspesialisasi. Selain itu, pada berbagai tahap pengembangan proyek (dan juga komunitas), peraturannya berubah.
Embox dimulai sebagai proyek siswa karena memiliki akses ke siswa dari departemen pemrograman sistem. Faktanya, kami memasuki komunitas lain. Kami dapat menarik minat para peserta komunitas ini, mahasiswa, dalam praktik industri yang baik di bidang spesialisasi mereka, karya ilmiah di bidang pemrograman sistem, kursus dan diploma. Artinya, kami mengikuti salah satu aturan dasar pengorganisasian komunitas: anggota komunitas harus menerima sesuatu, dan harga tersebut harus sesuai dengan kontribusi peserta.
Tahap selanjutnya untuk Embox adalah pencarian pengguna pihak ketiga. Sangat penting untuk dipahami bahwa pengguna adalah peserta penuh dalam komunitas sumber terbuka. Biasanya ada lebih banyak pengguna daripada pengembang. Dan agar ingin menjadi kontributor suatu proyek, pertama-tama mereka mulai menggunakannya dengan satu atau lain cara.
Pengguna pertama Embox adalah Departemen Sibernetika Teoritis. Mereka menyarankan untuk membuat firmware alternatif untuk Lego Mindstorm. Meskipun mereka masih merupakan pengguna lokal (kami dapat bertemu langsung dengan mereka dan mendiskusikan apa yang mereka inginkan). Tapi itu masih merupakan pengalaman yang sangat bagus. Misalnya, kami mengembangkan demo yang dapat diperlihatkan kepada orang lain, karena robot itu menyenangkan dan menarik perhatian. Hasilnya, kami mendapatkan pengguna pihak ketiga yang mulai bertanya apa itu Embox dan bagaimana cara menggunakannya.
Pada tahap ini, kami harus memikirkan tentang dokumentasi, tentang sarana komunikasi dengan pengguna. Tidak, tentu saja kami sudah memikirkan hal-hal penting ini sebelumnya, namun itu terlalu dini dan tidak memberikan efek positif. Dampaknya agak negatif. Izinkan saya memberi Anda beberapa contoh. Kami menggunakan Googlecode, yang wiki-nya mendukung multibahasa. Kami membuat halaman dalam beberapa bahasa, tidak hanya bahasa Inggris dan Rusia, yang sulit kami komunikasikan, tetapi juga bahasa Jerman dan Spanyol. Alhasil, terlihat sangat konyol jika ditanya dalam bahasa tersebut, namun kami tidak bisa menjawabnya sama sekali. Atau mereka memperkenalkan aturan tentang penulisan dokumentasi dan komentar, namun karena API cukup sering berubah dan signifikan, ternyata dokumentasi kami sudah ketinggalan zaman dan lebih menyesatkan daripada membantu.
Akibatnya, semua upaya kami, bahkan yang salah, berujung pada munculnya pengguna eksternal. Dan bahkan muncul pelanggan komersial yang ingin RTOS miliknya dikembangkan untuknya. Dan kami mengembangkannya karena kami memiliki pengalaman dan landasan. Di sini Anda perlu membicarakan momen baik dan buruk. Saya akan mulai dengan yang buruk. Karena banyak pengembang yang terlibat dalam proyek ini secara komersial, komunitas sudah cukup tidak stabil dan terpecah, yang tentu saja mempengaruhi perkembangan proyek. Faktor tambahannya adalah arah proyek ditentukan oleh satu pelanggan komersial, dan tujuannya bukanlah pengembangan proyek lebih lanjut. Setidaknya ini bukanlah tujuan utamanya.
Di sisi lain, ada sejumlah aspek positif. Kami benar-benar mendapatkan pengguna pihak ketiga. Bukan hanya pelanggannya, tetapi juga mereka yang menjadi tujuan sistem ini. Motivasi untuk berpartisipasi dalam proyek ini meningkat. Lagi pula, jika Anda juga bisa menghasilkan uang dari bisnis yang menarik, itu selalu menyenangkan. Dan yang terpenting, kami mendengar satu keinginan dari pelanggan, yang pada saat itu tampak gila bagi kami, namun kini menjadi ide utama Embox, yaitu menggunakan kode yang sudah dikembangkan dalam sistem. Sekarang ide utama Embox adalah menggunakan software Linux tanpa Linux. Artinya, aspek positif utama yang berkontribusi terhadap pengembangan proyek lebih lanjut adalah kesadaran bahwa proyek tersebut digunakan oleh pengguna pihak ketiga, dan ini akan menyelesaikan beberapa masalah mereka.
Pada saat itu, Embox sudah melampaui lingkup proyek mahasiswa. Faktor pembatas utama dalam pengembangan proyek model siswa adalah motivasi peserta. Mahasiswa berpartisipasi saat belajar, dan ketika lulus harus ada motivasi yang berbeda. Jika motivasi tidak muncul, siswa berhenti berpartisipasi dalam proyek. Jika kita memperhitungkan bahwa siswa perlu dilatih terlebih dahulu, ternyata mereka sudah menjadi spesialis yang baik pada saat mereka lulus, namun kontribusi mereka terhadap proyek tersebut, karena kurangnya pengalaman, tidak terlalu besar.
Secara umum, kami dengan lancar beralih ke poin utama yang memungkinkan kami berbicara tentang pembuatan proyek sumber terbuka - pembuatan produk yang akan memecahkan masalah penggunanya. Seperti yang saya jelaskan di atas, properti utama proyek opensource adalah komunitasnya. Selain itu, anggota komunitas pada dasarnya adalah pengguna. Tapi dari mana asalnya jika tidak ada yang bisa digunakan? Jadi ternyata, seperti halnya proyek non-opensource, Anda harus fokus pada pembuatan MVP (produk minimum yang layak), dan jika menarik minat pengguna, maka akan muncul komunitas di sekitar proyek tersebut. Jika Anda terlibat dalam pembuatan komunitas hanya melalui PR komunitas, menulis wiki dalam semua bahasa di dunia, atau memperbaiki alur kerja git di github, maka hal ini tidak akan menjadi masalah pada tahap awal proyek. Tentu saja, pada tahapan yang tepat, hal ini tidak hanya penting, tetapi juga perlu.
Sebagai kesimpulan, saya ingin menunjukkan , menurut pendapat saya, mencerminkan ekspektasi pengguna dari proyek sumber terbuka:
Saya serius berpikir untuk beralih ke OS ini (setidaknya cobalah. Mereka secara aktif mengejarnya dan melakukan hal-hal keren).
PS Aktif Kami akan memiliki sebanyak tiga laporan. Satu tentang open source dan dua tentang embedded (dan satu lagi praktis). Di stand tersebut kami akan mengadakan kelas master pemrograman mikrokontroler menggunakan . Seperti biasa, kami akan membawa perangkat kerasnya dan membiarkan Anda memprogramnya. Juga akan ada pencarian dan kegiatan lainnya. Datanglah ke festival dan stand kami, pasti menyenangkan.
Sumber: www.habr.com