Rug Pull, Fork และศักดินาแบบโอเพ่นซอร์ส

• สรุปว่า พลวัตของอำนาจ ในระบบนิเวศโอเพ่นซอร์สทำงานอย่างไรระหว่างบริษัท นักพัฒนา และผู้ใช้ รวมถึงผลกระทบของยุทธวิธีอย่าง rug pull (การเปลี่ยนไลเซนส์ใหม่) และ fork ที่เข้ามาเขย่าระบบนี้
• ท่ามกลางอิทธิพลมหาศาลของ ผู้ให้บริการคลาวด์ โครงการที่มีบริษัทเดียวเป็นศูนย์กลางสามารถ รีไลเซนส์ เพื่อจัดสรรอำนาจใหม่ได้ และ fork ก็เกิดขึ้นเพื่อตอบโต้
• การวิเคราะห์กรณีศึกษาพบรูปแบบที่แตกต่างกันของ การปรับโครงสร้างชุมชน และ การย้ายของผู้มีส่วนร่วม ใน Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey, Puppet→OpenVox เป็นต้น
• การใช้ CLA, การครอบงำโดยบริษัทเดียว, และ จังหวะเวลาในการย้ายไปอยู่ภายใต้มูลนิธิ ถูกเสนอเป็นสัญญาณเตือนความเสี่ยงของ rug pull ขณะที่ ธรรมาภิบาลที่เป็นกลาง และ การขยายฐานผู้มีส่วนร่วมจากหลายองค์กร ถูกแนะนำเป็นกลยุทธ์รับมือ
• โดยสรุป การรีไลเซนส์อาจเป็น เครื่องมือถ่วงดุลคลาวด์ ได้ แต่ก็ทำให้อำนาจของผู้มีส่วนร่วมอ่อนแอลงไปพร้อมกัน และ ความเป็นไปได้ของการ fork ก็ทำหน้าที่เป็นแรงยับยั้งต่อการตัดสินใจของบริษัท

---

โครงสร้างอำนาจในโอเพ่นซอร์ส, rug pull และ fork

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

ภาพรวมของพลวัตอำนาจและยุทธวิธี

• ในโลกโอเพ่นซอร์ส ผู้ให้บริการคลาวด์รายใหญ่ มี อำนาจด้านช่องทางและการกระจายซอฟต์แวร์ สูงที่สุด จนเกิดโครงสร้างที่เอาเปรียบบริษัทขนาดเล็ก ผู้มีส่วนร่วม และผู้ใช้
  • คล้ายยุคศักดินาที่ควบคุมที่ดิน ผู้ให้บริการคลาวด์ นำซอฟต์แวร์โอเพ่นซอร์สไปทำเป็นบริการ โดยหลีกเลี่ยงการมีส่วนร่วมกลับคืน
  • บริษัทขนาดเล็กเป็นฝ่ายรับภาระงานพัฒนาส่วนใหญ่ แต่กลับอยู่ในตำแหน่งเสียเปรียบเพราะคลาวด์นำไปใช้ได้ฟรี
• ยุทธวิธี rug pull ทำให้บริษัทขนาดเล็ก รีไลเซนส์ซอฟต์แวร์ เพื่อตอบโต้ผู้ให้บริการคลาวด์ แต่กลับสร้างความเสียหายต่อผู้มีส่วนร่วมและผู้ใช้มากกว่า
  • เมื่อผู้ให้บริการคลาวด์เปลี่ยนโครงการเป็นบริการโดยไม่ร่วมพัฒนา อำนาจของบริษัทขนาดเล็กจึงอ่อนลง
  • การรีไลเซนส์ทำให้ผู้ใช้เสียประโยชน์ แต่ยังสามารถ ปรับสมดุลอำนาจใหม่ผ่าน fork ได้
• ในโครงการที่ขับเคลื่อนโดยบริษัทเดียว ความเสี่ยงของ rug pull สูง จึงต้องประเมินชื่อเสียงของบริษัท แต่สิ่งนี้อาจไร้ความหมายเมื่อเกิดการควบรวมกิจการหรือบริษัทล้มละลาย
  • แรงกดดันจากนักลงทุนอาจนำไปสู่การรีไลเซนส์เพื่อเพิ่มรายได้ โดยเฉพาะเมื่อแข่งขันกับผู้ให้บริการคลาวด์
  • การใช้ไลเซนส์ที่เข้มงวดขึ้นเป็นความพยายามย้ายอำนาจ โดยทำให้บริษัทอื่นหารายได้จากโครงการนั้นได้ยากขึ้น
