บทเรียนจากโอเพนซอร์ส: 2 ปีของ Telescope

โดย Sacha Greif

    ผมได้ทำงานกับ Telescope (เป็นแอพพลิเคชั่นพวก hacker news ที่สร้างขึ้นด้วย Meteor JavaScript framework และเป็นโอเพนซอร์สด้วย) มาเกือบจะสองปีแล้ว ช่วงที่ผ่านมาผมได้เรียนรู้หลายสิ่งว่าต้องทำอย่างไรบ้างจึงจะทำให้โปนเจกต์โอเพนซอร์สประสบความสำเร็จ
    เริ่มจากสถิตินิดๆหน่อยๆ ในเดือนตุลาคม 2014 นี้ พบว่า Telescope repo บน Github นั้น

• ได้ดาว 1939 ดวง
• ถูก fork 707 ครั้ง
• ได้รับ pull request 142 ครั้งจาก contributor 59 ราย

    สถิตินี้ไม่ถึงกับทำให้ Telescope เป็นโปรเจกต์โอเพนซอร์สที่ยิ่งใหญ่อะไรหรอก (เพื่อเปรียบเทียบ Discourse ได้ดาวตั้ง 12000 ดวง) แต่ผมคิดว่าเป็นสถิติที่น่ายกย่องอยู่ การจะมาถึงจุดนี้ได้ไม่ง่ายเลย อันที่จริง ผมค่อนข้างแน่ใจว่าหากตอนนั้นผมรู้ว่าจะเจออะไรบ้าง โปรเจกต์นี้คงไม่มีมีวันถือกำเนิดขึ้นมาเสียด้วยซ้ำ สองปีก่อน ผมยังค่อนข้างไร้เดียงสาอยู่ และต่อไปนี้คือสิ่งที่ผมได้เรียนรู้ตลอดเวลาที่ผ่านมา

ของฟรีไม่มีในโลก

    ในเมื่อไม่มีของฟรีแล้วทำไมผมจึงอยากทำให้ Telescope เป็นโอเพนซอร์สตั้งแต่แรกล่ะ จริงๆจะตอบก็ง่ายอยู่หรอกหากใช้สำนวนมาตรฐานเช่น “เพราะอยากจะตอบแทนคืนสู่ชุมชนผู้ใช้” หรือไม่ก็ “เพราะผมเชื่อในซอฟท์แวร์ที่ฟรี”
    แต่ความจริงที่เกิดขึ้นมันจับต้องได้มากกว่านั้น และดูเห็นแก่ตัวมากกว่านั้น นั่นคือ ผมคิดว่าคงดีมากเลยหากจะมีใครสักคนมาช่วยผมให้บรรลุเป้าหมายได้ แบบฟรีๆ ผมมีความคิดแบบนี้แหละตอนที่ทำ clone ของ hacker news (ซึ่งตอนนี้กลายมาเป็น Sidebar) แต่ว่าตอนนั้น

• ผมไม่อยากจะลงมือทำทุกอย่างด้วยตนเอง
• แต่ผมก็ไม่อยากใช้เงินมากมายไปจ้างคนมาทำแทน เช่นกัน

    ตอนนั้นผมคาดการณ์ว่า ผมคงมาลงเอยที่เวอร์ชั่นพื้นฐานของแอพพลิเคชั่นดังกล่าว โดยจะทำให้เป็นโอเพนซอร์ส นั่งรอขณะที่มี pull request หลั่งไหลเข้ามาเรื่อยๆ และนำการปรับปรุงที่เกิดขึ้นในการพัฒนาให้ Sidebar ดีขึ้นไปอีก

