▲

Gem.coop

 (gem.coop)
2P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • gem.coop은 Ruby 생태계를 위한 새로운 gem 서버임
  • RubyGems.org의 전 운영진이 커뮤니티를 위해 구축함
  • RubyGems.org의 모든 공개 gem을 실시간 동기화로 제공함
  • Homebrew에서 영감을 받은 거버넌스로 투명성과 커뮤니티 참여를 중시함
  • 지속 가능하고 보안 강화된 gem 호스팅을 목표로 함

gem.coop 소개

  • gem.coop은 Ruby 생태계용으로 설계된 새로운 gem 서버로, 더 빠르고 간단한 호스팅 환경 제공을 목표로 구성함
  • Bundler와의 완벽한 호환성을 유지하면서, 차세대 개발 환경에 최적화된 성능과 안정성을 강조함
  • 이 프로젝트는 RubyGems.org의 전 관리자 및 운영진이 직접 참여하여 커뮤니티를 위한 서비스로 개발됨
  • 모든 공개 gem은 RubyGems.org에서 실시간으로 동기화되어 gem.coop에서도 즉시 사용 가능함
  • 기존 Gemfile에서 source 주소만 단순 변경하면 사용할 수 있어, 적용 방식이 매우 쉬움

거버넌스와 커뮤니티 참여

  • Homebrew 프로젝트의 거버넌스 모델을 참고하여 투명하고 참여가 쉬운 구조를 도입함
  • Mike McQuaid의 협조로 조직 세팅 및 운영 방식이 준비되고 있으며, 10월 10일 이전에 공식 거버넌스 형태가 공개 예정임
  • Ruby 커뮤니티 누구나 기여와 참여가 가능하도록 열린 구조로 운영 계획임

서비스 목표 및 향후 계획

  • gem.coop의 궁극적 목표는 커뮤니티 소유 방식의 빠르고, 투명하며, 지속 가능하고, 보안이 강화된 gem 호스팅 플랫폼 제공임
  • 초기에 모든 공개 gem의 bundling과 설치를 지원하며, 추후 기능 및 품질을 계속적으로 개선 예정임
  • gem.coop 뉴스레터를 통해 월간 업데이트 소식을 받아볼 수 있음

팀 구성

  • 개발 및 운영은 Gem Cooperative 소속으로, deivid-rodriguez, duckinator, indirect, martinemde, segiddins, simi가 주도함
