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

<p>&quot;Network effects: ยิ่งมีคนเข้ามามากขึ้น ก็ยิ่งมีผู้ใช้มากขึ้น มีคนเข้าร่วมมากขึ้น ฟีเจอร์ดีขึ้น และยิ่งเป็นที่รู้จักมากขึ้น&quot;<br /> แล้วถ้าอยากให้ได้รับความนิยม ต้องทำอย่างไร?<br /> <br /> #1. README ที่ออกแบบมาอย่างดี <br /> - อธิบายให้กระชับตั้งแต่ตอนต้น <br /> → มันทำอะไร?<br /> → มันแก้ปัญหาของฉันได้ไหม?<br /> → มันแก้ปัญหาของฉันได้ดีกว่าคู่แข่งไหม?<br /> → ติดตั้งอย่างไร?<br /> → คำสั่งพื้นฐานที่ฉันควรรู้มีอะไรบ้าง?<br /> → ถ้าจะขอความช่วยเหลือควรไปที่ไหน?<br /> <br /> 1.1 สร้างส่วนหัวที่สรุปโปรเจกต์ <br /> → โลโก้: ทำโลโก้แบบ GIF ได้จากที่อย่าง Canva <br /> → สโลแกน: อธิบายโปรเจกต์ในบรรทัดเดียว นำไปใส่ใน GitHub Desc<br /> ⇨ ต้องสะดุดตาทันที<br /> ⇨ ทำไมผู้ใช้ถึงต้องการสิ่งนี้ <br /> ⇨ ทำไมสิ่งนี้ถึงดีกว่าตัวอื่น <br /> ⇨ เข้าใจง่าย <br /> ⇨ ตัวอย่าง) hugo : The world’s fastest framework for building websites<br /> → แบดจ์: รูปภาพ/ลิงก์เล็ก ๆ ที่ใช้อธิบายโปรเจกต์ <br /> ⇨ จำนวนกิจกรรมล่าสุด จำนวนดาวน์โหลด มีคนอยู่ในห้องแชตกี่คน เวอร์ชันที่รองรับ ไลเซนส์ ฯลฯ <br /> → การติดตั้งแบบรวดเร็ว: แสดงคำสั่งติดตั้งที่ง่ายและเร็วให้เห็นทันที<br /> ⇨ คนที่รู้จักโปรเจกต์นี้อยู่แล้วจะได้ลองใช้ได้ทันที <br /> ⇨ ถ้าติดตั้งด้วย Docker/PIP แบบบรรทัดเดียวได้ ก็ควรแสดงไว้ตั้งแต่ต้นให้มากที่สุด <br /> ⇨ docker run -it --rm remnux/ciphey<br /> → ลิงก์ด่วนต่าง ๆ (ไม่จำเป็น)<br /> ⇨ เว็บไซต์ ฟอรัม เอกสาร คู่มือติดตั้ง คู่มือการมีส่วนร่วม Twitter เป็นต้น<br /> <br /> 1.2 อธิบายโปรเจกต์อย่างกระชับในส่วน &quot;What is This?&quot; <br /> → คำอธิบายสั้น ๆ + GIF ที่แสดงการทำงานของโปรเจกต์ + ฟีเจอร์สำคัญที่คนอยากเห็น <br /> → ตัวอย่าง) Starship: ใช้สองคอลัมน์ โดยฝั่งซ้ายแนะนำฟีเจอร์สำคัญ ฝั่งขวาเป็น GIF การทำงาน <br /> → ไม่จำเป็นต้องแสดงทุกฟีเจอร์ ให้ลิสต์เฉพาะสิ่งที่ผู้ใช้อยากเห็นและอธิบายให้เข้าใจง่าย <br /> <br /> 1.3 เปรียบเทียบกับคู่แข่งในแบบ &quot;X vs Y&quot; <br /> → ต้องแสดงให้เห็นว่าทำไมควรเลือกโปรเจกต์นี้แทนคู่แข่ง <br /> → ทำให้มองเห็นข้อดีได้ง่าย<br /> → คล้ายกับแนวคิดใน Lean Startup ที่ควรหา &quot;early adopters&quot; ก่อน &quot;ผู้ใช้ทั่วไป&quot; <br /> ⇨ คนที่ถ้ามีฟีเจอร์ดีกว่า ก็ไม่ลังเลที่จะเปลี่ยนไปใช้เครื่องมือใหม่ <br /> → ควรเจาะ &quot;ผู้ใช้ทั่วไป&quot; ก็ต่อเมื่อไม่มีคู่แข่งเลย หรือโซลูชันที่มีอยู่ตอนนี้ซับซ้อนกว่าโปรเจกต์ของคุณมาก <br /> → วิธีที่ง่ายที่สุดคือทำตารางเปรียบเทียบฟีเจอร์หลัก<br /> ⇨ แสดงเป็นตัวเลขแทนคำพูด <br /> ⇨ การเทียบการทำงานด้วย GIF ก็เป็นวิธีที่ดี <br /> <br /> 1.4 ทำเอกสารให้ยอดเยี่ยม <br /> → ไม่จำเป็นต้องใส่เอกสารทั้งหมดไว้ใน README เพราะอัปเดตและค้นหายาก และทำให้ README อ่านยาก <br /> → เมื่อด้านบนเขียนวิธีติดตั้งไปแล้ว สิ่งที่ควรแสดงเพิ่มเติมคือ <br /> ⇨ วิธีรันใช้งาน<br /> ⇨ จะหาเอกสารได้จากที่ไหน<br /> ⇨ จะรับการสนับสนุนได้อย่างไร <br /> → การแสดงวิธีใช้งานด้วย GIF ก็เป็นวิธีที่ดี <br /> <br /> 1.5 อธิบายวิธีมีส่วนร่วม และขอบคุณพร้อมต้อนรับผู้ร่วมพัฒนา <br /> → วิธีมีส่วนร่วมกับโปรเจกต์<br /> → ขอบคุณผู้มีส่วนร่วมในอดีต <br /> → ใช้บอตอย่าง all-contributors <br /> <br /> #2. สร้างสิ่งที่ผู้คนต้องการ <br /> → README ที่ดีจะดึงดูดความสนใจของผู้คน และโปรเจกต์ที่ &quot;แก้ปัญหา&quot; ให้พวกเขาได้จะทำให้คนพูดถึง <br /> <br /> 2.1 ปัญหามาก่อน ผลิตภัณฑ์มาทีหลัง<br /> → อย่าสร้างอะไรขึ้นมาเพียงเพื่อจะมีผลิตภัณฑ์ แต่ให้แก้ปัญหา <br /> → &quot;ความก้าวหน้าไม่ได้มาจากการกระโดดครั้งใหญ่เท่านั้น แต่มาจากก้าวเล็ก ๆ หลายร้อยก้าวด้วย&quot;<br /> <br /> 2.2 อยู่กับปัญหานั้นจริง ๆ <br /> → ถ้าไม่มีปัญหา ก็จะแก้ปัญหาได้อย่างมีประสิทธิภาพไม่ได้ <br /> → แทนที่จะสุ่มสร้างไอเดียขึ้นมา การสังเกตปัญหาที่มีอยู่ในชีวิตตัวเองง่ายกว่ามาก <br /> → เมื่อรู้ว่ามีปัญหาอยู่ คุณจะรู้อีกสองอย่างคือ ปัญหานั้นมีอยู่จริง และคนอื่นก็มีปัญหาเดียวกันด้วย<br /> <br /> 2.3 หาโจทย์จากคอมมูนิตี้ <br /> → เมื่อเข้าไปดูในคอมมูนิตี้ คุณจะเห็นว่าผู้คนเปิดเผยปัญหาที่พวกเขาเผชิญอยู่ <br /> → ยิ่งมีคนมาก ยิ่งได้ฟังมาก ก็ยิ่งได้ไอเดียมากกว่าการคิดเองล้วน ๆ <br /> → ลองสร้าง MVP (Minimum Viable Product) เพื่อแก้ปัญหาที่คอมมูนิตี้มีอยู่ <br /> → แชร์กับคอมมูนิตี้ วัดผล เรียนรู้ว่าจะทำให้ดีขึ้นได้อย่างไร แล้วค่อยทำใหม่หรือเพิ่มสิ่งต่าง ๆ เพื่อปรับปรุง <br /> <br /> #3. พูดออกไปให้คนรู้ <br /> → ต่อให้ทำมาดีแค่ไหน ถ้าไม่เผยแพร่ก็ไม่มีใครเห็น <br /> → ถ้าคุณใช้คอมมูนิตี้ตามที่กล่าวมาก่อนหน้านี้ ก็ถือว่าโชคดี เพราะพวกเขารู้จักและจะใช้มันอยู่แล้ว <br /> → การทำให้ GitHub Star จาก 0 เป็น 1 นั้นยาก แต่จาก 10 เป็น 100 นั้นง่ายกว่า <br /> <br /> 3.1 แชร์กับคอมมูนิตี้ <br /> → วงจร Build, Measure, Learn <br /> → ตอนปล่อยเวอร์ชันจริงครั้งแรก ต้องทำให้คอมมูนิตี้รับรู้ให้ได้ เพราะพวกเขาจะช่วยแชร์ต่อให้เพื่อน ๆ<br /> <br /> 3.2 News Aggregators <br /> → Subreddit ที่ต้องการ <br /> → HackerNews (หมายเหตุจากผู้แปลต้นฉบับ: GeekNews ด้วย!)<br /> → Lobste.rs <br /> <br /> 3.3 Awesome List <br /> → หา list ที่เกี่ยวข้องกับหัวข้อนั้นแล้วส่ง PR </p>