Sidebar: giving you the 5 best design links of the day.

    แต่แน่นอน ความจริงไม่ได้เป็นเช่นนั้น ผมเคยได้ขึ้นหน้าหนึ่งของ hacker news ก็จริงตอนที่เริ่มทำ Telescope แต่หลังจากนั้นก็เงียบกริบ ไม่มีอะไรเกิดขึ้น
    คนส่วนใหญ่ก็ลองใช้แอพพลิเคชั่นดู แต่พบว่ายังไม่สมบูรณ์ดีจริง และแทนที่คนเหล่านั้นจะร้องเรียนเข้ามาขอให้ช่วยแก้ bug ดังที่ผมคาดไว้ กลับปรากฏว่าต่างเงียบกริบ ลืมไปเสีย
     ดังนั้น บทเรียนบทแรกของผมคือ โอเพนซอร์สไม่ใช่ของวิเศษที่จะช่วยบันดาลสิ่งต่างๆได้ การที่คุณ host โค้ดของคุณบน GitHub ไม่ได้แปลว่านั่นจะทำให้คนอยากจะมาช่วยคุณในทันที

Skewed Ratio

    เมื่อมองกลับไป ก็เหมือนกับเส้นผมบังภูเขา แม้แต่สำหรับโปรเจกต์ใหญ่เช่น Discourse ที่กล่าวถึงข้างต้น จะพบว่าประมาณ 80% ของ code commit มาจากสมาชิก core team 5 คน ซึ่งดูเหมือนว่าจะเป็นอัตราส่วนปกติ สำหรับ Telescope นั้น ผมได้ร่วมพัฒนาประมาณ 78% ของ codebase commit ด้วยตัวเอง บางครั้งผมเป็นเพียงคนเดียวด้วยซ้ำที่พัฒนาเองเป็นแรมเดือน แม้ว่าระยะหลังนี้สถานการณ์จะดีขึ้นก็ตาม

Telescope’s main contributors.

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

โอเพนซอร์สนั้นยาก(กว่าอีก)

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

• เขียนเอกสารคู่มือสำหรับ Telescope
• ดูแลเว็บไซต์และบล็อกแยกต่างหากสำหรับโปรเจกต์นี้
• ตอบคำถามข้อสงสัยและให้การ support
• สนับสนุนและสื่อสารกับแวดวง Telescope

และทั้งหมดนี้ แน่นอน ไม่ได้เงินค่าตอบแทนเลยแม้แต่น้อย

    ที่ย้อนแย้งมากกว่านั้นคือว่า Sidebar นั้น ท้ายที่สุดพบว่าเรียบง่ายกว่าที่ผมวาดภาพไว้มากนัก ผมจึงยกเลิกการ upvote และการ comment ไปเสีย หันมาสร้าง aggregator/newsletter แทน

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

     บทเรียนที่สองที่ผมได้รับ คือ เมื่อเทียบกับการสร้าง solution ของตัวเอง ออกแบบเอง พบว่าโอเพนซอร์สนั้นยากกว่ามาก

ตัวอย่างค้าน

    น่าสนใจอยู่ทีเดียว หนึ่งปีหลังจากที่ผมสร้าง Sidebar ก็มีอีกโปรเจกต์ที่เกี่ยวกับ hacker news ตามมา อย่างไรก็ตาม ทีมของโปรเจกต์ดังกล่าวไม่ได้ทำให้เป็นโอเพนซอร์สแต่อย่างใด
    ดูๆไปก็พบว่าอาจจะเป็นการตัดสินใจที่ถูกแล้วสำหรับทีมนั้น เพราะเขาสามารถมุ่งสนใจที่ผลิตภัณฑ์ของเขาเพียงอย่างเดียว และเว็บไซต์ของเขาก็กลายมาเป็นตัวแสดงหลักในวงการอย่างรวดเร็ว อันที่จริง ผมพนันได้เลยว่าคุณต้องรู้จักพวกเขาแน่