• การเกิด fork หลัง rug pull เป็นรูปแบบของการรวมตัวเชิงต่อต้านเพื่อทวงคืนอำนาจ แต่ก็ มีความเสี่ยงล้มเหลวสูงจากการขาดคนและทรัพยากร
  • บริษัทใหญ่หรือผู้ให้บริการคลาวด์อาจใช้ทรัพยากรสนับสนุน fork ได้ แต่ fork ที่ได้รับความนิยมก็ไม่ได้ประสบความสำเร็จเสมอไป
  • มีกรณีที่ไม่เกิด fork เช่น MongoDB หรือ Sentry ขณะที่หลัง Perforce เข้าซื้อ Puppet และทำให้การพัฒนาไม่เปิดเผย ก็เป็นชนวนให้เกิด fork ชื่อ OpenVox

เปรียบเทียบกรณีศึกษาหลัก

Dawn Foster วิเคราะห์ rug pull, fork และผลกระทบหลังจากนั้น จากข้อมูลหลายชุด (มีการเผยแพร่ผลบางส่วนผ่านชุดข้อมูล Jupyter notebook)

• Elasticsearch → OpenSearch
  • หลัง Elastic รีไลเซนส์เป็น SSPL ในปี 2021 AWS ก็จัดตั้ง fork ชื่อ OpenSearch
  • สัดส่วน ผู้มีส่วนร่วมภายในบริษัท ของ Elastic แทบไม่เปลี่ยนมากก่อนและหลัง fork ขณะที่ OpenSearch ยังคงมีรูปแบบ การมีส่วนร่วมที่ Amazon นำเป็นหลัก
  • การวิเคราะห์ระบุว่าแม้จะ ย้ายไป Linux Foundation ในปี 2024 ก็ยังไม่พบ การพุ่งขึ้นของผู้มีส่วนร่วมภายนอก อย่างชัดเจน
• Terraform → OpenTofu
  • ทันทีหลัง HashiCorp เปลี่ยนเป็น BSL ในปี 2023 ก็เกิด OpenTofu ภายใต้ Linux Foundation
  • Terraform ยังคงรักษารูปแบบ การมีส่วนร่วมจากคนในบริษัทเป็นหลัก แต่ OpenTofu มี ผู้มีส่วนร่วมหน้าใหม่จากหลายบริษัท ไหลเข้ามาอย่างรวดเร็ว
  • กรณีนี้ชี้ว่า fork ที่ขับเคลื่อนโดยผู้ใช้ + การตั้งมูลนิธิที่เป็นกลางตั้งแต่ต้น เอื้อต่อการสร้าง ชุมชนที่มีชีวิตชีวา
• Redis → Valkey
  • ทันทีหลัง Redis เปลี่ยนเป็น SSPL ในปี 2024 ผู้มีส่วนร่วมภายนอก เดิมจำนวนมากก็ย้ายไป Valkey
  • Redis เป็นกรณีพิเศษที่ก่อน fork มี สัดส่วนการมีส่วนร่วมจากภายนอกสูง แต่หลัง fork ลดฮวบจนเหลือ ผู้มีส่วนร่วมภายนอกเป็นศูนย์ ขณะที่ Valkey เริ่มต้นเป็น ชุมชนพันธมิตรจากหลายบริษัท
• Puppet → OpenVox
  • หลังถูก Perforce เข้าซื้อกิจการในปี 2022 ก็เกิด การพัฒนาและการออกรุ่นแบบไม่เปิดเผย และ ความถี่ในการออกรุ่นลดลง ทำให้ชุมชนผลักดัน fork ชื่อ OpenVox เพื่อตอบโต้

ข้อสังเกตจากข้อมูลและเมตริก

• หลัง rug pull มักพบว่า จำนวน GitHub fork พุ่งสูงขึ้น ซึ่งตีความได้ว่าเป็น สัญญาณตัวแทน ของการเคลื่อนไหวเพื่อพิจารณา hard fork
  • ในระยะยาวมักเห็นแนวโน้มว่า ต้นฉบับกับ fork เดินหน้าควบคู่กัน แต่ก็มีการวิเคราะห์ว่าต้นฉบับที่ถูกรีไลเซนส์มักมี การใช้งานลดลง
