อนาคตของโอเพนซอร์ส

 (blog.gitbutler.com)
19 คะแนน โดย xguru 2024-08-12 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตอนที่ Anne ซึ่งเป็น COO และผู้ร่วมก่อตั้งของเรา เคยเป็น CEO ของบริษัทอาหารเยอรมัน Delinero เธอเคยถูกฟ้องร้อง เพราะมีการระบุแยมราสป์เบอร์รีที่ซัพพลายเออร์จัดหาให้ว่า "Himbeermarmelade" ทั้งที่ในเยอรมนีมี 'Konfitürenverordnung(กฎระเบียบแยม)' ซึ่งกำหนดว่าจึงจะระบุว่า "marmelade" ได้ ต้องมีผลไม้ตระกูลส้มอย่างน้อย 20%
  • แม้นี่จะเป็นข้อกำหนดที่ขัดกับความหมายของคำที่ใช้กันทั่วไป แต่ก็เป็นกฎหมายที่ผู้มีส่วนได้ส่วนเสียส่วนน้อยกำหนดไว้ตั้งนานแล้ว จึงต้องปฏิบัติตาม
  • สถานะของ "โอเพนซอร์ส" ในปัจจุบันก็อาจมองว่าคล้ายกัน OSI ยังคงกำกับคำที่วิวัฒน์ไปต่างจากการใช้งานทั่วไปอย่างเข้มงวด ราวกับ Konfitürenverordnung
  • แต่เราจะเดินหน้าไปในทิศทางที่สร้างสรรค์ได้อย่างไร?

วิธีที่จะไม่ทำ "โอเพนซอร์ส"

  • ตอนที่ GitButler เปิดเผยโค้ดฝั่งไคลเอนต์แบบ "Fair Sourcing" ภายใต้ไลเซนส์ที่ OSI ไม่รับรอง เราคิดหนักว่าจะประกาศอย่างไร
  • คนส่วนใหญ่มองว่า "โอเพนซอร์ส" เท่ากับ "เปิดไว้บน GitHub" และเพราะนัยที่ค่อนข้างเสี่ยงของไลเซนส์แบบ GPL/copyleft ผู้คนจึงคุ้นเคยมากกับการตรวจสอบว่าใช้ไลเซนส์ใด
  • แต่เราก็ไม่อยากใช้คำกำกวมอย่าง "Source Available'd" และเพื่อหลีกเลี่ยงความสับสนจึงใช้คำว่า "open" แต่กลับถูกโจมตี
  • ทำให้ตระหนักว่ามีคนจำนวนน้อยแต่เสียงดังที่พยายามปกป้องและทำให้คำนี้มีความหมายเฉพาะเจาะจง
  • "โอเพนซอร์ส" ไม่ใช่ภาวะปฏิเสธเชิงตรรกะของ "โคลสซอร์ส" ระหว่างการเปิดบน GitHub และเปิดให้มีส่วนร่วม กับ "โอเพนซอร์ส" แบบที่ OSI กำกับด้วยนิยามเชิงเทคนิค 10 ข้อนั้น มีช่องว่างของความเข้าใจในระดับมหาชนอยู่

