ควรเปลี่ยนบริษัทของฉันให้เป็นโอเพนซอร์สไหม? (2022)
(supabase.com)- Supabase เลือกใช้ โอเพนซอร์ส ตั้งแต่ช่วงเริ่มก่อตั้ง และเมื่อสร้างผลิตภัณฑ์แบบเปิดเผยต่อสาธารณะ ก็ได้รับประโยชน์ด้านคอมมูนิตี้ การสรรหาบุคลากร และการขยายผลิตภัณฑ์มากกว่าที่คาดไว้
- ความกังวลหลัก ๆ คือคำวิจารณ์เรื่องคุณภาพโค้ด การเปิดเผย ช่องโหว่ด้านความปลอดภัย และการถูกคู่แข่งลอกเลียนแบบ แต่ความเปิดเผยก็อาจนำไปสู่การมีส่วนร่วมในการปรับปรุงและการทำซ้ำอย่างรวดเร็วได้เช่นกัน
- ในการสรรหาบุคลากร การมีส่วนร่วมในรีโพซิทอรีช่วยแสดงโค้ดจริงและวิธีทำงานร่วมกันของผู้สมัคร ทำให้ Supabase เริ่มทำ outbound recruiting หลังจากจ้าง นักพัฒนา 32 คน แล้วเท่านั้น
- ฟีเจอร์สำหรับผู้ใช้กลุ่มเล็ก ๆ, integration และ adapter สามารถสร้างโดยคอมมูนิตี้ได้เอง จึงขยายขอบเขตผลิตภัณฑ์และช่วยชดเชยข้อจำกัดด้านลำดับความสำคัญของทีมภายใน
- ความสามารถในการป้องกันของบริษัทโอเพนซอร์สไม่ได้มาจากการซ่อนโค้ด แต่มาจากการสั่งสม ความเร็วในการลงมือทำ, แบรนด์, ทีม และคอมมูนิตี้ในระยะยาว
เหตุผลที่ Supabase เลือกโอเพนซอร์สตั้งแต่ต้น
- Supabase เป็น โอเพนซอร์ส ตั้งแต่วันแรก และเพราะผู้ก่อตั้งเป็นผู้ใช้และผู้สนับสนุนโปรเจกต์สาธารณะอย่าง PostgreSQL, Python, Bitcoin, React มาเป็นเวลานาน ตอนนั้นจึงไม่ได้รู้สึกว่าเป็นการตัดสินใจที่ยาก
- ตรงข้ามกับที่คาดไว้ว่าการสร้างธุรกิจแบบเปิดเผยต่อสาธารณะจะมีภาระมาก ระหว่างการเติบโตของผลิตภัณฑ์และบริษัทกลับมีข้อดีที่คาดไม่ถึงหลายอย่างปรากฏขึ้น
- แม้จะเป็นประสบการณ์ของบริษัทเครื่องมือสำหรับนักพัฒนาหรือ PaaS แต่เนื้อหาจำนวนมากก็ใช้ได้กับบริษัทซอฟต์แวร์โดยรวมเช่นกัน
- ความกังวลซ้ำ ๆ ที่ขัดขวางการเปลี่ยนเป็นโอเพนซอร์สมีอยู่สามข้อหลัก
- ผู้คนอาจวิจารณ์โค้ดที่รกหรือยังไม่สมบูรณ์
- แฮกเกอร์อาจหาช่องโหว่ด้านความปลอดภัยและนำไปใช้โจมตี
- คู่แข่งอาจขโมย ทรัพย์สินทางปัญญา
ความกังวลว่า “โค้ดของฉันแย่”
- ความกังวลเรื่องโค้ดที่ไม่ดีส่วนใหญ่ใกล้เคียงกับปัญหาเรื่อง อีโก้ และหากมีใครยอมใช้เวลาดูโค้ด ก็มีความเป็นไปได้ว่าเขาพบบางสิ่งในนั้นที่ควรค่าแก่การติดตามต่อ
- เช่นเดียวกับเรื่อง Stone Soup หากแบ่งปันไอเดียดี ๆ กับคอมมูนิตี้ คนอื่น ๆ ก็สามารถรับไปและช่วยกันปรับปรุงได้
- คอมมูนิตี้สามารถรีแฟกเตอร์หรือแทนที่โค้ดที่ไม่ดีได้ และยังสามารถนำแนวทางคุณภาพโค้ดใหม่มาใช้ เพื่อให้กระบวนการมีส่วนร่วมหลังจากนั้นดีขึ้นด้วย
- สมาชิกที่เป็นพิษซึ่งเอาแต่บ่นเรื่องโค้ดโดยไม่เสนอการปรับปรุง ไม่ใช่สมาชิกคอมมูนิตี้ที่เราต้องการตั้งแต่แรก
- ผู้มีส่วนร่วมโอเพนซอร์สต่างมี “สุสาน” ของโปรเจกต์เก่า ๆ และสำหรับคนที่ต้องการสร้างสิ่งคล้ายกัน สิ่งเหล่านั้นกลายเป็น คลังไอเดียและแนวทาง
- บางคนอาจได้รับแรงบันดาลใจจากวิธีแก้ปัญหาเฉพาะบางอย่าง
- อย่างน้อยก็ช่วยลดเวลาที่ต้องเสียไปกับการทำผิดซ้ำเดิม
- โปรเจกต์เก่ามีแนวโน้มจะถูกนำไปใช้ให้เกิดประโยชน์ หรือไม่ก็ไม่ได้รับความสนใจเลย มากกว่าจะทำลายชื่อเสียง
โค้ดสาธารณะกับความปลอดภัย
- เมื่อให้บริการโซลูชันแบบโฮสต์ด้วยโค้ดสาธารณะ ความกลัวที่ใหญ่ที่สุดคือสถานการณ์ที่ผู้ไม่ประสงค์ดีอ่านโค้ด ค้นหาช่องโหว่ แล้วแฮ็กบริการ
- จากประสบการณ์ของ Supabase คำกล่าวของ Linus's law ที่ว่า “ถ้ามีสายตามากพอ บั๊กทั้งหมดก็จะตื้น” ใช้ได้กับ ปัญหาด้านความปลอดภัย ด้วย
- ตั้งแต่ช่วงแรก ๆ นักวิจัยด้านความปลอดภัยซึ่งมักไม่เปิดเผยตัวตนได้ช่วยตรวจดูโค้ดและแพลตฟอร์มเพื่อค้นหาปัญหาที่อาจเกิดขึ้น
- หากให้บริการ SaaS ควรมีคำแนะนำง่าย ๆ ไว้ที่
/.well-known/security.txtเพื่อให้นักวิจัยที่หวังดีรู้ว่าควรเปิดเผยปัญหาที่อาจเกิดขึ้นอย่างไร - ตัวอย่างของโปรเจกต์สาธารณะที่อาจปลอดภัยกว่าโค้ดเบสแบบปิดคือ Bitcoin
- Andreas M. Antonopoulos กล่าวใน การบรรยายปี 2015 ว่าระบบธนาคารแบบปิดมีภูมิคุ้มกันเชิงซอฟต์แวร์ที่อ่อนแอ
- ในระบบปิด ช่องโหว่ด้านความปลอดภัยขนาดใหญ่อาจถูกปิดบังไว้นาน และเมื่อถูกใช้โจมตีในท้ายที่สุดก็อาจสร้างความเสียหายใหญ่หลวง
- ในโปรโตคอลโอเพนซอร์สอย่าง Bitcoin ช่องโหว่ด้านความปลอดภัยจะมองเห็นได้สำหรับทุกคน และ exploit จะถูกพบตั้งแต่เนิ่น ๆ และบ่อยครั้ง จากนั้นจึงถูกแพตช์
- บริษัทซอฟต์แวร์ที่ประสบความสำเร็จอาจถูกสร้างขึ้นเป็นเวลามากกว่า 10 ปี ดังนั้นในระยะยาว ระบบโอเพนซอร์สอาจเข้าใกล้สถานะที่ปลอดภัยกว่าระบบปิดที่เก็บเป็นความลับ
- ในช่วงที่การแข่งขันจ้างวิศวกรความปลอดภัยฝีมือดีรุนแรงมาก คุณค่าของการตรวจสอบแบบสาธารณะก็ยิ่งเพิ่มขึ้น
ความกังวลเรื่องคู่แข่งและทรัพย์สินทางปัญญา
- ในซอฟต์แวร์ ไอเดียนั้นมีราคาถูก และมูลค่าแทบจะเกิดจาก การลงมือทำ ตามไอเดียนั้นเสมอ
- เมื่อแบ่งปันไอเดียกับโลก คุณสามารถเลิกกังวลว่าใครจะเข้าถึงโค้ดเบส แล้วหันไปโฟกัสกับการทำซ้ำให้เร็วขึ้นแทน
-
สร้างคอมมูนิตี้ผู้เชี่ยวชาญ
- หากต้องการสร้างบริษัทที่ประสบความสำเร็จ ต้องลงมือทำให้ดีและขยายฐานลูกค้าเป็นเวลานาน เช่น 10 ปี
- ในการแข่งขันระยะไกลนี้ ข้อได้เปรียบที่คู่แข่งได้จากการดูโค้ดเบสอาจไม่ได้มากนักเมื่อมองตลอดทั้ง 10 ปี
- ในช่วงเวลานั้น โค้ดเบสมีแนวโน้มจะถูกทำซ้ำและรีแฟกเตอร์หลายครั้ง
- ในระยะยาว วิธีชนะคือการสร้างทีมและคอมมูนิตี้ที่สามารถทำซ้ำและปรับปรุงโซลูชันของตนเองได้ดีที่สุดในโลก
-
ชนะในตลาด
- หากตลาดรวมที่เข้าถึงได้ (TAM) มีขนาดใหญ่ เติบโต และคุ้มค่าที่จะไล่ตามจริง ๆ ก็มีแนวโน้มต่ำที่จะเป็นสถานการณ์ผู้ชนะกินรวบ
- ต้องหากลุ่มผู้ใช้ที่สามารถทำให้ประทับใจได้ก่อน แล้วทำซ้ำอย่างรวดเร็ว
- เวลาที่ใช้โฟกัสกับคู่แข่งคือเวลาที่สามารถใช้ปรับปรุงผลิตภัณฑ์หรือทีมได้
- หากคู่แข่งสามารถ fork โปรเจกต์โอเพนซอร์สแล้วเปิดตัวได้เร็วกว่า ก็ควรมองว่าการแข่งขันนั้นถูกกำหนดให้แพ้อยู่แล้ว
- IP และสิทธิบัตรในซอฟต์แวร์ขึ้นชื่อว่าบังคับใช้ได้ยาก ดังนั้นหากลดความกังวลเรื่องการพยายามปกป้องไอเดียซอฟต์แวร์ด้วยทนาย ก็จะประหยัดเวลา เงิน และพลังใจได้
- ธุรกิจอาจได้รับการปกป้องได้ดีกว่าด้วยการนำไอเดียซอฟต์แวร์ไปใช้งานให้ดีที่สุดในโลก
-
การแข่งขันกับคลาวด์ในช่วงหลัง
- เมื่อโปรเจกต์เติบโตถึงขนาดพอสมควร อาจเผชิญสถานการณ์ที่ผู้ให้บริการคลาวด์รายใหญ่นำเสนอผลิตภัณฑ์ด้วยโมเดลการจัดจำหน่ายที่แข็งแกร่งกว่า เช่น Elastic หรือ Mongo
- ปัญหาที่ใหญ่ที่สุดของบริษัทที่เพิ่งเริ่มต้นคือการไปให้ถึงจุดนั้นก่อน
- หาก AWS ถึงขั้นดึงทรัพยากรจากหนึ่งในกลุ่มผลิตภัณฑ์ระดับหลายพันล้านดอลลาร์มาแข่งด้วยผลิตภัณฑ์โฮสติ้ง แปลว่าคุณกำลังทำได้ดีมากแล้ว
- การตอบสนองที่สร้างสรรค์กว่าคือการมองหาพื้นที่ล่วงหน้าที่สามารถนำหน้าใครก็ตามในการแข่งขันได้
- ผู้ให้บริการคลาวด์จำนวนมากมักมี ประสบการณ์นักพัฒนา (DX) ที่ไม่ดี จึงสามารถยึด DX เป็นความสามารถหลักได้
- หากอีก 6 ปี Google พยายามมาแย่งอาหารกลางวัน ในช่วงหลายปีก่อนหน้านั้น แบรนด์ ทีม และคอมมูนิตี้ควรเตรียมพร้อมสำหรับการต่อสู้แบบ David ปะทะ Goliath ไว้แล้ว
- ต้องวางแผนตั้งแต่ต้นเพื่อไม่ให้ถูกสถานการณ์แบบนี้จู่โจม และสามารถใช้เวลาและสมาธิเพื่อสร้างกลยุทธ์ในการชนะได้
- หากคู่แข่งมาหาไอเดีย พวกเขาจะตามหลังอยู่หนึ่งก้าวเสมอ และโดยเฉพาะในช่วงแรกที่ทรัพยากรขาดแคลน คุณจะยิ่งใช้พลังงานไปกับความกังวลเรื่องการแข่งขันมากขึ้น
ผลต่อการสรรหานักพัฒนา
- หนึ่งในปัญหาใหญ่ที่สตาร์ทอัพต้องเผชิญ ไม่ว่าจะมีขนาดใด คือความยากของ การสรรหานักพัฒนา
- การ sourcing ทำได้ยาก
- การประเมินนักพัฒนาทำได้ยาก
- การโน้มน้าวเรื่องระดับความสามารถของเพื่อนร่วมงานในอนาคตทำได้ยาก
- โอเพนซอร์สสามารถช่วยลดปัญหาการสรรหานักพัฒนาได้
-
การ sourcing แบบสาธารณะ
- นักพัฒนาทุกคนได้รับประโยชน์จากโอเพนซอร์ส และนักพัฒนาจำนวนมากต้องการตอบแทนประโยชน์นั้นด้วยการมีส่วนร่วมในโปรเจกต์โอเพนซอร์สที่น่าสนใจ
- เหตุผลในการมีส่วนร่วมอาจเป็นคอมมูนิตี้ที่ดี การเรียนรู้เทคโนโลยีใหม่ หรือความสนุกในการแก้ปัญหาเทคนิคที่ยากในโค้ดเบสที่ไม่คุ้นเคย
- หากลดอุปสรรคในการมีส่วนร่วมด้านโค้ดของโปรเจกต์โอเพนซอร์ส นักพัฒนาฝีมือดีอาจค้นพบโปรเจกต์นั้น
- ผู้มีส่วนร่วมสามารถเข้าร่วมการถกเถียงใน issue, แก้บั๊ก, ระบุปัญหา และรีวิว PR ได้
- ไม่ใช่ผู้มีส่วนร่วมทุกคนที่กำลังหางาน แต่หลายคนอาจถูกดึงดูดด้วยโอกาสที่จะได้ทำงานกับโค้ดโอเพนซอร์สแบบเต็มเวลา
- Supabase ดำเนินงานมานานกว่า 2 ปีและจ้าง นักพัฒนา 32 คน แล้วจึงเริ่มทำ outbound recruiting
- โอเพนซอร์สเป็นเส้นทางหลักในการค้นหาคนเก่งของ Supabase และจะยังเป็นเช่นนั้นต่อไป
- สำหรับบริษัทแบบ remote และ asynchronous กลยุทธ์การจ้างงานผ่านโอเพนซอร์สทำให้ความสามารถของผู้สมัครแสดงออกมาเอง และทำให้ตรวจสอบความสามารถนั้นได้ง่ายขึ้น
-
การมีส่วนร่วมจริงแทน LeetCode และแบบทดสอบงานมอบหมาย
- หนึ่งในสิ่งที่นักพัฒนาบ่นมากที่สุดเมื่อหางานถัดไป คือการต้องแก้โจทย์ LeetCode หรือทำแบบทดสอบงานมอบหมายระหว่างกระบวนการสัมภาษณ์
- วิธีเหล่านี้ใช้เวลามากและเหนื่อย อีกทั้งมักไม่ได้เป็นตัวแทนของงานที่จะทำจริง
- หากใครสักคนมีส่วนร่วมในรีโพซิทอรี ก็มีข้อมูลต่อไปนี้แล้ว
- ตัวอย่างวิธีสื่อสารกับทีมและสมาชิกคอมมูนิตี้ในสภาพแวดล้อมแบบ remote และ asynchronous
- ตัวอย่าง การมีส่วนร่วมกับโค้ดจริง
- ผู้สมัครก็สามารถมองบริษัทได้เช่นกัน
- ตรวจสอบได้ว่าทีมให้ความสำคัญกับคุณภาพโค้ดหรือไม่
- เห็นได้ว่าสื่อสารอย่างมีประสิทธิภาพหรือไม่
- ประเมินได้ว่าตัดสินใจทางเทคนิคได้ดีหรือไม่
- คนที่ถูกจ้างผ่านรีโพซิทอรีของ Supabase ทำให้ตนเองกลายเป็นคนที่ขาดไม่ได้ และบางคนได้นำการพัฒนารีโพซิทอรีเดิม หรือเริ่มสร้าง client library และ SDK ใหม่
- พวกเขาไม่จำเป็นต้องแก้โจทย์ LeetCode บน Zoom
การขยายฟีเจอร์สำหรับผู้ใช้กลุ่มเล็กและ integration
- เมื่อสร้างสตาร์ทอัพ มักมีเวลาแก้เฉพาะปัญหาที่ใหญ่ที่สุดเท่านั้น
- หากต้องการเคลื่อนที่อย่างรวดเร็ว ต้องโฟกัสสิ่งที่ฐานผู้ใช้ 80% ร้องขอ {p:80}
- ฟีเจอร์ที่ผู้ใช้กลุ่มเล็กขอมักถูกเลื่อนออกไปอย่างไม่มีกำหนด
- หากระบบเป็นโอเพนซอร์ส ผู้ใช้เหล่านี้สามารถมีส่วนร่วมสร้างฟีเจอร์เองได้ ทำให้ซอฟต์แวร์มีประโยชน์มากขึ้น
- ผลเช่นนี้มักเกิดขึ้นกับ integration และ adapter
- ผู้ใช้อาจต้องการ integration กับ Azure หรือ Vercel
- หากมีคนอื่นจัดหาทรัพยากรนักพัฒนาเพื่อสร้างการเชื่อมต่อนั้น ผู้ใช้ทุกคนของโปรเจกต์ก็ได้รับประโยชน์
ไม่ต้องสร้างล้อเดิมซ้ำแล้วซ้ำเล่า
- ในโลกที่ไม่มีโอเพนซอร์ส บริษัทเทคโนโลยีจะต้องประดิษฐ์ล้อขึ้นมาใหม่ซ้ำไปเรื่อย ๆ
- Supabase ไม่เพียงเผยแพร่โปรเจกต์ใหม่เป็นโอเพนซอร์ส แต่ยังพยายามสนับสนุนโปรเจกต์โอเพนซอร์สที่มีอยู่ก่อนจะสร้างขึ้นใหม่
- สถานการณ์ที่บริษัทรถยนต์ใช้ฟังก์ชันแบบปิด, องค์ประกอบ UI แบบปิด, ไลบรารีหน้าต่างแบบปิด, ระบบปฏิบัติการแบบปิด และไดรเวอร์แบบปิด เพื่อแสดงข้อความผิดพลาดที่แทบไม่มีใครได้เห็น เป็นการสูญเปล่าเวลาและความพยายามของนักพัฒนา
- Supabase Launch Week คือชุดผลลัพธ์จากงานที่ทีมและคอมมูนิตี้ทำในช่วง 3 เดือน ที่ผ่านมา และข้อดีของการดำเนินบริษัทโอเพนซอร์สปรากฏให้เห็นจากความเร็วในการคืบหน้าของคอมมูนิตี้
- ดูรายละเอียดเพิ่มเติมได้ใน โพสต์ Launch Week 4 และหากต้องการเข้าร่วม สามารถไปที่ Supabase GitHub
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตรงนี้มีสมมติฐานใหญ่ซ่อนอยู่เรื่อง ความสามารถในการทำกำไรอย่างยั่งยืน และโดยเฉพาะเมื่อคำนึงถึงความเป็นจริงอย่างเงินเดือนนักพัฒนาในสหรัฐฯ ก็มีบางส่วนที่ไม่ตรงกับความรู้สึกจริง
สรุปคือบริษัทโอเพนซอร์สต้องถูกฟ้าผ่าสองครั้ง ครั้งหนึ่งลงที่โปรเจกต์โอเพนซอร์ส และอีกครั้งลงที่บริษัท
ทีม Graphistry ชอบและทำงานกับโอเพนซอร์สทุกวัน เคยช่วยเริ่มโปรเจกต์ที่ต่อยอดไปเป็น Apache Arrow และ Nvidia RAPIDS และยังเปิดซอร์สไคลเอนต์ Python/JS ด้วย PyGraphistry[AI] เป็นเหมือนมีดสวิสอาร์มีสำหรับกราฟ และยังรวมเครื่องมืออย่าง GFQL ที่นำภาษา query กราฟ Cypher มาทำให้ฝังใช้งานได้ เป็นแบบเนทีฟกับ dataframe และเร่งด้วย GPU ได้ด้วย
แต่การเติบโตที่ยั่งยืนส่วนใหญ่มาจากการขายไลเซนส์ self-hosted แบบคลาวด์/ออนพรีมิสของ เซิร์ฟเวอร์แสดงผลกราฟด้วย GPU ให้กับองค์กร รัฐบาล และบริษัทข้อมูล หลังจากประคองมาหลายปี โชคดีที่ธุรกิจนี้กำลังเติบโตได้ดี และรายได้จาก SaaS hosting อย่างเดียวก็พอเลี้ยงทีมเล็ก ๆ ได้ แต่ไม่พอสำหรับทีมส่วนใหญ่ ถ้าไม่มีรายได้จากไลเซนส์ self-hosted วงจรนวัตกรรมส่วนใหญ่ก็คงหายไป
บทความนี้ให้ความรู้สึกว่าพลาดจุดตัดระหว่างโชคแบบถูกลอตเตอรี่ ลักษณะตลาด SaaS และความสามารถในการป้องกันเชิงเทคนิค ไม่ได้หมายความว่าเป็นไปไม่ได้ เพราะในกรณีของเรา การเปิดตัว Louie.AI และ GFQL กำลังเปลี่ยนความเป็นไปได้ทางธุรกิจของโอเพนซอร์ส แต่จากประสบการณ์ที่มาถึงตรงนี้ ผมเป็นห่วงผู้ก่อตั้งหน้าใหม่ที่อ่านบทความนี้
[1] https://graphviz.org/
กล่าวคือ ประเด็นสำคัญคือถ้าบอกว่า “ตอนนี้เราจะเปิดซอร์สแล้ว” ลูกค้าเหล่านั้นจะตอบว่า “ดีเลย งั้นเราขอยกเลิกสัญญา” หรือไม่
มีประโยคว่า “เมื่อคุยเรื่องโมเดลธุรกิจโอเพนซอร์สกับผู้ก่อตั้งรายอื่น ๆ มีความกังวลสามอย่างที่วนกลับมาซ้ำ ๆ: อาจถูกวิจารณ์เรื่องโค้ดที่รก แย่ หรือยังไม่เสร็จ แฮกเกอร์อาจหาช่องโหว่ด้านความปลอดภัยแล้วนำไปใช้ และคู่แข่งอาจขโมยทรัพย์สินทางปัญญา” แต่ผมว่าขาดข้อที่สี่ไป
นั่นคือ Amazon/AWS อาจเอาโค้ดของผมไปต่อยอดเป็นบริการเชิงพาณิชย์แล้วขาย โดยไม่จ่ายอะไรเลย
เวลาคุยกับผู้ใช้และรับฟีดแบ็กก็รักษามารยาท แต่ในใจคิดว่า “พูดน่ะง่าย ฉันนี่แหละที่ลงมือทำจริง เงียบไปหรือส่ง PR มา” และก็ไม่น่าแปลกที่คนพวกนั้นแทบไม่เคยส่ง PR มาเลย
ทำงานที่เป็น การลงมือสร้างจริง ต่อไป แล้วปัดคนที่เอาแต่ตำหนิทิ้งก็พอ
[0] - https://heywillow.io/
ถ้าบริษัทใหญ่ ๆ พยายามลอกตาม ก็แปลว่าคุณกำลังชนะอยู่แล้ว และควรมีแผนล่วงหน้าเพื่อบรรเทาความเสี่ยงนี้ อย่างไรก็ดี ถ้าผมตีความบทความถูก ก็เหมือนจะหมายความว่านี่ไม่ใช่ปัญหาที่ควรโฟกัสหรือกังวลในช่วงเริ่มต้น
ที่บริษัทคลาวด์กลืนผลิตภัณฑ์โอเพนซอร์สอื่น ๆ เข้าไปได้ ก็เพราะผลิตภัณฑ์เหล่านั้นไม่ได้เลือกไลเซนส์ที่ปกป้องผลงานของตัวเองอย่างเหมาะสม
เป็นบทความที่ดีและลึกมาก แต่มีอย่างหนึ่งที่หลายโปรเจกต์มองข้าม: ขายให้ภาครัฐพลเรือนก็ได้
รัฐบาลสหรัฐฯ มีโปรแกรมด้านเทคโนโลยีจำนวนมาก เช่น ทุน NSF และหน่วยงานพลเรือน หน่วยข่าวกรอง รวมถึงรัฐบาลมลรัฐต่างก็แยกส่วนกัน ทำให้ท้ายที่สุดเกิดภูมิทัศน์การจัดซื้อซอฟต์แวร์ที่กว้างมหาศาล อุปสรรคด้านกฎระเบียบและ compliance ก็ไม่ได้สูงอย่างที่คิด โดยเฉพาะถ้าดีลแรก ๆ ทำร่วมกับพาร์ตเนอร์ได้ โดยทั่วไปเป็นรายได้ที่มั่นคงและรับประกันได้จากสัญญา 3–5 ปี ซึ่งช่วยให้มีเงินสนับสนุนโปรเจกต์ และความสามารถในการทำกำไรก็สูงมาก
อยากให้บริษัทโอเพนซอร์สใช้ประโยชน์จากสิ่งนี้มากขึ้น เพราะบริษัทเอกชนล้วน ๆ มักเอาไลบรารีโอเพนซอร์สไปใส่ในผลิตภัณฑ์ของตัวเอง แล้วขายพร้อมมาร์จินมหาศาล กวาดทุกอย่างไปหมด
ตัวอย่าง: https://x.com/ssankar/status/1749202248700420587?s=20
ตอนอยู่ในรัฐบาล ผมเห็นซอฟต์แวร์จำนวนมากที่โดยเนื้อแท้แล้วคือแผนที่โอเพนซอร์ส + ฐานข้อมูลโอเพนซอร์ส แต่มีมูลค่า 12 ล้านดอลลาร์ ตามเกณฑ์อื่น ๆ ก็เคยเห็น PDF OCR ราคา 2 ล้านดอลลาร์ต่อปี และเครื่องมือแบบ weights & biases ราคา 30 ล้านดอลลาร์ต่อปี
นอกจากการ deploy ซอฟต์แวร์แล้ว ยังมีแรงจูงใจอื่นด้วย เช่น การแก้บั๊กหรือช่องโหว่ด้านความปลอดภัยบางอย่างเป็นลำดับแรก หน่วยข่าวกรองมีแนวโน้มสูงว่าจะจ่ายเงินก้อนใหญ่ให้ safetensors
เส้นทางสี่แบบที่ Supabase ทำได้คือ ขายตรงให้ Cybercom, ขายตรงให้ DOS หรือทำสัญญาแบบทีม, ขายให้ VA ผ่าน PWS, และขายตรงให้ผู้รับเหมาซอฟต์แวร์รายใหญ่ของรัฐบาล
วิธีลงมือคือส่ง cold email ไปหา GS 14/15 หรือระดับเทียบเท่า, จ้างอดีต GS15, หรือหา bid ที่เหมาะใน SAM.gov แล้วทำข้อเสนอ โดยใช้ GovPro.ai แบบ full-service หรือใช้ rogue แบบจัดการเอง
กว่าระบบราชการของรัฐบาลจะอนุมัติสัญญาขั้นสุดท้าย สตาร์ตอัปส่วนใหญ่ก็น่าจะเงินหมดไปแล้ว
สัญญาอาจทำกำไรได้ดี แต่ ขั้นตอนราชการ มหาศาลมาก และต้องมีคนที่มีประสบการณ์จัดการเรื่องนี้ ไม่ใช่เส้นทางที่เหมาะกับทุกคน และต้องใช้เวลาและการเจรจามาก
ยังไม่ต้องพูดถึงระบบราชการขนาดใหญ่ รัฐบาลกลางเป็นองค์กรรัฐที่ใหญ่ที่สุด ช้าที่สุด และจัดการยากที่สุด ในสหรัฐฯ อย่างเดียวก็มีหน่วยงานรัฐอื่น ๆ อีกหลายหมื่นแห่ง เช่น โรงเรียน เมือง เคาน์ตี มลรัฐ เขตน้ำประปาและดับเพลิง ห้องสมุด เป็นต้น
ถ้าอยากเข้าสู่ภาครัฐ การเข้าหาแบบเล็กและกว้างน่าจะดีกว่าการทุ่มทั้งหมดไปที่หน่วยงานใหญ่ที่สุด
ภาครัฐที่ทำกำไรสูงที่สุดในโลกคือ กระทรวงกลาโหมสหรัฐฯ
แต่กระทรวงกลาโหมก็มีระบบราชการอย่างเหลือเชื่อ อ่อนไหวกับกำหนดการ และหมกมุ่นกับความลับ
โมเดลธุรกิจของ Supabase คือการทำการตลาดตัวเองว่าเป็นบริษัทโอเพนซอร์ส แต่ในความเป็นจริง ถ้ายังสติปกติอยู่ก็คงไม่มีใครอยากโฮสต์เองเพื่อใช้งานจริงในโปรดักชัน
เพราะมีสิ่งอย่างเอกสารที่ขาดไปเล็ก ๆ น้อย ๆ บั๊กแบบละเอียดอ่อน ฟีเจอร์สำคัญที่ขาดหายไปแบบไม่เด่นชัด เป็นต้น ดังนั้นแม้จะได้รับคำชื่นชมว่าเป็นโอเพนซอร์ส แต่ในทางปฏิบัติกลับไม่ค่อยใช้ได้จริง และมองได้ว่าเป็นแค่ เครื่องมือการตลาด
ข้อแรกคือ ความอุ่นใจ แม้ตอนนี้จะไม่ได้โฮสต์เอง แต่ก็มีทางออกเพิ่มอีกทางหากไม่พอใจกับบริการ แน่นอนว่าต้องให้เข้าถึงข้อมูลดิบได้ด้วย
ข้อสองคือคุณภาพโค้ด ถ้าเคยรับมือกับโค้ดที่ดูภายนอกทำงานได้ดีแต่ข้างในแย่มาก ก็จะรู้ว่าการมีโค้ดที่เปิดเผยได้โดยไม่อายสำคัญแค่ไหน
ข้อสามคือความเป็นไปได้ในการมีส่วนร่วม เมื่อก่อนอาจมองว่าไม่ใช่เรื่องใหญ่ แต่พอเจอจริงหลายครั้ง ก็รู้ว่าการสามารถร้องขอหรือมีส่วนร่วมเองได้เมื่อมีฟีเจอร์ขาดหาย บั๊ก หรือปัญหาประสิทธิภาพนั้นสำคัญมาก ในโปรเจกต์ซอร์สปิดส่วนใหญ่ แค่มีช่องทางให้ขอฟีเจอร์อย่างโปร่งใสก็ถือว่าโชคดีแล้ว
เมื่อเกินจุดวิกฤตบางอย่าง ผู้คนอาจตัดสินใจทุ่มแรงไปกับการ fork ได้ MariaDB เป็นตัวอย่างแบบนั้น
มีคนที่บอกกับเราโดยตรงด้วยว่า สิ่งนั้นเองทำให้พวกเขารู้สึกสบายใจที่จะใช้บริการแบบ managed ของบริษัทเรา
การเป็นบริษัทโอเพนซอร์สที่ถูกต้องและเป็นของจริงดูง่ายกว่ามาก
ถ้าไม่ได้หมายความแบบนั้นและผมอ่านผิดไป เนื้อหาที่เหลือกลับทำให้ Supabase ดูดีมาก
ในเชิงพาณิชย์อาจเป็นไปไม่ได้ แต่สภาพปัจจุบันกำลังกัดกร่อนมาตรฐานที่คาดหวังได้จากซอฟต์แวร์โอเพนซอร์สอย่างรุนแรง และก็ไม่เห็นประโยชน์ระยะยาวที่ชัดเจนสำหรับบริษัทที่เลือกแนวทางนี้ด้วย
แม้นักพัฒนาจะไม่ได้รันเอง ก็ทำให้เห็นโค้ดที่ทำงานอยู่จริงได้
ผมชอบ Supabase และชอบโอเพนซอร์สเชิงพาณิชย์โดยรวม อีกทั้งเห็นด้วยกับหลายส่วนของบทความ
แต่ส่วนที่ว่า “ในซอฟต์แวร์ ไอเดียนั้นถูก คุณค่าแทบจะเกิดจากการลงมือทำไอเดียเสมอ” ฟังดูขัด ๆ
ประโยคนี้เคยได้ยินในสถานการณ์ทำนอง “ผมมีไอเดียสตาร์ทอัพเจ๋ง ๆ แต่ก่อนเล่า ช่วยเซ็น NDA ก่อนได้ไหม?”
แต่ถ้าเปิดซอฟต์แวร์เป็นโอเพนซอร์ส นั่นไม่ใช่แค่การมอบไอเดีย แต่ยังมอบ ผลลัพธ์จากการลงมือทำส่วนใหญ่ ของไอเดียนั้นด้วย
แน่นอนว่าโค้ดไม่ใช่ทั้งหมดของการลงมือทำ และยังขยายไปถึงการขาย การตลาด การสนับสนุน ฯลฯ แต่บทความนี้ดูประเมินคุณค่าของโค้ดต่ำเกินไป และบอกเป็นนัยว่าถ้าไม่มีการขาย/การตลาด ฯลฯ ก็ไร้ค่า ซึ่งผมคิดว่าไม่จริง
ถ้าจะแบ่งคุณค่า ผมมองว่า การขาย/การตลาด/การตรวจสอบกับลูกค้า 90% โค้ดประมาณ 10% ผมกำลังทำ SaaS แบบ bootstrapped ที่มีรายได้ระดับเจ็ดหลักต้น ๆ อยู่ และบอกได้ว่าโค้ดโดยรวมค่อนข้างเละและวิวัฒนาการไปเรื่อย ๆ
บ้านคัดลอกฟรีไม่ได้ แต่ซอฟต์แวร์ทำได้
สิ่งที่นักพัฒนาได้รับเงินคือกระบวนการสร้างโค้ด และการแก้ปัญหาเล็ก ๆ น้อย ๆ ที่มองไม่เห็น
นั่นจึงเป็นเหตุผลที่การขายซอฟต์แวร์ทำกำไรได้สูงมาก ถ้าไม่ขายซอฟต์แวร์ ก็ทำเงินจากมันไม่ได้ ซอฟต์แวร์ไม่เหมือนสิ่งของทางกายภาพในความเป็นจริงที่เราแบ่งปันกัน
สำหรับผม คำถามสำคัญไม่ใช่ว่าโค้ดดีพอไหม หรือคู่แข่งจะลอกไหม แต่คือ จะทำเงินได้พอสร้างธุรกิจที่ยั่งยืนหรือไม่
โปรเจกต์โอเพนซอร์สที่ถูกอ้างถึงและเป็นที่รักไม่ใช่ธุรกิจที่ดี: PostgreSQL, Python, Bitcoin, React
Mongo และ Elastic ยอดเยี่ยม แต่เป็นข้อยกเว้น มีบริษัทฐานข้อมูลซอร์สปิดที่ประสบความสำเร็จมากกว่าบริษัทฐานข้อมูลโอเพนซอร์ส
บริษัทโอเพนซอร์สนั้นยาก แต่มีคุณค่ามากสำหรับผู้ใช้
ถ้าพักประเด็นถกเถียงว่าไลเซนส์แบบไหนคือ “โอเพนซอร์ส” ไว้ สิ่งสำคัญคือบริษัทเหล่านี้ตัดสินว่าไลเซนส์ที่ใช้กันแพร่หลายอย่าง (A)GPL, Apache, MIT เปิดช่องให้คู่แข่งสร้างบริการ managed/hosting และแข่งขันด้วยสเกลได้มากเกินไป เช่นกรณีที่ Amazon ให้บริการ OpenSearch ซึ่งถูกกว่า ElasticSearch
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
คำถามนี้ดูเหมือนจะหมายถึง “บริษัทของเราควรเปิดเผยซอร์สของซอฟต์แวร์หรือไม่?”
แต่สำหรับผม การตอบคำถามเดิมให้เส้นทางไปสู่การตอบคำถามที่เขียนใหม่ได้ คำถามเดิมเกี่ยวกับลักษณะของ ซอฟต์แวร์ที่บริษัทใช้ ไม่ใช่ซอฟต์แวร์ที่บริษัทขาย
โดยส่วนตัว ถ้ามีทางเลือก ผมจะเลือกผลิตภัณฑ์โอเพนซอร์สเสมอ แม้จะยินดีจ่ายค่าซัพพอร์ตหรือบริจาคให้โปรเจกต์ก็ตาม สิทธิ์เข้าถึงซอร์สได้อย่างเสรีมีความสำคัญในระดับพื้นฐาน แม้กับซอฟต์แวร์ที่ผมไม่มีความตั้งใจจะแก้ไขเลยก็ตาม
ผมรู้ว่าสำหรับหลายคนมันดูเหมือนจุดยืนสุดโต่ง แต่ผมไม่ชอบความคิดที่ว่าเราแยกไมโครเวฟ ลูกบิดประตู หรือกระปุกเกียร์ออกมาดูไม่ได้ อาจจะประกอบกลับให้ถูกต้องไม่ได้ก็จริง แต่ก็อาจหาเฟืองที่บิ่นแล้วซ่อมด้วยเงิน 2 ดอลลาร์ แทนการเปลี่ยนอะไหล่ 90 ดอลลาร์ได้ หรือไม่ก็อาจสร้างไมโครเวฟแฟรงเกนสไตน์ที่มีกระปุกเกียร์ติดอยู่ก็ได้
การขยายความสามารถของเว็บเซิร์ฟเวอร์ หรือการเข้าใจว่าทำไมปลั๊กอินของผมทำให้แอปโฮสต์แครช เป็นเรื่องสำคัญสำหรับผม ผมคิดว่ามันสำคัญต่อสังคมด้วย ดังนั้นผมจึงยังยึด ความสุดโต่งด้านโอเพนซอร์ส ของตัวเองไว้ ต่อให้มีคนเอาเว็บเซิร์ฟเวอร์จิ๋วรุ่นล่าสุดที่จัดการ HTTPS/4 ได้ใน 5KB ด้วย AI ฝังตัวมาให้ดู ผมคงสนใจ แต่ถ้าไม่ใช่โอเพนซอร์ส ผมก็จะใช้สแต็กเดิมต่อไป
ด้วยแนวคิดแบบนี้ ซอฟต์แวร์ที่ผมสร้างจึงเป็นโอเพนซอร์ส และบางครั้งผู้คนก็จ่ายเงินให้มัน
ในประเด็นที่ว่า “ถ้าอีก 6 ปีข้างหน้า Google จะมาขโมยมื้อเที่ยงของคุณ คุณก็ควรมีแบรนด์ ทีม และคอมมูนิตี้ที่เตรียมพร้อมสำหรับการต่อสู้แบบดาวิดกับโกลิอัทมาตลอดหลายปีที่ผ่านมา” จากประสบการณ์ของผม สิ่งอย่างแบรนด์ คอมมูนิตี้ ทีม และประสบการณ์ของนักพัฒนาแทบไม่มีความหมายสำหรับฝ่ายจัดซื้อเมื่อเทียบกับ คอมpliance
โดยเฉพาะอย่างยิ่งถ้าต้องชนตรง ๆ กับผู้ให้บริการเดิมอย่าง Google
ในกรณีของ Supabase จริง ๆ แล้วตลอดหลายปีที่ผ่านมาได้เตรียมคอมpliance อย่าง SOC2, HIPAA, GDPR เพื่อรองรับข้อกำหนดแบบนี้อยู่แล้ว ดังนั้นจึงเป็นการชี้ประเด็นที่ถูกต้อง
ผลิตภัณฑ์ของเราก็ครุ่นคิดเรื่องนี้มาเหมือนกัน สักวันหนึ่งตั้งใจจะเปิดซอร์สทั้งหมดภายใต้ไลเซนส์ MIT หรือ Apache แล้วแต่ว่าตอนนั้นชอบแบบไหน และได้เปิดเผยเรื่องนี้ไว้บนเว็บไซต์แล้วด้วย ไม่ใช่แนวทางแบบ AGPL หรือ open core
แต่ผมรู้สึกว่าการทำเงินจากผลิตภัณฑ์ด้วยโครงสร้างแบบนั้นเป็นไปไม่ได้เลย และจากประสบการณ์ก่อนหน้านี้ก็เป็นแบบนั้นด้วย งานคอนซัลต์อาจทำได้ แต่ผลิตภัณฑ์เป็นอีกเรื่อง Supabase ได้รับเงินลงทุน VC จำนวนมหาศาล และแทบทุกโปรเจกต์โอเพนซอร์ส “ใหญ่ ๆ” ก็เช่นกัน
ถ้าเป็นการบูตสแตรป โดยเฉพาะโปรเจกต์ที่ทะเยอทะยานและยาก ช่วงหนึ่งจะยังออกบิลเก็บเงินไม่ได้ คนเรามีช่วงเวลาจำกัดที่จะทำงานฟรีได้ และถ้าทีมเล็ก ๆ สื่อสารกันอย่างใกล้ชิดอยู่ตลอดบนโค้ดที่ไม่เปิดเผย ก็จะลด overhead ที่จำเป็นสำหรับโปรเจกต์โอเพนซอร์สที่ประสบความสำเร็จได้ และเคลื่อนไหวได้เร็วกว่ามาก
อยากได้ยินตัวอย่างโปรเจกต์ที่มีขนาดใกล้เคียงกัน เงินลงทุน 0 ดอลลาร์ เริ่มภายใน 5 ปีที่ผ่านมา มีทีมเต็มเวลาอย่างน้อย 2 คน ดำเนินต่อเนื่องมาเกิน 3 ปี และยังคงแนะนำแนวทางนี้อยู่ อยากรู้ว่าพวกเขาหาเลี้ยงชีพกันอย่างไร ผมคิดว่าสิ่งแบบ Redis จะไม่เกิดขึ้นอีกแล้ว อย่างน้อยผมก็ไม่เคยเห็น แม้แต่โปรเจกต์เรียบง่ายอย่าง langchain ยังได้รับเงินลงทุน VC หลายสิบล้านดอลลาร์ ทั้งที่ผมเคยคิดว่าโปรเจกต์แบบนั้นแหละน่าจะเป็นตัวเลือกที่ทีมไม่กี่คนสามารถลองทำเงินจากหลายแหล่งรายได้ได้
ซอฟต์แวร์ของผมทั้งหมดเผยแพร่เป็น public domain หรือก็คือซอฟต์แวร์เสรี แต่ไม่มีชิ้นไหนกลายเป็นโปรเจกต์โอเพนซอร์สหรือคอมมูนิตี้ที่ประสบความสำเร็จเลย ซอฟต์แวร์เสรีเหนือสิ่งอื่นใดคือ อุดมการณ์ ก่อน แล้วจึงค่อยเป็นการปฏิบัติหรือฟีเจอร์
ผมมองว่าการทำบริษัทให้เป็นโอเพนซอร์สไม่สมเหตุสมผล เว้นแต่จะทำผลิตภัณฑ์ที่มุ่งเป้าไปที่นักพัฒนา หรือเป็นผลิตภัณฑ์ที่ในความเป็นจริงแทบไม่มีใครจะโฮสต์เอง
Supabase เป็นตัวอย่างชัดเจนของทั้งสองข้อ ส่วนตัวอย่างของข้อหลังคือ Plausible Analytics ซึ่งสามารถโฮสต์เองได้ ผมเองก็ทำแบบนั้นด้วย Coolify.io อยู่ แต่ถ้าไม่สร้างระบบ CI/CD ของตัวเองเพื่อดึงและ merge อัปเดตจาก release ก็จะพลาดอัปเดตไป