• การ เริ่มต้นภายใต้ร่มของมูลนิธิ เอื้อต่อการ ดึงผู้มีส่วนร่วม ในระยะเริ่มต้นของโครงการใหม่ แต่ การย้ายเข้าไปภายหลัง อาจให้ผลจำกัด
  • กรณี OpenSearch ชี้ว่า การย้ายเพียงอย่างเดียว ไม่ได้รับประกันว่าจะทำให้ผู้มีส่วนร่วมภายนอกเพิ่มขึ้นอย่างรวดเร็ว

สัญญาณเตือนและแนวทาง

• การใช้ CLA (Contributor License Agreement) เป็นสัญญาณของการรวม อำนาจในการรีไลเซนส์ ไว้กับบริษัท และทำให้ ความไม่สมดุลของอำนาจ รุนแรงขึ้น
  • โครงการที่ใช้ DCO (Developers Certificate of Origin) มีแนวโน้ม เสี่ยงต่อ rug pull ต่ำกว่า
• จำเป็นต้อง ตรวจสอบธรรมาภิบาล และ การครอบงำโดยบริษัทเดียว รวมถึง ความกระจุกตัวของผู้นำ เป็นปัจจัยเสี่ยง
  • โครงการที่มี มูลนิธิเป็นกลาง, ผู้นำจากหลายองค์กร, และ ฐานผู้มีส่วนร่วมภายนอก จะได้เปรียบในแง่ ความยั่งยืน
• ความกว้างและความลึกของ ฐานผู้มีส่วนร่วม ก็เป็นเกณฑ์ประเมินสำคัญ
  • บริษัทควร ส่งผู้มีส่วนร่วมเข้าไปมีส่วนร่วมโดยตรง ในโครงการที่ตนพึ่งพา เพื่อเสริมทั้ง อิทธิพลและความยั่งยืน
  • CHAOSS มี เมตริกและคู่มือสำหรับผู้ปฏิบัติ ที่นำไปใช้วินิจฉัยและปรับปรุง สุขภาวะของโครงการ ได้

ข้อเสนอแนะด้านชุมชนและธรรมาภิบาล

• การผลักดันไปสู่ ระบบธรรมาภิบาลที่เป็นกลาง และ การขยายผู้มีส่วนร่วมภายนอก เป็นวิธีที่มีประสิทธิภาพจริงในการยับยั้ง rug pull
  • ความเป็นไปได้ของการ fork นั้นเองทำให้ ต้นทุนของการตัดสินใจรีไลเซนส์ ของบริษัทสูงขึ้น และทำหน้าที่เป็น แรงยับยั้ง
• เมื่อตอบคำถามของ Hazel Weakly เกี่ยวกับกลไกป้องกัน ผู้บรรยายยกตัวอย่างความสำเร็จของ Valkey และ OpenTofu ว่าเป็นกรณีจริงที่กระตุ้นให้เกิด การทบทวนการรีไลเซนส์
  • Dirk Hohndel เน้นว่า การดึงผู้มีส่วนร่วมภายนอกให้มากขึ้น จะเพิ่มความเสี่ยงของ rug pull และทำให้ การตัดสินใจเชิงบริหารมีความเสี่ยงสูงขึ้น

บทสรุป

• เมื่ออิทธิพลของผู้ให้บริการคลาวด์รายใหญ่เพิ่มขึ้น ระบบนิเวศโอเพ่นซอร์สก็กำลังเปลี่ยนไปสู่ โครงสร้างแบบศักดินา มากขึ้นเรื่อย ๆ
• การเปลี่ยนไลเซนส์ช่วยถ่วงดุลอำนาจของบริษัทคลาวด์ได้ แต่ในกระบวนการนั้นก็มี ผลข้างเคียงคือทำให้อำนาจของผู้มีส่วนร่วมในชุมชนลดลง
• อย่างไรก็ตาม สำหรับผู้มีส่วนร่วมและผู้ใช้ยังมี 'fork' เป็น เครื่องมือโต้กลับ ซึ่งเป็นพลังเฉพาะของโอเพ่นซอร์สที่ต่างจากยุคศักดินา
• ความเป็นไปได้จริงของการ fork มีอิทธิพลต่อการตัดสินใจเชิงนโยบายของบริษัทในอนาคต และในความเป็นจริงก็มีบางบริษัท ยกเลิกแผน rug pull หลังได้รับแรงกระตุ้นจากความสำเร็จของ Valkey และ OpenTofu
• ท้ายที่สุด ความเป็นกลางของธรรมาภิบาลโครงการ และ การทำให้ผู้มีส่วนร่วมภายนอกมีบทบาทคึกคัก คือกุญแจสำคัญต่อการป้องกัน rug pull และการรักษาระบบนิเวศที่แข็งแรง

เอกสารอ้างอิง

