โอเพนซอร์สไม่ได้ชนะเพราะราคาถูกกว่า
(github.com/getlago)- บริษัทโอเพนซอร์สเชิงพาณิชย์อยู่รอดระยะยาวได้ยาก หากมีเพียงผลิตภัณฑ์ทดแทนที่เอาผลิตภัณฑ์เสียเงินเดิมมาติด MIT License เท่านั้น และจำเป็นต้องมีเหตุผลว่าทำไมจึงต้องเป็นโอเพนซอร์ส หรือมีคุณภาพผลิตภัณฑ์ที่เหนือกว่า
- ต่างจากโปรเจ็กต์ไม่แสวงหากำไรหรือโปรเจ็กต์ที่พึ่งพาการสนับสนุนทางการเงิน ธุรกิจโอเพนซอร์สจำเป็นต้องมี รายได้ เพื่อจ้างคน เติบโต และพัฒนาต่อเนื่องได้
- บริษัทระยะเริ่มต้นมักเลือก free tier หรือเวอร์ชันโอเพนซอร์สได้ง่าย ขณะที่องค์กรใหญ่ก็มองค่าใช้จ่าย SaaS เป็นรายการในงบประมาณ ดังนั้นแค่ ราคาถูกกว่า อย่างเดียวมักไม่พอจะเปลี่ยนการตัดสินใจซื้อ
- จุดที่โอเพนซอร์สแข็งแกร่งคือเมื่อซอร์สแบบปิดสร้าง ปัญหาความโปร่งใส ที่บั่นทอนความเชื่อมั่นของลูกค้า และเมื่อมี ปัญหาด้านการขยายต่อ ที่ต้องอาศัยการเชื่อมต่อหรือปลั๊กอินจำนวนมาก
- กรณีของ PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte และ Elastic แสดงให้เห็นว่าโอเพนซอร์สสามารถพัฒนาเป็นผลิตภัณฑ์ที่ดีกว่าได้ผ่านความสามารถในการตรวจสอบ การโฮสต์เอง และการมีส่วนร่วมจากชุมชน
แค่เป็นผลิตภัณฑ์ทดแทนแบบโอเพนซอร์สยังไม่พอ
- คำอธิบายอย่าง “Stripe Billing เวอร์ชันโอเพนซอร์ส” หรือ “Chargebee เวอร์ชันโอเพนซอร์ส” มีประโยชน์ในการทำให้เข้าใจผลิตภัณฑ์ได้เร็ว แต่ไม่แข็งแรงพอที่จะใช้เป็นฐานให้ธุรกิจอยู่รอด
- เครื่องมือโอเพนซอร์สเชิงพาณิชย์พึ่งพาตำแหน่งทางการตลาดแบบเป็นเพียง ทางเลือกโอเพนซอร์ส ของผลิตภัณฑ์เสียเงินที่ประสบความสำเร็จอยู่แล้วได้ยาก
- แค่ให้นักพัฒนาลอกแบบผลิตภัณฑ์แล้วติด MIT License ก็ยังไม่พอ และการเป็นโอเพนซอร์สเองก็ไม่ได้รับประกันความสำเร็จ
- ประเด็นที่พูดถึงคือโปรเจ็กต์ โอเพนซอร์สเชิงพาณิชย์ ที่แข่งขันกับโซลูชันเสียเงินยอดนิยม
- ผลิตภัณฑ์ที่ขับเคลื่อนโดยชุมชนหรือได้รับการสนับสนุน เช่น React, TypeORM, VSCode มีลำดับความสำคัญต่างออกไป
- React ได้รับการสนับสนุนจากองค์กรขนาดใหญ่กว่าอย่าง Meta และ TypeORM หาเงินพัฒนาผ่านการบริจาค
- โดยเนื้อแท้แล้วโปรเจ็กต์เหล่านี้ไม่ใช่ธุรกิจ
- หากบริษัทโอเพนซอร์สจะประสบความสำเร็จ ต้องมีเหตุผลชัดเจนว่าทำไมต้องเป็นโอเพนซอร์ส หรือไม่ก็ต้องเหนือกว่าคู่แข่ง
เกณฑ์ความสำเร็จไม่ใช่จำนวนผู้ใช้ แต่คือรายได้
- หากไม่นับโปรเจ็กต์ไม่แสวงหากำไรที่ได้รับเงินบริจาคหรือการสนับสนุนจากบริษัทแม่ เกณฑ์สุดท้ายของธุรกิจโอเพนซอร์สทั่วไปคือ รายได้
- บริษัทแสวงหากำไรใช้รายได้เพื่อจ้างพนักงาน ขยายตัว ทำให้ธุรกิจยั่งยืน และพัฒนาต่อเนื่อง
- บริษัทที่สร้างซอฟต์แวร์ฟรีแต่ยังทำรายได้ได้ถือเป็นตัวอย่างเชิงบวก และบริษัทโอเพนซอร์สเองก็ไม่ได้ต้องการเอาเปรียบลูกค้าเกินควร แต่ต้องการให้ธุรกิจเดินต่อไปได้
- MongoDB เติบโตเป็นบริษัทฐานข้อมูลขนาดใหญ่ที่มีพนักงานมากกว่า 4,600 คน
- ต่อมาบริษัทเปลี่ยนไปใช้ SSPL License เพื่อจำกัดไม่ให้ Cloud Provider นำโปรเจ็กต์ไปเปิดบริการโดยไม่ร่วมพัฒนาให้โปรเจ็กต์
- แม้ SSPL จะไม่ได้รับการรับรองจาก OSI แต่ก็ถูกอธิบายว่าในทางปฏิบัติยังใกล้เคียงโอเพนซอร์ส
- เมื่อต้องวัดความสำเร็จระยะยาว ควรแยก อัตราการยอมรับใช้งาน ออกจากรายได้
- แม้โปรเจ็กต์จะมีการใช้งานสูง แต่ถ้าสร้างรายได้ไม่ได้ ก็อาจหายไปได้
- มุมมองนี้เห็นว่าความคาดหวังว่าชุมชนจะเข้ามารับช่วงโปรเจ็กต์ต่อมีหลักฐานรองรับอยู่น้อยมาก
ความถูกไม่ใช่สนามแข่งขันที่ยั่งยืน
- กลยุทธ์ที่มุ่งจับเฉพาะลูกค้าที่อ่อนไหวต่อราคานั้นแทบจะเป็น เกมที่แพ้ตั้งแต่ต้น
- ในกรณีสมมุติที่สร้างเวอร์ชันโอเพนซอร์สของ Amplitude ก็อาจให้เหตุผลได้ว่า Amplitude แพงเกินไป เป็นภาระกับบริษัทเริ่มต้น และองค์กรใหญ่ก็ประหยัดเงินได้เช่นกัน
- แต่บริษัทเริ่มต้นไวต่อราคาอยู่แล้ว จึงมีแนวโน้มเลือกเวอร์ชันโอเพนซอร์สหรือ free tier ซึ่งไม่พอจะค้ำจุนธุรกิจ
- กลยุทธ์สร้างทางเลือกที่ถูกกว่ามักใกล้เคียงกับการซื้อตั๋วสู่การล้มละลายในอนาคต
- โดยทั่วไปองค์กรใหญ่ก็ไม่ได้กังวลว่าค่า Amplitude จะทำให้บริษัทล้มละลาย
- ในการเจรจาสัญญา อาจพิจารณาราคาให้อยู่ในงบประมาณได้
- แต่ SaaS ส่วนใหญ่สุดท้ายก็เป็นเพียงหนึ่งในรายการค่าใช้จ่าย
- สิ่งที่สำคัญกว่าคือ เป็นโซลูชันที่ดีหรือไม่ จะอยู่รอดระยะยาวหรือไม่ และดูแลง่ายหรือไม่
- การติดตั้งใช้งานโซลูชันโอเพนซอร์สอาจดูแลจัดการได้ยาก
- ข้อยกเว้นคือกรณีที่ค่าใช้จ่ายของโซลูชันนั้นกินสัดส่วนใหญ่มากของงบทั้งหมด
- ตัวอย่างคือบริษัทที่ต้องลด Oracle เพราะค่าใช้จ่ายพุ่งสูงจากการใช้งานฐานข้อมูล
- แต่โซลูชันโอเพนซอร์สส่วนใหญ่มักไม่ได้มาแทน 3 อันดับแรกของต้นทุนทั้งหมด จึงยากที่ราคาจะเป็นเกณฑ์ตัดสินใจอันดับหนึ่ง
วิธีแรกที่โอเพนซอร์สชนะ: ความโปร่งใส
- กรณีตัวอย่างสำคัญที่ทำให้โซลูชันโอเพนซอร์สแข็งแกร่ง คือเมื่อซอร์สแบบปิดก่อให้เกิด ปัญหาความโปร่งใส ที่สร้างความไม่ไว้วางใจระหว่างลูกค้ากับผู้ขาย
- ตัวเลือกโอเพนซอร์สของ Amplitude คือ PostHog
- PostHog เติบโตโดยมี Airbus, DHL และ Staples เป็นลูกค้า
- รวมโซลูชันผลิตภัณฑ์ SaaS หลายตัวไว้ด้วยกันและให้บริการแบบโอเพนซอร์ส
- แม้แต่ซอร์สโค้ดของบล็อกและ roadmap ก็เปิดเผยต่อสาธารณะ
- PostHog วางตัวเป็นผลิตภัณฑ์ที่ดีกว่าคู่แข่ง เพราะเครื่องมือวิเคราะห์ต้องจัดการข้อมูลลูกค้าที่อ่อนไหว เช่น IP address, ชื่อ และ session recording
- ในสภาพแวดล้อมที่มีกฎระเบียบด้านข้อมูลอย่าง GDPR และ CCPA เพิ่มมากขึ้น การให้บุคคลที่สามเก็บข้อมูลประเภทนี้อาจเป็นภาระ
- PostHog ให้ทางเลือกสองแบบ
- โฮสต์โซลูชันวิเคราะห์แบบ self-hosting ด้วยตนเอง
- จ้าง PostHog เป็นบุคคลที่สาม แต่ยังคงได้ความโปร่งใสทั้งในวิธีจัดเก็บข้อมูลและวิธีย้ายไปสู่การโฮสต์เองในอนาคต
- แม้วิธีที่เป็นมิตรกับความเป็นส่วนตัวมากที่สุดจะเป็นการโฮสต์เอง แต่หลายบริษัทก็ยังอาจเลือกโมเดลแบบโฮสต์
- ถึงอย่างนั้นก็ยังเห็นได้ว่าซอฟต์แวร์ทำงานอย่างไรในระดับบรรทัดต่อบรรทัด
- และรู้ขั้นตอนว่าจะย้ายไปยังโมเดล self-hosting เมื่อจำเป็นได้อย่างไร
- บริษัทโอเพนซอร์สไม่ได้ชนะเพราะทำให้ไม่ต้องมีบุคคลที่สาม แต่ชนะด้วยการเปิดให้ตรวจสอบการทำงานได้ จนสร้างความเชื่อมั่น
ตัวอย่างผลิตภัณฑ์ที่ความโปร่งใสสำคัญ
- Medplum คือแพลตฟอร์ม เวชระเบียนอิเล็กทรอนิกส์ แบบโอเพนซอร์สที่แข่งขันกับผู้เล่นเดิมแบบซอร์สปิด
- เพราะเป็นโอเพนซอร์ส ผู้ใช้จึงตรวจสอบได้ชัดเจนว่าแพลตฟอร์มรองรับอะไรและไม่รองรับอะไร
- SuperTokens คือทางเลือกโอเพนซอร์สของโซลูชันยืนยันตัวตนอย่าง Auth0
- การล็อกอินเกี่ยวข้องกับข้อมูลอ่อนไหว เช่น ชื่อ อีเมล และรหัสผ่าน
- การเป็นโอเพนซอร์สช่วยสร้างความเชื่อมั่นได้มากขึ้น
- TableFlow คือทางเลือกโอเพนซอร์สของแพลตฟอร์มนำเข้า CSV อย่าง Flatfile
- จุดสำคัญคือข้อมูลที่นำเข้านั้นมีความอ่อนไหว
- Minio คือทางเลือกโอเพนซอร์สของสตอเรจ AWS S3
- ใน S3 อาจมีการเก็บ PII ของลูกค้าผ่านภาพหน้าจอหรือไฟล์ JSON แบบมีโครงสร้าง
- สำหรับบริษัทที่ใส่ใจว่าใครเข้าถึงข้อมูลผู้ใช้ได้ Minio อาจเป็นทางเลือกหนึ่ง
- AWS อ้างว่าพนักงาน AWS ไม่ได้เข้าถึงข้อมูลลูกค้าโดยตรง แต่ในโลกซอร์สปิด คำกล่าวนี้ก็ยังเป็นเรื่องของความไว้วางใจ
- Lago ก็เช่นกัน เพราะจัดการข้อมูลการเรียกเก็บเงินและการใช้งานผลิตภัณฑ์ ซึ่งเป็นข้อมูลที่ใกล้เคียงกับเนื้อหาที่อ่อนไหว จึงมองว่าโอเพนซอร์สช่วยสร้างความเชื่อมั่นของผู้ใช้ได้ดีกว่า
วิธีที่สองที่โอเพนซอร์สชนะ: การขยายต่อ
- ข้อได้เปรียบใหญ่ของโอเพนซอร์สอย่างหนึ่งคือเปิดให้ชุมชนช่วยพัฒนาฟีเจอร์เฉพาะทางได้
- ตัวผลิตภัณฑ์หลักมักดูแลโดยทีมวิศวกรรมส่วนกลาง แต่การเชื่อมต่อหรือปลั๊กอินนั้นนักพัฒนาชุมชนสามารถสร้างได้ และบางครั้งก็ถูกรวมกลับเข้า main branch
- โซลูชันซอร์สปิดต้องพึ่งทีมวิศวกรรมภายในของตนเอง จึงขยายในรูปแบบเดียวกันได้ยากกว่า
- จุดนี้เป็นประโยชน์มากเป็นพิเศษกับบริษัทโอเพนซอร์สที่สร้างระบบซึ่งต้องเชื่อมกับไลบรารี เฟรมเวิร์ก และแอปพลิเคชันจำนวนมาก
- Airbyte เป็นแพลตฟอร์ม ELT แบบโอเพนซอร์สที่เติบโตอย่างมากจาก connector ที่ชุมชนช่วยเพิ่มเข้ามา
- Elastic ก็เป็นบริษัทขนาดใหญ่ที่เดิมเป็นโอเพนซอร์ส และมีการเชื่อมต่อข้อมูลจำนวนมาก
- SuperTokens ชูเรื่องการขยายต่อเป็นคุณค่าหลัก และสมาชิกชุมชนสามารถสร้างการเชื่อมต่อกับผู้ให้บริการยืนยันตัวตนที่ไม่ค่อยพบได้ ซึ่งเป็นประโยชน์กับทุกฝ่าย
วิธีที่สามที่โอเพนซอร์สชนะ: ผลิตภัณฑ์ที่ดีกว่า
- ความโปร่งใสและการขยายต่อช่วยให้โอเพนซอร์สเชิงพาณิชย์กลายเป็นผลิตภัณฑ์ที่ดีกว่าในระยะยาว
- โปรเจ็กต์โอเพนซอร์สสามารถใช้ประโยชน์จากฟีดแบ็กและความช่วยเหลือของชุมชน เพื่อพัฒนาได้เร็วกว่าโซลูชันซอร์สปิด
- PostHog เริ่มต้นในฐานะทางเลือกแทน Amplitude และ FullStory แต่ต่อมาก็เติบโตเป็นโซลูชันขนาดใหญ่ที่ครอบคลุมมากขึ้น และแข่งขันกับ LaunchDarkly และ Pendo ได้ด้วย
- PostHog ระดมทุน Series B ได้ 15 ล้านดอลลาร์
- การเติบโตนี้เกิดขึ้นในช่วงไม่กี่ปีที่ผ่านมา และ PostHog มองว่าชุมชนเป็นหนึ่งในเหตุผลสำคัญ
- โปรเจ็กต์โอเพนซอร์สไม่ได้จำกัดอยู่แค่โอเพนซอร์สเชิงพาณิชย์ และเป็นแรงผลักสำคัญของการปรับปรุงผลิตภัณฑ์มาหลายทศวรรษแล้ว
- ซอฟต์แวร์บางประเภทอาจยังคงเป็นซอร์สปิดได้จากลักษณะของ first-mover advantage
- แต่ในพื้นที่ที่ความโปร่งใสและการขยายต่อเป็นประเด็นสำคัญ ผู้ตามในแบบโอเพนซอร์สก็อาจกลายเป็นภัยคุกคามที่แท้จริงได้
3 ความคิดเห็น
ไปเจอเข้าโดยบังเอิญตอนค้นหาอยู่ แล้วก็อดสงสัยไม่ได้ว่าเมื่อไร AI จะช่วยแก้การแปลแบบแปลตรงตัวจากอังกฤษอย่างนี้ (
저렴함으로써) ได้สักทีนี่คือผลการรัน Claude 4.5 Sonnet วันนี้ (2026-01-12)
"โอเพนซอร์สไม่ได้ชนะเพราะราคาถูกกว่า"
พรอมป์ต์
โอเพนซอร์สไม่ได้ชนะเพียงเพราะราคาถูก
ปัจจัยความสำเร็จของโอเพนซอร์สไม่ได้อยู่ที่ต้นทุนต่ำ แต่อยู่ที่สิ่งอื่น
โอเพนซอร์สได้เปรียบไม่ใช่เพราะราคาต่ำ
ความคิดเห็นบน Hacker News
คำว่า กำไร (profit) ในที่นี้ฟังดูแปลกและคลุมเครือ
ผมดำเนินโครงการโอเพนซอร์ส/ซอฟต์แวร์เสรีมาเกือบ 24 ปี และราว 17 ปีในนั้นก็มีรายได้เข้ามาด้วย แต่ไม่เคยมี “กำไร” มีแค่ รายได้ (revenue) เท่านั้น
โดยทั่วไป ถ้ามองแบบบริษัทหรือนักบัญชี กำไรคือเงินที่เหลือหลังหักค่าตอบแทนและค่าใช้จ่ายของคนที่เข้าร่วมโครงการแล้ว
โครงการโอเพนซอร์สที่ต้องการกำไรในความหมายนี้มีเฉพาะกรณีที่ได้รับเงินลงทุนซึ่งนักลงทุนคาดหวัง “อัตราผลตอบแทน” เท่านั้น และแม้จะมีโครงการแบบนั้นอยู่ แต่ส่วนใหญ่ไม่ใช่
อีกอย่าง สมกับเป็นบทความที่ขึ้น HN ภาพรวมเอนเอียงไปทางเว็บ/SaaS มากเกินไป เชื่อยากก็จริง แต่โครงการโอเพนซอร์สมีประเภทอื่นด้วย
ในบริบทนั้น สิ่งที่เหลือหลังรับรายได้และจ่ายค่าใช้จ่ายแล้วคือกำไร และค่าใช้จ่ายนั้นรวมถึงเงินเดือนประจำ สัญญาจ้างงาน สลิปเงินเดือน และสิ่งทำนองนี้
ธุรกิจจะนำกำไรไปใช้อย่างไรมีได้หลายแบบ อาจสะสมเป็นเงินสดสำรองเพื่อจ่ายค่าใช้จ่ายในเดือนที่รายได้ต่ำ ซื้อสินทรัพย์อย่างฮาร์ดแวร์ใหม่ หรือทำให้จ้างคนเพิ่มได้ ถึงจะไม่พบบ่อยเท่าที่คิด แต่ก็อาจจ่ายเป็นเงินปันผลให้เจ้าของได้
กรณีของคุณมีรายละเอียดไม่มากจึงได้แต่คาดเดา แต่ถ้าคุณทำคนเดียวและโครงการเล็กจนไม่มีความจำเป็นหรือความตั้งใจจะเพิ่มพนักงาน รายได้ที่เข้ามาก็แทบจะใกล้เคียงรายได้ส่วนบุคคล บางเดือนได้มาก บางเดือนได้น้อย ดังนั้นในบริบทนี้ควรมองว่าเป็นรายได้ ไม่ใช่ “กำไร”
โดยเฉพาะถ้าเป็นซอฟต์แวร์ที่แทบไม่มีค่าโสหุ้ยอื่น ๆ และการติดตามค่าใช้จ่ายเพื่อวัตถุประสงค์ทางภาษีก็ไม่ได้มีความหมายมากนัก ยิ่งเป็นเช่นนั้น และคุณอาจไม่ได้ทำบัญชีอย่างเป็นระบบด้วยซ้ำ ถ้าเป็นสถานการณ์แบบนั้น ก็เข้าใจได้ว่าทำไมบทความนี้ถึงไม่โดนใจ เพราะบทความกำลังพูดถึงสถานการณ์ที่ค่อนข้างต่างออกไป
ถ้าไม่มีนักลงทุนล้วน ๆ ที่เรียกร้องผลตอบแทนอย่างต่อเนื่อง แรงกดดันก็ลดลงมาก และทำสิ่งที่เหมาะกับโครงการได้ง่ายขึ้น
แต่ในตลาดผลิตภัณฑ์ที่ต้องแข่งขันกับบริษัทที่ทะเยอทะยาน การเติบโตก็จำเป็นและมีแนวโน้มจะสมเหตุสมผล
การเหลือกำไรไว้เพื่อรับมือภาวะถดถอย โอกาส หรือรายจ่ายก้อนใหญ่ ไม่ใช่แค่เรื่องสมเหตุสมผลธรรมดา ยิ่งมีผู้ร่วมโครงการและลูกค้ามากขึ้น เหตุผลที่จะไม่เผารายได้ทั้งหมดที่เข้ามาก็ยิ่งมากขึ้น
ในบริษัทใหญ่จริง ๆ ตัวเลขสองอย่างนี้มักไม่เกี่ยวกันเลย และแต่ละอย่างถูกนิยามตามว่าจะสื่อสารกับใครและกฎใดที่ใช้กับการสื่อสารนั้น
อาจมีสิ่งอย่าง “กำไรเพื่อการบริหาร” ด้วย ซึ่งเป็นคำรวม ๆ สำหรับตัวชี้วัดที่ไม่ได้มาตรฐานและไม่ได้ถูกกำกับ เช่น แม้ธุรกิจหนึ่งจะออกจากการบัญชีแบบเกณฑ์เงินสดไปแล้วเพื่อวัตถุประสงค์ด้านภาษีและรายงานต่อนักลงทุน แต่สำหรับผู้บริหารเดิม การติดตามนิยามกำไรแบบเดิมต่อไปอาจยังมีประโยชน์ อาจเพราะความเคยชิน หรือเพราะมันสะท้อนกระแสเงินสดได้ดี หรือมีประโยชน์ในทางอื่น
เรื่องแบบนี้เป็นหนึ่งในปัญหาแนวโพสต์โมเดิร์น เจ้าหน้าที่ SEC, IRS และเจ้าหน้าที่ธนาคารจะไม่ยอมรับคำอย่าง “กำไรแบบ SEC” แต่จะเรียกร้องกำไร “ที่แท้จริง” คล้ายกับนักการเมืองท้องถิ่นที่ถามโรงพยาบาลอย่างไร้เดียงสาว่าจ่ายให้ผู้รับเหมาไปเท่าไร “จริง ๆ”
อย่างไรก็ตาม ผู้เขียนก็ใช้คำจากมุมมองของตัวเองเช่นเดียวกับ SEC หรือ IRS คำว่า “โอเพนซอร์ส” ในประโยค “โอเพนซอร์สไม่ได้ชนะเพราะถูกกว่า” หมายถึงธุรกิจโอเพนซอร์สในโมเดลแบบ MongoDB ดังนั้นจึงมีสมมติฐานเรื่องนักลงทุนและเป้าหมายการเติบโตอยู่ด้วย
ในบทความเองก็ทำให้ประเด็นนี้ชัดเจนแล้ว จึงไม่มีเหตุผลมากนักที่จะไปขู่คำรามกันเรื่องความหมายของคำ
ปัญหาของโมเดลธุรกิจนี้คือมันสร้าง ความตึงเครียดระหว่างเวอร์ชัน OSS กับเวอร์ชันแบบเสียเงิน
เราอยากให้เวอร์ชัน OSS ดี แต่ก็ต้องไม่ดีถึงขั้นที่ไม่มีใครรู้สึกว่าจำเป็นต้องจ่ายเงินให้ SaaS หรือบริการที่ปรึกษา ฯลฯ
สุดท้ายความตึงเครียดนั้นดูเหมือนจะนำไปสู่การตัดฟีเจอร์ที่จำเป็นอย่างชัดเจนออกไป หรือซ่อนฟีเจอร์·ความรู้ที่จำเป็นต่อการรันในสเกลใหญ่ไว้เป็น closed source เพื่อให้บริษัทผู้สนับสนุนทำเงินได้
ถ้าผลิตภัณฑ์มีลักษณะเป็นโครงสร้างพื้นฐาน รูปแบบการเปลี่ยนไปใช้ ไลเซนส์ที่ดูได้อย่างเดียวแต่แตะต้องไม่ได้ เพื่อไม่ให้ผู้ให้บริการคลาวด์รายใหญ่กินรวบด้วยบริการแบบ one-click เหมือน Elastic, Hashicorp ก็กลายเป็นเรื่องปกติไปแล้ว
ไม่ได้หมายความว่าบทความนี้ผิด แต่ก็ไม่อยากให้ทำเหมือนว่า OSS ที่ได้รับการสนับสนุนเชิงพาณิชย์เป็น win-win แบบ kumbaya ที่ดีต่อทุกคน จริง ๆ แล้วมันใกล้กับโครงสร้างที่สตาร์ทอัพใช้เป็น growth hack เพื่อสร้างความน่าเชื่อถือ แล้วพอถึงจุดที่ต้องทำรายได้ ก็ต้องบีบชุมชนที่ช่วยให้เติบโตขึ้นมาไม่ทางใดก็ทางหนึ่ง
ผมดูแลโมดูลเล็ก ๆ ตัวหนึ่ง และตลอดหลายปีได้รับคำขอฟีเจอร์กับคำขอซัพพอร์ตมากมาย จนกว่าจะหาเงินได้พอจ่ายค่าเช่า ผมไม่รู้สึกผิดแม้แต่น้อยที่จะคิดเงินกับเรื่องพวกนั้น
แม้แต่การกดปุ่ม merge Pull Request ถ้าต้องใช้เวลาของผมแม้แต่ 1 วินาที ผมก็คิดค่าใช้จ่าย ผมใช้เวลาหลายเดือน หลายปีไปกับโค้ด และเผยแพร่โค้ดนั้นให้โลกใช้ฟรี
ถ้าต้องการฟีเจอร์เพิ่มเติมหรือต้องการเวลาของผม ก็ต้องจ่ายเงิน
การที่หลายบริษัททำไม่ได้ ไม่ได้แปลว่าโมเดลธุรกิจนี้ใช้ไม่ได้ แต่ใกล้เคียงกับการบอกว่าทำให้ดีนั้นยากมากกว่า
แต่ถ้าเรามองว่าคนส่วนใหญ่โดยรวมเป็นคนดี ก็ควรพิจารณาความเป็นไปได้ว่าบริษัทหรือคนเหล่านี้อาจเข้าใจการเข้าตลาดผิดไป อาจเป็นความไร้ความสามารถมากกว่าความประสงค์ร้าย
ถ้าตั้งแต่วันแรกโปร่งใสว่าอะไรจะฟรีตลอดไป และอะไรจะกลายเป็นแบบเสียเงินในที่สุด ผมจะไม่มองว่าเป็นการหักหลังชุมชน
แน่นอนว่าต้องมีเงื่อนไขว่าจะรักษา roadmap และปรับตาม feedback กับ contribution ด้วย
ซัพพอร์ตแบบเสียเงินหรือฟีเจอร์เสริมก็ปล่อยให้อยู่ในพื้นที่เชิงพาณิชย์ ซึ่งเป็นที่ที่ซอฟต์แวร์ทำเงินส่วนใหญ่อยู่แล้วได้
อาจไม่เข้ากับทุก use case แต่ก็ไม่จำเป็นต้องเป็นแบบนั้น การประมวลผลส่วนใหญ่ควรเป็นเรื่องส่วนบุคคล
มีคำพูดว่า “MinIO เป็นทางเลือกที่ดีสำหรับบริษัทที่ใส่ใจว่าใครเข้าถึงข้อมูลผู้ใช้” แต่บริษัทหนึ่งอาจอ้างว่าโฮสต์ด้วยซอฟต์แวร์โอเพนซอร์ส ทั้งที่จริง ๆ แล้วใช้ ซอฟต์แวร์ closed source ภายในบริษัท ที่เลียนแบบ API endpoint เดียวกันก็ได้ไม่ใช่หรือ?
ถ้าอย่างนั้นก็ยังต้องมีความเชื่อใจแบบเดียวกับที่มีต่อ AWS อยู่ดี
อย่าสรุปว่า self-hosting หมายถึงมีจิตสำนึกด้านความปลอดภัยสูง ในองค์กรส่วนใหญ่ IT แบบ on-premises ถูกปฏิบัติเหมือนระบบ HVAC หรือระบบไฟฟ้า เพียงแต่ยุ่งยากกว่าเท่านั้น
ใครก็ตามที่ใส่ชุดช่างก็อาจหลอกขอกุญแจห้องเซิร์ฟเวอร์จากเคาน์เตอร์ต้อนรับได้
มันแค่หมายความว่าผู้ให้บริการแชร์ซอร์สโค้ดที่เขาบอกว่ารันอยู่หลังบริการของตัวเอง
แม้โค้ดนั้นจะตรงจริง ๆ ก็ไม่น่าจะเป็นโค้ดเพียงชุดเดียวที่รันอยู่หลังบริการ “ทางการ” และผู้ใช้ก็ไม่สามารถ build เองแล้ว deploy ไปยังเซิร์ฟเวอร์ของพวกเขาได้
โอเพนซอร์สมีความหมายจริง ๆ เฉพาะตอน self-hosting เท่านั้น ไม่เช่นนั้นโดยเนื้อแท้ก็ไม่ต่างจากซอฟต์แวร์กรรมสิทธิ์ ทุกอย่างขึ้นอยู่กับความเชื่อใจต่อผู้ให้บริการ และถ้าเป็นไปได้ ก็ขึ้นอยู่กับสัญญา
เช่น ถ้าในสัญญาระบุว่าข้อมูลเข้าและออกผ่านโค้ดโอเพนซอร์สนี้และไม่ไปที่อื่น พร้อมแจกแจงกระบวนการต่าง ๆ เพื่อรับประกันเรื่องนี้ แต่ทั้งหมดนั้นเป็นคำโกหกอย่างโจ่งแจ้ง ก็จะกลายเป็นปัญหาใหญ่ในแบบที่ชัดเจนและบังคับใช้ได้
การปกปิดจากพนักงานภายในก็ทำได้ยาก และคนก็เข้าออกองค์กรอยู่เรื่อย ๆ หากไม่เป็นความจริง ก็คงไม่น่าจะกล้าอ้างแบบนั้น
ผู้เขียนระบุชัดเจนว่ากำลังพูดถึง โซลูชันโอเพนซอร์ส ที่แข่งขันกับผลิตภัณฑ์แบบเสียเงิน
โดยส่วนตัว ผมคิดว่าในบริบทนี้ยังสรุปไม่ได้ว่าโอเพนซอร์ส “ชนะ” หรือไม่
ในช่วง 10 ปีที่ผ่านมา ผลิตภัณฑ์โอเพนซอร์สเพิ่มขึ้นมาก และในราว 5 ปีหลังมานี้ ก็เห็นผลิตภัณฑ์จำนวนมากในกลุ่มนั้นค่อย ๆ ถอยห่างจากโอเพนซอร์ส เช่น MongoDB, Hashicorp stack, Elastic, Red Hat, MinIO เป็นต้น
ผลิตภัณฑ์ที่เป็นโอเพนซอร์สอย่างแท้จริงและยังมีความสามารถในการแข่งขันเชิงพาณิชย์เหลืออยู่ไม่มาก และหลายรายในนั้นกำลังพยายามพิสูจน์ว่านี่เป็นโมเดลธุรกิจที่ทำได้จริง
เมื่อไม่กี่สัปดาห์ก่อน ผมได้นำเสนอเรื่องนี้ในงานภายในบริษัท และอีกไม่กี่สัปดาห์ข้างหน้าก็จะนำเสนออีกครั้งที่ GoWest
สมมติฐานหลักคือ ใบอนุญาตโอเพนซอร์สให้เสรีภาพตามตัวอักษรจริง ๆ แต่ไม่ได้มอบสิ่งอื่น ๆ ที่บริษัทน่าจะยอมจ่ายเงินให้ ส่วนใบอนุญาตแบบปิดให้สิ่งที่บริษัทต้องการ แต่ต้องแลกด้วยเสรีภาพ
ผมเชื่อว่ามีโมเดลที่สามซึ่งทำงานอยู่ตรงกลางได้โดยไม่ประนีประนอมกับเสรีภาพหรือความน่าเชื่อถือ หากยังคงเป็นโอเพนซอร์สไว้ และเติมเต็มช่องว่างที่บริษัทต้องการด้วยการสนับสนุนทางการเงิน โมเดลนี้อาจเป็นไปได้สำหรับบางโปรเจกต์
ตอนนี้กำลังออกแบบเว็บไซต์ Caddy ใหม่ให้สอดคล้องกับข้อความนี้ และหวังว่าจะได้ผลดี
ที่บอกว่า MinIO “ถอยห่างจากโอเพนซอร์ส” หมายถึงเรื่องนั้นหรือเปล่า?
ชื่อเรื่องโง่มาก แน่นอนว่าโอเพนซอร์สชนะเพราะถูกกว่า
สิ่งที่ผู้เขียนพยายามจะบอกคือ ธุรกิจโอเพนซอร์ส ไม่ได้ชนะเพราะถูกกว่า
โค้ดเบสโอเพนซอร์สชนะเพราะถูกกว่าเสมอ ไม่มีใครจ่ายเงินให้กับอัลกอริทึมบีบอัดข้อมูล, network time daemon, หรือตัวแปลงสื่อ โอเพนซอร์สลบตลาดเหล่านั้นทิ้งไปหมดแล้ว
แต่หงุดหงิดที่ชื่อเรื่องผิดแบบตรงตัวเพราะคำเพียงคำเดียว
ผมถึงกับย้อนกลับไปอ่านย่อหน้าก่อน ๆ ใหม่ เพราะคิดว่าตัวเองพลาดอะไรไปหรือเปล่า
จากมุมมองของวิศวกรที่มีอิทธิพลต่อการนำเทคโนโลยีมาใช้ โอเพนซอร์สชนะเพราะ เข้าใจได้
ถ้าผมกับเพื่อนร่วมงานดูซอร์สโค้ดได้ เราก็ตัดสินได้ว่าผลิตภัณฑ์นั้นจะทำฟังก์ชันที่อ้างไว้ได้หรือไม่
เมื่อเจอบั๊กหรือ use case ที่ไม่คาดคิดระหว่างใช้งาน อย่างน้อยก็สามารถสืบหาวิธีแก้แล้วเสนอในรายงานบั๊กได้ หรือไม่ก็เปิด PR ได้เลย
จากนั้นก็ทำ workaround แบบรวดเร็วได้ และโดยปกติก็รายงานบั๊กได้ด้วย
องค์กรไม่ได้สนใจตัวโค้ดมากนัก ต่อให้สนใจ ข้อกำหนดเรื่องความต่อเนื่องทางธุรกิจ ก็ช่วยลดความกังวลส่วนใหญ่เกี่ยวกับซอฟต์แวร์ปิดได้
สุดท้ายแล้ว มีสถาบันการเงินกี่แห่งที่ย้ายจาก Excel ไปใช้ OpenOffice Calc?
กลยุทธ์ go-to-market ของ AWS พึ่งพาการดึงดูดสตาร์ทอัพและนักพัฒนารายบุคคลด้วยบริการแบบคิดตามการใช้งานจริงที่มีต้นทุนต่ำ และจุดนี้ก็ลงตัวมาก เพราะ Airbnb, Stripe, Twitch และบริษัทอื่น ๆ เติบโตเป็นบริษัทใหญ่ไปพร้อมกับ AWS
มีไม่กี่อย่างที่แข่งขันกับต้นทุนต่ำหรือของฟรีได้ แล้วค่อยขยับขึ้นตลาดบนทีหลังก็ได้ ลองไปถาม ARM กับ Intel ดู
สำหรับสตาร์ทอัพเครื่องมือนักพัฒนา โอเพนซอร์สแทบจะกลายเป็นกลยุทธ์ go-to-market ขั้นพื้นฐานไปแล้ว แม้อย่างที่บทความชี้ไว้ถูกต้องว่ามันไม่ใช่โมเดลธุรกิจก็ตาม
ดังนั้น ถ้าไม่ได้ยอดเยี่ยมระดับ Snowflake และยังสามารถสู้กับค่ายเสรี/โอเพนซอร์สอย่าง Databricks ได้ด้วย open core model ย่อมดีกว่า
ถ้าคอมไพล์เองได้จะยิ่งชอบมากกว่า
ถ้าคุณกำลังรัน Postgres เองบนเซิร์ฟเวอร์จริง นักลงทุนอาจไม่สนใจ หรือไม่ก็จะถามคำถามยาก ๆ ว่าคุณเสียเวลาไปมากแค่ไหน ตอนนั้นคุณต้องมีคำตอบที่ค่อนข้างดี หรือมีนักลงทุนที่เข้าใจคุณ
แปลกใจที่ไม่ได้พูดถึง vendor lock-in นี่เป็นจุดขายที่ชัดเจนของโอเพนซอร์ส
แน่นอนว่าแตกต่างกันไปตามองค์กรและแต่ละคน และก็มีหลายคนที่ไม่สนใจการผูกติดหากเป็นบริษัทที่ไว้ใจได้ แต่ไม่ใช่ศูนย์แน่นอน
ตอนที่ทำงานเป็นที่ปรึกษา OpenShift ที่ Red Hat ผมได้พบผู้บริหารจำนวนมากที่กังวลเรื่อง vendor lock-in สำหรับพวกเขา การเลือก OpenShift เป็นการตัดสินใจที่ชัดเจน
เป็นเรื่องที่เกี่ยวข้องแค่เล็กน้อยกับแวดวงการขายซอฟต์แวร์ แต่เมื่อนานมาแล้ว ผมเคยขายอัปเดตอินเทอร์เฟซผู้ใช้ให้กับเกมที่ออกแบบมาแย่มาก
ผมตั้งราคาไว้เป็น 2 เท่าของราคาเกมเอง แต่คนก็ยังซื้อ เพราะมันถูกออกแบบอย่างมืออาชีพ
ในฐานะนักออกแบบมืออาชีพ ผมสละเวลาจากงานหลักมาทำสิ่งที่นักพัฒนาคนนั้นคงทำไม่ได้
ความไม่พอใจที่เห็นชัดที่สุดในคอมเมนต์บนแพลตฟอร์มจัดจำหน่ายดิจิทัลที่ใช้ขายตอนนั้นคือ อัปเดตแพงเกินไป และแน่นอนว่าผู้คนก็วิจารณ์เรื่องการวางตำแหน่งราคา
แต่มีอย่างหนึ่งที่ชัดเจนคือ ตัวเกมเองถูกเกินไป
ถ้าผู้คนบ่นแต่เรื่องราคาแต่ก็ยังซื้ออยู่เรื่อย ๆ นั่นหมายความว่าเรื่องอื่น ๆ แทบไม่มีอะไรให้บ่น
นกย่อมอยากได้อาหารฟรีเสมอ อย่าไปปรับตัวตามนก
เพิ่มเติมคือ อัปเดตนั้นถูกเผยแพร่แบบผิดกฎหมายด้วย และแพร่กระจายพอสมควรในหมู่ผู้ใช้เถื่อน ผมกลับดีใจด้วยซ้ำ เพราะลูกค้าส่วนใหญ่จ่ายเงิน
อีกอย่างหนึ่งก็ชัดเจนว่าผมกำลังตอบสนองชุดฟีเจอร์ที่ผู้คนต้องการและที่ไม่มีที่อื่นเสนอให้ ปัญหาแบบนั้นถือเป็นอาการที่ค่อนข้างดีว่าคุณได้สร้างสิ่งที่ผู้คนต้องการ
มองว่าโปรเจกต์โอเพนซอร์สจำนวนมากกลายเป็น โอเพนซอร์สเพราะความจำเป็น ไม่ใช่เพราะเป็นทางเลือก
ผลิตภัณฑ์บางอย่างต้องทำเป็นโอเพนซอร์สเท่านั้นจึงจะมีโอกาสถูกนำไปใช้อยู่บ้าง
ผู้เขียนมุ่งเน้นไปที่โปรเจกต์โอเพนซอร์สระดับหัวกะทิจำนวนน้อย และสิ่งเหล่านั้นไม่ได้เป็นตัวแทนของโปรเจกต์โอเพนซอร์สส่วนใหญ่
บางบริษัทมีคอนเน็กชันทางธุรกิจและภาครัฐที่เหมาะสม จึงขายไลเซนส์ผลิตภัณฑ์ในราคาสูงได้ง่าย แต่บริษัทแบบนั้นมีเพียงส่วนน้อย
คนส่วนใหญ่และธุรกิจขนาดเล็กไม่มีเครือข่ายแบบนั้น หากไม่มีเครือข่ายธุรกิจที่เหมาะสม การหาเงินแม้เพียงเล็กน้อยก็เป็นเรื่องยาก
ไม่สำคัญว่าผลิตภัณฑ์จะดีแค่ไหน หรือช่วยลดต้นทุนให้ใครได้มากเพียงใด ก็ไม่มีใครเชื่อถือ และไม่มีใครทดลองใช้ แม้ผลประโยชน์ระยะยาวอาจมหาศาล แต่อุปสรรคในการนำไปใช้ก็สูงเกินไป
การทำผลิตภัณฑ์ให้เป็นโอเพนซอร์สคือวิธีเดียวที่จะได้แทรกเท้าเข้าไปในประตู เพราะมันให้โอกาสเล็กน้อยมากที่ผลิตภัณฑ์จะถูกมองเห็น และบางครั้งนั่นก็เป็นทั้งหมดที่มี