ทีมคอร์ของ Ruby รับโอนความเป็นเจ้าของ RubyGems และ Bundler

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

---

ความสำคัญของ RubyGems และ Bundler

• RubyGems คือเครื่องมือจัดการแพ็กเกจหลักของอีโคซิสเต็ม Ruby และ Bundler คือองค์ประกอบสำคัญที่รับผิดชอบด้านการจัดการ dependency และการเผยแพร่
• ทั้งสองโปรเจกต์เป็น เครื่องมือมาตรฐานที่รวมอยู่ในดิสทริบิวชันของ Ruby และถูกผสานเข้ากับภาษา Ruby อย่างใกล้ชิด
• อย่างไรก็ตาม ตลอดมานั้น RubyGems และ Bundler ถูกดูแลอย่างอิสระโดย Ruby Central ซึ่งไม่ใช่องค์กรของ Ruby โดยตรง
  แม้จะเป็น องค์ประกอบมาตรฐานของภาษา Ruby แต่กลับดำเนินการอยู่ในองค์กรแยกต่างหากบน GitHub ทำให้ขาดความสอดคล้องเชิงโครงสร้าง
• ด้วยเหตุนี้ ทีมคอร์ของ Ruby จึงตัดสินใจอย่างเป็นทางการที่จะ รับช่วงสิทธิ์ในการจัดการและบำรุงรักษารีโพซิทอรี
• เป้าหมายคือการสร้าง เสถียรภาพระยะยาวของโครงการและความสอดคล้อง (alignment) กับอีโคซิสเต็ม Ruby

การเปลี่ยนแปลงหลัก

• ความเป็นเจ้าของรีโพซิทอรีอย่างเป็นทางการถูก โอนไปยังทีมคอร์ของ Ruby และเปลี่ยนเป็น ระบบบริหารร่วมกับ Ruby Central
• เงื่อนไขไลเซนส์โอเพนซอร์สเดิมไม่เปลี่ยนแปลง และไม่มีการเปลี่ยนแปลงด้านโครงสร้างเชิงพาณิชย์หรือกฎหมาย
• ทรัพย์สินทางปัญญาและลิขสิทธิ์ ของผู้ร่วมพัฒนาทั้งหมดจะ ยังคงเดิม โดยไม่มีการเปลี่ยนแปลงความเป็นเจ้าของโค้ด
• จะยังคงใช้ โมเดลการพัฒนาที่ขับเคลื่อนโดยชุมชน และทุกคนยังสามารถมีส่วนร่วมได้

ความร่วมมือของชุมชนและแผนในอนาคต

• ทีมคอร์ของ Ruby มีแผนจะรักษา กรอบความร่วมมืออย่างต่อเนื่อง กับ Ruby Central และนักพัฒนาทั่วโลก
• มาตรการครั้งนี้ถูกประเมินว่าเป็นการวางรากฐานระยะยาวเพื่อ ยกระดับเสถียรภาพและความน่าเชื่อถือของอีโคซิสเต็ม Ruby
• ในแถลงการณ์ Matz ได้แสดงความขอบคุณต่อความทุ่มเทของ Ruby Central และกล่าวว่า “มาสร้างอนาคตที่สดใสกว่าของ Ruby ไปด้วยกัน”

นัยสำคัญ

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

[GN⁺]

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

• คิดว่านี่เป็นทิศทางที่ถูกต้อง รู้สึกขอบคุณที่ Ruby Core และ Matz ออกมาช่วยสร้างเสถียรภาพให้ทั้งภาษาและชุมชน
  • อยากเน้นว่า Matz คือแกนกลางที่แท้จริง คิดว่าคำกล่าวเก่าอย่าง “Matz is nice and so we are nice” ควรถูกเปลี่ยนเป็น “ใจดีและมีความรับผิดชอบ”