• สไลด์การบรรยาย: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

ดูเหมือนว่าตอนนี้การ fork ยังไม่ใช่เรื่องง่ายนัก เลยอยากให้มีองค์กรที่เกี่ยวข้องกับโอเพนซอร์สคอยช่วยเรื่องนี้บ้างครับ

[GN⁺]

ความเห็นจาก Hacker News

• มองว่าโปรเจ็กต์ที่ใช้ CLA (Contributor License Agreement) มักเกิดการ rug pull (ปรากฏการณ์ที่ความพยายามของผู้มีส่วนร่วมถูกทำให้กลายเป็นทรัพย์สินส่วนตัวของคนส่วนน้อย) ได้บ่อยกว่า ขณะที่โปรเจ็กต์ที่ใช้ DCO (Developers Certificate of Origin) จะมีความไม่สมดุลแบบนี้น้อยกว่า การเซ็น CLA เท่ากับมอบสิทธิในการเปลี่ยนไลเซนส์โค้ดที่เรามีส่วนร่วมให้กับโปรเจ็กต์ กล่าวคือ ต่อให้เรามีส่วนร่วมกับโปรเจ็กต์ GPL ด้วยโค้ดภายใต้ GPL ก็ยังสามารถเปลี่ยนไลเซนส์ได้ หากเป็นไลเซนส์แบบ permissive อยู่แล้ว CLA ก็แทบไม่มีผลมากนัก แต่ถ้าเป็น copyleft (เช่น GPL) ก็จะไม่เป็นธรรม เพราะมีเพียงฝ่ายที่ให้เซ็น CLA เท่านั้นที่ถือครองแบบผูกขาดได้ หากอยากป้องกัน rug pull ก็ควรใช้ไลเซนส์แบบ copyleft และหลีกเลี่ยงการเซ็น CLA ส่วนไลเซนส์แบบ permissive ต้องเข้าใจว่า rug pull เป็น "ส่วนหนึ่งของเกม"
  • โปรเจ็กต์ GNU ก็เรียกให้เซ็น CLA เหมือนกัน แต่คิดว่าพวกเขาไม่น่าทำเช่นนั้นด้วยเจตนาจะ rug pull
  • อยากย้ำว่าการเซ็น CLA ไม่ได้แปลว่าจะมอบสิทธิการเปลี่ยนไลเซนส์ทั้งหมดเสมอไป เพราะแต่ละ CLA ต่างกัน ตัวอย่างเช่นเงื่อนไขใน CLA ของ Canonical(ลิงก์) ระบุว่าจะนำ contribution ของฉันไปให้บริการภายใต้ไลเซนส์เดิมด้วย การอ่านและทำความเข้าใจ CLA จึงสำคัญมาก CLA ส่วนใหญ่ยังคงให้ลิขสิทธิ์อยู่กับผู้มีส่วนร่วม ดังนั้นเรายังมีสิทธิทำอะไรก็ได้กับ contribution ของตัวเอง ปัญหาพื้นฐานคือความเชื่อมั่นต่อเจ้าของโปรเจ็กต์อาจพังทลายได้ CLA มอบอำนาจควบคุมให้เจ้าของ จึงเพิ่มความเสี่ยงของ rug pull การรับมือกับ rug pull ในทางปฏิบัติคือต้อง fork แล้วร่วมมือกันพัฒนาต่อเองจึงจะได้ประโยชน์ หากเป็นไลเซนส์ copyleft ที่บวก CLA เข้าไปอีก (เช่น AGPL + CLA) อาจยิ่งอันตรายกว่า permissive license + CLA เสียอีก เพราะ AGPL บังคับให้บริการที่นำไป deploy ต้องเปิดซอร์สด้วย แต่เมื่อมี CLA เจ้าของกลับสามารถทำบริการแบบปิดและไม่ต้องเผยแพร่การปรับปรุงได้จริง กรณี Incus และ LXD ก็เป็นตัวอย่างว่าการผสมไลเซนส์กับ CLA ทำให้ชุมชนแตกแยกและจำกัดการแชร์โค้ดได้(บทความกรณีศึกษาแบบละเอียด)
  • มองว่าปรากฏการณ์แบบ rug pull ไม่มีอยู่จริงในโอเพนซอร์ส สำเนา GPL จะคงอยู่ตลอดไป
  • หากใช้ไลเซนส์แบบ permissive ก็มีโอกาสเกิด rug pull สูงขึ้นจริง แต่ก็ต้องชี้ว่า CLA ไม่ได้มอบสิทธิทุกอย่างเสมอไป
  • คิดว่าวาทกรรมเชิงลบอย่าง "rug pull" ถูกมองแบบบริสุทธิ์นิยมเกินไปในโลกโอเพนซอร์ส ซึ่งไม่ดีต่อสุขภาพของวงการ โปรเจ็กต์ต้องอยู่รอดได้ ในสถานการณ์ที่ผู้ให้บริการคลาวด์รายใหญ่ผูกขาดโครงสร้างพื้นฐานอยู่ การที่นักพัฒนารายเล็กไปเสียพลังกับข้อพิพาทในโปรเจ็กต์โอเพนซอร์สหรือโปรเจ็กต์ที่ใช้ CLA อาจสู้เอาพลังไปลดการผูกขาดของบริษัทยักษ์ใหญ่จะดีกว่า