▲
GN⁺ 5일전  [-]
Hacker News 의견

  • 모든 논란을 차치하고, 현재 원래의 RubyGems는 유지 관리자가 모두 떠난 상황이고, 새로운 프로젝트에는 기존의 핵심 기여자들이 대부분 참여 중임을 확인함. 예전에는 deivid만 존재감이 뚜렷했지만 지금은 주요 인물 대부분이 이쪽으로 온 것 같음. 이제 이 포크가 더 잘 관리되는 소프트웨어 같다는 느낌을 받음. 사람들이 곧 이쪽으로 이동할 가능성, 그리고 펀딩 모델이나 호스팅 비용 부담에 대한 정보가 있는지 궁금함. 추가 정보는 여기에도 있음

    • 지금 이 포크가 더 잘 관리되고 있는 소프트웨어처럼 보이기도 하지만, 실제 중요한 건 소프트웨어 자체보다는 인덱싱 서비스의 저장 및 대역폭일 것이라는 생각임. 간단히 gem 검색 엔진이 해시를 저장하고 다운로드는 외부, 예를 들어 GitHub 같은 리포로 연결하게 만들어도 잘 작동하지 않을까 생각함

    • 이 상황이 조금 씁쓸함. 만약 이 포크가 성공하면 JS 세계처럼 “어느 패키지 매니저를 쓸까?”를 고민하는 구조가 될 것임. 기존의 “bundler와 rubygems만 쓰면 된다”는 아름다운 단순함이 사라질 것임. 다만 억울했던 RubyGems 기존 관리진이 공개적으로 문제 제기 후 조용히 포크 작업에 착수한 점은 크게 칭찬하고 싶음. RubyGems 포크라는 게 불가능해 보였는데, 지금은 작은 가능성이나마 그들이 만들어내고 있음. 대기업들은 대부분 Shopify가 백업하는 RC에 남을 듯하고, 이런 조직에서는 보안 관련 감사도 강화할 테지만 혁신은 부족하리라 봄. 반면 gems.coop가 성공하게 된다면, 단순히 “더 좋은 도구”로 자리 잡기 때문일 것임. 예를 들어 André가 만드는 rv.dev는 루비 버전 관리, gem 의존성, npx 같은 기능까지 지원하는 “빠르고 올인원” 도구라 개발자 경험(DX) 면에서 앞설 것임. 네임스페이스, 체크섬, 기술적으로 더 공격적인 보안 접근 등도 논의 중이고, 만약 RC가 지금처럼 간다면 결국 기술적으로 우월한 쪽이 승리할 수도 있다고 봄. 펀딩 측면에서는 André가 “OSS 인프라에 비용을 감당할 수 있는 조직은 실제로 돈을 내야 한다”고 보는 것 같고, 나도 동의함. 이렇게 하면 정확히 비용 예측하고 지불 기업 수로 분담하는 투명한 방식이 될 수 있다고 생각함. 마지막으로 RC가 이렇게 망가진 근본 원인은 소수 후원자에 자금이 과도하게 집중됐기 때문이라고 생각하는데, Ruby Co-op이 100명, 1000명 이상의 분산된 펀딩 모델을 구축하길 바람

    • 펀딩 모델은 아직 미정임을 참고함. 관련 링크

    • 공식 페이지에 정보가 너무 없음. 그래서 논리적으로 몇 가지 가정해 보면: 1) 배포를 RubyGems에 의존할 수밖에 없음. 2) gem 검색 및 뷰를 위한 UI가 없어 RubyGems에 의존함. 기술적 세부사항을 떠나서, 실질적인 전환 계기는 내가 포크 관리진들과 이념적으로 동의하지 않는 이상 전혀 없음. 전문적인 목적이라면 이동할 이유가 없고, 개인적으로 관심 있으면 기억해 두는 정도일 것임. 대부분의 포크가 이렇듯, 목표를 이루면 합쳐지거나, 아예 새로운 표준이 되거나, 잊히게 됨. 내가 직접적으로 영향을 받지 않는다면 난 그냥 지켜볼 것임. 이들의 문제제기나 작업을 폄하하는 게 아니라, DHH 때문에 Rails를 포크하는 경우보다는 훨씬 더 설득력이 있는 상황임

    • 지난 10년간 ruby gems나 bundler에서 기억에 남거나 필요하다고 느낀 새 기능은 떠오르지 않음. 분명 새로운 기능들이 있었겠지만, 내가 인지하지 못함

  • Andre Arko에 대한 평판을 보면 (최근 이 글에서 정리된 것처럼), 이번 움직임의 동기가 무엇인지 조금 경계되는 입장임

    • 해당 글은 개인적 원한에 기반한 공격 글처럼 보임. 평가를 내릴 때 너무 무게를 두지 말길 권장함

    • 가장 부정적인 시나리오로 보면 다음과 같음: uv는 멋진 도구이지만, Astral이 유료 서비스와의 연동을 분명히 계획함. 이런 게 일종의 진입장벽임. 그리고 Andre와 팀이 Python 세계(uv의 성공처럼)에서 힌트를 얻어 똑같이 Ruby에서 하려고 했다고 보는 시각임. rv를 발표하면서 Ruby Gems를 자신들에게 의존하게 하려는 것이고, Hashicorp 등의 사례를 보면 무료로 끌어들여 필수 기능을 엔터프라이즈 페이월에 넣는 게 점점 더 잦아짐. Ruby 생태계가 특정 개인 또는 소규모 집단에 종속되는 건 지금 Ruby Central과 똑같이 위험하다고 생각함

  • 오픈소스 커뮤니티가 이렇게 합심하여 해법을 찾는 모습이 놀라움. 이 과정에 힘쓴 모든 분들께 감사를 전하고 싶음

    • 그래도 관리자의 시간과 전문성에는 보상이 필요함. 대역폭, 저장소가 저렴해도 누군가는 그 비용을 내야 하니, 프로젝트에 기부하는 게 좋다고 생각함

  • 내 생각인데, 왜 git을 새로운 표준으로 옮기지 않는지 궁금함. 커밋 서명, 태그 서명, 분산 구조 등 훨씬 나은 대안처럼 보이지 않음?

    • git 프로토콜은 복잡도가 높고 확장성이 떨어짐. 특히 매번 모든 패키지를 CI에서 다시 다운로드한다면 비효율적임. 단일 파일 아카이브가 훨씬 분배가 쉬움. 다이제스트, 서명 알고리즘은 git만의 것이 아니고, 키 및 신원 관리가 더 어려운 부분인데, git이 이것도 완전히 해결하는 건 아님 (git과 GitHub를 혼동하지 말라는 의미임)

    • 누군가는 git 서버를 운영해야 하고, 각 gem마다 해당 git 서버를 찾아서 Pull해야 함. 모든 git 서버가 최신 버전을 갖고 있지도 않을 테니, 각각이 따로따로 확장해야 함. 중앙화의 장점은 모든 게 한곳에 모여 있고, 스케일도 한 번에 되고, 업데이트도 동시 적용된다는 점임. 예전에는 artifactory 등으로 NPM, 패키지 매니저, docker 컨테이너를 프록시로 썼는데, 중간 서비스가 중단되어도 문제없이 배포 가능했음. 하지만 소규모 개발자나 팀에는 이런 관리가 불필요한 오버헤드처럼 느껴짐

    • 사실 rubygems(소프트웨어)는 이미 아무 git 리포에서도 패키지를 가져올 수 있음. 어느 정도 이미 지원되는 상황임

    • Go 언어는 이미 그런 접근을 차용하고 있음

    • Go의 패키징 생태계를 봤음에도 git로 전환하는게 좋은 생각이라 여기는지 의문임

  • 가장 중요한 점은, 프로젝트를 유지 관리하는 모습을 외부에서 볼 수 있게 git 리포 링크라도 올려둘 수 있었을 텐데, 지금은 없음. 유지관리자 명단은 있는데 git 리포 링크가 없으니, 코드보다는 사람 중심의 프로젝트라는 인상을 받았음

    • 패키지 저장소라면 Ansible 리포같은 링크가 첫 공지사항에 굳이 있을 필요는 없다고 생각함. 패키지 저장소에서 가장 중요한 건 신뢰임. RubyGems에서 발생한 적대적 인수합병이 그 신뢰를 깨뜨렸는데, 오프라인된 원래 관리진들이 직접 나와서 운영하는 대안이 오히려 좋은 변화임. 오히려 너가 결론을 미리 내려놓고 핑계만 붙이는 것 같음. 참고로, https://rubygems.org/">rubygems.org 메인에도 git 리포 링크가 잘 보이지 않음

    • 소스는 여기에 있음

  • 최근 논란을 빼고 본다면, 호환성 있는 대안 패키지 소스나 매니저, 버전 관리자가 오픈소스 생태계에 중립적, 긍정적, 부정적인지에 대해 고민이 됨

    • 대부분 긍정적이라고 봄. 독점은 정체를 부르고, 경쟁이 혁신을 일으킴. 오픈소스도 마찬가지임

  • 포크가 필요할 때가 있는 건 이해하지만, 서로 조율할 수 없었다는 감정은 조금 씁쓸함. 모두가 루비 생태계를 발전시키는 공통 목표가 있다면 정치적 배경이나 개인 의견 차이가 있어도 협력할 수 있지 않을까 생각함. 과거 Merb와 Rails, Bundler와 RubyGems, RubyTogether와 RubyCentral도 결국 합쳐졌으니, 언젠간 해결될 거라고 희망함

  • gem 배포·다운로드 방식을 개편하면 이런 문제가 해결될 수 있다고 봄. 다만 그 변화를 만들 수 있는 주체들은 현재 소프트웨어와 인프라를 통제하는 쪽이고, 개선 동기가 별로 없다는 게 문제임. 이런 상황 자체가 말도 안 된다 여겨지고, DHH에 대한 반감도 이유를 모르겠음. 오픈소스 프로젝트를 무너뜨리는 가장 쉬운 방법이 이런 드라마와 포크라서 안타까움. Ruby가 오래된 언어임에도 사용자 기반이 크지 않은데, 이런 논란이 생태계 전반에 해가 되고 있어 전직 Ruby 개발자로서 슬픈 마음임

  • RubyGems GitHub 리포와 조직이 Ruby Central에 의해 적대적으로 인수된 상황에 효과적으로 대응한 훌륭한 움직임이라고 생각함. 호스팅 비용을 위한 재정 지원이 마련되길 바람

    • 호스팅 비용은 이미 확보된 것으로 알고 있음
답변달기