เคล็ดลับในการสร้างโปรเจกต์โอเพนซอร์สที่ได้รับความนิยม

"Network effects: ยิ่งมีคนเข้ามามากขึ้น ก็ยิ่งมีผู้ใช้มากขึ้น มีคนเข้าร่วมมากขึ้น ฟีเจอร์ดีขึ้น และยิ่งเป็นที่รู้จักมากขึ้น"

แล้วถ้าอยากให้ได้รับความนิยม ต้องทำอย่างไร?

#1. README ที่ออกแบบมาอย่างดี

• อธิบายให้กระชับตั้งแต่ตอนต้น

→ มันทำอะไร?

→ มันแก้ปัญหาของฉันได้ไหม?

→ มันแก้ปัญหาของฉันได้ดีกว่าคู่แข่งไหม?

→ ติดตั้งอย่างไร?

→ คำสั่งพื้นฐานที่ฉันควรรู้มีอะไรบ้าง?

→ ถ้าจะขอความช่วยเหลือควรไปที่ไหน?

1.1 สร้างส่วนหัวที่สรุปโปรเจกต์

→ โลโก้: ทำโลโก้แบบ GIF ได้จากที่อย่าง Canva

→ สโลแกน: อธิบายโปรเจกต์ในบรรทัดเดียว นำไปใส่ใน GitHub Desc

⇨ ต้องสะดุดตาทันที

⇨ ทำไมผู้ใช้ถึงต้องการสิ่งนี้

⇨ ทำไมสิ่งนี้ถึงดีกว่าตัวอื่น

⇨ เข้าใจง่าย

⇨ ตัวอย่าง) hugo : The world’s fastest framework for building websites

→ แบดจ์: รูปภาพ/ลิงก์เล็ก ๆ ที่ใช้อธิบายโปรเจกต์

⇨ จำนวนกิจกรรมล่าสุด จำนวนดาวน์โหลด มีคนอยู่ในห้องแชตกี่คน เวอร์ชันที่รองรับ ไลเซนส์ ฯลฯ

→ การติดตั้งแบบรวดเร็ว: แสดงคำสั่งติดตั้งที่ง่ายและเร็วให้เห็นทันที

⇨ คนที่รู้จักโปรเจกต์นี้อยู่แล้วจะได้ลองใช้ได้ทันที

⇨ ถ้าติดตั้งด้วย Docker/PIP แบบบรรทัดเดียวได้ ก็ควรแสดงไว้ตั้งแต่ต้นให้มากที่สุด

⇨ docker run -it --rm remnux/ciphey

→ ลิงก์ด่วนต่าง ๆ (ไม่จำเป็น)

⇨ เว็บไซต์ ฟอรัม เอกสาร คู่มือติดตั้ง คู่มือการมีส่วนร่วม Twitter เป็นต้น

1.2 อธิบายโปรเจกต์อย่างกระชับในส่วน "What is This?"

→ คำอธิบายสั้น ๆ + GIF ที่แสดงการทำงานของโปรเจกต์ + ฟีเจอร์สำคัญที่คนอยากเห็น

→ ตัวอย่าง) Starship: ใช้สองคอลัมน์ โดยฝั่งซ้ายแนะนำฟีเจอร์สำคัญ ฝั่งขวาเป็น GIF การทำงาน

→ ไม่จำเป็นต้องแสดงทุกฟีเจอร์ ให้ลิสต์เฉพาะสิ่งที่ผู้ใช้อยากเห็นและอธิบายให้เข้าใจง่าย

1.3 เปรียบเทียบกับคู่แข่งในแบบ "X vs Y"

→ ต้องแสดงให้เห็นว่าทำไมควรเลือกโปรเจกต์นี้แทนคู่แข่ง

→ ทำให้มองเห็นข้อดีได้ง่าย

→ คล้ายกับแนวคิดใน Lean Startup ที่ควรหา "early adopters" ก่อน "ผู้ใช้ทั่วไป"

⇨ คนที่ถ้ามีฟีเจอร์ดีกว่า ก็ไม่ลังเลที่จะเปลี่ยนไปใช้เครื่องมือใหม่

→ ควรเจาะ "ผู้ใช้ทั่วไป" ก็ต่อเมื่อไม่มีคู่แข่งเลย หรือโซลูชันที่มีอยู่ตอนนี้ซับซ้อนกว่าโปรเจกต์ของคุณมาก

→ วิธีที่ง่ายที่สุดคือทำตารางเปรียบเทียบฟีเจอร์หลัก

⇨ แสดงเป็นตัวเลขแทนคำพูด

⇨ การเทียบการทำงานด้วย GIF ก็เป็นวิธีที่ดี

1.4 ทำเอกสารให้ยอดเยี่ยม

→ ไม่จำเป็นต้องใส่เอกสารทั้งหมดไว้ใน README เพราะอัปเดตและค้นหายาก และทำให้ README อ่านยาก

→ เมื่อด้านบนเขียนวิธีติดตั้งไปแล้ว สิ่งที่ควรแสดงเพิ่มเติมคือ

⇨ วิธีรันใช้งาน

⇨ จะหาเอกสารได้จากที่ไหน

⇨ จะรับการสนับสนุนได้อย่างไร

→ การแสดงวิธีใช้งานด้วย GIF ก็เป็นวิธีที่ดี

1.5 อธิบายวิธีมีส่วนร่วม และขอบคุณพร้อมต้อนรับผู้ร่วมพัฒนา

