Ruby Central의 주장들에 대한 저자의 사실 확인 결과는 다음과 같습니다.
Ruby Central 주장의 진위 분석
- 신뢰 의무 및 이사회 승인:
- 주장: Ruby Central은 공급망 보호 및 생태계 장기적 안정성 유지를 위한 신뢰 의무를 가지며, RubyGems 프로젝트 인수 결정은 이사회 승인을 받았다.
- 판단: 사실(True). Freedom Dumlao가 이를 확인했으며, Shopify가 이사회에 상당한 재정적 압력을 가한 것으로 파악됩니다.
- 임시 온콜 로테이션:
- 주장: Ruby Central은 강력한 임시 온콜 로테이션을 운영 중이다.
- 판단: 불분명(Unclear). Shopify의 숙련된 엔지니어들과 자원봉사자들이 포함되어 있으나, 대부분은 RubyGems.org 서비스 운영 경험이 부족합니다.
- 건강하고 투명한 거버넌스 목표:
- 주장: Ruby Central의 목표는 RubyGems 프로젝트를 더 건강하고 투명하며 커뮤니티 중심적인 거버넌스 모델로 전환하는 것이다.
- 판단: 거짓(False). RubyGems 프로젝트는 이미 건강하고 투명한 커뮤니티 중심의 거버넌스 모델로 운영되고 있었으며, 인수는 기존 합의를 깨고 Shopify의 요청에 따라 이루어졌습니다. Shan Cureton이 전무이사로 취임한 이후 Ruby Central의 투명성은 오히려 감소했습니다.
- 오픈 소스 관리 환경 조성:
- 주장: Ruby Central은 오픈 소스 관리가 번성할 수 있는 올바른 조건을 구축하는 데 중점을 둔다.
- 판단: 거짓(False). 위의 거버넌스 문제와 맥락을 같이합니다.
- Ruby Together 합병으로 인한 책임:
- 주장: Bundler와 RubyGems는 Ruby Together와의 합병을 통해 Ruby Central의 책임 하에 들어왔다.
- 판단: 거짓(False). 합병 문서를 검토한 결과, Bundler와 RubyGems는 Ruby Together에 속한 적이 없으며, 합병을 통해 Ruby Central로 이전되지도 않았습니다.
- RubyGems.org 서비스 보안을 위한 인수 필요성:
- 주장: Bundler와 RubyGems의 인수는 RubyGems.org 서비스의 보안을 위해 필수적이었다.
- 판단: 거짓(False). Ruby Central은 RubyGems.org 서비스의 운영 주체로서, 커뮤니티 커밋을 검증하여 동기화하거나, 자체적인 소프트 포크 또는 하드 포크를 통해 서비스를 운영할 수 있었습니다.
- 커밋 권한 박탈의 비영구적 성격:
- 주장: RubyGems 유지보수 담당자들의 커밋 권한 박탈은 영구적이지 않다.
- 판단: 거짓(False). Ruby Central은 기존 유지보수 담당자들에게 RubyGems 오픈 소스 자산을 되돌려줄 의도가 없었습니다. HSBT와 Colby(Ruby Central 소속)를 제외한 모든 유지보수 담당자들이 GitHub 조직에서 제거되었으며, 특히 André Arko와 Samuel Giddins는 복귀가 허용되지 않을 것으로 알려졌습니다. 현재 Marty Haught와 Ufuk Kayserilioglu가 새로운 ‘소유자’로 추가되었습니다.
- 선의의 인수:
- 주장: RubyGems 오픈 소스 자산 인수는 선의로 이루어졌다.
- 판단: 거짓(False). 저자는 Ruby Central이 RubyGems 오픈 소스 자산을 인수할 권리가 없음을 인지하고 있었다는 증거를 가지고 있다고 주장합니다.
- RubyGems.org는 프로덕션 서비스:
- 주장: RubyGems.org는 단순히 코드가 아니라 프로덕션 서비스이다.
- 판단: 거짓(False). 이 주장은 의도적으로 오해의 소지가 있습니다. RubyGems.org 서비스는 프로덕션 서비스이지만 소스 코드가 아니며, RubyGems.org 오픈 소스 코드는 소스 코드이지만 프로덕션 서비스가 아닙니다.
- 사고 대응 및 핵심 유지보수 지속:
- 주장: 사고 대응 및 핵심 유지보수가 평소와 같이 계속된다.
- 판단: 거짓(False). 많은 운영자를 잃은 상황에서 ‘평소와 같이’ 지속될 수 없으며, 새로운 온콜 로테이션은 RubyGems.org 서비스 운영 경험이 부족합니다. 오픈 소스 프로젝트 유지보수 담당자들이 커밋할 수 없으므로 핵심 유지보수도 평소와 같이 진행될 수 없습니다.