บทความนี้เผยแพร่ครั้งแรกบนบล็อก Andreessen Horowitz แปลและแบ่งปันโดย InfoQ ภาษาจีน
บันทึกบรรณาธิการ: ขบวนการซอฟต์แวร์โอเพนซอร์ส (OSS) ได้สร้างเทคโนโลยีที่สำคัญและใช้กันอย่างแพร่หลายที่สุดบางอย่าง รวมถึงระบบปฏิบัติการ เว็บเบราว์เซอร์ และฐานข้อมูล หากไม่มีซอฟต์แวร์โอเพนซอร์ส โลกของเราจะไม่สามารถทำงานได้ อย่างน้อยก็ไม่สามารถทำงานได้ดี
โอเพนซอร์สนำมาซึ่งนวัตกรรมทางเทคโนโลยีที่น่าทึ่ง ในขณะเดียวกัน นวัตกรรมทางธุรกิจ - โดยเฉพาะซอฟต์แวร์เป็นบริการที่เพิ่งเกิดขึ้นใหม่ - มีความสำคัญต่อความสำเร็จของขบวนการนี้เช่นกัน เนื่องจากโอเพนซอร์สถูกกำหนดให้เป็นซอฟต์แวร์ที่ทุกคนสามารถใช้ แก้ไข และแจกจ่ายได้ฟรี ดังนั้นบริษัทโอเพนซอร์สจึงต้องการโมเดลและการวางตำแหน่งในตลาดที่แตกต่างจากบริษัทซอฟต์แวร์ประเภทอื่น
ในฐานะนักพัฒนา ผู้ประกอบการ และนักลงทุน Peter Levine ได้ทำงานด้านโอเพนซอร์สมากว่า 30 ปี เมื่อเร็วๆ นี้ เขาได้บรรยายในหัวข้อ “โอเพนซอร์ส: จากชุมชนสู่การพาณิชย์” (คุณสามารถ ดาวน์โหลดงานนำเสนอฉบับเต็มได้ที่นี่) เขาแนะนำประสบการณ์ของตัวเองและการสัมภาษณ์ผู้เชี่ยวชาญด้านโอเพนซอร์สหลายสิบคน ด้านล่างนี้คือเวอร์ชันตัวอักษรของงานนำเสนอนี้ Peter สำรวจการเพิ่มขึ้นของซอฟต์แวร์โอเพนซอร์ส และมอบกรอบการทำงานแบบ end-to-end ที่ใช้ได้จริงสำหรับการเปลี่ยนโครงการโอเพนซอร์สให้เป็นธุรกิจที่ประสบความสำเร็จ
โอเพนซอร์สเริ่มต้นจากกิจกรรมชายขอบ แต่ต่อมากลายเป็นศูนย์กลางของการพัฒนาซอฟต์แวร์ ในยุคแรกของโอเพนซอร์ส หนึ่งในเรื่องสนุกที่ฉันชอบคือเรื่องเกี่ยวกับคำสั่ง Linux/Unix [~}$ BIFF - ตอนนั้นยังไม่เรียกว่า “โอเพนซอร์ส” แต่เรียกว่า “ซอฟต์แวร์ฟรี” - มันสามารถแจ้งเตือนผู้ใช้เมื่อได้รับอีเมลใหม่ คำสั่งนี้ตั้งชื่อตามสุนัขของฮิปปี้คนหนึ่งในเบิร์กลีย์ มันจะวิ่งออกมาเห่าไปรษณีย์ ฉันชอบเรื่องนี้เพราะในยุคแรกโอเพนซอร์สเป็นชายขอบมากจนคำสั่งสำคัญถูกตั้งชื่อตามสุนัขของนักพัฒนา
ฉันทำงานด้านโอเพนซอร์สมาหลายทศวรรษแล้ว เริ่มจากการเป็นนักพัฒนาในโครงการ Athena ของ MIT และ Open Software Foundation ต่อมาเป็น CEO ของบริษัทโอเพนซอร์ส XenSource ในช่วง 10 ปีที่ผ่านมา ฉันทำงานในคณะกรรมการของบริษัทที่เกี่ยวข้องกับโอเพนซอร์ส จากนักพัฒนาสู่สมาชิกคณะกรรมการ ฉันได้เห็นวิวัฒนาการของโอเพนซอร์ส และเห็นบริษัทใหญ่ที่สร้างขึ้นบนพื้นฐานโครงการโอเพนซอร์ส
ฉันคิดจริงๆ ว่าตอนนี้เป็นเวลาที่ดีที่สุดในการสร้างบริษัทโอเพนซอร์ส นวัตกรรมทางธุรกิจมีความสำคัญต่อขบวนการโอเพนซอร์ส และที่นี่ฉันมอบกรอบการทำงานสำหรับนำผลิตภัณฑ์โอเพนซอร์สสู่ตลาด
ยุคฟื้นฟูโอเพนซอร์สกำลังดำเนินอยู่
ทศวรรษที่ผ่านมาเป็นยุคฟื้นฟูของโอเพนซอร์ส ภาพด้านบนแสดงว่าในช่วง 30 ปีที่ผ่านมา มีบริษัทประมาณ 200 แห่งที่มีเทคโนโลยีโอเพนซอร์สเป็นแกนกลาง บริษัทเหล่านี้ระดมทุนรวมกันมากกว่า 10 พันล้านดอลลาร์ และในช่วง 10 ปีที่ผ่านมา ขนาดการทำธุรกรรมของพวกเขาใหญ่ขึ้นเรื่อยๆ อันที่จริง สามในสี่ของบริษัทและ 80% ของการระดมทุนเสร็จสมบูรณ์หลังปี 2005 ฉันคิดว่าเรากำลังอยู่ที่จุดเริ่มต้นของยุคฟื้นฟูนี้
การลงทุนเหล่านี้นำไปสู่ IPO ขนาดใหญ่และการควบรวมกิจการขนาดใหญ่
น่าสนใจที่ในปี 2008 MySQL ถูกซื้อกิจการโดย Sun Microsystems (ต่อมาถูก Oracle ซื้อกิจการ) ในราคา 1 พันล้านดอลลาร์ ตอนนั้นฉันมั่นใจว่า 1 พันล้านดอลลาร์เป็นราคาสูงสุดที่บริษัทโอเพนซอร์สใดๆ สามารถได้รับ นี่เป็นขีดจำกัดที่ไม่สามารถทะลุได้มาหลายปี ในสายตาของอุตสาหกรรมซอฟต์แวร์ที่มองโอเพนซอร์สเป็นสินค้าโภคภัณฑ์ 1 พันล้านดอลลาร์เป็นการจากไปที่ยอดเยี่ยมมาก
อย่างไรก็ตาม ดูสิ่งที่เกิดขึ้นในช่วงไม่กี่ปีที่ผ่านมา เรามี Cloudera, MongoDB, Mulesoft, Elastic และ GitHub ซึ่งทั้งหมดเป็นส่วนหนึ่งของการทำธุรกรรม IPO หรือการควบรวมกิจการมูลค่าหลายพันล้านดอลลาร์ และแน่นอน ยังมี Red Hat ในปี 1999 มันเข้าตลาดหลักทรัพย์ในราคา 3.6 พันล้านดอลลาร์ ปีนี้ มันถูกขายให้ IBM ในราคา 34 พันล้านดอลลาร์ ในอนาคต ฉันหวังว่าจะได้เห็นว่าจะมีการสร้างสถิติใหม่อีกหรือไม่
โอเพนซอร์สยังขยายไปสู่สาขาซอฟต์แวร์อื่นๆ ตามประเพณี OSS ส่วนใหญ่พัฒนาโดยรอบโครงสร้างพื้นฐานขององค์กร เช่น ฐานข้อมูลและระบบปฏิบัติการ (เช่น Linux และ MySQL) ด้วยยุคฟื้นฟูโอเพนซอร์สในปัจจุบัน การพัฒนา OSS ที่กระตือรือร้นปรากฏในเกือบทุกอุตสาหกรรม - fintech, e-commerce, การศึกษา, ความปลอดภัยไซเบอร์ และอื่นๆ
แล้วอะไรคือแรงผลักดันเบื้องหลังยุคฟื้นฟูนี้? เพื่อทำความเข้าใจ เรามาทบทวนอดีตและประวัติศาสตร์ของโอเพนซอร์สกัน
ประวัติโอเพนซอร์สจากฟรีสู่ SaaS
โอเพนซอร์ส 0.0 - ยุค “ซอฟต์แวร์ฟรี”
โอเพนซอร์สเริ่มต้นในช่วงกลางทศวรรษ 70 ฉันเป็นโปรแกรมเมอร์ ฉันเรียกยุคนี้ว่า 0.0 - ยุค “ซอฟต์แวร์ฟรี” นักวิชาการและมือสมัครเล่นพัฒนาซอฟต์แวร์ ทัศนคติทั้งหมดคือ: ให้ซอฟต์แวร์ฟรี เมื่อ ARPANET กลายเป็นอินเทอร์เน็ต เครือข่ายทำให้การพัฒนาร่วมกันและการแลกเปลี่ยนโค้ดง่ายขึ้น
ฉันจำได้ว่าตอนไปทำงานที่ MIT หรือ Open Software Foundation ฉันไม่รู้ว่าเงินเดือนของฉันมาจากไหน ตอนนั้นยังไม่มีแนวคิดโมเดลธุรกิจ เงินทุนสนับสนุนการพัฒนา “ซอฟต์แวร์ฟรี” (ถ้ามี) มาในรูปแบบทุนวิจัยจากมหาวิทยาลัยหรือองค์กร
โอเพนซอร์ส 1.0 - ยุคการสนับสนุนทางเทคนิคและบริการ
เมื่อ Linux มาถึงในปี 1991 โอเพนซอร์สกลายเป็นสิ่งสำคัญมากขึ้นสำหรับองค์กร และได้รับการพิสูจน์ว่าเป็นวิธีการพัฒนาซอฟต์แวร์หลักที่เร็วและดีกว่า เมื่อเทคโนโลยีโอเพนซอร์สพื้นฐานปรากฏมากขึ้น ชุมชนและองค์กรโอเพนซอร์สเริ่มทดลองการพาณิชย์
ในปี 1998 Open Software Initiative สร้างคำว่า “โอเพนซอร์ส” ประมาณช่วงนั้น โมเดลธุรกิจที่แท้จริงแรกปรากฏขึ้น คือการให้การสนับสนุนและบริการแบบชำระเงินสำหรับ RedHat, MySQL และซอฟต์แวร์ฟรีอื่นๆ อีกมากมาย นี่เป็นครั้งแรกที่เราเห็นโมเดลเศรษฐกิจที่ใช้ได้จริงที่สามารถสนับสนุนการพัฒนาขององค์กรเหล่านี้
ตอนนั้นยังมีอีกเรื่องหนึ่งที่น่าสังเกต เมื่อเทียบกับบริษัทซอฟต์แวร์กรรมสิทธิ์ มูลค่าตลาดของบริษัทโอเพนซอร์สดูน้อยมาก ฉันเปรียบเทียบ Microsoft กับ Red Hat, MySQL กับ Oracle, XenSource กับ VMWare ฉันพบว่ามูลค่าตลาดของบริษัท closed-source ใหญ่กว่าบริษัทโอเพนซอร์สมาก คนในวงการคิดว่า OSS เป็นสินค้าโภคภัณฑ์ที่ไม่มีทางใกล้เคียงมูลค่าทางเศรษฐกิจที่อาจเกิดขึ้นได้ของบริษัทซอฟต์แวร์กรรมสิทธิ์
โอเพนซอร์ส 2.0 - ยุค SaaS และ Open Core
ถึงกลางทศวรรษ 2000 การประเมินค่าเหล่านี้เริ่มเปลี่ยนแปลง คลาวด์คอมพิวติ้งเปิดโอกาสให้บริษัทรันซอฟต์แวร์โอเพนซอร์สเป็นบริการ (SaaS) เมื่อฉันสามารถโฮสต์บริการโอเพนซอร์สบนคลาวด์ ผู้ใช้ไม่รู้หรือไม่สนใจว่าเบื้องหลังเป็นซอฟต์แวร์โอเพนซอร์สหรือซอฟต์แวร์กรรมสิทธิ์ ทำให้การประเมินค่าของบริษัทซอฟต์แวร์โอเพนซอร์สและบริษัทซอฟต์แวร์กรรมสิทธิ์คล้ายกัน และแสดงว่าโอเพนซอร์สมีคุณค่าทางเศรษฐกิจและยุทธศาสตร์ที่แท้จริง
การเข้าซื้อกิจการหลายครั้ง รวมถึงสตาร์ทอัพของฉันเอง XenSource ถูก Citrix เข้าซื้อกิจการ (ไม่ต้องพูดถึง Sun เข้าซื้อ MySQL และ Oracle เข้าซื้อ Sun) ทำให้โอเพนซอร์สกลายเป็นส่วนสำคัญของบริษัทเทคโนโลยีขนาดใหญ่ ในปี 2001 Steve Ballmer CEO ของ Microsoft เรียก Linux ว่า “มะเร็ง” ตอนนี้ แม้แต่ Microsoft ก็ใช้ซอฟต์แวร์โอเพนซอร์สในสแต็กเทคโนโลยีของตน และลงทุนอย่างมากในโครงการโอเพนซอร์ส ดังนั้น สตาร์ทอัพโอเพนซอร์สแห่งต่อไปอาจเกิดจากบริษัทเทคโนโลยีขนาดใหญ่ เหมือนที่เกิดจากห้องปฏิบัติการวิจัยทางวิชาการหรือโรงรถของนักพัฒนา
วงจร virtuous ของโอเพนซอร์ส
ประวัติโอเพนซอร์สแสดงว่าการเพิ่มขึ้นของมันเกิดจากวงจร virtuous ของนวัตกรรมทางเทคโนโลยีและธุรกิจ ทางด้านเทคโนโลยี โอเพนซอร์สเป็นวิธีที่ดีที่สุดในการสร้างซอฟต์แวร์ เพราะมันเร่งการตอบสนองผลิตภัณฑ์และนวัตกรรม เพิ่มความน่าเชื่อถือของซอฟต์แวร์ ขยายขอบเขตการสนับสนุน ผลักดันการนำไปใช้ และรวบรวมบุคลากรทางเทคนิค โอเพนซอร์สเป็นโมเดลที่ขับเคลื่อนด้วยเทคโนโลยี คุณสมบัติเหล่านี้มีอยู่ตั้งแต่ยุค “ซอฟต์แวร์ฟรี”
อย่างไรก็ตาม เฉพาะนวัตกรรมทางเทคโนโลยีเมื่อรวมกับนวัตกรรมทางธุรกิจจึงจะสามารถใช้ศักยภาพของโอเพนซอร์สได้อย่างเต็มที่ หากไม่มีโมเดลธุรกิจ (เช่น การสนับสนุนแบบชำระเงิน, open core และโมเดล SaaS) ก็จะไม่มียุคฟื้นฟูโอเพนซอร์ส
ผลประโยชน์ทางเศรษฐกิจสร้างวงจร virtuous ยิ่งมีนวัตกรรมทางธุรกิจมากเท่าไหร่ ชุมชนนักพัฒนาก็ยิ่งใหญ่ขึ้น ซึ่งกระตุ้นนวัตกรรมทางเทคโนโลยีมากขึ้น และเพิ่มแรงจูงใจทางเศรษฐกิจของโอเพนซอร์ส สุดท้าย ฉันจะพูดถึงมุมมองเกี่ยวกับอนาคตของโอเพนซอร์ส 3.0 และชี้ให้เห็นนวัตกรรมที่น่าสนใจบางอย่างที่เกิดขึ้นในปัจจุบันทั้งทางด้านเทคโนโลยีและธุรกิจ
แต่ก่อนอื่น มาพูดถึงวิธีสร้างบริษัทโอเพนซอร์สกัน
เสาหลักสามประการที่บริษัทโอเพนซอร์สต้องพึ่งพาเพื่อความสำเร็จ
ความสำเร็จของบริษัทโอเพนซอร์สสร้างขึ้นบนเสาหลักสามประการ พวกมันเริ่มต้นเป็นขั้นตอนต่อเนื่องกัน ในบริษัทที่โตเต็มที่ พวกมันจะกลายเป็นเสาหลัก หากต้องการให้องค์กรยั่งยืน ต้องรักษาและสมดุล:
โครงการ-ความเหมาะสมกับชุมชน: โครงการโอเพนซอร์สของคุณสร้างชุมชนนักพัฒนาที่มีส่วนร่วมอย่างแข็งขันในโค้ดเบสโอเพนซอร์ส สามารถวัดได้จาก GitHub stars, commits, pull requests หรือการเติบโตของผู้มีส่วนร่วม
- ผลิตภัณฑ์-ความเหมาะสมกับตลาด: ซอฟต์แวร์โอเพนซอร์สของคุณถูกนำไปใช้โดยผู้ใช้ สามารถวัดได้จากจำนวนดาวน์โหลดและการใช้งาน
- คุณค่า-ความเหมาะสมกับตลาด: คุณค้นพบข้อเสนอคุณค่าที่ลูกค้ายินดีจ่ายเงิน ความสำเร็จที่นี่วัดจากรายได้
- เสาหลักทั้งสามต้องผ่านตลอดวงจรชีวิตของบริษัท และแต่ละเสามีเป้าหมายที่วัดได้
โครงการ-ความเหมาะสมกับชุมชน
โครงการ-ความเหมาะสมกับชุมชนเป็นเสาหลักแรก มันเกี่ยวข้องกับมวลชนที่สำคัญของชุมชนและความน่าสนใจของโครงการที่มีต่อนักพัฒนา แม้ว่าขนาดของชุมชนซอฟต์แวร์โอเพนซอร์สจะแตกต่างกัน แต่ผู้ติดตามที่ภักดีและความนิยมที่เติบโตเป็นตัวบ่งชี้สำคัญว่าโครงการซอฟต์แวร์โอเพนซอร์สดึงดูดความสนใจอย่างแรงกล้าจากกลุ่มนักพัฒนา ตัวชี้วัดเหล่านี้รวมถึง GitHub stars, จำนวนผู้ทำงานร่วมกัน และจำนวน pull requests
โครงการโอเพนซอร์สสามารถเริ่มต้นได้ในหลายที่ รวมถึงบริษัทใหญ่หรือสถาบันการศึกษา อย่างไรก็ตาม ไม่สำคัญว่าโครงการเริ่มต้นที่ไหน สิ่งสำคัญคือต้องมีผู้นำโครงการที่ขับเคลื่อนงาน และผู้นำโครงการคนนี้มักจะกลายเป็น CEO ของนิติบุคคลทางธุรกิจ
การบรรลุความเหมาะสมของโครงการ-ชุมชนต้องการการมีส่วนร่วมแบบ high-touch และการยอมรับอย่างต่อเนื่องจากชุมชนนักพัฒนา ผู้นำโครงการที่ดีที่สุดจะสร้างสมดุลที่ละเอียดอ่อนระหว่างการรวมและการยืนยัน - ตัดสินใจอย่างชัดเจนเพื่อระบุทิศทางโครงการ ในขณะที่รับรองว่าเสียงของทุกคนถูกได้ยิน และการมีส่วนร่วมได้รับการยอมรับ เมื่อสมดุลนี้เกิดขึ้น โครงการจะเติบโตอย่างมีสุขภาพดีและดึงดูดให้ผู้คนมีส่วนร่วมและแจกจ่ายโครงการมากขึ้น
ในฐานะนักลงทุน เราเอนเอียงอย่างมากที่จะให้ทุนแก่ผู้นำโครงการ OSS เพราะพวกเขาเข้าใจอินพุตและเอาต์พุตของโค้ดเบส เป็นผู้พิทักษ์จิตวิญญาณและวิสัยทัศน์ของชุมชนนักพัฒนา
ผลิตภัณฑ์-ความเหมาะสมกับตลาด
เมื่อคุณมีผู้นำโครงการและกลุ่มผู้ทำงานร่วมกันที่กระตือรือร้น ขั้นตอนต่อไปคือการทำความเข้าใจและวัดความเหมาะสมของผลิตภัณฑ์กับตลาด ในกระบวนการนี้ ผู้นำโครงการต้องชัดเจน: ซอฟต์แวร์โอเพนซอร์สช่วยแก้ปัญหาอะไร? มันแก้ปัญหานั้นให้ใคร? มีทางเลือกอื่นในตลาดหรือไม่? หากไม่มีความเข้าใจที่ชัดเจนเกี่ยวกับผู้ใช้และ use case ของพวกเขา โครงการอาจถูกดึงไปหลายทิศทางและสูญเสียแรงผลักดัน
เมื่อคำถามข้างต้นได้รับคำตอบ คุณสามารถสังเกตการนำไปใช้ตามธรรมชาติ เช่น วัดจากจำนวนดาวน์โหลด ความเหมาะสมของผลิตภัณฑ์กับตลาดเป็นบทนำของกิจกรรมการขายในอนาคต ในอุดมคติ ผู้ใช้ OSS จะกลายเป็นผู้นำที่ด้านบนของกรวยสำหรับผลิตภัณฑ์หรือบริการที่เพิ่มมูลค่า - เราจะเห็นสิ่งนี้มากขึ้นเมื่อเข้าสู่ตลาด
เมื่อศึกษาความเหมาะสมของผลิตภัณฑ์กับตลาด สิ่งสำคัญคือต้องพิจารณาว่าจะอธิบายผลิตภัณฑ์เชิงพาณิชย์ของคุณอย่างไร และคุณจะส่งมอบคุณค่าที่ผู้คนยินดีจ่ายเงินได้อย่างไร ฉันต้องชี้ให้เห็นว่ามีกับดักทั่วไปอย่างหนึ่ง บางครั้งผลิตภัณฑ์ OSS อาจดีเกินไป ความเหมาะสมของผลิตภัณฑ์กับตลาดอาจดีมาก จนไม่ต้องการความเหมาะสมของคุณค่ากับตลาด ซึ่งหมายความว่าไม่มีการขยายตัวตามธรรมชาติเพื่อผลักดันรายได้ ดังนั้น เมื่อคุณผลักดันการนำไปใช้ตามธรรมชาติ คุณและชุมชนของคุณควรพิจารณาอย่างรอบคอบว่าคุณอาจพาณิชย์สิ่งใดในอนาคต
คุณค่า-ความเหมาะสมกับตลาด
ขั้นตอนสุดท้าย มักเป็นขั้นตอนที่ยากที่สุด คือการค้นหาความเหมาะสมของคุณค่ากับตลาดและสร้างรายได้ ความเหมาะสมของผลิตภัณฑ์กับตลาดมักได้รับจากผู้ใช้รายบุคคล ในขณะที่ความเหมาะสมของคุณค่ากับตลาดมักมุ่งเน้นที่ผู้ซื้อระดับแผนกและองค์กร ความลับของความเหมาะสมของคุณค่ากับตลาดคือการมุ่งเน้นที่สิ่งที่ลูกค้าใส่ใจและยินดีจ่ายเงิน ไม่ใช่สิ่งที่คุณสามารถทำเงินได้จากอะไร
ความเหมาะสมของคุณค่ากับตลาดมักเกี่ยวข้องกับฟังก์ชันของผลิตภัณฑ์น้อยกว่า แต่เกี่ยวข้องกับวิธีการนำผลิตภัณฑ์ไปใช้และประเภทของคุณค่าที่มันขับเคลื่อนมากกว่า คุณค่าที่ OSS มอบไม่เพียงแต่อยู่ที่ฟังก์ชันของมัน แต่ยังอยู่ที่ข้อได้เปรียบในการดำเนินงานและคุณสมบัติด้านขนาด ดังนั้น เมื่อพิจารณาผลิตภัณฑ์เชิงพาณิชย์ ต้องพิจารณาคำถามเหล่านี้: ผลิตภัณฑ์ของคุณแก้ปัญหาธุรกิจหลักหรือให้ข้อได้เปรียบในการดำเนินงานที่ชัดเจนหรือไม่? ยากที่จะคัดลอกหรือหาทดแทนหรือไม่? สำหรับคุณสมบัติด้านขนาดที่ทีมหรือองค์กรต้องการ มีสิ่งที่ยังไม่ถูกนำไปใช้ใน OSS หรือไม่?
แม้ว่ารายการด้านล่างนี้จะไม่ครบถ้วนสมบูรณ์ แต่บริษัทโอเพนซอร์สได้ค้นพบคุณสมบัติความเหมาะสมของคุณค่ากับตลาด เช่น:
- RAS (ความน่าเชื่อถือ, ความพร้อมใช้งาน, ความปลอดภัย)
- เครื่องมือ, ปลั๊กอิน
- ประสิทธิภาพ
- การตรวจสอบ
- บริการ
เลือกโมเดลธุรกิจ
คุณเลือกโมเดลธุรกิจแบบไหนขึ้นอยู่กับคุณค่าที่คุณสามารถมอบให้ลูกค้า และวิธีที่ดีที่สุดในการส่งมอบคุณค่านั้น โปรดทราบว่าโมเดลธุรกิจเหล่านี้ไม่ได้เฉพาะเจาะจงกัน และสามารถสร้างธุรกิจแบบผสมโดยใช้องค์ประกอบจากหลายโมเดล
การสนับสนุนและบริการเป็นโมเดลยุคโอเพนซอร์ส 1.0 RedHat ผูกขาดตลาดและขยายขนาดในด้านนี้ หากคุณตัดสินใจไปตามเส้นทางนี้ คุณอาจต้องแข่งขันกับ RedHat ในที่สุด (นี่คือเหตุผลที่ห้าปีก่อน ฉันเขียนบล็อกโพสต์ “ทำไมจะไม่มี Red Hat อีก: เศรษฐศาสตร์ของโอเพนซอร์ส)
โมเดล open core คือการเพิ่มชั้นโค้ดกรรมสิทธิ์ที่เพิ่มมูลค่าบนซอฟต์แวร์โอเพนซอร์ส นี่เป็นโมเดลซอฟต์แวร์ภายในที่ดี หากคุณมีคอมโพเนนต์ที่มีคุณค่ามาก (เช่น ความปลอดภัยหรือการบูรณาการ) ที่สามารถคงไว้เป็นกรรมสิทธิ์โดยไม่ส่งผลต่อการนำโอเพนซอร์สไปใช้ open core จะเป็นโมเดลที่ดี โปรดทราบ: การใช้ open core เมื่อตัดสินใจว่าฟีเจอร์ใดอยู่ในโค้ดใด การแปลกแยกจากชุมชนอาจกลายเป็นปัญหาได้ ฉันเห็นสิ่งนี้ในบริษัทของฉันเอง การหาวิธีที่ถูกต้องในการปรับเทียบกับชุมชนเป็นสิ่งสำคัญมาก กับดักสุดท้ายคือชุมชนตัดสินว่าพวกเขาไม่ชอบพฤติกรรมของคุณในด้านกรรมสิทธิ์ พวกเขาจึง fork โครงการ หรือเริ่มโครงการใหม่รอบโค้ดเบสเดียวกัน
ในโมเดล SaaS คุณสามารถให้บริการซอฟต์แวร์ที่โฮสต์อย่างสมบูรณ์ หากคุณค่าและความได้เปรียบในการแข่งขันของคุณอยู่ที่การดำเนินงานที่ยอดเยี่ยมของซอฟต์แวร์ SaaS เป็นตัวเลือกที่ดี อย่างไรก็ตาม เนื่องจาก SaaS มักโฮสต์บนคลาวด์ คลาวด์สาธารณะอาจเลือกที่จะรับโค้ดโอเพนซอร์สของคุณและแข่งขันกับคุณ
คลาวด์และกำแพงการแข่งขัน
เมื่อบริษัทโอเพนซอร์สบรรลุความสมบูรณ์ในระดับหนึ่ง ภัยคุกคามจากคลาวด์สาธารณะและหัวข้อการอนุญาตอาจปรากฏขึ้น การอนุญาตเป็นหัวข้อที่ถกเถียงกันมาก แม้ว่ามันจะสำคัญ แต่ฉันเห็นบริษัทใช้เวลามากเกินไปในการอภิปรายเรื่องการอนุญาตในช่วงต้น
ฉันยังคิดว่าเราให้ความสำคัญกับภัยคุกคามจากผู้ให้บริการคลาวด์สาธารณะมากเกินไป แม้ว่าผู้ให้บริการเหล่านี้อาจให้บริการโครงการโอเพนซอร์ส แต่จนถึงตอนนี้ ตามที่ฉันรู้ ไม่มีบริษัทโอเพนซอร์สใดถูกแทนที่อย่างสมบูรณ์โดยผู้ให้บริการคลาวด์
สำหรับบริษัทโอเพนซอร์ส คำถามที่สำคัญกว่าคือ: หากโค้ดไม่ใช่กำแพงการแข่งขัน แล้วอะไรคือ?
คำตอบกลับไปที่จุดแข็งดั้งเดิมของโอเพนซอร์ส: ชุมชนและมุมมองของคุณเกี่ยวกับการพัฒนา บริษัทโอเพนซอร์สอิสระมีข้อได้เปรียบในการแข่งขันสามประการ:
- ลูกค้าองค์กรไม่ต้องการถูกล็อคอินโดยผู้ขาย
- ลูกค้าองค์กรต้องการซื้อซอฟต์แวร์จากคนที่เขียนโค้ด
- บริษัทใหญ่ไม่มีความเชี่ยวชาญเฉพาะทางของคุณ
เมื่อคุณรวมสามสิ่งนี้เข้าด้วยกัน ฉันคิดว่านี่เป็นคุณค่าเพิ่มที่แข่งขันได้อย่างแท้จริง และเป็นเหตุผลที่เรายังไม่เห็นผู้ให้บริการคลาวด์รายใหญ่แทนที่บริษัทโอเพนซอร์สอิสระอย่างสมบูรณ์
ตอนนี้เราได้แนะนำเสาหลักทั้งสามแล้ว มาดูวิธีสร้างองค์กรรอบพวกมันกัน
สำหรับบริษัทโอเพนซอร์ส คำถามที่สำคัญกว่าคือ: หากโค้ดไม่ใช่กำแพงการแข่งขัน แล้วอะไรคือ? ชุมชน
การเข้าสู่ตลาด: โอเพนซอร์สอยู่ที่ด้านบนของกรวย
ชุมชนโอเพนซอร์สของคุณเป็นกิจกรรมที่ด้านบนของกรวยที่ขับเคลื่อนโดยนักพัฒนา การสร้างองค์กรคือการเชื่อมต่อด้านบนของกรวยโอเพนซอร์สนี้กับผลิตภัณฑ์เชิงพาณิชย์ที่ขับเคลื่อนด้วยคุณค่าที่แข็งแกร่ง แนวคิดกรวยไม่ใช่เรื่องใหม่ แต่สำหรับบริษัทโอเพนซอร์สมันแตกต่างจริงๆ ในส่วนนี้ ฉันจะแนะนำว่างานโอเพนซอร์สผสานรวมและเข้ากับงานเชิงพาณิชย์ในขั้นตอนต่างๆ ของกรวยอย่างไร และวิธีทำให้แต่ละขั้นตอนทำงานร่วมกับขั้นตอนอื่นๆ
กรวยการเข้าสู่ตลาดโอเพนซอร์สแบ่งออกเป็นสี่ขั้นตอนและฟังก์ชันองค์กรหลัก
- การจัดการชุมชนนักพัฒนาส่งเสริมความตระหนักรู้และความสนใจในผลิตภัณฑ์โอเพนซอร์สของคุณ
- การจัดการผลิตภัณฑ์ที่มีประสิทธิภาพจะนำผู้ใช้จำนวนมากมาสู่ผลิตภัณฑ์โอเพนซอร์สฟรีของคุณ
- ผู้นำและการพัฒนาธุรกิจประเมินเจตนาของผู้ใช้เหล่านี้เพื่อระบุคุณค่าที่อาจเกิดขึ้นและโอกาสในการขายในองค์กร
- บริการตนเอง (จากล่างขึ้นบน) และบริการขาย (จากบนลงล่าง) ส่งมอบและขยายคุณค่าของผลิตภัณฑ์หรือบริการที่ชำระเงินให้กับองค์กร
มาดูขั้นตอนและฟังก์ชันเหล่านี้อย่างละเอียดมากขึ้น
ขั้นตอนที่หนึ่ง: ความตระหนักรู้และความสนใจ - การจัดการชุมชนนักพัฒนา
การผลักดันการบอกกล่าวปากต่อปากของนักพัฒนา - วัดจากการลงทะเบียนผู้ใช้และจำนวนดาวน์โหลด - มีความสำคัญต่อความสำเร็จในขั้นตอนต่อมาของกรวยนี้ ในช่วงแรกของการก่อตั้งบริษัท ผู้ก่อตั้งมักเป็นผู้เผยแพร่กลุ่มแรกในช่วงนี้ เมื่อบริษัทขยายตัว การมีทีมเฉพาะที่ประกอบด้วยผู้เผยแพร่นักพัฒนาที่มีทั้งทักษะทางเทคนิคและทักษะการสื่อสารที่แข็งแกร่งเป็นสิ่งสำคัญ แม้ว่านี่จะเป็นการผสมผสานที่หาได้ยาก แต่เมื่อคนคนหนึ่งมีทั้งทักษะทางเทคนิคและการสื่อสาร มักจะถูกค้นพบได้ง่าย เมื่อคุณค้นพบนักพัฒนาเช่นนี้ จ้างพวกเขา ให้พวกเขาสื่อสารกับชุมชนนักพัฒนาในการประชุมและโซเชียลมีเดีย และอธิบายความสำคัญและคุณค่าของโครงการของคุณ
แม้ว่าคุณต้องการรวมข้อความการขายและนักพัฒนา แต่คุณไม่ต้องการให้ผู้จัดการชุมชนของคุณ “ขาย” พวกเขาควรกระตุ้นความสนใจในผลิตภัณฑ์ ทำให้ผู้คนเข้าใจผลิตภัณฑ์ การเน้นขายอาจทำลายความน่าเชื่อถือของพวกเขาในชุมชน
เมื่อคุณก่อตั้งบริษัท คุณยังต้องตัดสินใจว่าจะใช้ชื่อและแบรนด์เดียวกับโครงการโอเพนซอร์สหรือไม่ ไม่ว่าจะด้วยวิธีใด มีบริษัทที่ประสบความสำเร็จทั้งสองแบบ แต่ละแบบมีข้อดีข้อเสีย ชื่อที่แยกต่างหาก เช่น Databricks และ Spark สามารถป้องกันการเจือจางแบรนด์และให้ความยืดหยุ่นในการอนุญาต ในขณะที่ชื่อเดียวกันมักให้แรงผลักดันมากขึ้นสำหรับโครงการ OSS แต่อาจแปลกแยกจากชุมชนโอเพนซอร์สหากพวกเขาคิดว่าถูกใช้เพื่อผลกำไร
สุดท้าย การลงทะเบียนผู้ใช้และดาวน์โหลดเป็นมาตรฐานทั่วไปสำหรับการวัดซอฟต์แวร์โอเพนซอร์สและซอฟต์แวร์กรรมสิทธิ์ ดังนั้นความลับไม่ได้อยู่ที่คุณวัดอะไร แต่อยู่ที่ความแม่นยำในการวัด ที่ XenSource เราเคยได้ตัวเลขที่ไม่ถูกต้องเพราะเราวัดดาวน์โหลดที่รวมดาวน์โหลดที่เริ่มต้นแล้วแต่ยังไม่เสร็จสมบูรณ์จำนวนมาก การปรับปรุงวิธีวัดการลงทะเบียนผู้ใช้และความสนใจอย่างต่อเนื่องจะป้องกันไม่ให้ดาวน์โหลดกลายเป็นตัวชี้วัดความหลงตัวเองที่ไม่สามารถบรรลุขั้นตอนถัดไปของกรวยได้
ขั้นตอนที่สอง: การคิด - การจัดการผลิตภัณฑ์
ขั้นตอนต่อไปคือการคิด เมื่อคุณเข้าร่วมชุมชนนักพัฒนาแล้ว เป้าหมายของคุณคือการเพิ่มความชื่นชม การนำไปใช้ และคุณค่าจากนักพัฒนาและผู้ใช้ให้มากที่สุด ขั้นตอนที่สองของกรวยโอเพนซอร์สมักทำผ่านการจัดการผลิตภัณฑ์
การจัดการผลิตภัณฑ์ที่มีประสิทธิภาพจะใช้ฟังก์ชันหลายอย่างเพื่อสนับสนุนขั้นตอนนี้: จัดการ roadmap closed-source และโอเพนซอร์ส สื่อสารการตัดสินใจกับนักพัฒนาและผู้ใช้ สร้างฟังก์ชันการวิเคราะห์ในผลิตภัณฑ์เพื่อรวบรวมข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบการใช้งานและคาดการณ์โอกาสในการขาย
ต่างจากซอฟต์แวร์กรรมสิทธิ์ องค์กรโอเพนซอร์สมักต้องจัดการ roadmap สองอัน CEO และผู้ก่อตั้ง OSS มักใช้เวลาส่วนใหญ่ในการจัดการ roadmap เหล่านี้และวิธีที่หนึ่งตอบสนองอีกอันหนึ่ง ฉันต้องการเห็นพวกมันในหน้าเดียวกัน เพื่อให้เห็นความสัมพันธ์ระหว่างพวกมันได้ง่าย และแต่ละอันให้ฟังก์ชันอะไรบ้าง
บริษัทและผู้ก่อตั้งที่ประสบความสำเร็จมากที่สุดมีกรอบหรือแนวทางที่ช่วยให้พวกเขาอธิบายและสื่อสารว่าอะไรคือสิ่งที่ต้องชำระเงินและอะไรคือสิ่งที่ฟรี ตัวอย่างเช่น PlanetScale มุ่งมั่นที่จะรับประกันว่าจะทำให้โครงการที่สร้างการล็อคอินผู้ขายเป็นโอเพนซอร์ส ซึ่งนำมาซึ่งคุณค่าที่สามารถรักษาความปรารถนาดีของชุมชนโอเพนซอร์สและลูกค้าองค์กร การมีตารางเปรียบเทียบฟีเจอร์มีประโยชน์ เพื่อให้ลูกค้าและชุมชนเข้าใจคุณค่าที่แตกต่างกันที่ซอฟต์แวร์ฟรีและซอฟต์แวร์ที่ชำระเงินมอบให้
ความโปร่งใสของการวิจัยและพัฒนาและการนำข้อเสนอแนะจากชุมชนเข้าใน roadmap ผลิตภัณฑ์ของคุณมีความสำคัญอย่างยิ่งต่อการรักษาความไว้วางใจของชุมชน บริษัทโอเพนซอร์สที่ประสบความสำเร็จหลายแห่งยังคงกระตือรือร้นและมักเป็นผู้มีส่วนร่วมหลักของโครงการโอเพนซอร์สที่เกี่ยวข้อง ตัวอย่างเช่น Databricks มีส่วนร่วมกับ Spark มากกว่าบริษัทอื่น 10 เท่า
เมื่อพูดถึงตัวผลิตภัณฑ์เอง คุณควรสร้างฟังก์ชันการวิเคราะห์ที่ช่วยให้คุณเข้าใจผู้ใช้และคาดการณ์เปอร์เซ็นต์ของผู้ใช้ OSS ที่จะแปลงเป็นผู้ซื้อ เมื่อผู้ใช้มีผลิตภัณฑ์แล้ว การวิเคราะห์การใช้ผลิตภัณฑ์จะช่วยให้คุณระบุความเหมาะสมของผลิตภัณฑ์กับตลาดผ่านความเหมาะสมของคุณค่ากับตลาด และคิดออกว่ามีกี่คนที่เปลี่ยนจากผู้ใช้ฟรีเป็นผู้ใช้ที่ชำระเงิน จากนั้นสามารถคาดการณ์โอกาสในการขายได้ ตัวอย่างเช่น หากจากผู้ใช้ 100 คนมีผู้ใช้ 5 คนเสมอที่จะแปลงเป็นผู้ใช้ที่ชำระเงิน คุณสามารถใช้ 5% เป็นค่าประมาณเพื่อสร้างโมเดลทางการเงินของคุณ
นี่จะเป็นกระบวนการที่ซับซ้อน คุณควรทดลองแพ็คเกจผลิตภัณฑ์ที่แตกต่างกันเพื่อระบุเส้นแบ่งที่ดีที่สุดระหว่างฟรีและชำระเงิน สำหรับผู้ก่อตั้งโอเพนซอร์สหลายคน การทดลองผลิตภัณฑ์นี้เป็นการเดินทางที่ไม่รู้จบ ความสำเร็จในการนำผลิตภัณฑ์สู่ตลาดขึ้นอยู่กับวงจรข้อเสนอแนะผลิตภัณฑ์ที่แน่นแฟ้น
ขั้นตอนที่สาม: การประเมินและเจตนา - ลีดและการพัฒนาธุรกิจ
ขั้นตอนต่อไปของกรวย - การประเมินและเจตนา - เกี่ยวข้องกับการตรวจสอบและปรับปรุงทฤษฎีที่เกี่ยวข้องกับลีดและการพัฒนาธุรกิจ เป้าหมายคือการค้นหาเส้นทางสู่ความสำเร็จจากผู้ใช้สู่ผู้ซื้อองค์กรผ่านการวัดความสำเร็จของลีดที่ผ่านการคัดเลือก (sales qualified leads, SQL)
ส่วนแรกคือการตลาดแบบ outbound การตลาดแบบ outbound ควรให้ความสำคัญกับตลาดเฉพาะกลุ่มก่อน โดยอ้างอิงจากรูปแบบที่ผู้เผยแพร่นักพัฒนาที่ด้านบนของกรวยคุ้นเคย มุ่งเน้นไปที่ผู้ใช้โอเพนซอร์สของคุณ ทำความเข้าใจว่าบทบาทและแผนกใดกำลังใช้ผลิตภัณฑ์ และความสนใจของพวกเขาคืออะไร จากนั้นคุณสามารถกำหนดเป้าหมายการตลาดแบบ outbound ไปที่ผู้จัดการวิศวกรรม, DevOps หรือบุคลากรด้าน IT ที่คิดว่าผลิตภัณฑ์ของคุณมีคุณค่า
ต่อไปคืองานพัฒนาการขาย ตัวแทนพัฒนาการขาย (SDR) ควรใช้วิธีการที่ทำให้ลูกค้าประสบความสำเร็จแทนที่จะเป็นการขายผลิตภัณฑ์โดยสมบูรณ์ และมีความอยากรู้อยากเห็นเกี่ยวกับความต้องการของผู้ใช้และสถานการณ์การใช้ผลิตภัณฑ์ของพวกเขาเสมอ
เมื่อคุณได้ลีดจากกิจกรรม มีเกณฑ์การคัดกรองหลักสองประการ: 1) นักพัฒนาหรือผู้ใช้เป็นตัวแทนขององค์กรใด? 2) พวกเขาได้ดาวน์โหลดหรือมีส่วนร่วมในโครงการของคุณหรือไม่ และเป้าหมายคือการทำให้มันเป็นสิ่งที่ช่วยบรรลุเป้าหมายองค์กรที่ใหญ่ขึ้น?
ขั้นตอนที่สี่: การซื้อและการขยาย - การขายภายในและภาคสนาม
เมื่อมีลีดที่ผ่านการคัดเลือกแล้ว คุณอาจมีกิจกรรมการขายให้องค์กรสองประเภท ประเภทแรกอาจเป็นกิจกรรมแบบ bottom-up ที่ผู้ใช้ในองค์กรนำผลิตภัณฑ์ไปใช้ทีละน้อยและชำระเงินเพื่อผลิตภัณฑ์ โดยทั่วไป ผลิตภัณฑ์นี้มุ่งเน้นที่บุคคล ประเภทที่สองคือกิจกรรมบริการขายที่ใช้วิธีการ top-down แบบดั้งเดิมมากขึ้น ทำธุรกรรมในระดับแผนก หรือขยายการใช้งานทั่วทั้งองค์กร
ความสำเร็จและความล้มเหลวเป็นอย่างไร
ดังที่เพื่อนร่วมงานของฉัน Martin Casado ชี้ในหนังสือของเขา “การเติบโต การขาย และยุคใหม่ของ B2B” การปฏิบัติต่อการเติบโตแบบออร์แกนิกและการขายองค์กรเท่าเทียมกันอาจนำไปสู่โหมดความล้มเหลวของธุรกิจโอเพนซอร์สทั่วไปหลายแบบ ก่อนอื่น ผู้ใช้โอเพนซอร์สของคุณจะไม่กลายเป็นผู้ซื้อ ในกรณีนี้ คุณมีความเหมาะสมของผลิตภัณฑ์กับตลาดที่ดี แต่ไม่มีความเหมาะสมของคุณค่ากับตลาด
ในโหมดความล้มเหลวประเภทที่สอง โครงการ OSS ของคุณล้าหลังการขายองค์กรของคุณ ในกรณีนี้ ความเหมาะสมของผลิตภัณฑ์กับตลาดอาจไม่ดีมาก ในกรณีที่สาม ผลิตภัณฑ์เชิงพาณิชย์ของคุณทำลายความน่าเชื่อถือของคุณในชุมชนนักพัฒนา สิ่งที่เป็นกรรมสิทธิ์อาจมากเกินไป และสิ่งที่เป็นโอเพนซอร์สน้อยเกินไป ทำให้โครงการโอเพนซอร์สของคุณสูญเสียชีวิต
ด้านบนของกรวยเป็นกุญแจสำคัญของงานที่ตามมาทั้งหมด ดังนั้นให้ลงทุนกับชุมชนนักพัฒนา โครงการโอเพนซอร์ส และผู้ใช้ของคุณก่อน จากนั้นจึงเป็นการตลาดและการขายอย่างเป็นทางการ อย่าลืมคำถามหลักสามข้อนี้: ใครคือผู้ใช้ของคุณ? ใครคือผู้ซื้อของคุณ? ผลิตภัณฑ์โอเพนซอร์สและเชิงพาณิชย์ของคุณมอบคุณค่าให้ทุกคนอย่างไร?
หากประสบความสำเร็จ คุณอาจเห็นกราฟคล้ายด้านบน แกน y คือรายได้ต่อลูกค้า แกน x คือเวลา กราฟนี้เป็นการสังเกตโดยตรงของฉันในฐานะอดีตสมาชิกคณะกรรมการของ GitHub มันแสดงการขายแบบ top-down และ bottom-up เนื่องจากรายได้ของพวกเขารวมกัน ประเด็นคือ: หากรายได้ของคุณดูเหมือนเค้กเป็นชั้นๆ นี่เป็นสัญญาณที่ดี เส้นสีส้มคือรายได้แบบ bottom-up จากบุคคล มักจะมีเส้นรายได้แบบนี้ เส้นรายได้ถัดไปอาจเป็นการขายให้ผู้ซื้อระดับแผนก แต่เป็นแบบ top-down มักใช้การขายภายใน ส่วนถัดไปของเค้กเป็นชั้นๆ คือการขายภาคสนาม หรือการขายโดยตรง ขายหรือขยายบัญชีทั่วทั้งองค์กร เพื่อปรับให้เหมาะสมกับเส้นรายได้แต่ละเส้น อย่าขายแบบสุ่ม หาคนที่มีฟังก์ชันเฉพาะและผลักดันงานนี้อย่างมีจุดประสงค์
สุดท้าย ขึ้นอยู่กับผลิตภัณฑ์ของคุณ คุณอาจมีเฉพาะบริการตนเองหรือเฉพาะการขายภายใน นี่ก็โอเค ขึ้นอยู่กับความซับซ้อนของผลิตภัณฑ์ และที่ไหนและอย่างไรที่ดีที่สุดในการใช้มัน ฉันพบว่าบริษัทโอเพนซอร์สส่วนใหญ่มีการผสมผสานกิจกรรมการขายแบบ top-down และ bottom-up บางอย่าง มักเริ่มจาก bottom-up จากนั้นเพิ่มกิจกรรมการขยายรายได้ด้านบน
OSS 3.0 - โอเพนซอร์สกลายเป็นส่วนประกอบของทุกบริษัทซอฟต์แวร์
เช่นเดียวกับที่ซอฟต์แวร์กลืนกินโลก โอเพนซอร์สก็กลืนกินซอฟต์แวร์
ปัจจุบัน เกือบทุกบริษัทเทคโนโลยีหลัก ตั้งแต่ Facebook ถึง Google ต่างสร้างบนซอฟต์แวร์โอเพนซอร์ส บริษัทเหล่านี้ยังสร้างโครงการโอเพนซอร์สของตัวเองมากขึ้นเรื่อยๆ - ตัวอย่างเช่น Airbnb มีโครงการโอเพนซอร์สมากกว่า 30 โครงการ Google มีมากกว่า 2,000 โครงการ!
ในอนาคต วงจร virtuous นี้จะดำเนินต่อไป ทางด้านเทคโนโลยี ปัญญาประดิษฐ์ ข้อมูลโอเพนซอร์ส และบล็อกเชนเป็นตัวอย่างของนวัตกรรมที่เกิดขึ้นใหม่ โมเดลธุรกิจรุ่นต่อไปอาจรวมถึง OSS ที่สนับสนุนโดยโฆษณา (เหมือนบริษัทกรรมสิทธิ์ขนาดใหญ่สนับสนุนโครงการโอเพนซอร์ส) รายได้ที่ขับเคลื่อนด้วยข้อมูล และ crypto tokens (การทำให้บล็อกเชนเป็นเงินตรา)
ฉันเชื่อว่าโอเพนซอร์ส 3.0 จะขยายความคิดและนิยามของเราเกี่ยวกับองค์กรโอเพนซอร์ส โอเพนซอร์สจะไม่ใช่ RedHat, Elastic, Databricks และ Cloudera อีกต่อไป มันจะเป็น - อย่างน้อยบางส่วน - Facebook, Airbnb, Google และองค์กรอื่นๆ ที่ใช้โอเพนซอร์สเป็นธุรกิจหลัก เมื่อเรามองโอเพนซอร์สในแบบนี้ ยุคฟื้นฟูที่กำลังดำเนินอยู่อาจเพิ่งเริ่มต้น ตลาดและความเป็นไปได้ของซอฟต์แวร์โอเพนซอร์สใหญ่กว่าที่เราจินตนาการ
ลิงก์ต้นฉบับ: https://a16z.com/2019/10/04/commercializing-open-source/
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