ประวัติโดยย่อของโอเพนซอร์ส

  • ในยุคคอมพิวเตอร์แรกเริ่มช่วงทศวรรษ 1950-60 ซอฟต์แวร์ผูกติดกับฮาร์ดแวร์ จึงไม่จำเป็นต้องแยกมันออกมา และบริษัทฮาร์ดแวร์ก็แจกจ่ายอย่างเสรี
  • พอเข้าสู่ทศวรรษ 1970-80 เมื่อฮาร์ดแวร์กลายเป็นสินค้าโภคภัณฑ์ ซอฟต์แวร์จึงมีมูลค่าในตัวเอง และบริษัทใหญ่เช่น IBM, AT&T ก็เริ่มจำกัดการเข้าถึงซอร์สโค้ดที่พัฒนาด้วยต้นทุนของตน
  • เพื่อตอบโต้ Richard Stallman และคนอื่น ๆ จึงเริ่มสร้าง OS และเครื่องมือของตนเองที่ได้รับการคุ้มครองจากผลประโยชน์ขององค์กร และใช้ไลเซนส์แบบต่างตอบแทนอย่าง GPL เพื่อบังคับว่าหาก IBM, AT&T ใช้ผลงานเหล่านั้น ก็ต้องทำของตนให้เป็นฟรีซอฟต์แวร์ด้วย

    "ถ้าพวกเราเล่นของเล่นของคุณไม่ได้ คุณก็เล่นของเล่นของพวกเราไม่ได้เหมือนกัน"

    • พวกเขาเรียกขบวนการนี้ว่า "ฟรีซอฟต์แวร์" และสร้างเครื่องมือที่ยอดเยี่ยมมากมาย เช่น Emacs และระบบคอมไพเลอร์ GNU ซึ่งยังคงเป็นเครื่องมือพื้นฐานของคอมพิวเตอร์สมัยใหม่ส่วนใหญ่จนถึงทุกวันนี้
    • จุดเน้นหลักของขบวนการฟรีซอฟต์แวร์คือการรับประกันเสรีภาพที่ผู้ใช้จะสามารถรัน คัดลอก แจกจ่าย ศึกษา แก้ไข และปรับปรุงซอฟต์แวร์ได้ เป็นเสรีภาพที่เวลานั้นถูกผลประโยชน์ทางธุรกิจรอบตัวพวกเขาช่วงชิงไป
  • ต้นทศวรรษ 1990 เมื่อมีเคอร์เนล Linux ของ Linus Torvalds จึงเกิดเป็น OS ที่สมบูรณ์ และระบบนิเวศฟรีซอฟต์แวร์อย่าง LAMP stack ก็เติบโตขึ้นจนภาคธุรกิจเริ่มใช้งานและพึ่งพา
  • ในปี 1997 Eric Raymond เผยแพร่บทความ "The Cathedral and the Bazaar" ที่ชี้ว่าโมเดลการพัฒนาฟรีซอฟต์แวร์เหนือกว่าแบบปิด และบทความนี้ถูกอ้างเพื่อสร้างความชอบธรรมให้ Netscape เปิดซอร์สโค้ดของ Navigator Suite
    • เมื่อ Netscape ตัดสินใจเปิดซอร์สโค้ด ในการประชุมเชิงกลยุทธ์ที่ Palo Alto Raymond และนักพัฒนา Linux กับฟรีซอฟต์แวร์ที่มีชื่อเสียงอีกไม่กี่คน ตกลงกันว่าจะสร้างและใช้คำใหม่ว่า "โอเพนซอร์ส"

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

  • สิ่งสำคัญคือ ระหว่าง "ฟรีซอฟต์แวร์" กับ "โอเพนซอร์ส" แทบไม่มีความแตกต่างเชิงกฎหมายหรือเชิงปฏิบัติที่เป็นสาระสำคัญ
    • ไลเซนส์ส่วนใหญ่เข้ากันได้และได้รับการยอมรับภายใต้นิยามทั้งสองแบบ
    • "โอเพนซอร์ส" เป็นเพียงการรีแบรนด์ให้เป็นมิตรกับธุรกิจ เพื่อแยกเป้าหมายทางการเมืองของ Stallman และขบวนการของเขาออกจากคุณค่าด้านประโยชน์ใช้สอยของการเปิดซอฟต์แวร์ เพื่อให้บริษัทต่าง ๆ อย่าง Netscape ยอมรับการเปิดซอร์สโค้ดเชิงวิชาชีพมากขึ้น
  • หรืออย่างที่ฝั่งฟรีซอฟต์แวร์พูดไว้ว่า

    "โอเพนซอร์สคือวิธีวิทยาการพัฒนา ส่วนฟรีซอฟต์แวร์คือขบวนการทางสังคม"

