Gem.coop

 (gem.coop)
2 คะแนน โดย GN⁺ 2025-10-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • gem.coop เป็นเซิร์ฟเวอร์ gem ใหม่สำหรับระบบนิเวศ Ruby
  • สร้างโดย อดีตทีมปฏิบัติการของ RubyGems.org เพื่อชุมชน
  • ให้บริการ gem สาธารณะทั้งหมดจาก RubyGems.org ผ่านการซิงก์แบบเรียลไทม์
  • ให้ความสำคัญกับความโปร่งใสและการมีส่วนร่วมของชุมชนด้วยรูปแบบการกำกับดูแลที่ได้แรงบันดาลใจจาก Homebrew
  • มุ่งสู่การโฮสต์ gem ที่ยั่งยืนและเสริมความปลอดภัย

แนะนำ gem.coop

  • gem.coop เป็นเซิร์ฟเวอร์ gem ใหม่ที่ออกแบบมาสำหรับระบบนิเวศ Ruby โดยตั้งเป้าที่จะมอบสภาพแวดล้อมการโฮสต์ที่เร็วขึ้นและเรียบง่ายยิ่งขึ้น
  • ยังคง เข้ากันได้อย่างสมบูรณ์ กับ Bundler พร้อมเน้นประสิทธิภาพและความเสถียรที่เหมาะกับสภาพแวดล้อมการพัฒนายุคถัดไป
  • โปรเจกต์นี้พัฒนาเป็นบริการเพื่อชุมชน โดยมี อดีตผู้ดูแลระบบ และทีมปฏิบัติการของ RubyGems.org เข้าร่วมโดยตรง
  • gem สาธารณะทั้งหมดจะถูก ซิงก์แบบเรียลไทม์จาก RubyGems.org ทำให้สามารถใช้งานได้ทันทีบน gem.coop
  • สามารถใช้งานได้ด้วยการเปลี่ยน source address ใน Gemfile เดิมเพียงอย่างเดียว จึงนำไปใช้ได้ง่ายมาก

การกำกับดูแลและการมีส่วนร่วมของชุมชน

  • นำโครงสร้างที่โปร่งใสและเปิดให้มีส่วนร่วมได้ง่าย โดยอ้างอิงจากโมเดลการกำกับดูแลของโปรเจกต์ Homebrew
  • ด้วยความร่วมมือของ Mike McQuaid กำลังเตรียมการด้านการตั้งค่าองค์กรและแนวทางการดำเนินงาน และมีแผนเผยแพร่รูปแบบการกำกับดูแลอย่างเป็นทางการก่อนวันที่ 10 ตุลาคม
  • วางแผนดำเนินงานในรูปแบบเปิดเพื่อให้ทุกคนในชุมชน Ruby สามารถ ร่วมพัฒนาและมีส่วนร่วม ได้

เป้าหมายของบริการและแผนในอนาคต

  • เป้าหมายสูงสุดของ gem.coop คือการมอบแพลตฟอร์มโฮสต์ gem ที่ชุมชนเป็นเจ้าของ ซึ่งรวดเร็ว โปร่งใส ยั่งยืน และมีความปลอดภัยสูง
  • ในระยะแรกจะรองรับการ bundling และการติดตั้ง gem สาธารณะทั้งหมด และจะทยอยปรับปรุงฟีเจอร์และคุณภาพอย่างต่อเนื่อง
  • สามารถติดตามอัปเดตรายเดือนได้ผ่านจดหมายข่าวของ gem.coop