Product Hunt: not open source, but has $6M in the bank.

    เพื่อเป็นเกร็ดเล็กๆน้อยๆ ทีม Product Hunt เคยคิดจะใช้ Telescope เป็น platform สำหรับโปรเจกต์เขาเหมือนกัน แต่แอพพลิเคชั่นยังไม่สมบูรณ์ดี พวกเขาจึงเริ่มสร้างเองใหม่ตั้งแต่เริ่มต้น

    ผมคิดว่า ณ ตอนนั้นพวกเขาก็ตัดสินใจถูกนะ แต่บางครั้งผมก็อดสงสัยไม่ได้จริงๆว่า จะเป็นอย่างไรหาก Product Hunt เป็นหนึ่งในบรรดาผู้ใช้ Telescope

2 ตลาดที่แตกต่าง

    ที่ผ่านมาทั้งหมด ผมได้แนะนำเหตุผลดีๆ 2 ประการว่าทำไมคุณต้องคิดหนักก่อนที่จะลงมาเล่นโปรเจกต์โอเพนซอร์ส แต่คงไม่มีประโยชน์อีกแล้วล่ะหากว่าคุณได้ตัดสินใจลงมาเรียบร้อยแล้ว หากเป็นเช่นนั้น จงฟังให้ดี บทเรียนต่อไปเป็นสิ่งที่ผมเพิ่งจะเรียนรู้เมื่อไม่นานนี้เอง แต่สำคัญมาก
    โปรเจกต์โอเพนซอร์สนั้นมีเป้าหมายที่คน 2 กลุ่ม คือ ผู้ใช้ กับผู้พัฒนา อย่างไรก็ตาม จะมีการคาบเกี่ยวกันเล็กน้อยระหว่างสองกลุ่มนี้ อย่างน้อยก็สำหรับกรณีของ Telescope นี้เอง

    เห็นไหม ว่าผมทำพลาดไปอย่างไร้เดียงสาเหลือเกิน ที่ทึกทักเอาเองว่าบรรดาผู้ใช้จะกลายมาเป็นผู้ที่ช่วยพัฒนาโค้ดกลับมาให้และช่วยทำให้ Telescope ดียิ่งขึ้น นี่คือความผิดพลาดที่ชัดเจนมาก อย่างแรกเลย ในหนึ่งวันมีเพียง 24 ชั่วโมงเท่านั้น ยิ่งคนหนึ่งใช้เวลาในการ customize แอพพลิเคชั่นของตนและสร้างชุมชนของตน มากเท่าใด เขายิ่งมีเวลาพัฒนาโค้ดกลับมาให้ codebase น้อยลงเท่านั้น
    อย่างที่สอง ไม่มีเหตุผลอะไรเลยที่คนที่อยากจะมีแอพพลิเคชั่นข่าวของตนจะต้องมาเป็นผู้พัฒนาเสียเอง คนจำนวนมากเลยไม่ได้ใช้เวลาทั้งวันของเขาอยู่กับ text editor หรอกนะ จะบอกให้

อุดช่องโหว่

    กระนั้น โปรเจกต์โอเพนซอร์สที่จะประสบความสำเร็จต้องอาศัยทั้งสองฝ่ายที่กล่าวมา ทั้งผู้ใช้และผู้พัฒนา ดังนั้นคุณจึงต้องมีกลยุทธ์ในการสื่อสาร 2 แบบด้วยกัน
    เมื่อกล่าวถึงผู้ใช้ คุณจะต้องเน้นย้ำสิ่งต่อไปนี้

• ใช้ง่าย
• customize ง่าย
• ผู้ใช้ได้ประโยชน์ เช่น ใช้ Telescope ในการสร้างชุมชนและผู้ติดตามของคุณเอง

    ส่วนเมื่อกล่าวถึงผู้พัฒนา คุณจะต้องชี้ให้เห็นว่า การเป็นส่วนหนึ่งของชุมชน จะช่วยพวกเขาในเรื่องต่อไปนี้อย่างไรบ้าง