• หากมองระยะยาว โครงสร้างที่มีหลายแหล่งอย่าง gem.coop น่าจะปลอดภัยและแข็งแรงกว่า แต่ใน RubyGems ความไว้วางใจได้พังลงอย่างสิ้นเชิงผ่านหลายชั้น ทั้งผู้ดูแล สมาชิกชุมชน ผู้สนับสนุน ฯลฯ และยังมีโจทย์ที่ต้องแก้อีก เช่น การระดมทุนหรือความเป็นส่วนตัวของข้อมูล อย่างไรก็ตาม ดูเหมือนว่าคนส่วนใหญ่ในชุมชน Ruby จะสนับสนุนการเปลี่ยนแปลงครั้งนี้
  • ช่วยสรุปหน่อยว่าเกิดอะไรขึ้นจริง ๆ บ้าง ช่วงนี้ไม่ได้ตามข่าว Ruby ล่าสุดเลยเลยสงสัย
  • เห็นด้วย คิดว่าตอนนี้ต้องรอดูต่ออีกหน่อยว่า gem.coop จะรวมพลังได้มากแค่ไหน พวกเขาให้คำมั่นเกี่ยวกับอนาคตไว้ และคาดว่าสุดท้ายก็น่าจะทำผลงานได้ เมื่อเปิดเบต้าแล้วก็มีความตั้งใจจะอัปโหลด gem ที่เคยลงไว้บางส่วนอีกครั้ง อย่างน้อยก็พวกตัวหลัก ยังมีหลายอย่างที่ต้องปรับปรุง โดยเฉพาะเรื่องเอกสารประกอบ ซึ่งเกี่ยวพันกับ ruby documentation ด้วยและการแยกกันอยู่ก็เป็นปัญหา อีกเรื่องคือการขาด namespacing ก็เป็นปัญหาเช่นกัน ใน Ruby ไม่มี namespacing อย่างเป็นทางการ ซึ่งเป็นทั้งคุณสมบัติและปัญหา และคิดว่าควรมีวิธีแยกตามความสนใจหรือขอบเขตงาน ประเมินอีกครั้งในอีกราวครึ่งปี ช่วงปลายเดือนพฤษภาคม 2026 น่าจะสมจริงกว่า ถ้า DHH ยังเขียนบล็อกวิจารณ์แรง ๆ ต่อไป คนที่ไม่พอใจกับ gem.coop อาจไหลเข้ามาใหม่และทำให้มีผู้ร่วมพัฒนามากขึ้นจนเกิดประโยชน์มากขึ้นได้ สำหรับผู้ใช้ก็น่าจะเป็นสถานการณ์แบบ win-win ที่มีอิสระและความยืดหยุ่นมากขึ้น คนจำนวนมากอาจยังอยู่กับ rubygems.org แต่ก็น่าจะมีอีกหลายคนที่ชอบ gem.coop มากกว่า และบางคนก็คงใช้ทั้งคู่ ซึ่งเรื่องนี้ค่อนข้างซับซ้อน เลยคิดว่า gem.coop ก็ควรมีฟีเจอร์กำหนดแหล่งที่มาราย gem ด้วย ยังมีงานอีกมาก
  • น่าเหลือเชื่อที่ผู้ดูแลที่เลิกบำรุงรักษาไปแล้ว ยังมีสิทธิ์ระดับ root อยู่ รู้สึกแปลกใจที่ยังเหลืออำนาจในระดับใดระดับหนึ่งไว้บนแพลตฟอร์มสำคัญแบบนี้ ช็อกที่ช่วงหลังสมาชิกในชุมชน Ruby บางคนกลับต่อต้านมาตรฐานความปลอดภัยสมัยใหม่ที่ใช้กันแพร่หลายอยู่แล้ว ทั้งที่นี่เป็นแพลตฟอร์มสำคัญของเว็บ ตอนนี้ไม่ใช่ปี 2006 แล้ว และไม่ใช่ยุคที่ติดตั้ง rails ด้วยคำสั่ง curl อย่างเดียว ความไร้เดียงสาของแรงต้านแบบนี้น่ากลัวมาก ช็อกที่ปล่อยให้ท่าทีด้านความปลอดภัยที่ไม่ได้รับการดูแลเปิดช่องให้โดน supply chain attack ตรง ๆ อย่างน้อยก็ดีที่ตอนนี้มีคนสักคนเริ่มใส่ใจกับความปลอดภัยที่เหมาะกับยุคปัจจุบันแล้ว
  • สำหรับข้ออ้างที่ว่ามีหลายแหล่งแล้วจะปลอดภัยกว่า คิดว่ามันอาจทำให้พื้นผิวการโจมตีเพิ่มขึ้นสามเท่าและมีช่องโหว่มากขึ้น
  • มันเป็นแค่การเปลี่ยนแปลงเครื่องมือของ Ruby เท่านั้น ส่วน rubygems.org เองก็ยังอยู่ภายใต้การครอบครองขององค์กรที่เป็นปฏิปักษ์อยู่ดีแล้วแต่จะมอง ดังนั้นจึงสงสัยว่าสิ่งนี้จะช่วยฟื้นความเชื่อมั่นได้มากแค่ไหน
• ดูจุดยืนของ Ruby Central ได้ที่นี่ https://rubycentral.org/news/ruby-central-statement-on-rubygems-bundler/
  • อนึ่ง ถ้าได้ดูแถลงการณ์ก่อนหน้านี้เมื่อวันที่ 19 กันยายนด้วยก็น่าจะดี ซึ่งมีข้อความว่า “สะท้อนถึงความมุ่งมั่นร่วมกันต่อเสถียรภาพและการเติบโตระยะยาวของ ecosystem ของ Ruby” https://rubycentral.org/news/strengthening-the-stewardship-of-rubygems-and-bundler/
