Satu festival IT akan diadakan di St. Petersburg minggu ini . Salah seorang penceramah ialah Richard Stallman. juga mengambil bahagian dalam festival itu, dan sudah tentu kita tidak boleh mengabaikan topik perisian percuma. Itulah sebabnya salah satu laporan kami dipanggil . Ia akan didedikasikan untuk sejarah pembangunan Embox sebagai projek sumber terbuka. Dalam artikel ini saya ingin bercakap tentang idea utama yang, pada pendapat saya, mempengaruhi pembangunan projek sumber terbuka. Artikel itu, seperti laporan itu, adalah berdasarkan pengalaman peribadi.
Mari kita mulakan dengan sesuatu yang mudah, dengan definisi istilah sumber terbuka. Jelas sekali, projek sumber terbuka ialah projek yang mempunyai salah satu lesen yang membenarkan akses kepada kod sumber projek itu. Selain itu, projek terbuka bermakna pembangun pihak ketiga boleh membuat perubahan. Iaitu, jika sesetengah syarikat atau pembangun menerbitkan kod produknya, sebahagian atau sepenuhnya, ini belum lagi menjadikan produk ini sebagai projek sumber terbuka. Dan akhirnya, sebarang aktiviti projek mesti membawa kepada beberapa jenis hasil, dan keterbukaan projek membayangkan bahawa hasil ini digunakan bukan sahaja oleh pemaju sendiri.
Kami tidak akan menyentuh masalah lesen terbuka. Ini adalah topik yang terlalu besar dan kompleks yang memerlukan penyiasatan mendalam. Banyak artikel dan bahan yang bagus telah ditulis mengenai topik ini. Tetapi oleh kerana saya sendiri bukan pakar dalam bidang hak cipta, saya hanya akan mengatakan bahawa lesen mesti memenuhi matlamat projek. Sebagai contoh, untuk Embox, pilihan BSD dan bukannya lesen GPL tidak disengajakan.
Hakikat bahawa projek sumber terbuka harus menyediakan keupayaan untuk membuat perubahan dan mempengaruhi pembangunan projek sumber terbuka membayangkan bahawa projek itu diedarkan. Menguruskannya, mengekalkan integriti dan prestasi adalah lebih sukar berbanding projek dengan pengurusan berpusat. Persoalan yang munasabah timbul: mengapa projek terbuka sama sekali? Jawapannya terletak pada bidang kebolehlaksanaan komersial; untuk kelas projek tertentu, faedah pendekatan ini melebihi kos. Iaitu, ia tidak sesuai untuk semua projek dan pendekatan terbuka secara amnya boleh diterima. Sebagai contoh, sukar untuk membayangkan membangunkan sistem kawalan untuk loji kuasa atau pesawat berdasarkan prinsip terbuka. Tidak, sudah tentu, sistem sedemikian harus memasukkan modul berdasarkan projek terbuka, kerana ini akan memberikan beberapa kelebihan. Tetapi seseorang mesti bertanggungjawab untuk produk akhir. Walaupun sistem sepenuhnya berdasarkan kod projek terbuka, pembangun, setelah membungkus semuanya ke dalam satu sistem dan membuat binaan dan tetapan khusus, pada dasarnya menutupnya. Kod itu mungkin tersedia secara umum.
Terdapat juga banyak faedah untuk sistem ini daripada mencipta atau menyumbang kepada projek sumber terbuka. Seperti yang telah saya katakan, kod sistem akhir mungkin kekal tersedia secara terbuka. Mengapa, kerana ia adalah jelas bahawa tidak mungkin sesiapa akan mempunyai pesawat yang sama untuk menguji sistem. Ini benar, tetapi mungkin ada seseorang yang ingin menyemak bahagian tertentu kod, atau, sebagai contoh, seseorang mungkin mendapati bahawa perpustakaan yang digunakan tidak dikonfigurasikan dengan betul.
Manfaat yang lebih besar muncul jika syarikat memperuntukkan beberapa bahagian asas sistem ke dalam projek yang berasingan. Sebagai contoh, perpustakaan untuk menyokong beberapa jenis protokol pertukaran data. Dalam kes ini, walaupun protokol adalah khusus untuk kawasan subjek tertentu, anda boleh berkongsi kos penyelenggaraan bahagian sistem ini dengan syarikat lain dari kawasan ini. Di samping itu, pakar yang boleh mengkaji bahagian sistem ini dalam domain awam memerlukan lebih sedikit masa untuk menggunakannya dengan berkesan. Dan akhirnya, mengasingkan bahagian menjadi entiti bebas yang digunakan oleh pembangun pihak ketiga membolehkan kami menjadikan bahagian ini lebih baik, kerana kami perlu menawarkan API yang berkesan, mencipta dokumentasi dan saya tidak bercakap tentang meningkatkan liputan ujian.
Sebuah syarikat boleh menerima faedah komersil tanpa membuat projek sumber terbuka; ia cukup untuk pakarnya untuk mengambil bahagian dalam projek pihak ketiga yang digunakan dalam syarikat. Lagipun, semua faedah kekal: pekerja mengetahui projek itu dengan lebih baik, oleh itu mereka menggunakannya dengan lebih berkesan, syarikat boleh mempengaruhi hala tuju pembangunan projek, dan penggunaan kod siap pakai, nyahpepijat jelas mengurangkan kos syarikat.
Faedah mencipta projek sumber terbuka tidak berakhir di situ. Mari kita ambil komponen penting dalam perniagaan sebagai pemasaran. Baginya, ini adalah kotak pasir yang sangat baik yang membolehkannya menilai keperluan pasaran dengan berkesan.
Dan sudah tentu, kita tidak boleh lupa bahawa projek sumber terbuka adalah cara yang berkesan untuk mengisytiharkan diri anda sebagai pembawa mana-mana pengkhususan. Dalam sesetengah kes, ini adalah satu-satunya cara untuk memasuki pasaran. Sebagai contoh, Embox bermula sebagai projek untuk mencipta RTOS. Mungkin tidak perlu dijelaskan bahawa terdapat banyak pesaing. Tanpa mewujudkan komuniti, kami tidak akan mempunyai sumber yang mencukupi untuk membawa projek kepada pengguna akhir, iaitu, untuk pembangun pihak ketiga mula menggunakan projek itu.
Komuniti adalah kunci dalam projek sumber terbuka. Ia membolehkan anda mengurangkan dengan ketara kos pengurusan projek, membangun dan menyokong projek. Kita boleh mengatakan bahawa tanpa komuniti tidak ada projek sumber terbuka sama sekali.
Banyak bahan telah ditulis tentang cara mencipta dan mengurus komuniti projek sumber terbuka. Untuk tidak menceritakan semula fakta yang telah diketahui, saya akan cuba memberi tumpuan kepada pengalaman Embox. Sebagai contoh, proses mewujudkan komuniti adalah isu yang sangat menarik. Iaitu, ramai yang memberitahu bagaimana untuk menguruskan komuniti yang sedia ada, tetapi detik-detik penciptaannya kadang-kadang diabaikan, memandangkan ini adalah sesuatu yang diberikan.
Peraturan utama semasa mencipta komuniti projek sumber terbuka ialah tiada peraturan. Maksud saya tidak ada peraturan sejagat, sama seperti tiada peluru perak, jika hanya kerana projeknya sangat berbeza. Tidak mungkin anda boleh menggunakan peraturan yang sama semasa membuat komuniti untuk perpustakaan pengelogan js dan beberapa pemandu yang sangat khusus. Lebih-lebih lagi, pada peringkat pembangunan projek yang berbeza (dan oleh itu komuniti), peraturan berubah.
Embox bermula sebagai projek pelajar kerana ia mempunyai akses kepada pelajar dari jabatan pengaturcaraan sistem. Sebenarnya, kami memasuki beberapa komuniti lain. Kami boleh menarik minat peserta komuniti ini, pelajar, dalam amalan industri yang baik dalam kepakaran mereka, kerja saintifik dalam bidang pengaturcaraan sistem, kerja kursus dan diploma. Iaitu, kami mengikuti salah satu peraturan asas menganjurkan komuniti: ahli komuniti mesti menerima sesuatu, dan harga ini mesti sepadan dengan sumbangan peserta.
Peringkat seterusnya untuk Embox ialah pencarian pengguna pihak ketiga. Adalah sangat penting untuk memahami bahawa pengguna adalah peserta penuh dalam komuniti sumber terbuka. Biasanya terdapat lebih ramai pengguna daripada pembangun. Dan untuk mahu menjadi penyumbang kepada projek, mereka mula-mula mula menggunakannya dalam satu cara atau yang lain.
Pengguna pertama Embox ialah Jabatan Sibernetik Teoritikal. Mereka mencadangkan mencipta perisian tegar alternatif untuk Lego Mindstorm. Dan walaupun ini masih pengguna tempatan (kita boleh berjumpa dengan mereka secara peribadi dan membincangkan perkara yang mereka mahukan). Tetapi ia masih merupakan pengalaman yang sangat baik. Sebagai contoh, kami membangunkan demo yang boleh ditunjukkan kepada orang lain, kerana robot menyeronokkan dan menarik perhatian. Hasilnya, kami mendapat pengguna pihak ketiga yang benar-benar mula bertanya apa itu Embox dan cara menggunakannya.
Pada peringkat ini, kami perlu memikirkan tentang dokumentasi, tentang cara komunikasi dengan pengguna. Tidak, sudah tentu, kami memikirkan perkara-perkara penting ini sebelum ini, tetapi ia adalah pramatang dan tidak memberi kesan positif. Kesannya agak negatif. Biar saya berikan anda beberapa contoh. Kami menggunakan googlecode, yang wikinya menyokong multibahasa. Kami mencipta halaman dalam beberapa bahasa, bukan sahaja bahasa Inggeris dan Rusia, di mana kami hampir tidak dapat berkomunikasi, tetapi juga bahasa Jerman dan Sepanyol. Akibatnya, ia kelihatan sangat tidak masuk akal apabila ditanya dalam bahasa-bahasa ini, tetapi kami tidak dapat menjawab sama sekali. Atau mereka memperkenalkan peraturan tentang menulis dokumentasi dan mengulas, tetapi memandangkan API berubah agak kerap dan ketara, ternyata dokumentasi kami sudah lapuk dan lebih mengelirukan daripada membantu.
Akibatnya, semua usaha kami, walaupun yang salah, membawa kepada kemunculan pengguna luar. Malah seorang pelanggan komersial muncul yang mahu RTOS sendiri dibangunkan untuknya. Dan kami membangunkannya kerana kami mempunyai pengalaman dan beberapa asas. Di sini anda perlu bercakap tentang kedua-dua detik baik dan buruk. Saya akan mulakan dengan yang buruk. Memandangkan ramai pemaju terlibat dalam projek ini secara komersial, masyarakat sudah agak tidak stabil dan berpecah belah, yang tentunya tidak boleh tidak menjejaskan pembangunan projek. Faktor tambahan ialah hala tuju projek itu ditetapkan oleh seorang pelanggan komersil, dan matlamatnya bukanlah pembangunan lanjut projek itu. Sekurang-kurangnya ini bukan matlamat utama.
Sebaliknya, terdapat beberapa aspek positif. Kami mendapat pengguna pihak ketiga yang benar-benar. Ia bukan sahaja pelanggan, tetapi juga mereka yang bertujuan untuk sistem ini. Motivasi untuk menyertai projek telah meningkat. Lagipun, jika anda juga boleh menjana wang daripada perniagaan yang menarik, ia sentiasa bagus. Dan yang paling penting, kami mendengar satu keinginan daripada pelanggan, yang pada masa itu kelihatan gila kepada kami, tetapi yang kini menjadi idea utama Embox, iaitu, menggunakan kod yang telah dibangunkan dalam sistem. Kini idea utama Embox adalah menggunakan perisian Linux tanpa Linux. Iaitu, aspek positif utama yang menyumbang kepada pembangunan selanjutnya projek adalah kesedaran bahawa projek itu digunakan oleh pengguna pihak ketiga, dan ia harus menyelesaikan beberapa masalah mereka.
Pada masa itu, Embox telah pun melangkaui skop projek pelajar. Faktor penghad utama dalam pembangunan projek mengikut model pelajar ialah motivasi peserta. Pelajar mengambil bahagian semasa mereka belajar, dan apabila mereka tamat pengajian, harus ada motivasi yang berbeza. Jika motivasi tidak muncul, pelajar hanya berhenti mengambil bahagian dalam projek. Jika kita mengambil kira bahawa pelajar perlu dilatih terlebih dahulu, ternyata mereka menjadi pakar yang baik pada masa mereka menamatkan pengajian, tetapi sumbangan mereka kepada projek itu, kerana kurang pengalaman, tidak begitu besar.
Secara umum, kami lancar beralih ke perkara utama yang membolehkan kami bercakap tentang mencipta projek sumber terbuka - mencipta produk yang akan menyelesaikan masalah penggunanya. Seperti yang saya jelaskan di atas, harta utama projek sumber terbuka ialah komunitinya. Selain itu, ahli komuniti terutamanya pengguna. Tetapi dari mana mereka datang apabila tiada apa-apa untuk digunakan? Jadi ternyata, sama seperti projek bukan sumber terbuka, anda perlu menumpukan pada mencipta MVP (produk berdaya maju minimum), dan jika ia menarik minat pengguna, maka komuniti akan muncul di sekitar projek itu. Jika anda terlibat dalam mewujudkan komuniti hanya melalui PR komuniti, menulis wiki dalam semua bahasa di dunia, atau membetulkan aliran kerja git pada github, maka ini tidak mungkin penting pada peringkat awal projek. Sudah tentu, pada peringkat yang sesuai ini bukan sahaja penting, tetapi juga perkara yang perlu.
Kesimpulannya saya ingin nyatakan , pada pendapat saya, mencerminkan jangkaan pengguna daripada projek sumber terbuka:
Saya serius memikirkan tentang beralih kepada OS ini (sekurang-kurangnya cuba. Mereka giat mengejarnya dan melakukan perkara yang menarik).
PS Dihidupkan Kami akan mempunyai sebanyak tiga laporan. Satu tentang sumber terbuka dan dua tentang terbenam (dan satu lagi praktikal). Di tempat berdiri kami akan menjalankan kelas induk mengenai pengaturcaraan mikropengawal menggunakan . Seperti biasa, kami akan membawa perkakasan dan membenarkan anda memprogramkannya. Terdapat juga pencarian dan aktiviti lain. Datanglah ke festival dan pendirian kami, pasti menyeronokkan.
Sumber: www.habr.com