Mẹo để tạo ra một dự án mã nguồn mở được nhiều người yêu thích
(skerritt.blog)<p>"Hiệu ứng mạng lưới: càng có nhiều người tìm đến, càng có nhiều người dùng hơn, tham gia nhiều hơn, tính năng tốt hơn, và nhờ đó ngày càng nổi tiếng hơn"<br />
Làm thế nào để trở nên phổ biến?<br />
<br />
#1. README được thiết kế tốt <br />
- Hãy giải thích ngắn gọn ngay từ đầu <br />
→ Nó dùng để làm gì?<br />
→ Nó có giải quyết vấn đề của tôi không?<br />
→ Nó có giải quyết vấn đề của tôi tốt hơn đối thủ không?<br />
→ Cài đặt thế nào?<br />
→ Những lệnh cơ bản tôi cần biết là gì?<br />
→ Tôi nên đi đâu để nhận trợ giúp?<br />
<br />
1.1 Tạo phần đầu để tóm tắt dự án <br />
→ Logo: có thể tạo GIF logo bằng Canva hoặc công cụ tương tự <br />
→ Slogan: mô tả dự án trong một dòng. Áp dụng vào phần mô tả trên GitHub<br />
⇨ Phải thật bắt mắt<br />
⇨ Vì sao người dùng cần nó <br />
⇨ Vì sao nó tốt hơn những thứ khác <br />
⇨ Dễ hiểu <br />
⇨ Ví dụ) hugo: The world’s fastest framework for building websites<br />
→ Badge: những hình ảnh/liên kết nhỏ dùng để mô tả dự án <br />
⇨ số hoạt động gần đây, số lượt tải, số người trong phòng chat, các phiên bản đang dùng, giấy phép... v.v. <br />
→ Cài đặt nhanh: hiển thị ngay lệnh cài đặt đơn giản và nhanh chóng<br />
⇨ Để những người đã biết trước có thể dùng thử ngay <br />
⇨ Những thứ như có thể cài bằng một dòng Docker/PIP nên được đưa lên càng sớm càng tốt <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Các liên kết nhanh (không bắt buộc)<br />
⇨ website, diễn đàn, tài liệu, hướng dẫn cài đặt, hướng dẫn đóng góp, Twitter, v.v.<br />
<br />
1.2 "What is This?" Mô tả dự án thật ngắn gọn <br />
→ Mô tả ngắn + GIF cho thấy dự án hoạt động thế nào + các tính năng cốt lõi mà mọi người muốn xem <br />
→ Ví dụ) Starship: hai cột, bên trái giới thiệu các tính năng chính, bên phải là GIF hoạt động <br />
→ Không cần cho thấy mọi tính năng. Chỉ liệt kê những gì người dùng muốn xem và giải thích sao cho dễ hiểu <br />
<br />
1.3 "X vs Y" So sánh với đối thủ <br />
→ Cần cho thấy vì sao nên chọn dự án này thay vì đối thủ <br />
→ Hãy để ưu điểm có thể được nhìn ra ngay<br />
→ Điều này giống như trong Lean Startup: nên tìm "early adopter" trước thay vì "người dùng trung bình" <br />
⇨ Nếu bạn có tính năng tốt hơn, hãy nhắm đến những người không ngại chuyển sang công cụ mới <br />
→ Chỉ khi hoàn toàn không có đối thủ, hoặc các giải pháp hiện tại quá phức tạp so với của bạn, thì mới nên nhắm đến "người dùng trung bình" <br />
→ Cách dễ nhất là tạo bảng so sánh các tính năng chính<br />
⇨ Hãy thể hiện bằng số liệu thay vì lời nói <br />
⇨ Cũng tốt nếu so sánh bằng GIF để cho thấy cách hoạt động <br />
<br />
1.4 Tạo tài liệu thật tốt <br />
→ Không cần nhét mọi tài liệu vào README. Việc đó khiến khó cập nhật, khó tìm kiếm và README trở nên khó đọc <br />
→ Vì phần cài đặt đã có ở trên, những gì nên bổ sung là <br />
⇨ Cách chạy nó<br />
⇨ Có thể tìm tài liệu ở đâu<br />
⇨ Có thể nhận hỗ trợ thế nào <br />
→ Cũng tốt nếu dùng GIF để cho thấy cách chạy <br />
<br />
1.5 Cách đóng góp, gửi lời cảm ơn và chào đón người đóng góp <br />
→ Cách đóng góp cho dự án<br />
→ Cảm ơn những người đã đóng góp trước đây <br />
→ Dùng bot như all-contributors <br />
<br />
#2. Hãy tạo thứ mà mọi người muốn <br />
→ README tốt sẽ thu hút sự chú ý, còn dự án "giải quyết vấn đề" của họ sẽ khiến mọi người bàn tán về nó <br />
<br />
2.1 Vấn đề đi trước, sản phẩm đi sau<br />
→ Đừng làm gì đó chỉ để tạo ra một sản phẩm, hãy giải quyết một vấn đề <br />
→ "Tiến bộ không chỉ đến từ những cú nhảy vọt lớn, mà còn từ hàng trăm bước nhỏ"<br />
<br />
2.2 Sống cùng vấn đề <br />
→ Nếu không có vấn đề, bạn không thể giải quyết nó một cách hiệu quả <br />
→ Thay vì ngẫu nhiên nghĩ ý tưởng, việc quan sát những vấn đề đang tồn tại trong chính cuộc sống của mình dễ hơn rất nhiều <br />
→ Khi nhận ra có một vấn đề, bạn biết được hai điều: nó thực sự tồn tại, và người khác cũng có vấn đề đó.<br />
<br />
2.3 Tìm vấn đề trong cộng đồng <br />
→ Khi quan sát cộng đồng, bạn sẽ thấy mọi người tự bộc lộ những vấn đề họ đang gặp phải <br />
→ Càng có nhiều người, càng lắng nghe nhiều, bạn càng có thể nảy ra nhiều ý tưởng hơn so với chỉ tự suy nghĩ một mình <br />
→ Hãy thử tạo một MVP (Minimum Viable Product) để giải quyết vấn đề mà cộng đồng đang có <br />
→ Chia sẻ với cộng đồng, đo lường hiệu quả, học cách làm tốt hơn, rồi làm lại hoặc bổ sung để tiếp tục cải thiện <br />
<br />
#3. Hãy nói ra ngoài <br />
→ Dù làm tốt đến đâu, nếu không công khai thì sẽ không ai thấy <br />
→ Nếu trước đó đã tận dụng cộng đồng thì thật may, họ đã biết và sẽ dùng nó <br />
→ Tăng GitHub Star từ 0 lên 1 là khó, nhưng từ 10 lên 100 thì dễ hơn <br />
<br />
3.1 Chia sẻ với cộng đồng <br />
→ Vòng lặp Build, Measure, Learn <br />
→ Khi có bản phát hành thực sự đầu tiên, hãy chắc chắn cộng đồng biết đến nó. Họ sẽ chia sẻ với bạn bè của mình<br />
<br />
3.2 News Aggregators <br />
→ Subreddit phù hợp <br />
→ HackerNews (ghi chú của người biên tập: GeekNews cũng vậy!)<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Tìm các danh sách liên quan đến chủ đề và gửi PR </p>
2 bình luận