
Pada
pertemuan komunitas Apache Ignite terakhir di Moskow, saya berbicara tentang:
- Komunitas open source;
- Kekuasaan dan uang dalam sumber terbuka;
- Bagaimana menjadi kontributor dan pengangkut barang, dan mengapa Anda membutuhkannya.
Waktu laporan yang terbatas tidak memungkinkan saya untuk memberikan lebih banyak contoh, jadi saya memposting versi panjangnya di HabrΓ©. Semua hal di atas didasarkan pada pengalaman pribadi saya dan bukan posisi resmi perusahaan atau organisasi mana pun.
Apa itu komunitas?
Ini mungkin tampak jelas, tetapi tetap mari kita perjelas apa yang kami maksud dengan komunitas. Pertama-tama, kita berbicara tentang komunitas online. Ini adalah semacam platform bagi orang untuk berinteraksi satu sama lain. Jika sebuah komunitas didedikasikan, misalnya, untuk kesehatan, kebugaran, dan kegiatan serupa, maka tugasnya mungkin untuk mendukung anggotanya. Atau komunitas dapat membuat barang publik. Ini persis dengan komunitas pengembangan perangkat lunak sumber terbuka. Selain itu, jika Anda memiliki keinginan untuk mengembangkan beberapa jenis perangkat lunak, maka Anda tidak akan menemukan orang dengan tampilan yang sama, misalnya, saat mendarat atau di pintu masuk berikutnya. Ada proyek seperti itu, tetapi biasanya sebagai proyek siswa. Dan komunitas online menghapus penghalang antara benua dan zona waktu, memungkinkan Anda menemukan lebih banyak penggemar.
Yayasan Apache
Sejarah Apache dimulai pada tahun 1999 dengan server web HTTPD: sekelompok orang mulai mengembangkan server web, pengguna mulai mendatangi mereka, beberapa di antaranya mulai mengirim tambalan karena mereka ingin meningkatkan sesuatu dalam produk ini atau memperbaiki bug. Pengembang secara bertahap mulai mengalokasikan anggota paling aktif dari komunitas ini hak untuk mendorong ke repositori, yang sekarang disebut hak berkomitmen.
Menerapkan pendekatan yang sama untuk pengembangan open source, Apache kini telah menjadi organisasi (yayasan) terbesar, yang mengembangkan perangkat lunak open source. Organisasi ini dibagi menjadi 319 (sejauh ini) proyek yang beragam, di mana sekitar 200 di antaranya adalah Tingkat Tertinggi. Tidak ada proses tunggal untuk semua proyek, semua peserta adalah sukarelawan, pekerjaan mereka tidak pernah dibayar oleh organisasi.
Apache tanpa gagal mengharuskan semua proyek memiliki:
- Kebijakan hukum;
- Kebijakan Penggunaan Merek;
- Voting pada adopsi rilis;
- Penggunaan milis;
- Keamanan informasi.
Apache inkubator
Untuk membangun komunitas, semua proyek Apache melalui Apache Incubator tanpa gagal. Ini adalah tahap perantara dalam pengembangan bahkan bukan proyek, tetapi masyarakat di sekitarnya. Tidak seorang pun di Apache akan menentukan teknologi mana yang akan digunakan. Selain itu, mereka bahkan tidak akan meminta keputusan untuk memilih. Tujuan Apache Incubator adalah membangun komunitas yang membuat keputusan bersama. Sangat penting bagi peserta untuk memahami bagaimana dan siapa yang membuat keputusan, di mana mereka dapat berbicara, di mana suara mereka akan didengar. Mengorganisir ASF membantu dengan melampirkan mentor ke proyek.
Proyek Apache Tingkat Atas
Jika sebuah proyek meninggalkan Apache Incubator, itu bisa menjadi proyek tingkat atas. Apache membantu proyek untuk berpartisipasi dalam konferensi, memberikan semua bantuan yang mungkin dalam mempromosikan merek, dan mendukung infrastruktur.
Komunitas proyek tingkat atas menjamin pengguna bahwa:
- Kode dapat digunakan secara legal;
- Kode berkualitas tinggi;
- Keamanan informasi diamati: misalnya, semua rilis ditandatangani;
- Proyek ini akan selalu tersedia untuk pengguna.
Sumber terbuka dan daya
Sekarang mari kita bicara tentang kekuasaan dan uang, dan bagaimana keputusan dibuat. Ini tidak selalu jelas bahkan bagi anggota masyarakat. Ada beberapa peran dalam proyek Apache dan beberapa milis sesuai dengan mereka:
- Pengguna (user@project.apache.org);
- Pengembang (dev@project.apache.org);
- Committer (dev@project.apache.org);
- PMC (private@project.apache.org);
- Ketua PMC (private@project.apache.org).
Selanjutnya, Anda dapat tumbuh dalam kerangka Yayasan Perangkat Lunak Apache, menjadi mentor proyek, membantu proyek lain membangun komunitas.
Semakin tinggi perannya, semakin sedikit orang yang melakukannya, yaitu bentuk piramida terbalik: sebagian besar pengguna, paling sedikit PMC. Biasanya setiap orang tertarik pada peserta yang tumbuh dan memainkan peran yang lebih tinggi.
Tidak seperti perusahaan komersial, di mana staf dan pertumbuhan dibatasi oleh anggaran, open source tidak memilikinya, tidak ada yang membatasi jumlah komiser atau PMC. Grup mengatur dirinya sendiri secara independen.
Pengguna
Pengguna adalah kita semua. Tentunya Anda masing-masing menggunakan beberapa jenis perangkat lunak open source. Penting bagi komunitas bahwa pengguna tidak hanya menggunakan atau memberikan umpan balik dalam bentuk laporan bug atau permintaan fitur, tetapi juga membantu orang lain. Yaitu, dari sudut pandang komunitas, seorang peserta menjadi pengguna hanya ketika dia berlangganan dan merespons daftar pengguna dan membantu orang lain untuk menguasai produk, membagikan pengetahuannya.
Pengembang / Kontributor
Jika pengguna siap berkontribusi pada proyek, maka dengan kontribusi pertama ia akan secara otomatis menjadi kontributor, atau pengembang - ini adalah sinonim. Kontributor berpartisipasi dalam buletin pengembang yang membahas segala sesuatu yang berkaitan dengan kontribusi komunitas. Semua pengembang memengaruhi pengambilan keputusan komunitas, semua mengkritik keputusan dan menawarkan alternatif.
Committer
Jika komunitas percaya bahwa orang tersebut telah memberikan kontribusi yang cukup, ia dapat berhak untuk mendorong ke repositori, yaitu, jumlah minimum pengulas kode-nya dikurangi menjadi nol (meskipun di Apache Ignite, komuter kadang-kadang masih melalui parsing kode). Committer menandatangani ICLA (
Perjanjian Lisensi Kontributor Individu ). Namun, itu juga dapat ditandatangani sebelum menerima komisi. Committer menerima kotak surat di apache.org dan dapat membuat keputusan terkait setiap kontribusi pada proyek.
Anggota PMC
Anggota PMC (Komite Manajemen Proyek) - Anggota komite manajemen proyek. Anggota komunitas ini telah memberikan kontribusi besar pada pengembangan produk dan berhak membuat keputusan pengembangan jangka panjang, mengendalikan proyek, memantau banyak aspek, khususnya, pengambilan keputusan bersama. Ini membantu anggota masyarakat mencapai konsensus. PMC memiliki banyak tanggung jawab di Apache, misalnya, ia dapat memilih untuk menerima rilis. Committer dan kontributor juga bisa, tetapi, tidak seperti mereka, PMC memiliki suara yang mengikat. PMC dapat mengusulkan pengendara atau PMC baru.
Ketua PMC
Ketua PMC adalah jembatan antara Yayasan Perangkat Lunak Apache. Mungkin Ketua PMC tidak memiliki banyak kekuatan dibandingkan dengan Anggota PMC. Tetapi dia harus menyelesaikan masalah dan melaporkan ke Dewan Apache tentang status proyek.
Pengambilan Keputusan: Duokrasi
Apache didominasi oleh prinsip duokrasi (do-ocracy, from do - "do"). Semakin banyak Anda melakukannya, semakin banyak peluang yang harus Anda lakukan, semakin Anda memengaruhi proyek.
Jika suatu keputusan membutuhkan posisi terkoordinasi dari semua peserta, pemungutan suara diambil. Itu berlangsung setidaknya 72 jam untuk semua orang untuk memilih.
Daftar pemilih:
+1: "untuk keputusan itu."
0: "Saya tidak peduli."
-1: "menentang keputusan." Dalam hal ini, Anda perlu mengusulkan sesuatu yang lain dan menjelaskan secara terperinci mengapa Anda memilih menentang.
Ada jenis suara lain:
0: "Saya tidak suka ide itu, tapi itu cocok untuk saya."
-0: "Saya tidak akan ikut campur, tetapi lebih baik tidak melakukan ini."
-0.5: "Saya tidak menyukai ide itu, tetapi saya tidak dapat menemukan argumen rasional yang menentangnya."
++ 1: "Super, mari kita lakukan!"
-0.9: "Saya tidak suka, tetapi jika semua orang mau, saya tidak akan memasukkan tongkat ke roda, silakan."
+0.9: "Idenya keren, saya suka, tapi saya tidak punya waktu / pengetahuan untuk membantu."
Konsensus Malas
Ada kebijakan pengambilan keputusan seperti konsensus malas, atau persetujuan melalui keheningan. Prosedur ini juga berlangsung setidaknya 72 jam. Jika seseorang secara eksplisit menulis: "Saya ingin meneruskan keputusan ini melalui konsensus malas", maka dalam tiga hari, bahkan jika tidak ada yang menjawab, keputusan itu dianggap diterima oleh masyarakat.
Persetujuan oleh mayoritas dan persetujuan oleh konsensus
Voting untuk rilis lebih aktif: dalam hal ini, persetujuan mayoritas anggota masyarakat diperlukan: tiga suara mengikat (dari PMC) "untuk", dan lebih banyak suara "untuk" daripada "melawan".
Konsensus adalah pilihan terbaik: semua mendukung, dengan setidaknya tiga PMC.
Veto
Kontributor yang berkualifikasi, biasanya anggota PMC, dapat memveto itu. Dia memberikan suara -1 untuk memodifikasi kode dan menulis penjelasan terperinci. Tidak ada yang bisa menyiasati solusi anggota PMC tersebut. Anda tidak dapat memveto rilis, tetapi jika hasil edit sangat buruk, misalnya, itu membuat lubang keamanan atau sangat menurunkan kinerja, maka PMC dapat memilih -1. Dan sampai dia menarik veto, tidak mungkin untuk menerapkan suntingan.
Meritokrasi
Prinsip lain yang dekat dengan duokrasi. Secara harfiah, "meritokrasi" berarti "kekuatan yang layak." Dalam open source, ini berarti bahwa jika pengguna, seperti yang diyakini kelompok, telah melakukan cukup banyak untuk komunitas, maka ia dipromosikan menjadi pengendara. Anda mungkin bertanya seberapa adil keputusan ini, apakah selalu benar-benar jujur ββdan seimbang? Ini adalah keputusan yang sangat subyektif oleh semua PMC di komunitas ini. Di komunitas besar, seperti Apache Ignite, kebijakan ini bisa lebih atau kurang diformalkan. Kontribusi manusia tertentu penting, pastikan untuk berpartisipasi aktif dalam buletin untuk pengembang. Tetapi "kecukupan" ditentukan secara individual oleh setiap proyek.
Poin penting adalah kualitas manusia dari peserta. Kebijakan Apache secara eksplisit menyatakan bahwa interaksi orang tersebut dengan peserta lain dievaluasi, bagaimana perilakunya jika dia tidak setuju dengan pendapatnya. Agar seorang anggota dipromosikan menjadi komuter atau PMC, PMC lain harus memberikan suara pada daftar pribadi, dan tidak boleh ada suara "tidak".
Sumber terbuka dan uang
Topik penting ini muncul dengan satu atau lain cara: bagaimana menghasilkan uang dengan produk Yayasan Perangkat Lunak Apache. Organisasi ini memberikan lisensi paling ramah-komersial dari semua yang ada. Anda dapat menjual produk berbasis Apache atau dukungan untuk produk Apache, Anda dapat menggunakannya dalam produk komersial.
Persyaratan penting: harus selalu ada penggunaan gratis produk-produk Apache. Mereka dikelola terlepas dari kepentingan komersial. Ini sedang dipantau oleh PMC.
Komisaris dapat menerima uang dari organisasi pihak ketiga untuk kontribusi pada proyek. Komisaris dapat disewa oleh pihak ketiga. Baru-baru ini, anggota komunitas
memberi tahu Habr bagaimana mereka bekerja dengan komunitas open source Apache Ignite di Sberbank Technologies. Tetapi Yayasan Apache tidak pernah membayar kepada pengendara. Ini adalah posisi berprinsip. Untuk Apache, pengendara selalu merupakan sukarelawan dan seorang individu. Artinya, perusahaan tidak dapat berpartisipasi dalam proyek Apache, hanya satu pengembang yang bisa.
Mengapa dan bagaimana cara bergabung dengan open-source
Mengapa layak untuk mulai berkontribusi pada proyek sumber terbuka?
Ini adalah kesempatan yang baik untuk meningkatkan keterampilan Anda dan mendapatkan reputasi profesional. Perusahaan komersial menghargai partisipasi dalam sumber terbuka. Banyak pengembang terkenal berpartisipasi dalam berbagai proyek, menjadi komiser dan PMC.
Apa yang mencegah orang untuk berpartisipasi dalam sumber terbuka?- "Kamu harus menjadi Olimpiade atau senior dengan 20 tahun pengalaman, kalau tidak aku tidak bisa melakukannya." Bahkan tidak. Apache Ignite adalah proyek yang kompleks, tetapi bahkan di sini Anda dapat menemukan tugas-tugas sederhana. Misalnya, tiket mudah dan tugas untuk menulis dokumentasi yang dirancang untuk menggambarkan proyek dengan lebih baik. Tidak ada tempat di Apache yang mengatakan bahwa untuk menjadi pengalih, Anda perlu menulis kode.
- "Aku butuh bahasa Inggris yang fasih, kalau tidak aku tidak bisa mengatasinya." Mereka yang berpartisipasi dalam daftar dev akan mengonfirmasi: di sana Anda tidak perlu fasih berbahasa Inggris. Selain itu, komunikasi tertulis tidak sama sekali dalam waktu nyata, ada waktu untuk berpikir dan menulis jawaban yang seimbang.
- "Jika saya mengirim komponen saya ke open source, saya tidak akan pernah bisa menggunakannya lagi." Di Apache, ini tidak begitu. Anda dapat terus menggunakan komponen Anda dalam produk komersial, itu hanya akan ada di bawah Yayasan Apache di bawah lisensi Apache.
- "Semua orang akan membaca apa yang saya tulis di Internet." Bahkan di komunitas Apache Ignite, tidak semua orang membaca apa yang kami tulis. Ini seperti lelucon tentang Joe yang sulit ditangkap: tidak ada yang bisa menangkapnya, karena tidak ada yang membutuhkannya. Saya yakin bahwa teman dan kerabat saya tidak membaca apa yang saya tulis di daftar dev, karena mereka tidak peduli.
- "Ini akan menghabiskan seluruh waktu luangku." Ini sebagian benar: partisipasi masyarakat membuat kecanduan. Jika Anda mulai berpartisipasi dalam diskusi, itu akan memakan waktu. Dan saat Anda tumbuh, itu akan membutuhkan lebih banyak. Semakin banyak Anda tahu, semakin banyak yang dapat Anda beri tahu, semakin banyak Anda berpartisipasi dalam pengguna dan dev.list. Tetapi, sekali lagi, tidak ada kewajiban untuk Apache. Masing-masing mengatur keterlibatannya sendiri. Jika Anda dapat membuat satu tambalan, buat satu tambalan. Namun, tidak ada yang akan memaksamu. Bahkan ketika seseorang ditunjuk sebagai komisaris, surat proposal menyatakan bahwa dia tidak diharuskan untuk terlibat lebih dari yang dia mau berikan.
Bagaimana memulainya
Jika Anda ingin berpartisipasi dalam proyek-proyek Apache, Anda akan memerlukan akun di Github, kotak surat, pendaftaran di
Apache JIRA dan, mungkin, di
Wiki . Komunitas mana pun memiliki artikel
Cara Mengkontribusikan Pemula di Apache Ignite.
Adalah bentuk yang baik untuk menulis surat sambutan:
"Halo! Saya ini dan itu. Saya ingin membuat tiket seperti itu, nama panggilan saya di JIRA adalah ini dan itu .
" Surat ini penting dalam hal menugaskan pengguna peran kontributor.
Milis
Untuk berinteraksi dengan anggota lain, Apache memerlukan penggunaan milis. Saya terkadang mendengar ketidakpuasan: mengapa begitu kuno? Ada banyak obrolan, pengirim pesan instan. Ini karena setiap anggota proyek Apache adalah sukarelawan. Dia mungkin memiliki keluarganya sendiri, pekerjaan yang tidak terkait dengan open source, hobinya. Dia tidak bisa mengobrol online. Mungkin dia bisa memeriksa surat setiap tiga hari. Dan dalam situasi seperti itu, milis berfungsi dengan baik.
Juga, jangan lupa bahwa anggota masyarakat tersebar di seluruh dunia. Dan bung
kepada siapa Anda mengajukan pertanyaan, mungkin berada di benua lain dan hanya akan menjawab besok.
Karena itu, kesabaran dan kesopanan adalah kualitas-kualitas yang sangat penting dalam korespondensi dalam milis. Misalnya, di komunitas Apache Ignite, anggota yang berpengalaman tidak akan pernah menulis bahwa mereka tidak setuju dengan Anda, mereka akan menulis bahwa mereka tidak yakin bahwa mereka setuju.
Surat contoh:
Hai, β‘β‘β‘β‘β‘β‘β‘, saya tidak yakin saya setuju, karena ...Komunitas lebih penting daripada kode
Salah satu prinsip Apache: komunitas lebih penting daripada kode. Ini berarti bahwa hal pertama yang ingin dibuat oleh proyek Apache adalah komunitas di sekitar proyek open source. Dan kemudian keajaiban dimulai dan kode yang bagus muncul. Jika Anda tidak setuju dengan surat apa pun, tunda selama 4 jam, baca kembali dan tunda lagi. Lalu ada kemungkinan besar bahwa Anda akan merespons dengan menahan diri, tanpa mendorong anggota komunitas lainnya dengan kata-kata yang ceroboh. Kita semua adalah sukarelawan, dan jika orang tidak nyaman, mereka akan mulai pergi, dan untuk proyek sumber terbuka ini adalah risiko yang sangat serius.
Rekomendasi Korespondensi
Mereka kurang lebih mirip dengan yang digunakan dalam korespondensi bisnis biasa. Jika ada kalimat yang bisa ditafsirkan dengan cara yang salah, itu akan ditafsirkan dengan cara yang salah, terutama mengingat ukuran komunitas. Semua rekomendasi datang ke tiga prinsip dasar: untuk menjadi positif, konstruktif dan hormat.
Contoh surat yang tidak terlalu bagus:
Hai, β‘β‘β‘β‘β‘.
Solusi ini terlihat agak jelek bagi saya.Sebuah permintaan dari saya sebagai anggota daftar dev: menulis surat pendek - tiga paragraf atau 7 kalimat. Kita semua teknisi dan ingin memberikan detail sebanyak mungkin. Tetapi jika jumlahnya terlalu banyak, mungkin ini adalah kesempatan untuk menulis artikel terpisah.
Apa yang harus diselundupkan?
Setiap komunitas memiliki daftar apa yang dibutuhkan saat ini. Ignite memiliki daftar tiket sederhana. Jika Anda menemukan bug saat digunakan dan Anda memperbaikinya di garpu Anda, maka sangat mungkin untuk membuat masalah JIRA untuk bisnis ini, buat permintaan tarik dan tulis ke daftar dev.
Cara melewati tinjauan kode
Meskipun Anda baru mengenal komunitas, Anda tidak mungkin dapat menentukan tiket mana yang menjadi prioritas. Mungkin masuk akal untuk menghubungi orang yang menyertai komponen tersebut, bantuan Anda akan sangat penting baginya. Anda juga dapat menanyakan di daftar dev tiket mana yang lebih penting.
Jika tidak ada jawaban, kami ingat bahwa setiap orang adalah sukarelawan. Mungkin merupakan ide yang baik untuk mengingatkan Anda tentang apa yang Anda usulkan untuk dilakukan dalam tiga hari.
Dalam proyek Apache, termasuk Ignite, tidak ada peran manajer proyek yang akan memantau jaminan simpanan, sehingga tiket yang tidak relevan juga dapat ditemukan di sana. Disarankan agar Anda terlebih dahulu menulis ke daftar dev dan mengklarifikasi.
Fitur lain dari Apache: di perusahaan komersial, mungkin ada kebijakan yang jelas bahwa karyawan dari level tertentu dapat mengakses dan mengedit dokumentasi, tetapi karyawan dari level yang lebih rendah tidak dapat. Tidak ada yang seperti itu di Apache. Jika ada sesuatu untuk dipinjamkan, tidak ada masalah. Saya pikir dalam proyek apa pun Anda tidak akan memiliki masalah dengan memperoleh hak akses, dan tidak masalah jika orang tersebut tidak secara resmi penglaju.
Bicara tentang proyek
Komunitas sangat terbantu dengan artikel produk. Yayasan Perangkat Lunak Apache sendiri membantu dengan konferensi. Anda juga dapat menggambarkan pengalaman Anda, tidak hanya dengan Apache Ignite. Ini bisa menjadi kasus penggunaan yang menarik, karya siswa. Mereka selalu diterbitkan pada daftar dev.