• รู้สึกขอบคุณอย่างมากที่ Matz แสดงภาวะผู้นำด้วยตัวเองในสถานการณ์ยากลำบาก ในฐานะนักพัฒนาชาวญี่ปุ่น ก่อนหน้านี้กังวลมากว่าช่วงเหตุการณ์ล่าสุดจะลงเอยอย่างไร แต่ประกาศครั้งนี้ทำให้สบายใจขึ้น
  • อยากรู้ว่าเขาแสดงภาวะผู้นำอย่างไร เพราะก็ชัดเจนอยู่แล้วว่าไม่ใช่ว่า Hiroshi Shibata จะตัดสินใจลำพังมาตลอด จึงสงสัยว่าการตัดสินใจมารับผิดชอบ gem และ bundler ครั้งนี้อาจถูกตัดสินใจกันภายในมาตั้งแต่หลายเดือนก่อนแล้วก็ได้ ส่วนความเห็นที่ว่ารู้สึกสบายใจในฐานะนักพัฒนาชาวญี่ปุ่นนั้น กลับทำให้กังวลยิ่งกว่าเดิม ฉันอาศัยอยู่นอกสหรัฐและญี่ปุ่น เลยรู้สึกอึดอัดและไม่พอใจที่สหรัฐกับญี่ปุ่นดูจะครอบงำ ecosystem ของ Ruby มากเกินไป ฝั่งญี่ปุ่นยังพอเข้าใจได้ว่าเป็นชุมชนท้องถิ่น แต่ที่อิทธิพลของสหรัฐมีมากถึงขนาดนี้ก็รู้สึกว่าเกินไปหน่อย Python ก็คล้ายกัน เลยรู้สึกเสียดายในจุดนี้
• คิดว่าใครก็ตามที่เคยแตะ ruby มาบ้าง น่าจะมองว่าบทสรุปครั้งนี้เป็นผลลัพธ์ที่ไม่มีใครไม่พอใจ
  • คิดว่าฝ่ายที่ได้ประโยชน์มีแค่ Ruby Central เพราะไม่ได้ยอมอะไรเลย แถมยังได้รับการรับรองอย่างเป็นทางการจาก Ruby Core ให้เป็นผู้ดูแล Rubygems ด้วย แม้ ownership ของ repository จะถูกโอนย้าย แต่ Ruby Central ยังคงรับผิดชอบด้านการดำเนินงานและ governance โดยทำงานใกล้ชิดกับ Ruby Core ขณะเดียวกัน Andre ถือสิทธิ์เครื่องหมายการค้า Bundler และเคยระบุว่าจะใช้สิทธิ์นั้นกับ Ruby Central https://andre.arko.net/2025/09/25/bundler-belongs-to-the-ruby-community/, Ruby Central โอน ownership ของ Bundler ให้ Ruby Core แต่ยังคงดูแลต่อ ขณะที่ Ruby Core กลับต้องรับความเสี่ยงทางกฎหมายแทน ถ้า Andre ฟ้องร้อง ก็จะกลายเป็นการปะทะกับ Ruby Core ฝั่งญี่ปุ่นและภาพลักษณ์จะยิ่งแย่ลง
  • คนยังไม่มีใครบ่น เพราะ Matz ยังไม่ได้ออกความเห็นในประเด็นสังคมอย่างกฎหมายคนเข้าเมือง
  • อยากถามกลับว่าหมายถึงไม่มีใครไม่พอใจจริง ๆ หรือ
  • สงสัยว่าทำไมถึงดูเหมือนไม่มีใครไม่พอใจ ทั้งที่ยังมีคำถามอีกมาก และสุดท้ายจุดชี้ขาดก็น่าจะเป็นว่า gem.coop จะได้รับความนิยมแค่ไหน จะโตขึ้นจริงหรือไม่ การสร้างวิธีติดตั้งโปรเจกต์ Ruby แบบใหม่ไปเลยอาจจะดีกว่าก็ได้ เช่นกรณี Rust+cargo แต่ส่วนตัวคิดว่าควรแยกเรื่องผู้ให้บริการออกจากการถกเถียงด้านการพัฒนาจริง ๆ ความจริงที่ว่ามีทั้งไฟล์ไบนารี gem และ bundle อยู่พร้อมกันนั้นไม่ค่อยดี คิดว่า API ควรถูกรวมเป็นหนึ่งเดียว หรือไม่ก็ให้ ruby core ดูแล API ง่าย ๆ เพียงตัวเดียว แล้วฟีเจอร์เพิ่มเติมค่อยให้แต่ละฝ่ายพัฒนากันเอง สุดท้ายหลายโปรเจกต์ก็เสี่ยงจะลงเอยเหมือน การ์ตูน xkcd ความเรียบง่ายของ bin/gem นั้นดีอยู่แล้ว และ Bundler ก็แค่เพิ่มความสะดวกบางอย่างให้ ถ้าคำสั่ง gem ระบุหลายแหล่งได้ง่ายขึ้นก็น่าจะดี รวมถึง gem.coop ด้วย