• ผู้มีส่วนร่วมและเมนเทนเนอร์มักมีอำนาจน้อยกว่าธุรกิจขนาดเล็กเสียอีก ถึงอย่างนั้น ถ้าเป็นไลเซนส์แบบ liberal แล้วไม่พอใจ ก็ยัง fork แล้วเดินเส้นทางใหม่ได้ กรณี Valkey ทำให้เห็นพลวัตด้านไลเซนส์ที่น่าสนใจเมื่อเทียบกับ Redis ความรู้สึกคือช่วงนี้ชุมชนนักพัฒนาโดยรวมพึ่งบริการคลาวด์มากเกินไป จนขาดความกระตือรือร้นแบบในอดีตที่จะ fork หรือเขียน OS, compiler, DB ใหม่ขึ้นมาเอง อีกเรื่องที่มักถูกมองข้ามคือบริษัทคลาวด์อย่าง AWS ก็ช่วยเพิ่มการรับรู้ให้โปรเจ็กต์ผ่านการนำไปให้บริการด้วยเช่นกัน (เช่น ElasticSearch ได้รับความนิยมหลัง AWS นำไปให้บริการ) คลาวด์ยังมีส่วนร่วมกับ kernel, gcc, jdk จนธุรกิจขนาดเล็กได้ประโยชน์ทางอ้อมด้วย จึงไม่ควรโทษคลาวด์รายใหญ่อย่างเดียว แต่อาจต้องกลับมาคิดเรื่องโมเดลธุรกิจใหม่ เพราะถ้าเริ่มต้นแบบปิดตั้งแต่แรกก็คงไม่มีใครสนใจ
• ถ้าไม่รับซอฟต์แวร์ที่ใช้งานในรูปไบนารี แต่รับซอร์สโค้ดมาสร้างเอง จะรับมือเหตุการณ์อย่าง rug pull ได้ดีกว่า ผู้ใช้ที่ติดตั้งผ่านไบนารีหรืออิมเมจจากเวนเดอร์จะย้ายไปใช้ fork ได้ยาก แต่การเปลี่ยน build infrastructure ไปใช้ซอร์สใหม่กลับทำได้ค่อนข้างง่าย และยังใส่แพตช์หรือฟีเจอร์ที่ต้องการได้เอง จึงลดการพึ่งพาการบำรุงรักษาจากภายนอก
  • นี่คือเหตุผลที่ชอบ Guix โครงสร้างของมันเป็นแบบนี้เลย โดยพื้นฐานคือ build จากซอร์ส แต่ก็มีแพ็กเกจไบนารีผ่านระบบแคชด้วย หากไม่มีไบนารีก็จะ build จากซอร์สเองแบบ reproducible แม้แต่แพตช์เวอร์ชันก็ยังติดตั้งง่ายด้วย package manager ตัวเดิม จึงไม่ต้องมี build infrastructure แยกต่างหาก ถ้าเป็นสภาพแวดล้อมที่ deploy ขนาดใหญ่ การมี build server ก็จะมีประสิทธิภาพกว่า
  • ไม่รู้ว่าทำไมมีคนกดลบ แต่เห็นด้วย การ build จากซอร์สโดยทั่วไปไม่ได้ยากนัก (ดู sqlite เป็นตัวอย่าง)
  • ในความเป็นจริง ข้อจำกัดจะแตกต่างกันไปตามไลเซนส์ซอฟต์แวร์ ซอฟต์แวร์เชิงพาณิชย์บางตัวแม้จะให้ซอร์ส แต่ตามไลเซนส์ก็ไม่ได้เปิดให้ดัดแปลงได้อย่างอิสระ เช่น ผลิตภัณฑ์เชิงพาณิชย์ที่อิงภาษาสคริปต์ หรือกรณีที่บริษัทที่ปรึกษาส่งมอบซอร์สให้ลูกค้า แต่สิทธิในการคอมไพล์ต้องจ่ายเพิ่มแยกต่างหาก