โอเพนซอร์สและยุค GitHub

  • นิยามและการตลาดของวลี "โอเพนซอร์ส" เกิดขึ้นในปี 1998 ซึ่งนับจากตอนนี้ก็เกิน 25 ปีแล้ว ถ้าอย่างนั้น ในช่วง 25 ปีที่ผ่านมาเกิดอะไรขึ้นกับโอเพนซอร์สและการพัฒนาซอฟต์แวร์บ้าง?
  • โดยเฉพาะในช่วง 10 ปีที่ผ่านมา GitHub และการพัฒนาซอฟต์แวร์สไตล์ GitHub มีอิทธิพลอย่างมหาศาลต่อโอเพนซอร์ส
  • ปี 1998 เราพยายามโน้มน้าวให้บริษัทต่าง ๆ ยอมรับซอฟต์แวร์แบบเปิด แต่ปัจจุบันซอฟต์แวร์โอเพนซอร์สแทบทั้งหมดถูกเขียนหรือสนับสนุนโดยบริษัท
  • หนึ่งในการเปลี่ยนแปลงที่ใหญ่ที่สุดคือ "การทำให้เวิร์กโฟลว์การพัฒนาเป็นมาตรฐาน" โดยเฉพาะอย่างยิ่งจากบทบาทนำของ GitHub
  • ก่อนหน้านี้มีความแตกต่างมากระหว่างโปรเจ็กต์ซอฟต์แวร์เปิดกับโปรเจ็กต์ของบริษัท แต่ตอนนี้แทบไม่ต่างกันแล้ว
    • ทุกคนใช้ Git
    • เกือบทุกคนใช้ pull request (หรือ merge request หรือวิธีอื่นที่โคลนฟีเจอร์นี้)
    • ทีมส่วนใหญ่ใช้รูปแบบใดรูปแบบหนึ่งของ GitHub Flow (Trunk-based development, Gitlab Flow เป็นต้น)
  • ตอนนี้ความต่างเพียงอย่างเดียวคือรีโพซิทอรีเป็นสาธารณะหรือไม่ เมื่อ 25 ปีก่อนมีแรงเสียดทานในกระบวนการมาก แต่ตอนนี้แทบไม่ต้องเปลี่ยนกระบวนการเลยเพื่อทำให้เป็นโอเพนซอร์ส

ก้าวถัดไปของโอเพนซอร์สคืออะไร

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

ปัญหาความยั่งยืนของนักพัฒนา

  • เมื่อเราพึ่งพาโอเพนซอร์สมากขึ้น ก็เกิดปัญหาเรื่องความยั่งยืนและการบำรุงรักษา กรณีการโจมตีด้วย backdoor ใน XZ Utils เป็นตัวอย่างที่ดังเมื่อไม่นานมานี้
  • เมนเทนเนอร์แทบทุกคนกำลังเผชิญกับภาวะหมดไฟและการคุกคาม การเขียนและดูแลซอฟต์แวร์โอเพนซอร์สพร้อมกับหาเลี้ยงชีพจากมันแทบเป็นไปไม่ได้
  • ตอนนี้นักพัฒนาและเมนเทนเนอร์โอเพนซอร์สส่วนใหญ่ได้รับการสนับสนุนจากบริษัทใหญ่
    • หากดู Linux, Git, Ruby, React เป็นต้น ผู้มีส่วนร่วมส่วนใหญ่ในโปรเจ็กต์โอเพนซอร์สสำคัญ ๆ ถูกจ้างงานอย่างมืออาชีพโดยสปอนเซอร์องค์กรอย่าง GitHub, Microsoft, Red Hat ฯลฯ
  • เป็นเรื่องยากที่นักพัฒนาจะดูแลโปรเจ็กต์อย่าง XZ Utils ไปพร้อมกับมีรายได้เลี้ยงชีพที่เหมาะสม
    • แทนที่จะให้บริษัทเดียวจ่ายเงินให้นักพัฒนา ทางออกที่เหมาะกว่าน่าจะเป็นให้บริษัทหลายพันแห่งช่วยจ่ายคนละเล็กละน้อยแก่เมนเทนเนอร์มืออาชีพ
  • ปัญหาหลักคือ ตอนนี้ยังไม่มีวิธีที่ดีพอจะทำสิ่งนี้ได้
    • มีโครงการริเริ่มที่มีแนวโน้มดี เช่น GitHub Sponsors, Thanks.dev, Liberapay, Tidelift แต่ก็ยังแก้ปัญหาแรงจูงใจที่เหมาะสมให้บริษัทบริจาคไม่ได้
  • Sentry กำลังผลักดันโครงการริเริ่มใหม่ชื่อ OSS Pledge และ GitButler ก็มีแผนจะเข้าร่วมเมื่อเปิดตัวในเดือนตุลาคม
  • แต่ก็ยังไม่แน่ชัดว่าวิธีแบบนี้จะสามารถแก้ปัญหาใหญ่และยิ่งทวีความรุนแรงขึ้นเรื่องความยั่งยืนของนักพัฒนาในระบบนิเวศโอเพนซอร์สได้หรือไม่