ทีมงาน

  • การพัฒนาและการดำเนินงานอยู่ภายใต้ Gem Cooperative โดยมี deivid-rodriguez, duckinator, indirect, martinemde, segiddins และ simi เป็นแกนนำ

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

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

 
GN⁺ 2025-10-07
ความเห็นจาก Hacker News

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

    • ตอนนี้ฟอร์กนี้อาจดูเหมือนเป็นซอฟต์แวร์ที่ได้รับการดูแลดีกว่า แต่คิดว่าสิ่งสำคัญจริง ๆ อาจไม่ใช่ตัวซอฟต์แวร์เอง แต่อยู่ที่การเก็บข้อมูลและแบนด์วิดท์ของบริการทำดัชนีมากกว่า คิดว่าแค่ทำให้เสิร์ชเอนจิน gem เก็บ hash ไว้ แล้วให้การดาวน์โหลดชี้ไปยังรีโปภายนอก เช่น GitHub ก็น่าจะทำงานได้ดีไม่ใช่หรือ

    • สถานการณ์นี้ค่อนข้างขมขื่นนิดหน่อย ถ้าฟอร์กนี้สำเร็จ มันอาจกลายเป็นแบบโลก JS ที่ต้องมานั่งคิดว่า “จะใช้ package manager ตัวไหนดี?” ความเรียบง่ายงดงามแบบเดิมที่ “ใช้แค่ bundler กับ rubygems ก็พอ” จะหายไป อย่างไรก็ตาม อยากชมทีมผู้ดูแล RubyGems เดิมที่ถูกกระทำอย่างไม่เป็นธรรม ว่าพวกเขาออกมาตั้งคำถามในที่สาธารณะแล้วค่อย ๆ เริ่มทำฟอร์กอย่างเงียบ ๆ ได้ดีมาก เดิมทีการฟอร์ก RubyGems ดูเหมือนเป็นไปไม่ได้ แต่ตอนนี้อย่างน้อยพวกเขาก็กำลังสร้างความเป็นไปได้เล็ก ๆ ขึ้นมา บริษัทใหญ่ส่วนมากคงจะอยู่กับ RC ที่ Shopify หนุนหลังต่อไป และองค์กรแบบนั้นก็น่าจะเข้มเรื่องการตรวจสอบความปลอดภัยมากขึ้น แต่คงขาดนวัตกรรม ในทางกลับกัน ถ้า gems.coop ประสบความสำเร็จ ก็คงเพราะมันกลายเป็น “เครื่องมือที่ดีกว่า” จริง ๆ ตัวอย่างเช่น rv.dev ที่ André กำลังทำอยู่ เป็นเครื่องมือ “เร็วและครบจบในตัว” ที่รองรับทั้งการจัดการ Ruby version, gem dependency และความสามารถแบบ npx จึงน่าจะนำหน้าในแง่ประสบการณ์นักพัฒนา (DX) ยังมีการคุยกันเรื่อง namespace, checksum และแนวทางความปลอดภัยเชิงเทคนิคที่ดุดันกว่านี้ด้วย และถ้า RC ยังเดินต่อแบบตอนนี้ สุดท้ายฝ่ายที่เหนือกว่าทางเทคนิคอาจชนะก็ได้ ในมุมการระดมทุน ดูเหมือน André จะมองว่า “องค์กรที่สามารถรับภาระค่าใช้จ่ายของ OSS infrastructure ได้ ก็ควรจ่ายเงินจริง” ซึ่งฉันก็เห็นด้วย แบบนี้จะเป็นวิธีที่โปร่งใส คาดการณ์ต้นทุนได้ตรง และกระจายค่าใช้จ่ายตามจำนวนบริษัทที่จ่ายเงินจริง สุดท้าย ฉันคิดว่าต้นเหตุหลักที่ทำให้ RC พังแบบนี้คือเงินทุนกระจุกอยู่กับผู้สนับสนุนจำนวนน้อยเกินไป จึงหวังว่า Ruby Co-op จะสร้างโมเดลระดมทุนแบบกระจายจาก 100 คน หรือ 1000 คนขึ้นไปได้

    • ขอเสริมว่าโมเดลการระดมทุนยังไม่ได้ข้อสรุป ลิงก์ที่เกี่ยวข้อง

    • ในหน้าอย่างเป็นทางการมีข้อมูลน้อยเกินไป เลยลองตั้งสมมติฐานแบบมีเหตุผลดูสักหน่อย: 1) การเผยแพร่ยังไงก็ต้องพึ่ง RubyGems 2) ไม่มี UI สำหรับค้นหาและดู gem จึงยังต้องพึ่ง RubyGems อยู่ ต่อให้ไม่ลงรายละเอียดทางเทคนิค ปัจจัยที่ทำให้ย้ายจริง ๆ ก็แทบไม่มีเลย เว้นแต่ฉันจะเห็นด้วยทางอุดมการณ์กับทีมผู้ดูแลฟอร์กนี้ ในแง่วิชาชีพไม่มีเหตุผลให้ย้าย ส่วนถ้าสนใจเป็นการส่วนตัวก็คงแค่จำชื่อไว้ เหมือนฟอร์กส่วนใหญ่ ถ้าบรรลุเป้าหมายก็จะถูกรวมกลับ หรือไม่ก็กลายเป็นมาตรฐานใหม่ไปเลย หรือไม่ก็ถูกลืม ถ้าไม่ได้รับผลกระทบโดยตรง ฉันก็คงเฝ้าดูอยู่เฉย ๆ ไม่ได้จะดูแคลนข้อเรียกร้องหรือผลงานของพวกเขานะ แต่สถานการณ์นี้น่าเชื่อถือกว่ากรณีฟอร์ก Rails เพราะ DHH มาก

    • ตลอด 10 ปีที่ผ่านมา ฉันนึกไม่ออกเลยว่ามีฟีเจอร์ใหม่อะไรใน ruby gems หรือ bundler ที่น่าจดจำหรือรู้สึกว่าจำเป็น แน่นอนว่าคงมีฟีเจอร์ใหม่บ้าง แต่ฉันไม่ได้รับรู้มัน

  • เมื่อดูชื่อเสียงของ Andre Arko (อย่างที่สรุปไว้ในบทความนี้เมื่อไม่นานมานี้) ก็ทำให้ฉันระวังอยู่พอสมควรว่าการเคลื่อนไหวครั้งนี้มีแรงจูงใจอะไรอยู่เบื้องหลัง

    • บทความนั้นดูเหมือนเป็นบทโจมตีที่ตั้งอยู่บนความแค้นส่วนตัว จึงไม่แนะนำให้ให้น้ำหนักมากเกินไปเวลาใช้ประเมินสถานการณ์

    • ถ้ามองในฉากทัศน์ที่แย่ที่สุด ก็อาจเป็นแบบนี้: uv เป็นเครื่องมือที่ยอดเยี่ยม แต่ Astral ก็มีแผนเชื่อมกับบริการแบบเสียเงินอย่างชัดเจน ซึ่งสิ่งนี้เองเป็นเหมือนกำแพงกั้นการเข้าใช้ และมีมุมมองว่า Andre กับทีมได้แรงบันดาลใจจากโลก Python (เหมือนความสำเร็จของ uv) แล้วพยายามทำแบบเดียวกันในโลก Ruby โดยการเปิดตัว rv ก็เพื่อทำให้ Ruby Gems ต้องพึ่งพาพวกเขา และถ้าดูตัวอย่างอย่าง Hashicorp ก็จะเห็นว่าการดึงคนเข้ามาด้วยของฟรีก่อน แล้วเอาฟีเจอร์สำคัญไปใส่หลัง enterprise paywall เกิดขึ้นบ่อยขึ้นเรื่อย ๆ ฉันคิดว่าการที่ระบบนิเวศ Ruby ต้องขึ้นกับบุคคลคนเดียวหรือกลุ่มเล็ก ๆ ก็อันตรายพอ ๆ กับที่ตอนนี้มันขึ้นกับ Ruby Central

  • น่าทึ่งมากที่ชุมชนโอเพนซอร์สรวมพลังกันเพื่อหาทางออกแบบนี้ อยากขอบคุณทุกคนที่ลงแรงในกระบวนการนี้

    • ถึงอย่างนั้น เวลาและความเชี่ยวชาญของผู้ดูแลก็ควรได้รับค่าตอบแทน ถึงแบนด์วิดท์กับสตอเรจจะถูก แต่สุดท้ายก็ต้องมีคนจ่ายค่าใช้จ่ายเหล่านั้นอยู่ดี ดังนั้นฉันคิดว่าควรบริจาคให้โปรเจ็กต์

  • เป็นความคิดส่วนตัว แต่สงสัยว่าทำไมไม่ย้ายไปใช้ git เป็นมาตรฐานใหม่เลย เพราะมันดูเป็นทางเลือกที่ดีกว่ามาก ทั้งเรื่องการเซ็นชื่อ commit, การเซ็นชื่อ tag, และโครงสร้างแบบกระจาย

    • โปรโตคอล git มีความซับซ้อนสูงและขยายตัวได้ไม่ดีนัก โดยเฉพาะถ้าต้องดาวน์โหลดทุกแพ็กเกจใหม่ทั้งหมดใน CI ทุกครั้งก็จะไม่มีประสิทธิภาพ ไฟล์ archive เดี่ยว ๆ กระจายได้ง่ายกว่ามาก ส่วน digest กับอัลกอริทึมลายเซ็นก็ไม่ใช่ของเฉพาะ git และส่วนที่ยากกว่าคือการจัดการกุญแจและตัวตน ซึ่ง git เองก็ไม่ได้แก้ปัญหานี้ได้สมบูรณ์ (หมายถึงอย่าสับสนระหว่าง git กับ GitHub)

    • ยังไงก็ต้องมีใครสักคนดูแล git server และต้องไปค้นหาแล้ว Pull จาก git server นั้นสำหรับแต่ละ gem อีกทั้งไม่ใช่ทุก git server จะมีเวอร์ชันล่าสุด จึงทำให้แต่ละแห่งต้องขยายระบบของตัวเองแยกกัน ข้อดีของความเป็นศูนย์กลางคือทุกอย่างอยู่ที่เดียว สเกลทีเดียวได้ และอัปเดตพร้อมกันได้ สมัยก่อนเคยใช้ proxy อย่าง artifactory สำหรับ NPM, package manager และ docker container ซึ่งทำให้ยัง deploy ได้แม้บริการกลางจะล่ม แต่สำหรับนักพัฒนาหรือทีมเล็ก ๆ ภาระในการดูแลแบบนี้ก็ดูเป็น overhead ที่ไม่จำเป็น

    • ที่จริงแล้ว rubygems (ตัวซอฟต์แวร์) สามารถดึงแพ็กเกจจาก git repo ใด ๆ ก็ได้อยู่แล้ว พูดได้ว่ารองรับอยู่ในระดับหนึ่งแล้ว

    • ภาษา Go ก็ใช้แนวทางแบบนั้นอยู่แล้ว

    • พอเห็น ecosystem ด้านแพ็กเกจของ Go แล้ว ก็ยังสงสัยว่าการย้ายไปใช้ git เป็นความคิดที่ดีจริงหรือไม่

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

    • ถ้าเป็น package registry ฉันไม่คิดว่าจำเป็นต้องมีลิงก์แบบ Ansible repo อยู่ในประกาศแรกเสมอไป สิ่งสำคัญที่สุดของ package registry คือความน่าเชื่อถือ แต่ความน่าเชื่อถือนั้นถูกทำลายไปแล้วจากการยึดครองแบบเป็นปฏิปักษ์ที่เกิดกับ RubyGems และทางเลือกที่ผู้ดูแลชุดเดิมซึ่งถูกทำให้ออฟไลน์ออกมาดูแลเองกลับเป็นการเปลี่ยนแปลงที่ดีเสียด้วยซ้ำ จริง ๆ แล้วดูเหมือนคุณจะสรุปไว้ก่อนแล้วค่อยหาเหตุผลมารองรับมากกว่า อ้างอิงไว้ด้วยว่าแม้แต่หน้าแรกของ rubygems.org ก็ไม่ได้มีลิงก์ git repo ที่มองเห็นได้ชัดเจน

    • ซอร์สอยู่ที่นี่

  • ถ้าไม่นับประเด็นขัดแย้งล่าสุด ฉันก็ยังสงสัยอยู่ว่าการมีแหล่งแพ็กเกจหรือ package manager ที่เข้ากันได้ รวมถึงตัวจัดการเวอร์ชันแบบทางเลือก จะส่งผลต่อระบบนิเวศโอเพนซอร์สในทางเป็นกลาง ทางบวก หรือทางลบ

    • ฉันมองว่าโดยมากเป็นผลบวก การผูกขาดนำไปสู่ความหยุดนิ่ง ส่วนการแข่งขันก่อให้เกิดนวัตกรรม โอเพนซอร์สก็เช่นกัน

  • เข้าใจว่าบางครั้งการฟอร์กก็จำเป็น แต่ก็ยังรู้สึกขมขื่นนิดหน่อยที่ไม่สามารถหาจุดประสานกันได้ ถ้าทุกคนมีเป้าหมายร่วมกันในการพัฒนาระบบนิเวศ Ruby บางทีแม้จะมีภูมิหลังทางการเมืองหรือความเห็นส่วนตัวต่างกันก็น่าจะร่วมมือกันได้ ฉันหวังว่าสุดท้ายแล้วเรื่องนี้จะคลี่คลาย เพราะในอดีตทั้ง Merb กับ Rails, Bundler กับ RubyGems, RubyTogether กับ RubyCentral ก็กลับมารวมกันได้ในที่สุด

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

  • ฉันคิดว่านี่เป็นการเคลื่อนไหวที่ยอดเยี่ยมและตอบสนองได้อย่างมีประสิทธิภาพต่อสถานการณ์ที่ RubyGems GitHub repo และองค์กรถูก Ruby Central ยึดครองแบบเป็นปฏิปักษ์ หวังว่าจะมีการสนับสนุนทางการเงินสำหรับค่าโฮสต์

    • เท่าที่ทราบ ค่าโฮสต์ได้รับการจัดหาไว้แล้ว