• เห็นด้วยว่า Ruby Core เป็นตัวเลือกที่ดีกว่า Ruby Central แต่ก็ยังสงสัยอยู่ว่าเรื่องนี้จริง ๆ แล้วคืออะไรกันแน่ และภาพลักษณ์ของ ecosystem ของ ruby โดยรวมก็ดูพร่ามัวลงเล็กน้อย
  • ปกติพัฒนาด้วยหลายภาษา โดยเฉพาะ go และรู้สึกว่าความเป็นแบบกระจายศูนย์ของ ecosystem แพ็กเกจของ go เป็นข้อดีมาก แม้จะมีข้อเสียอยู่บ้างก็ตาม ทั้งที่วิกฤต supply chain ของ NPM และ ecosystem แพ็กเกจสาธารณะยังเกิดซ้ำแล้วซ้ำเล่า ก็ยังแปลกใจว่าทำไมถึงไม่มีการกระจายศูนย์หรือการทดลองที่ขับเคลื่อนโดยชุมชนมากกว่านี้
• รอการตัดสินใจนี้อยู่ เพราะคิดว่าเป็นทางเลือกที่เรียบง่ายที่สุดและน่าจะช่วยกู้คืนความเชื่อมั่นได้ และยังเชื่อว่าเหล่าผู้นำที่มีเจตนาดีสามารถกอบกู้ชุมชนได้
• ช่วงหลังติดตามอย่างสนุกเหมือนดูดราม่า รู้สึกเสียใจกับคนที่ได้รับผลกระทบในชุมชน ruby และสุดท้ายก็ยังคิดว่า Matz เจ๋งที่สุด
  • สงสัยว่าจุดเริ่มต้นของเรื่องทั้งหมดนี้เกิดจากความไม่ชอบ DHH หรือเปล่า รู้สึกว่าอาจลอง fork ออกไปใช้เองเพื่อใส่การปรับปรุงด้านความปลอดภัยและ governance ที่จำเป็นบน rubygems.org ได้ไม่ใช่หรือ ในกรณีแบบนี้จากมุมมองโอเพนซอร์ส การแก้ความขัดแย้งด้วยการ fork ไม่ใช่วิธีมาตรฐานหรอกหรือ
• การกระทำและท่าทีในการประกาศของ Matz น่าประทับใจและน่าเคารพจริง ๆ เตือนให้เห็นว่านี่แหละคือความยิ่งใหญ่
  • ไม่พอใจที่ดูเหมือนจะดูแลแต่ Ruby Central ซึ่งเป็นฝ่ายที่แข็งกร้าว ขณะที่ไม่ได้แสดงความขอบคุณต่ออดีตผู้ดูแลที่มีส่วนร่วมมาหลายปีเลย
  • การไม่พูดถึงว่าโปรเจกต์ไปอยู่ฝั่ง RC (Ruby Central) ได้อย่างไร ดูเหมือนเป็นการทำให้กระบวนการครั้งนี้สวยงามเกินจริง
• ในมุมของคนนอก อยากรู้ว่ามีใครอธิบายเรื่องนี้แบบสั้น ๆ ได้ไหม
  • ลองดูเธรดนี้ https://news.ycombinator.com/item?id=45299170#45300774 โดยเฉพาะสรุปของ Mike McQuaid ที่ช่วยได้มาก เขามีบทบาทช่วยไกล่เกลี่ยและทำให้การสื่อสารดีขึ้น และโพสต์บนโซเชียลล่าสุดของเขาก็น่าอ่านด้วย https://bsky.app/profile/mikemcquaid.com
  • เจ้าของเปลี่ยนมือไปมาหลายครั้ง และรายละเอียดของกระบวนการก็ไม่โปร่งใสเลย ความตึงเครียดในชุมชนจึงสูงขึ้น แล้วก็มีบุคคลที่เสียงดังและโดดเด่นที่สุดคนหนึ่งซึ่งมีสไตล์แสดงความคิดเห็นแรง ๆ แบบไม่ค่อยเป็นที่นิยม ทำให้ความขัดแย้งยิ่งบานปลาย
  • รู้สึกว่าไม่มีใครอธิบายได้ชัดเจนจริง ๆ มันทั้งสับสนและเหมือนไม่มีคำตอบ