Bagaimana cara menangani pertumbuhan proyek sumber terbuka?

Saya telah terlibat dalam membantu melakukan dukungan untuk proyek open source selama satu atau dua tahun sekarang, dan proyek ini telah mendapatkan banyak popularitas sejak saya mulai. Program ini melihat lebih dari 100.000 unduhan per minggu, dan digunakan oleh lebih dari 60% orang di bidang utamanya, jadi kami jelas senang bahwa orang-orang sangat menikmati menggunakannya.

Namun, masalahnya adalah bahwa basis pengembangan dan dukungan belum tumbuh hampir secepat, dan kami mulai mengalami beberapa kesulitan. Sejumlah kecil pengembang (pengembang utama khususnya) semakin melebar, dan sukarelawan pendukung teknologi mulai kehabisan tenaga.

Sejauh ini, sudah cukup banyak dudes nongkrong di IRC, menulis program ini dan membantu pengguna. Tidak ada 501 (c) (3) organisasi atau LLC atau sesuatu seperti itu.

Saat ini, kami tidak memiliki pelacak bug atau database masalah yang sangat formal (kami memiliki forum dengan kategori yang didedikasikan untuk laporan bug), yang saya akui adalah sesuatu yang bisa kami tingkatkan untuk mendapatkan lebih banyak pengembang. Tetapi saya kira pertanyaan saya yang sebenarnya adalah, bagaimana seseorang melakukan transisi dari proyek pribadi kecil menjadi ... hal yang nyata ? Bagaimana anak-anak besar seperti GIMP, FFmpeg, Blender, dll menangani transisi ini?

Dan di atas semua ini, adakah cara untuk menawarkan kompensasi dengan proyek FOSS? Saya kira sumbangan membantu, tetapi itu hanya berjalan sejauh ... tampaknya aneh mencari nafkah dari perangkat lunak bebas, tetapi jika program akan terus menjadi lebih baik, saya tidak melihat bagaimana kita dapat melanjutkan tanpa memberi kompensasi kepada orang-orang untuk pekerjaan penuh waktu.

Pada dasarnya, kita mengalami rasa sakit yang tumbuh, dan merasa "terlalu besar untuk masalah kita." Apa yang bisa kita lakukan untuk mengelola transisi ini dan tidak merasa lelah melakukan terlalu banyak hal sekaligus?

open-source project-management

— Ben Torell
sumber

hal pertama yang pertama adalah menjalankan pelacak bug yang tepat dan berjalan, tidak ada sumber terbuka yang akan bertahan tanpa kecuali tim inti sangat baik. Juga pastikan arah fitur jelas dan tidak merayap pada Anda.

— ratchet freak

Jika Anda tidak keberatan saya bertanya, apa proyeknya?

— Robert Harvey

Saya ragu untuk menyebutkan nama proyek, sebagian karena itu sedikit menakutkan pergi ke sana dan mengatakan kepada orang-orang "Hei, kami tidak begitu yakin apa yang kami lakukan, dan kami butuh bantuan!" Juga, saya tidak ingin posting ini muncul sebagai iklan untuk bantuan dengan proyek ini. Saya yakin bahwa beberapa internet sleuthing sepintas akan mengungkapkannya. : /

— Ben Torell

Jawaban:

Tahap proyek Anda adalah sangat menarik dan penting, sangat mudah untuk crash (terbakar) tetapi juga di mana Anda dapat membuat beberapa keputusan penting yang, jika semuanya berfungsi, akan membantu memastikan kelangsungan hidup jangka panjang.

Berikut adalah beberapa saran.