• หลัง ElasticSearch rug pull แล้ว Amazon ก็หันมามีส่วนร่วมกับ fork โอเพนซอร์สโดยตรงอย่าง OpenSearch ซึ่งถึงจะไม่ใช่ผลลัพธ์ตามเจตนาเดิมทั้งหมด แต่ก็อาจถือว่าได้ผลอยู่บ้าง อย่างไรก็ดี ประเด็นที่บริษัทยักษ์ใหญ่สร้างความไม่สมดุลระหว่างผู้มีส่วนร่วมกับผู้รับผลประโยชน์ จนทำให้โปรเจ็กต์ไม่มั่นคง ก็ยังเป็นเรื่องสำคัญที่ต้องถกกัน
  • การใช้ซอฟต์แวร์ภายใต้การปฏิบัติตามไลเซนส์ไม่ใช่ปัญหา แถมในทางกลับกัน ถ้านักพัฒนาหรือสตาร์ตอัปใช้ไลเซนส์แบบ permissive เพราะหวังแต่การกระจายตัวและการเติบโต แล้วค่อยมาเห็นเป็นปัญหาเมื่อคลาวด์รายใหญ่เข้ามา แบบนั้นก็ขัดแย้งในตัวเอง มองว่าไม่สามารถเอาทั้งสองอย่างพร้อมกันได้
  • ผลลัพธ์ที่ Elastic ต้องการคือรายได้จากไลเซนส์ที่มากขึ้น แต่ผู้ใช้จำนวนมากกลับย้ายไป fork จนความน่าเชื่อถือของ Elastic ลดลง การแข่งขันระหว่าง OpenSearch กับ ElasticSearch อาจส่งผลบวกต่อ ecosystem ก็จริง แต่ตอนนี้ทั้งสองผลิตภัณฑ์ไม่เข้ากันแล้ว และฐานะของ Elastic ก็อ่อนลง
  • ไลเซนส์แบบ copyleft อย่าง AGPL/GPL บังคับให้ต้องคืนโค้ดกลับมา จึงสร้าง feedback loop ได้โดยไม่ต้องพึ่งไลเซนส์แบบผูกขาด
• โปรเจ็กต์โอเพนซอร์สไม่ได้ rug pull ได้ง่ายเพียงเพราะเปลี่ยนไลเซนส์ ปัญหาที่ลึกกว่านั้นคือความจริงที่ว่าเราไม่ได้อยู่ในสภาพยูโทเปียที่ทุกคนทำงานฟรีแล้วยังมีคุณภาพชีวิตที่ดีได้ หากไม่มีเมนเทนเนอร์ อายุครึ่งชีวิตของโปรเจ็กต์ก็สั้นลงเป็นธรรมดา และหากไม่มีสปอนเซอร์ การย้ายไปใช้ไลเซนส์ที่ปิดมากขึ้นก็จะเร่งตัวขึ้น
  • ทำให้นึกถึงกรณี Mojang/Microsoft กับชุมชน Bukkit ตอนรับนักพัฒนาเข้าทำงาน พวกเขาแอบซื้อโปรเจ็กต์ไว้ และปล่อยให้อาสาสมัครทำงานฟรีอยู่หลายปี สุดท้ายเจ้าตัวใช้ DMCA ปิดโปรเจ็กต์ลง รายละเอียดเพิ่มเติม: blog
  • สุดท้ายแล้วมันคือปัญหาเรื่องแรงจูงใจ ต่อให้สร้างซอฟต์แวร์โอเพนซอร์สขึ้นมาเอง ผู้ให้บริการคลาวด์ก็ยังหยิบไปทำเงินได้ง่าย แม้จะเข้าใจว่าโครงสร้างไลเซนส์ FOSS(Fully Open Source Software) หมายถึงแบบนั้นอยู่แล้ว แต่ก็รู้สึกว่าสังคมชินกับแรงงานฟรีมากเกินไป จึงคิดว่าวิธีใหม่อย่าง SSPL(Source-available licensing) จะยิ่งดูน่าสนใจขึ้นเรื่อย ๆ ความต่างแค่ข้อกำหนดเดียวทำให้ AGPL เป็น foss แต่ SSPL ไม่เป็น foss นั้น รู้สึกว่าเป็นความสับสนทางคำศัพท์