• ช่วยให้พวกเขาเรียนรู้จากสถาปัตยกรรมและรูปแบบของแอพพลิเคชั่น
• ช่วยให้พวกเขาสามารถนำ codebase กลับมาใช้อีกได้ เพื่อเป็นเทมเพลตสำหรับแอพพลิเคชั่นของเขาเอง
• ช่วยให้พวกเขาสร้างแหล่งที่จะเป็นระโยชน์ต่อชุมชนผู้พัฒนาโดยรวม
• ช่วยให้พวกเขาสร้างผลิตภัณฑ์ที่เหมาะเจาะกับสภาพแวดล้อมของแอพพลิเคชั่นนั้นๆ เช่น ธีม ปลั๊กอิน
• ช่วยให้พวกเขาสามารถหางานที่เกี่ยวข้องกับแอพพลิเคชั่น เช่น การ customize การบำรุงรักษา

ตอบโจทย์เรื่องเวลาและเงิน

    โอเพนซอร์สนั้นอาจจะเหมือนเบียร์ฟรี แต่เบียร์นั้นไม่เคยฟรีเหมือนโอเพนซอร์ส กล่าวอีกนัยหนึ่งก็คือ ไม่ว่าโปรเจกต์ของคุณจะเป็นโอเพนซอร์สหรือไม่ ท้ายที่สุดคุณก็มีค่าใช้จ่ายที่ต้องแบกรับ

    ดังนั้น จึงจำเป็นอย่างยิ่งที่ต้องหากิจกรรมที่จะช่วยสนับสนุนค่าใช้จ่ายโปรเจกต์ของคุณ และจะดีมากหากกิจกรรมดังกล่าวเกี่ยวข้องกับแอพพลิเคชั่นของคุณด้วย

    ด้วยเหตุผลนี้ หลายคนจึงหันมาหา hosting แต่กระนั้น hosting ก็ก่อปัญหาประเภท คนติดต่อขอความช่วยเหลือเมื่อเว็บไซต์ล่ม แต่ติดต่อมาตอนตี 4

    ขอโทษเถอะครับ ผมไม่อยากรับผิดชอบกับความอยู่รอดของธุรกิจคนอื่นนะ แค่ต้องรับผิดชอบเรื่องของผมเองก็มากพออยู่แล้ว ขอบคุณครับ

    ดังนั้น สิ่งที่ผมทำได้ คือการเขียนหนังสือแทน

Our book, Discover Meteor.

    หากคุณเชี่ยวชาญพอที่จะสร้างแอพพลิเคชั่นโอเพนซอร์สที่คนนิยม ก็หมายความว่าคุณเชี่ยวชาญพอที่จะเขียนคู่มือเกี่ยวกับการสร้างแอพพลิเคชั่นนั้น และนี่คือสิ่งที่ Tom Coleman และผมร่วมกันทำ หนังสือชื่อ Discover Meteor

    Discover Meteor จะนำคุณไปสู่กระบวนการใช้ Meteor ในการสร้าง Microscope ซึ่งเป็นเวอร์ชันที่เล้กกว่าและเรียบง่ายกว่า Telescope ปรากฏว่าหนังสือเล่มดีลงเอยได้ดีพอสมควร และผมก็มีเวลาที่จะมุ่งความสนใจไปยัง Telescope และ Meteor ในช่วงปีสุดท้าย

Microscope, Telescope’s little brother.

    อีกเส้นทางหนึ่งที่คุณอาจจะสนใจคือบริการสำเร็จรูปครบวงจร โดยพื้นฐานแล้ว คือการเลือกบริการซักหนึ่งบริการที่คนมักจะต้องการเพียงครั้งเดียว (เช่น การ customize แอพพลิเคชั่น) แล้วทำให้เป็นระบบ หรือเป็นตัวแทนบริการนั้นเสียเอง ในระดับที่คุณสามารถขายได้ในราคาที่ถูกแต่ยังได้กำไรอยู่

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