Baca buku hebat Karl Fogel, Memproduksi Perangkat Lunak Sumber Terbuka . Dia membahas sebagian besar masalah langsung utama. Meskipun saya tidak setuju dengan semua yang dia katakan, itu hanya pendapat. Dia benar-benar memahami dunia open source.
Seperti yang dikatakan @Ross Patterson, Anda harus benar-benar membuat pelacak dan milis atau yang serupa untuk menghindari kekacauan total. Apa yang Anda gunakan untuk kontrol versi? Jika Anda menggunakan github, Anda dapat mulai dengan pelacak mereka atau Anda dapat berintegrasi dengan Jira atau yang serupa atau jika Anda mau, Anda dapat pergi ke SourceForge untuk saat ini dan menggunakan infrastruktur gratis mereka. Anda tidak mengatakan dari mana orang-orang mengunduh tetapi Anda ingin memastikan bahwa Anda telah mengaturnya dengan cara yang dapat diandalkan dan dengan penghitungan unduhan yang baik.
Tidak ada alasan bahwa Anda tidak dapat mencari nafkah dengan perangkat lunak gratis jika itu yang Anda inginkan, banyak orang melakukannya, tetapi dibutuhkan banyak bentuk yang berbeda. Anda perlu memutuskan bagaimana Anda ingin melakukan itu sebelum membuat keputusan organisasi yang besar. Misalnya, Anda dapat dan mungkin harus mendirikan perusahaan untuk memegang merek dagang dan hak cipta yang juga akan memberikan perlindungan hukum jika diperlukan. Namun kemudian Anda akan membutuhkan presiden atau bendahara. Organisasi seperti apa yang seharusnya (nirlaba atau untuk laba, LLC, co-op, kemitraan) benar-benar tergantung pada tujuan Anda dan harus didiskusikan dengan pengacara yang baik. Jika Anda diterima oleh Software Freedom Conservacy, mereka akan membantu Anda mengetahuinya dan juga membantu masalah akuntansi dan pajak, dan sebagainya. Ada juga beberapa inkubator FOSS lainnya sepertiPerangkat Lunak untuk Kepentingan Umum . Juga, saya pikir Outercurve adalah suatu kemungkinan.
Dalam hal bagaimana Anda mencari nafkah, ini akan sangat tergantung pada sifat proyek Anda. Ini juga mengapa saya tidak langsung mengatakan bahwa Anda membutuhkan 501c3 (dan Anda mungkin tidak mendapatkannya ... lihat proyek Yorba). Blender mendukung dirinya sendiri terutama dengan menjual dokumentasi. Proyek lain memiliki ekosistem bisnis kecil dan / atau konsultasi di sekitarnya dan pengembang mendapatkan penghasilan dari itu. Proyek-proyek lain flat out memiliki model lisensi ganda sehingga mereka menjual versi yang didukung (itu sebabnya MySQL melakukannya dan mengapa itu bisa dijual ke Sun dan tentu saja ada RedHat) dan memiliki rilis komedi terpisah. Lainnya seperti WordPress memiliki versi yang dihosting sebagai model bisnis. Jadi ada semua jenis opsi dan Anda perlu mencari tahu apa yang masuk akal untuk Anda dan komunitas Anda.
Pilih seseorang sekarang untuk menjadi manajer komunitas Anda untuk memulai. Dan baca buku Jono Bacon setelah Anda menyelesaikan buku Fogel.
Putuskan sekarang pada peta jalan yang masuk akal untuk tim inti Anda; realistislah dan jangan diganggu oleh orang-orang yang tidak berkontribusi. Peta jalan tidak hanya berarti rencana dan fitur teknis, ini tentang ke mana Anda ingin pergi sebagai proyek.
Jangan malu berbicara dengan proyek lain yang Anda kagumi atau yang berada di ruang yang sama dalam hal ini. Cari tahu apa yang berhasil dan tidak berhasil untuk mereka. Cukup kirim email. Juga, Anda dapat pergi ke beberapa acara umum open source dan hanya berbicara dengan proyek lain. Secara keseluruhan, orang-orang sangat membantu.

Semoga beruntung, ini hal yang mengasyikkan untuk berada di tahap ini.

— Elin
sumber

Terima kasih! Kode sudah di-host di Github (yang juga merupakan tempat rilis di-host), tapi kami benar-benar tidak suka pelacak masalah Github ... salah satu orang di tim memiliki pengalaman dengan Mantis jadi saya pikir kita akan menggunakan bahwa. Saya juga mendengar Anda tentang peta jalan ... paling tidak, memiliki peta jalan publik akan menyenangkan hanya untuk merujuk pengguna yang sedang berteriak-teriak untuk fitur tertentu, sehingga kami dapat memberi tahu mereka ketika fitur tersebut datang relatif terhadap fitur lainnya. Saya menjelajahi Outercurve tadi malam, dan saya akan memeriksa yang lain juga, serta buku-buku. Terima kasih atas dorongannya!

