- gem.coop là một máy chủ gem mới cho hệ sinh thái Ruby
- Được đội ngũ vận hành cũ của RubyGems.org xây dựng cho cộng đồng
- Cung cấp mọi gem công khai của RubyGems.org thông qua đồng bộ thời gian thực
- Đề cao tính minh bạch và sự tham gia của cộng đồng với mô hình quản trị lấy cảm hứng từ Homebrew
- Hướng tới dịch vụ lưu trữ gem bền vững và được tăng cường bảo mật
Giới thiệu về gem.coop
- gem.coop là một máy chủ gem mới được thiết kế cho hệ sinh thái Ruby, được xây dựng với mục tiêu mang lại môi trường lưu trữ nhanh hơn và đơn giản hơn
- Vẫn duy trì tương thích hoàn toàn với Bundler, đồng thời nhấn mạnh hiệu năng và độ ổn định được tối ưu cho môi trường phát triển thế hệ mới
- Dự án này có sự tham gia trực tiếp của các cựu quản trị viên và đội ngũ vận hành của RubyGems.org, và được phát triển như một dịch vụ dành cho cộng đồng
- Mọi gem công khai đều được đồng bộ theo thời gian thực từ RubyGems.org nên có thể dùng ngay trên gem.coop
- Có thể sử dụng chỉ bằng cách thay đổi đơn giản địa chỉ source trong Gemfile hiện có, nên cách áp dụng rất dễ dàng
Quản trị và sự tham gia của cộng đồng
- Tham khảo mô hình quản trị của dự án Homebrew để áp dụng một cấu trúc minh bạch và dễ tham gia
- Với sự hợp tác của Mike McQuaid, cách thiết lập tổ chức và phương thức vận hành đang được chuẩn bị, và hình thức quản trị chính thức dự kiến sẽ được công bố trước ngày 10 tháng 10
- Dự kiến vận hành theo một cấu trúc mở để bất kỳ ai trong cộng đồng Ruby cũng có thể đóng góp và tham gia
Mục tiêu dịch vụ và kế hoạch sắp tới
- Mục tiêu cuối cùng của gem.coop là cung cấp một nền tảng lưu trữ gem theo mô hình cộng đồng sở hữu, nhanh, minh bạch, bền vững và được tăng cường bảo mật
- Giai đoạn đầu hỗ trợ bundling và cài đặt cho mọi gem công khai, sau đó sẽ tiếp tục cải thiện tính năng và chất lượng
- Có thể nhận tin cập nhật hằng tháng thông qua bản tin của gem.coop
Thành phần đội ngũ
- Việc phát triển và vận hành do Gem Cooperative phụ trách, với deivid-rodriguez, duckinator, indirect, martinemde, segiddins và simi dẫn dắt
1 bình luận
Ý kiến trên Hacker News
Bỏ qua mọi tranh cãi, tôi xác nhận rằng RubyGems gốc hiện ở trong tình trạng tất cả maintainer đều đã rời đi, còn dự án mới thì có sự tham gia của hầu hết các cộng tác viên nòng cốt trước đây. Trước kia chỉ deivid là có sự hiện diện nổi bật, nhưng giờ có vẻ như phần lớn những nhân vật chủ chốt đã chuyển sang phía này. Giờ tôi có cảm giác fork này giống một phần mềm được quản lý tốt hơn. Tôi tò mò liệu mọi người có sớm chuyển sang bên này không, và có thông tin nào về mô hình tài trợ hay gánh nặng chi phí hosting hay không. Có thêm thông tin ở đây
Dù hiện tại fork này trông có vẻ là phần mềm được quản lý tốt hơn, tôi nghĩ điều thực sự quan trọng có lẽ không phải bản thân phần mềm mà là lưu trữ và băng thông của dịch vụ indexing. Tôi nghĩ có thể vẫn hoạt động tốt nếu chỉ cần một công cụ tìm kiếm gem lưu hash và việc tải xuống thì trỏ ra bên ngoài, ví dụ như một repo trên GitHub
Tình huống này hơi chua chát. Nếu fork này thành công, Ruby sẽ giống thế giới JS, nơi phải băn khoăn “nên dùng package manager nào?”. Sự đơn giản đẹp đẽ trước đây là “chỉ cần bundler và rubygems” sẽ biến mất. Dù vậy, tôi rất muốn khen đội ngũ quản lý RubyGems cũ vì sau khi công khai nêu vấn đề, họ đã lặng lẽ bắt tay vào làm fork. Một fork của RubyGems từng có vẻ là điều bất khả thi, nhưng giờ họ đang tạo ra dù chỉ là một khả năng nhỏ. Phần lớn các công ty lớn có lẽ sẽ ở lại với RC do Shopify hậu thuẫn, và ở các tổ chức như vậy thì kiểm toán bảo mật chắc cũng sẽ được tăng cường, nhưng đổi lại sẽ thiếu đổi mới. Ngược lại, nếu gems.coop thành công thì sẽ là vì nó đơn giản trở thành “công cụ tốt hơn”. Chẳng hạn rv.dev do André làm là một công cụ “nhanh và all-in-one”, hỗ trợ quản lý phiên bản Ruby, phụ thuộc gem, cả tính năng kiểu npx, nên sẽ đi trước về trải nghiệm nhà phát triển (DX). Namespace, checksum, cách tiếp cận bảo mật quyết liệt hơn về mặt kỹ thuật cũng đang được bàn tới, và nếu RC cứ tiếp tục như bây giờ thì cuối cùng bên vượt trội hơn về kỹ thuật có thể sẽ thắng. Về mặt tài trợ, có vẻ André cho rằng “các tổ chức có khả năng chi trả chi phí cho hạ tầng OSS thì thực sự nên trả tiền”, và tôi đồng ý. Làm vậy sẽ là một cách minh bạch để dự báo chính xác chi phí rồi chia đều theo số công ty trả tiền. Cuối cùng, tôi nghĩ nguyên nhân gốc khiến RC sụp đổ như thế này là vì nguồn tiền bị tập trung quá mức vào một số ít nhà tài trợ, và tôi mong Ruby Co-op sẽ xây dựng được mô hình tài trợ phân tán với 100, 1000 người trở lên
Xin lưu ý là mô hình tài trợ vẫn chưa được quyết định. Liên kết liên quan
Trang chính thức có quá ít thông tin. Vì vậy nếu suy luận một cách logic thì có thể giả định vài điều: 1) phát hành vẫn buộc phải phụ thuộc vào RubyGems. 2) không có UI cho tìm kiếm và xem gem nên vẫn phụ thuộc vào RubyGems. Bỏ qua chi tiết kỹ thuật, động lực thực tế để chuyển sang với tôi là không có, trừ khi tôi đồng ý về mặt ý thức hệ với những người duy trì fork này. Với mục đích chuyên môn thì không có lý do để chuyển, còn nếu quan tâm cá nhân thì chỉ đáng để ghi nhớ. Giống như phần lớn các fork khác, hoặc là đạt được mục tiêu rồi nhập lại, hoặc trở thành tiêu chuẩn mới, hoặc bị lãng quên. Nếu tôi không bị ảnh hưởng trực tiếp thì tôi sẽ cứ quan sát. Không phải tôi xem nhẹ vấn đề họ nêu ra hay công việc họ đang làm, nhưng đây là một tình huống thuyết phục hơn rất nhiều so với việc fork Rails vì DHH
Trong 10 năm qua, tôi không nghĩ ra được tính năng mới nào ở ruby gems hay bundler khiến tôi nhớ hoặc thấy thật sự cần thiết. Chắc chắn đã có tính năng mới, nhưng tôi không nhận ra
Nhìn vào danh tiếng của Andre Arko (như được tổng hợp trong bài viết này gần đây), tôi hơi dè chừng về động cơ của động thái lần này
Bài đó trông giống một bài công kích dựa trên thù oán cá nhân. Tôi khuyên đừng đặt quá nhiều trọng lượng vào nó khi đánh giá
Nếu nhìn theo kịch bản tiêu cực nhất thì sẽ là như sau: uv là một công cụ rất hay, nhưng Astral rõ ràng có kế hoạch tích hợp với các dịch vụ trả phí. Kiểu đó là một dạng rào cản gia nhập. Và có một góc nhìn cho rằng Andre và đội ngũ đã lấy cảm hứng từ thế giới Python (như thành công của uv) rồi định làm y hệt với Ruby. Bằng cách công bố rv, họ muốn khiến Ruby Gems phải phụ thuộc vào mình, và nếu nhìn vào các trường hợp như Hashicorp thì việc lôi kéo bằng miễn phí rồi nhốt các tính năng thiết yếu sau paywall doanh nghiệp ngày càng phổ biến. Tôi nghĩ việc hệ sinh thái Ruby phụ thuộc vào một cá nhân hoặc một nhóm nhỏ cũng nguy hiểm chẳng kém tình trạng Ruby Central hiện nay
Thật đáng kinh ngạc khi cộng đồng mã nguồn mở có thể đồng lòng như vậy để tìm ra giải pháp. Tôi muốn gửi lời cảm ơn tới tất cả những người đã bỏ công sức vào quá trình này
Đây chỉ là suy nghĩ của tôi, nhưng tôi tự hỏi tại sao không chuyển sang git như một tiêu chuẩn mới. Chẳng phải đó là một lựa chọn tốt hơn nhiều với commit được ký, tag được ký và cấu trúc phân tán sao?
Giao thức git có độ phức tạp cao và khả năng mở rộng kém. Đặc biệt nếu CI phải tải lại mọi package mỗi lần thì sẽ rất kém hiệu quả. Một archive dạng file đơn sẽ dễ phân phối hơn nhiều. Digest và thuật toán chữ ký không phải thứ chỉ riêng git mới có, và phần khó hơn là quản lý khóa và danh tính, mà git cũng không giải quyết trọn vẹn được việc đó (ý là đừng nhầm git với GitHub)
Sẽ phải có ai đó vận hành các máy chủ git, và với mỗi gem thì phải tìm máy chủ git tương ứng rồi Pull. Không phải mọi máy chủ git đều có phiên bản mới nhất, nên từng bên sẽ phải tự mở rộng riêng. Ưu điểm của tập trung hóa là mọi thứ ở cùng một chỗ, scale một lần, và cập nhật cũng được áp dụng đồng thời. Trước đây người ta từng dùng NPM, package manager, docker container qua proxy bằng artifactory các kiểu, nên kể cả khi dịch vụ trung gian ngừng hoạt động thì vẫn có thể triển khai bình thường. Nhưng với nhà phát triển hoặc nhóm nhỏ thì kiểu quản lý này có vẻ là overhead không cần thiết
Thực ra rubygems (phần mềm) đã có thể lấy package từ bất kỳ repo git nào rồi. Ở mức độ nào đó thì điều này đã được hỗ trợ
Go đã áp dụng cách tiếp cận như vậy rồi
Sau khi nhìn vào hệ sinh thái đóng gói của Go mà vẫn nghĩ chuyển sang git là ý hay thì tôi thấy hơi khó hiểu
Điểm quan trọng nhất là lẽ ra họ có thể ít nhất đưa lên một liên kết repo git để bên ngoài thấy dự án đang được duy trì thế nào, nhưng hiện tại thì không có. Có danh sách maintainer nhưng không có liên kết repo git, nên tôi có ấn tượng đây là một dự án tập trung vào con người hơn là vào code
Nếu là một kho package thì tôi không nghĩ một liên kết kiểu repo Ansible nhất thiết phải có ngay trong thông báo đầu tiên. Điều quan trọng nhất với một kho package là niềm tin. Việc thâu tóm mang tính thù địch đã xảy ra ở RubyGems đã phá vỡ niềm tin đó, và một phương án thay thế do chính đội ngũ maintainer cũ đã bị cho ra rìa đứng ra vận hành lại là một thay đổi tích cực. Ngược lại, tôi cảm giác bạn đã có sẵn kết luận rồi chỉ đang thêm lý do để biện minh. Tham khảo thêm, trên trang chủ rubygems.org cũng không dễ thấy liên kết repo git
Mã nguồn ở đây
Nếu bỏ qua tranh cãi gần đây, tôi cũng băn khoăn liệu một nguồn package, manager hay trình quản lý phiên bản thay thế nhưng tương thích có trung lập, tích cực hay tiêu cực đối với hệ sinh thái mã nguồn mở hay không
Tôi hiểu là đôi khi fork là cần thiết, nhưng việc họ đã không thể điều phối với nhau vẫn để lại cảm giác hơi buồn. Nếu mọi người cùng có mục tiêu chung là phát triển hệ sinh thái Ruby, thì liệu họ không thể hợp tác bất chấp khác biệt chính trị hay quan điểm cá nhân sao? Merb và Rails, Bundler và RubyGems, RubyTogether và RubyCentral trước đây cuối cùng cũng đã hợp nhất, nên tôi vẫn hy vọng rồi sẽ có cách giải quyết
Tôi nghĩ nếu cải tổ cách phát hành và tải gem thì những vấn đề như thế này có thể được giải quyết. Nhưng vấn đề là những bên có thể tạo ra thay đổi đó hiện đang kiểm soát phần mềm và hạ tầng, và họ lại không có nhiều động lực để cải thiện. Bản thân tình huống này đã là điều vô lý, và tôi cũng không hiểu vì sao lại có ác cảm với DHH. Thật đáng tiếc vì cách dễ nhất để phá hỏng một dự án mã nguồn mở lại chính là các màn kịch tính và những vụ fork như thế này. Ruby là một ngôn ngữ lâu đời nhưng tệp người dùng không quá lớn, nên những tranh cãi như vậy đang gây hại cho cả hệ sinh thái, và với tư cách một cựu lập trình viên Ruby, tôi thấy buồn
Tôi nghĩ đây là một động thái rất tốt để đối phó hiệu quả với tình trạng repo và tổ chức RubyGems trên GitHub bị Ruby Central thâu tóm một cách thù địch. Mong rằng sẽ có hỗ trợ tài chính cho chi phí hosting