[alstjr7375]

<p>เรื่องราวการรวบรวม GitHub Stars ได้ 500 ดวงภายในวันเดียว<br /> https://black7375.tumblr.com/post/653140399088631808/<br /> <br /> เป็นบทความที่ผมเคยเขียนไว้ก่อนหน้านี้<br /> ตอนนั้นเน้นเขียนเกี่ยวกับกลยุทธ์การโปรโมตเป็นหลัก<br /> ได้เขียนไว้ทั้งวิธีและช่วงเวลาในการลงโพสต์ประชาสัมพันธ์ รวมถึงแนวทางการพัฒนาและวิธีที่ใช้กำหนดช่วงเวลาปิดงานด้วย</p>

[xguru]

<p>แม้จะเป็นเรื่องที่ฟังดูแน่นอนอยู่แล้วก็ตาม... แต่ README ของโอเพนซอร์สนั้นสำคัญมากจริงๆ<br /> ต่อให้เป็นโปรเจกต์ที่แก้ปัญหาที่ไม่มีใครแก้ได้/ไม่ยอมแก้ หรือมีฟีเจอร์น่าทึ่งที่เหนือกว่าคู่แข่ง ผลลัพธ์ก็อาจแตกต่างกันได้ขึ้นอยู่กับว่าคุณเขียน README อย่างไร<br /> <br /> หวังว่าจะมีโอเพนซอร์สที่เป็นที่รู้จักไม่ใช่แค่ในประเทศ แต่รวมถึงต่างประเทศเพิ่มมากขึ้น<br /> <br /> ช่วงนี้ลองดู GitHub About และ README ของโอเพนซอร์สที่สร้างโดยนักพัฒนาชาวเกาหลีที่มีชื่อเสียงที่สุดในตอนนี้ด้วย<br /> <br /> swc : &quot;Make the web (development) faster.&quot; swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript. <br /> - https://github.com/swc-project/swc<br /> <br /> fzf : fzf is a general-purpose command-line fuzzy finder.<br /> - https://github.com/junegunn/fzf</p>;