• เข้าใจความรู้สึกของผู้ใช้ที่เสียใจกับ rug pull แต่ในโลกจริง บริษัทที่เป็นผู้นำพัฒนาและดูแลโปรเจ็กต์เองก็มีข้อจำกัดทางการเงิน จนเหลือทางเลือกไม่กี่ทาง หากไม่มีโมเดลรายได้ การเปลี่ยนไลเซนส์ก็อาจเลี่ยงไม่ได้ ทางเลือกที่กำลังคิดกันมีทั้ง crowdfunding, ลดปริมาณงาน, ขายสินค้า, หรือถ้าไม่มีเงินทุนเพิ่มก็ประกาศล่วงหน้าว่าจะเปลี่ยนให้เปิด บทความที่เกี่ยวข้อง
  • แก่นของความไม่พอใจคือการเคยเปิดเป็น OSS เพื่อเพิ่มจำนวนผู้ใช้ แล้วอยู่ ๆ ก็เปลี่ยนไปเป็นไลเซนส์ปิดมากขึ้น ถ้าไม่ได้เป็น OSS มาตั้งแต่แรกก็คงไม่รู้สึกถูกหักหลัง แต่การเริ่มแบบ OSS เพื่อดึงผู้ใช้ แล้วค่อยเปลี่ยนทีหลังต่างหากที่เป็นปัญหา
  • Mongo, Elastic, Redis, Hashicorp ต่างก็ไม่ได้อยู่ในภาวะการเงินย่ำแย่หนักในช่วงที่ rug pull ด้วยซ้ำ สำหรับ Hashicorp อาจเป็นกลยุทธ์เพื่อเพิ่มมูลค่าก่อนการเข้าซื้อกิจการก็ได้
• ช่วงหลังมานี้มีกรณีเพิ่มขึ้นที่ใช้บอร์ดกำกับดูแลหรือแนวทางปฏิบัติที่เข้มงวดขึ้นเป็นข้ออ้าง เพื่อชักจูงให้คนสายเทคนิคถอนตัวไปเอง จากนั้นก็กดเสียงคัดค้านและเพิกถอนสิทธิในโปรเจ็กต์ บรรยากาศแบบออร์เวลเลียนที่อ้างเรื่อง "ความปลอดภัย" กำลังถูกนำเข้ามาในชุมชนจริง ๆ
• ผู้ใช้โอเพนซอร์สแทบทั้งหมดคือ free rider เราใช้งานโปรเจ็กต์ต่าง ๆ อย่างเสรีโดยไม่ได้มีส่วนร่วมอะไรเลย โอเพนซอร์สอาจมองได้ว่าเป็นของขวัญที่ไม่หวังสิ่งตอบแทน หรือเป็นวัฒนธรรมการดูการบ้านคนอื่น หากอยากสร้างประโยชน์ให้โลกก็ทำได้ด้วยความเต็มใจ แต่ไม่ควรคาดหวังผลตอบแทนอะไรเลย การเรียกการเปลี่ยนไลเซนส์ว่า rug pull ก็เป็นมุมมองที่เอนเอียงเช่นกัน อย่างไรเสีย เราก็ได้รับโค้ดมาแล้ว แม้การเปลี่ยนทิศทางจะน่าเสียดาย แต่ไม่มีสิ่งใดคงอยู่ตลอดไป
  • ข้อความที่ว่า "พวกเราส่วนใหญ่ก็แค่ใช้โดยไม่ตอบแทนอะไรกลับไป" ไม่ได้จริงทั้งหมด หลายโปรเจ็กต์มีการมีส่วนร่วมในหลากหลายด้าน ทั้งโค้ด การทดสอบ เอกสาร การตลาด และการเผยแพร่ โปรเจ็กต์เหล่านี้ไม่ใช่งานพัฒนาเงียบ ๆ ที่บังเอิญถูกอัปขึ้น GitHub แต่เป็นสิ่งที่บริษัทลงทุนเงินจำนวนมาก จ้าง developer evangelist มาช่วยบอกต่อข้อดีทางเทคนิคและด้านไลเซนส์เพื่อขยายฐานผู้ใช้มาโดยตลอด ในสภาพแวดล้อมแบบนั้น การรับโค้ดและ contribution จำนวนมากไว้ก่อน แล้วจู่ ๆ เปลี่ยนไลเซนส์ ขณะที่โปรเจ็กต์ FOSS อื่นยังพึ่งพาอยู่ นั่นแหละคือเหตุผลที่ถูกวิจารณ์ว่าเป็น rug pull ถ้าเป็นโปรเจ็กต์ที่ถูกอัปขึ้น GitHub แบบไม่มีการตลาดและคนค่อย ๆ หยิบไปใช้เอง ก็คงไม่กลายเป็นประเด็น rug pull แต่แทบไม่ค่อยเห็นกรณีแบบนั้น
  • ไม่จำเป็นต้องเป็นโครงสร้างแบบนั้นเสมอไป องค์กรหรือผู้มีทุนสามารถเพิ่มความยั่งยืนให้โปรเจ็กต์โอเพนซอร์สที่ตัวเองพึ่งพาได้ผ่านการสนับสนุนทั้งด้านการเงินและเทคนิค เช่น ตั้ง Open Source Program Office, ตรวจสอบซอฟต์แวร์และ dependency ทั้งหมดที่ใช้อยู่, ลงเวลาและงบประมาณเพื่อ contribution และการสนับสนุนผู้พัฒนา รวมถึงผลักดันให้คนในอุตสาหกรรมเดียวกันทำแบบนี้มากขึ้น