ซอฟต์แวร์โอเพนซอร์สไม่ได้เป็นแค่ซอฟต์แวร์

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

    ในทางกลับกัน ซอฟต์แวร์โอเพนซอร์สกลับเป็นเรื่องของ ผู้คน มากกว่า

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

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

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

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

ล้มเลิก

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

ผม: ทุกวันนี้ผมไม่รู้จริงๆว่าจะทำอะไรกับ Telescope ต่อดี

เพื่อน: หมายถึง ในแง่ของฟีเจอร์เหรอ

ผม: ผมเชื่อมั่นในตัวโปรเจกต์นี้นะ แต่มันมีอะไรต้องทำมากมายมหาศาลเหลือเกิน

ผม: ผมว่าผมคงแค่ท้อใจบ้างล่ะเมื่อนึกถึงปริมาณงานมหาศาลที่ผมต้องทำ

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

จากมองโกเลียสู่ศรีลังกา

    ช่วงหน้าร้อนที่ผ่านมา ผมได้รื้อองค์ประอบต่างๆของแอพพลิเคชั่นเสียใหม่ เพิ่มเทมเพลตของอีเมลเข้าไป และจดหมายข่าวแบบอัตโนมัติ และสร้างธีมสำหรับ Telescope จนสำเร็จโดยไม่ต้องดัดแปลง core file ของมันแต่อย่างใด นอกจากนี้แล้ว ผมยังทำโฮมเพจและเอกสารคู่มือ Telescope ใหม่หมดเลย
     ดูเหมือนว่าความพยายามทั้งหมดของผมก็ไม่ได้สูญเปล่านัก จริงอยู่ Telescope ยังค่อนข้างอยู่ในวงแคบ ซึ่งอาจจะเร็วไปที่จะมองว่าทั้งหมดสำเร็จลุล่วง แต่อย่างน้อยที่สุด ความสนใจและการตอบรับที่เพิ่มขึ้นก็ช่วยให้ผมเรียกแรงผลักดันกลับมาอีกครั้ง
     ทุกวันนี้ องค์ประกอบอื่นที่เกี่ยวข้องกับแอพพลิเคชั่นก็เริ่มมีมากขึ้นอย่างน่าประหลาดใจ ผู้พัฒนาจากมองโกเลียไปจนถึงศรีลังกาต่างร่วมพัฒนาโค้ด ผู้คนจำนวนมากก็เริ่มใช้แอพพลิเคชั่นในการสร้างชุมชนเกี่ยวกับ bootstrapping การพัฒนา front-end การสนับสนุนลูกค้า วิดิโอเกม รถยนต์ และอื่นๆอีกมากมาย

ไปสู่ดวงดาว

    อย่างน้อยที่สุด ในตอนนี้อะไรๆก็ดูมีความหวังขึ้นมา สัปดาห์ก่อนโปรเจกต์ก็ได้รับ pull request จำนวนหนึ่ง ผมเองก็ได้รับคำถามใหม่ๆทุกวัน และผมกำลังคิดถึงกระทั่งการจัดการนัดพบรายสัปดาห์เพื่อช่วยเหลือสนับสนุนผู้ใช้
    แล้วจะเป็นอย่างไรต่อไปล่ะ ตอนนี้ผมกำลังมุ่งสนใจเวอร์ชัน 1.0 อยู่ อยากจะให้ Telescope ไปอยู่ในจุดที่มั่นคง ใช้ง่าย แต่หลังจากนั้นไม่มีใครรู้หรอก บางทีวันหนึ่ง Telescope อาจจะมีบทบาทต่อเว็บไซต์ข่าวในแบบเดียวกันกับที่ Wordpress มีบทบาทต่อบล็อกละมั้ง
    ท้องฟ้ายังมีขอบเขตของมัน แต่นี่คือ Telescope นะ ผมจึงหวังไกลจนถึงดวงดาว!

ที่มา :http://www.telesc.pe/blog/open-source-lessons-learned