ปัญหาของโอเพนซอร์สเชิงพาณิชย์

  • นักพัฒนาจำนวนมากเติบโตมาพร้อมกับความรักต่อโอเพนซอร์สและชุมชนแบบเปิด ดังนั้นเมื่อเริ่มบริษัทหรือโปรเจ็กต์ พวกเขาจึงอยากทำให้เปิดโดยปริยาย
    • แต่เช่นเดียวกับเมนเทนเนอร์รายบุคคล โอเพนซอร์สก็มีปัญหาความยั่งยืนในระดับบริษัทด้วย
  • อย่างที่เห็นในกรณีของ Elasticsearch และ Redis เมื่อคุณลงทุนเวลาและเงินเพื่อพัฒนาซอฟต์แวร์อย่างมืออาชีพ ก็มีความเสี่ยงที่บริษัทใหญ่อย่าง Amazon จะนำผลงานของคุณไปใช้เพื่อแข่งขันโดยตรงกับคุณ
  • ผู้สร้างซอฟต์แวร์มืออาชีพจำนวนมากจึงต้องการลงทุนในซอฟต์แวร์ โดยมั่นใจว่าภายหลังมันจะไม่ถูกนำไปใช้ย้อนกลับมาทำร้ายตนเอง
    • นั่นหมายถึงการต้องสร้างสรรค์ด้านไลเซนส์ หรือไม่ก็ปิดซอร์สโค้ด
  • ฉันเชื่อว่าขบวนการ Fair Source คือคำตอบที่ยอดเยี่ยมและจำเป็นต่อปัญหาที่เพิ่มขึ้นนี้ และช่วยอุดช่องว่างในระบบนิเวศโอเพนซอร์สที่ก่อปัญหาและความสับสนมากขึ้นเรื่อย ๆ ในช่วงหลายปีที่ผ่านมา
    • มันคือคำใหม่ที่ใช้เรียกโปรเจ็กต์เชิงวิชาชีพที่ส่วนใหญ่เปิดกว้าง อนุญาตได้ ซอร์สพร้อมใช้ และมีชุมชน GitHub เข้ามามีส่วนร่วม ซึ่งฉันคิดว่าเป็นทางออกที่จำเป็นอย่างยิ่งเพื่อกระตุ้นให้โปรเจ็กต์ที่ก่อนหน้านี้ทำกันแบบปิด หันมาเปิดมากขึ้น

