Tips Membuat Proyek Open Source yang Populer
(skerritt.blog)<p>"Efek jaringan: semakin banyak orang mencarinya, semakin banyak pengguna yang datang, semakin banyak partisipasi, fiturnya makin baik, dan akhirnya menjadi semakin terkenal"<br />
Bagaimana caranya agar bisa populer?<br />
<br />
#1. README yang dirancang dengan baik <br />
- Jelaskan secara ringkas di bagian paling awal <br />
→ Ini untuk apa?<br />
→ Apakah ini menyelesaikan masalah saya?<br />
→ Apakah ini menyelesaikan masalah saya lebih baik daripada kompetitor?<br />
→ Bagaimana cara memasangnya?<br />
→ Perintah dasar apa yang perlu saya ketahui?<br />
→ Ke mana saya harus pergi jika butuh bantuan?<br />
<br />
1.1 Buat header yang merangkum proyek <br />
→ Logo: buat logo GIF di tempat seperti Canva <br />
→ Slogan: jelaskan proyek dalam satu kalimat. Terapkan juga di deskripsi GitHub<br />
⇨ Harus langsung menarik perhatian<br />
⇨ Mengapa pengguna membutuhkan ini <br />
⇨ Mengapa ini lebih baik daripada yang lain <br />
⇨ Mudah dipahami <br />
⇨ Contoh) hugo : The world’s fastest framework for building websites<br />
→ Badge: elemen gambar/link kecil untuk menjelaskan proyek <br />
⇨ Jumlah aktivitas terbaru, jumlah unduhan, berapa orang di ruang obrolan, versi yang digunakan, lisensi, dll. <br />
→ Instalasi cepat: tampilkan perintah pemasangan yang mudah dan cepat langsung terlihat<br />
⇨ Agar orang yang memang sudah datang karena tahu kebutuhannya bisa segera mencoba <br />
⇨ Tampilkan sedini mungkin hal seperti bisa dipasang dengan satu baris Docker/PIP <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Quick links (opsional)<br />
⇨ Website, forum, dokumentasi, panduan instalasi, panduan kontribusi, Twitter, dll.<br />
<br />
1.2 Jelaskan proyek secara ringkas di "What is This?" <br />
→ Deskripsi singkat + GIF yang menunjukkan cara kerja proyek + fitur inti yang ingin dilihat orang <br />
→ Contoh) Starship: dua kolom, sisi kiri memperkenalkan fitur inti, sisi kanan GIF yang menunjukkan cara kerjanya <br />
→ Tidak perlu menampilkan semua fitur. Cukup daftar hal-hal yang ingin dilihat pengguna dan jelaskan dengan mudah dipahami <br />
<br />
1.3 Bandingkan dengan kompetitor di bagian "X vs Y" <br />
→ Harus bisa menunjukkan mengapa orang harus memilih proyek ini daripada kompetitor <br />
→ Buat agar kelebihannya mudah terlihat<br />
→ Ini mirip dengan prinsip lean startup yang menyarankan mencari "early adopter" lebih dulu daripada "pengguna rata-rata" <br />
⇨ Jika Anda punya fitur yang lebih baik, targetkan orang yang tidak keberatan beralih ke alat baru <br />
→ Menargetkan "pengguna rata-rata" hanya tepat jika sama sekali tidak ada kompetitor, atau solusi yang ada saat ini jauh lebih rumit daripada milik Anda <br />
→ Cara termudah adalah membuat tabel perbandingan fitur utama<br />
⇨ Tampilkan dengan angka, bukan sekadar kata-kata <br />
⇨ Bagus juga jika bisa membandingkan perilakunya dengan GIF <br />
<br />
1.4 Buat dokumentasi yang hebat <br />
→ Tidak perlu memasukkan semua dokumentasi ke README. Itu sulit diperbarui dan dicari, serta membuat README sulit dibaca <br />
→ Karena cara instalasi sudah ditulis di atas, hal tambahan yang perlu ditunjukkan adalah <br />
⇨ Cara menjalankannya<br />
⇨ Di mana dokumentasinya bisa ditemukan<br />
⇨ Bagaimana mendapatkan dukungan <br />
→ Menunjukkan cara menjalankan dengan GIF juga bagus <br />
<br />
1.5 Tunjukkan cara berkontribusi, berterima kasih kepada kontributor, dan sambut mereka <br />
→ Cara berkontribusi ke proyek<br />
→ Berterima kasih kepada kontributor sebelumnya <br />
→ Gunakan bot seperti all-contributors <br />
<br />
#2. Buat sesuatu yang benar-benar diinginkan orang <br />
→ README yang bagus menarik perhatian orang, dan proyek yang "menyelesaikan masalah" akan membuat orang membicarakannya <br />
<br />
2.1 Masalah lebih dulu, produk belakangan<br />
→ Jangan membuat sesuatu demi punya produk, tetapi untuk menyelesaikan masalah <br />
→ "Kemajuan datang bukan hanya dari lompatan besar, tetapi juga dari ratusan langkah kecil"<br />
<br />
2.2 Hidup bersama masalah itu <br />
→ Jika tidak ada masalah, Anda tidak bisa menyelesaikannya dengan efektif <br />
→ Daripada menghasilkan ide secara acak, jauh lebih mudah mengamati masalah yang ada dalam hidup Anda sendiri <br />
→ Saat menyadari ada masalah, Anda mengetahui dua hal: masalah itu benar-benar ada, dan orang lain juga mengalaminya.<br />
<br />
2.3 Cari masalah di komunitas <br />
→ Jika melihat ke dalam komunitas, orang sering kali secara terbuka menunjukkan masalah yang mereka hadapi <br />
→ Semakin banyak orang, semakin banyak yang Anda dengar, dan itu bisa menghasilkan lebih banyak ide daripada hanya memikirkannya sendiri <br />
→ Cobalah membuat MVP (Minimum Viable Product) yang menyelesaikan masalah yang dimiliki komunitas <br />
→ Bagikan ke komunitas, ukur dampaknya, pelajari cara memperbaikinya, lalu buat ulang atau tambahkan hal baru untuk meningkatkannya <br />
<br />
#3. Sampaikan ke luar <br />
→ Sekalipun dibuat dengan baik, kalau tidak dipublikasikan, tidak ada yang akan melihatnya <br />
→ Jika sebelumnya Anda sudah memanfaatkan komunitas, untungnya mereka kemungkinan sudah tahu dan akan menggunakannya <br />
→ Mendapatkan GitHub Star dari 0 ke 1 itu sulit, tetapi dari 10 ke 100 lebih mudah <br />
<br />
3.1 Bagikan ke komunitas <br />
→ Loop Build, Measure, Learn <br />
→ Saat rilis nyata pertama, pastikan komunitas mengetahuinya. Mereka akan membagikannya ke teman-teman mereka<br />
<br />
3.2 News Aggregators <br />
→ Subreddit yang relevan <br />
→ HackerNews (catatan penerjemah asli: GeekNews juga!)<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Cari daftar yang relevan dengan topik lalu kirim PR </p>
2 komentar