→ วิธีมีส่วนร่วมกับโปรเจกต์

→ ขอบคุณผู้มีส่วนร่วมในอดีต

→ ใช้บอตอย่าง all-contributors

#2. สร้างสิ่งที่ผู้คนต้องการ

→ README ที่ดีจะดึงดูดความสนใจของผู้คน และโปรเจกต์ที่ "แก้ปัญหา" ให้พวกเขาได้จะทำให้คนพูดถึง

2.1 ปัญหามาก่อน ผลิตภัณฑ์มาทีหลัง

→ อย่าสร้างอะไรขึ้นมาเพียงเพื่อจะมีผลิตภัณฑ์ แต่ให้แก้ปัญหา

→ "ความก้าวหน้าไม่ได้มาจากการกระโดดครั้งใหญ่เท่านั้น แต่มาจากก้าวเล็ก ๆ หลายร้อยก้าวด้วย"

2.2 อยู่กับปัญหานั้นจริง ๆ

→ ถ้าไม่มีปัญหา ก็จะแก้ปัญหาได้อย่างมีประสิทธิภาพไม่ได้

→ แทนที่จะสุ่มสร้างไอเดียขึ้นมา การสังเกตปัญหาที่มีอยู่ในชีวิตตัวเองง่ายกว่ามาก

→ เมื่อรู้ว่ามีปัญหาอยู่ คุณจะรู้อีกสองอย่างคือ ปัญหานั้นมีอยู่จริง และคนอื่นก็มีปัญหาเดียวกันด้วย

2.3 หาโจทย์จากคอมมูนิตี้

→ เมื่อเข้าไปดูในคอมมูนิตี้ คุณจะเห็นว่าผู้คนเปิดเผยปัญหาที่พวกเขาเผชิญอยู่

→ ยิ่งมีคนมาก ยิ่งได้ฟังมาก ก็ยิ่งได้ไอเดียมากกว่าการคิดเองล้วน ๆ

→ ลองสร้าง MVP (Minimum Viable Product) เพื่อแก้ปัญหาที่คอมมูนิตี้มีอยู่

→ แชร์กับคอมมูนิตี้ วัดผล เรียนรู้ว่าจะทำให้ดีขึ้นได้อย่างไร แล้วค่อยทำใหม่หรือเพิ่มสิ่งต่าง ๆ เพื่อปรับปรุง

#3. พูดออกไปให้คนรู้

→ ต่อให้ทำมาดีแค่ไหน ถ้าไม่เผยแพร่ก็ไม่มีใครเห็น

→ ถ้าคุณใช้คอมมูนิตี้ตามที่กล่าวมาก่อนหน้านี้ ก็ถือว่าโชคดี เพราะพวกเขารู้จักและจะใช้มันอยู่แล้ว

→ การทำให้ GitHub Star จาก 0 เป็น 1 นั้นยาก แต่จาก 10 เป็น 100 นั้นง่ายกว่า

3.1 แชร์กับคอมมูนิตี้

→ วงจร Build, Measure, Learn

→ ตอนปล่อยเวอร์ชันจริงครั้งแรก ต้องทำให้คอมมูนิตี้รับรู้ให้ได้ เพราะพวกเขาจะช่วยแชร์ต่อให้เพื่อน ๆ

3.2 News Aggregators

→ Subreddit ที่ต้องการ

→ HackerNews (หมายเหตุจากผู้แปลต้นฉบับ: GeekNews ด้วย!)

→ Lobste.rs

3.3 Awesome List

→ หา list ที่เกี่ยวข้องกับหัวข้อนั้นแล้วส่ง PR

[alstjr7375]

เรื่องราวการรวบรวม GitHub Stars ได้ 500 ดวงภายในวันเดียว

https://black7375.tumblr.com/post/653140399088631808/

เป็นบทความที่ผมเคยเขียนไว้ก่อนหน้านี้

ตอนนั้นเน้นเขียนเกี่ยวกับกลยุทธ์การโปรโมตเป็นหลัก

ได้เขียนไว้ทั้งวิธีและช่วงเวลาในการลงโพสต์ประชาสัมพันธ์ รวมถึงแนวทางการพัฒนาและวิธีที่ใช้กำหนดช่วงเวลาปิดงานด้วย

[xguru]

แม้จะเป็นเรื่องที่ฟังดูแน่นอนอยู่แล้วก็ตาม... แต่ README ของโอเพนซอร์สนั้นสำคัญมากจริงๆ

ต่อให้เป็นโปรเจกต์ที่แก้ปัญหาที่ไม่มีใครแก้ได้/ไม่ยอมแก้ หรือมีฟีเจอร์น่าทึ่งที่เหนือกว่าคู่แข่ง ผลลัพธ์ก็อาจแตกต่างกันได้ขึ้นอยู่กับว่าคุณเขียน README อย่างไร

หวังว่าจะมีโอเพนซอร์สที่เป็นที่รู้จักไม่ใช่แค่ในประเทศ แต่รวมถึงต่างประเทศเพิ่มมากขึ้น

ช่วงนี้ลองดู GitHub About และ README ของโอเพนซอร์สที่สร้างโดยนักพัฒนาชาวเกาหลีที่มีชื่อเสียงที่สุดในตอนนี้ด้วย

swc : "Make the web (development) faster." swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.

• https://github.com/swc-project/swc

fzf : fzf is a general-purpose command-line fuzzy finder.

• https://github.com/junegunn/fzf