อนาคตของการทำงานร่วมกัน

  • อนาคตของโอเพนซอร์สไม่ใช่แค่ "Open Source" และ Konfitürenverordnung 10 ข้อของ OSI เท่านั้น
  • แต่มันคือการผสมผสานระหว่าง Open Source ที่เป็นไปได้และมีคุณค่าสำหรับทุกคน, Fair Source ที่จำเป็นต่อการลงทุนอย่างปลอดภัย และการร่วมระดมทุนขนาดใหญ่ให้กับไลบรารีและโปรเจ็กต์โอเพนสำคัญระดับฐานราก
  • เราต้องทำให้การดูแลไลบรารีโอเพนซอร์สสำคัญ ๆ มีความยั่งยืน และต้องยอมรับพร้อมทำให้เป็นเรื่องปกติสำหรับกลุ่มไลเซนส์เชิงพาณิชย์แบบซอร์สพร้อมใช้ที่ยั่งยืน
  • เราควรทำทุกอย่างให้เป็นโอเพนซอร์สด้วยไลเซนส์แบบ OSI ที่เปิดได้มากที่สุดเท่าที่จะทำได้ และเหนือสิ่งอื่นใด ต้องทำให้โคลสซอร์สกลายเป็นเรื่องของอดีต
  • สิ่งที่คุณทำได้ตอนนี้คือ
    • เปลี่ยนซอฟต์แวร์แบบปิดให้เป็น Fair Source และ
    • หากคุณพึ่งพาโอเพนซอร์ส ก็เข้าร่วม OSS Pledge

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
bus710 2024-08-13

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

โดยเฉพาะยูทิลิตีเดสก์ท็อป/เทอร์มินัลใน user space นั้นยิ่งได้รับการสนับสนุนแบบนี้ได้ยาก ถ้าเป็นเคอร์เนลก็มีบริษัทยักษ์ใหญ่สนับสนุนกันมาก ถ้าเป็นมือถือก็มี App Store ที่ทำเชิงพาณิชย์ได้ดีอยู่แล้ว ส่วนเว็บหรือเฟิร์มแวร์ก็มีการวิเคราะห์ตลาดในระดับหนึ่งก่อนพัฒนา จึงกังวลน้อยกว่า แต่ซอฟต์แวร์และไลบรารีที่ผู้ใช้ทั่วไปใช้งานกันโดยไม่รู้ตัวนั้น มักตั้งเกณฑ์ได้ยาก เลยดูจะหารายได้ยากมาก โอเพนซอร์สแม้จะค่อนข้างคึกคัก แต่ก็ไม่ง่ายที่จะก้าวไปได้ไกลกว่านั้น
 
bus710 2024-08-13

ฉันรักและใช้งานโอเพนซอร์สอยู่เสมอ จึงหวังว่าผู้คนที่ทุ่มเทพัฒนาอย่างหนักอยู่เบื้องหลังเพื่อคนจำนวนมากจะได้รับประโยชน์จากการกำหนดไลเซนส์ที่เหมาะสมเช่นกัน
 
chabulhwi 2024-08-13

ในบทความของ Drew Devault ชื่อ 'So you want to compete with or replace open source(คุณอยากแข่งขันกับหรือแทนที่โอเพนซอร์สสินะ?)' มีข้อความต่อไปนี้

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

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

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

แต่ผมก็ยังสงสัยว่า fair source จะได้รับประโยชน์จากการมีผู้ร่วมพัฒนาโดยไม่คิดค่าใช้จ่ายได้เหมือนโอเพนซอร์สหรือไม่ และเมื่อใครก็ตามเผยแพร่ซอฟต์แวร์ของตนเป็นโอเพนซอร์ส คนคนนั้นควรตระหนักว่าตนอาจไม่ได้รับค่าตอบแทนทางการเงินจากผู้ใช้คนใดเลย {และ/หรือ} ซอฟต์แวร์นั้นอาจกลายเป็น 'มื้อฟรี' ของบริษัทยักษ์ใหญ่ด้านคลาวด์ได้