• ในบริษัทที่ทำงานอยู่ตอนนี้ ฝ่ายบริหารก็สับสนเพราะประเด็น rug pull เช่นกัน เราเคยยืนยันมาตลอดว่าจะต้องมีสัญญาซัพพอร์ตสำหรับระบบ แต่สุดท้ายก็เจอสถานการณ์คล้ายกันซ้ำ ๆ กับ Chef, CentOS, VMWare, Broadcom ทั้งที่ตั้งใจจะจ่ายเงินใช้งานอยู่แล้ว ค่าบริการบำรุงรักษาพื้นฐานกลับสูงถึงหลักหลายพันถึงหลายหมื่นดอลลาร์ต่อปี และถึงอย่างนั้นก็ยังไม่ไว้ใจ ในสถานการณ์แบบนี้จึงรู้สึกว่าบางทีการสนับสนุนมูลนิธิ หรือจ้าง OSS maintainer โดยตรงเป็นประจำ อาจดีกว่า เมื่อก่อนเคยมองข้อเสนอแบบนี้ในแง่ลบ แต่ตอนนี้ยิ่งมีคนเห็นด้วยมากขึ้น ส่วนตัวแล้วแทนที่จะจ่ายเงินให้ VMWare ฉันคงเลือกจ้างนักพัฒนา Proxmox หรือ qemu มากกว่า
  • คิดว่าเป็นแนวคิดที่ถูกต้อง สิ่งสำคัญคือต้องตรวจสอบซอฟต์แวร์และ dependency ทั้งหมดที่ใช้อยู่ และช่วยรับประกันความยั่งยืนผ่านการลงแรงพัฒนาและเงินสนับสนุน พร้อมทั้งผลักดันทัศนคติแบบนี้ให้แพร่หลายในวงการเดียวกัน
  • น่าสนใจที่บริษัทที่ถูกยกตัวอย่างต่างก็เคยตั้ง open source program office เพื่อทำงานแบบเน้นชุมชนมากขึ้น แต่เมื่อองค์กรใหญ่ขึ้นมาก ๆ ก็เหมือนความย้อนแย้งระหว่างชุมชนกับผลประโยชน์ของบริษัทจะกลายเป็นราคาที่ต้องจ่ายอย่างหลีกเลี่ยงไม่ได้
• การ fork ไม่ใช่เรื่องง่าย ต้องมีคนและทรัพยากรจึงจะสำเร็จ โอเพนซอร์สเป็นโครงสร้างที่ทำงานได้ก็ต่อเมื่อมีผู้มีส่วนร่วมจำนวนมากเท่านั้น ถ้า fork ตายไป ก็แปลว่าโปรเจ็กต์นั้นมี free rider มากเกินไป ปัญหาใหญ่ที่สุดของ rug pull จริง ๆ คือมันแทบจะเป็นการโฆษณาชวนเชื่อเท็จ คือใช้โอเพนซอร์สดึงลูกค้ามาก่อน แล้วเมื่อเริ่มเสียเปรียบก็ฉีกคำมั่นสัญญานั้นทิ้ง จึงมีปัญหาในเชิงศีลธรรม อย่างไรก็ตาม การหยุดมีส่วนร่วมเองนั้นไม่น่ากังวล เพราะไม่มีใครมีหน้าที่ต้องอยู่กับโปรเจ็กต์ตลอดไป การที่บุคคลหรือบริษัทจะหยุดก็เป็นเรื่องธรรมดา