— Ben Torell

@ BenTorell, saya memberi tahu siapa pun yang bertanya, "Setiap pelacak bug menyebalkan, satu-satunya pertanyaan adalah, 'Yang mana yang paling menyebalkan sehubungan dengan proses Anda?'".

— Ross Patterson

Ross sepenuhnya benar. Saya sangat tidak suka pelacak Github karena sejumlah alasan, tetapi terutama karena kurangnya ACL yang sebenarnya. Saya setuju menemukan satu yang cocok dengan proses Anda. Banyak pelacak tidak bekerja dengan baik untuk proyek yang didorong oleh sukarelawan karena mereka membuat semua jenis asumsi yang masuk akal dalam pengaturan komersial, bahkan dalam kosakata yang mereka gunakan. Tentu saja, berbicara tentang apa sebenarnya proses Anda adalah latihan yang baik. Jangan mencoba menggunakan pelacak untuk membuat perubahan yang tidak realistis dalam proses Anda. Semuanya benar-benar berbeda ketika itu semua adalah sukarelawan.

— Elin

Anak laki-laki BENAR-BENAR besar mengatur semua mekanisme yang Anda tahu - mereka menjalankan peternakan server besar, mereka menjalankan (kadang-kadang menulis) pelacak bug dan membangun sistem, dll. Mereka sering memiliki 501 (c) 3 yayasan yang memiliki hak cipta, dll. Mereka dapatkan donasi perusahaan besar, dan perusahaan meminjamkan mereka pengembang, dll. Anda tahu, hal-hal BESAR.

Anak laki-laki yang tidak terlalu besar mendapatkan banyak bantuan dari tempat lain. The Software Freedom Conservancy , misalnya, akan membantu proyek cukup-besar mendapatkan dasar-dasar hukum mereka benar, dan memfasilitasi donasi. Ada banyak opsi untuk hosting kode dan pelacakan bug akhir-akhir ini - huh, siapa pun bisa mendapatkan situs GitHub. Dan Anda akan menemukan bahwa banyak perusahaan perangkat lunak kecil hingga menengah akan menyumbangkan lisensi untuk produk eksklusif mereka untuk mendukung proyek Open Source yang terorganisir - terutama ketika mereka entah bagaimana menyelaraskan dengan bisnis mereka.

— Ross Patterson
sumber

Saya tidak berusaha menjadi orang yang bertele-tele dan saya 100% yakin Anda tidak bermaksud ini secara negatif, tetapi itu benar-benar tidak membantu menumbuhkan partisipasi dalam sumber terbuka untuk merujuk pada orang-orang yang terlibat sebagai anak laki-laki. Hanya sesuatu untuk dipikirkan; Saya tahu ini adalah frasa yang digunakan orang.

— Elin

@Elin Hanya menjawab pertanyaan yang diajukan: "Bagaimana anak-anak besar seperti GIMP, FFmpeg, Blender, dll menangani transisi ini?"

— Ross Patterson

Oh, dan memberi +1 pada komentar - kami perlu diingatkan dari waktu ke waktu. Bisnis ini terlalu sentris laki-laki.

— Ross Patterson

Terima kasih dan ya saya tidak melihat referensi itu di posting asli.

— Elin

Ya, saya hanya menggunakan "anak laki-laki besar" sebagai pergantian frasa ... Saya kira saya tidak memikirkannya seperti itu, tapi saya bisa mengerti apa yang Anda maksudkan. Terima kasih atas sarannya! Prioritas utama saya saat ini adalah untuk mendapatkan pelacak isu nyata yang dapat diselidiki oleh para kontributor dan mudah-mudahan dapat memilih suatu masalah untuk diambil celahnya (saat ini yang kita miliki hanyalah papan Trello yang berantakan). Seperti yang saya katakan pada @Elin, saya condong ke arah Mantis alih-alih sistem masalah Github. Saya kira kita hanya perlu sesuatu pada saat ini.

— Ben Torell