Ruby Central’s Attack On RubyGems 🔗 **Source:** [Ruby Central’s Attack On RubyGems](https://pup-e.com/goodbye-rubygems.pdf?ref=404media.co) > [!note]+ Document Notes > ```markdown > > --- > tags: [open-source-governance, RubyGems, community] > author: [Ellen Dash] > source: [pup-e.com] > reference: [https://pup-e.com/goodbye-rubygems.pdf?ref=404media.co] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > --- > > # 🏷️ Title: Ruby Central’s Attack On RubyGems > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - A maintainer renamed the GitHub org and removed maintainers. - Ruby Central’s leader gained owner status on GitHub. - Access was revoked again days later. - The author resigned on September 19, 2025. - Why it matters. - Control of core Ruby tooling shifted without consent. - Trust, security, and governance are at risk. - Key stakeholders. - RubyGems, Bundler, Ruby Central, maintainers, Ruby developers. - Risks and tradeoffs. - Centralized control can speed decisions. - It also increases capture and abuse risks. - Bottom line. - The author alleges a hostile takeover with repeated overreach. ## 📖 Main Content - Explain the core arguments in plain language. - The author reports unilateral permission changes on GitHub. - The changes removed long-time maintainers without notice. - A later “restoration” preserved new owner control. - A second removal reinforced the power shift. - The author labels this a hostile takeover. - Add sourced context and define terms. - RubyGems and Bundler are critical Ruby package tools. - Governance policies define decision rights and escalation. - The author cites Homebrew’s governance as a model. - Note uncertainties or contested claims. - We lack Ruby Central’s full incident timeline. - We have limited logs or forensic evidence publicly available. - The PDF states Marty called changes a “mistake.” - Independent verification remains limited so far. ### 🗒️ Notes - The author is a decade-long RubyGems maintainer. - The report covers September 9–19, 2025. - Initial actions: - Org renamed to “Ruby Central.” - Non-maintainer gained access. - Other maintainers were removed. - Partial rollback occurred after pushback. - New owner access remained after rollback. - Maintainers began drafting governance policy. - A second revocation removed admin access. - Access to key gems was also revoked. - The author resigned immediately. - The author frames this as not in good faith. ## 📚 References - Ruby Central’s Attack on RubyGems (original PDF) (https://pup-e.com/goodbye-rubygems.pdf?ref=404media.co) - RubyGems.org project overview (https://rubygems.org/pages/about) - Bundler project site (https://bundler.io/) - Homebrew governance model (https://docs.brew.sh/Homebrew-Governance) - Ruby Central organization site (https://rubycentral.org/) - GitHub organization: rubygems (access may vary) (https://github.com/rubygems) ## 🗣️ Paraphrase - Paragraph A paraphrase. - The maintainer changed org settings without warning and removed peers. - Leadership retained new owner rights after a partial rollback. - Paragraph B paraphrase. - Leadership again revoked access and took control of key gems. - The author calls this a hostile takeover and resigns. ## 📰 Newsletter - This week in OSS governance, RubyGems faced leadership turmoil. - Maintainer access changed twice within ten days. - The incident raises trust and security concerns for developers. - WordPress can learn from this event. - Publish clear governance and incident processes. - Consider lessons from the Homebrew model. - See background on RubyGems and Bundler. ## ✅ Action Items - DevRel - Publish a neutral incident explainer for developers. - Offer office hours on governance and access controls. - Developer advocacy: plans, talks, demos, and measurable outcomes. - Run a talk on “Maintainer Access as Critical Infrastructure.” - Track reach, feedback, and follow-up issues. - Education: workshops, curricula, office hours, mentorship programs. - Create a workshop on GitHub org security practices. - Offer mentorship on governance design. - Developer experience: docs, SDKs, examples, templates, quickstarts. - Provide templates for access policies and rotations. - Add examples for incident response runbooks. - Developer marketing: campaigns, content, funnels, and attribution. - Launch a series on OSS governance basics. - Attribute engagement by org and role. - Community management: moderation, code of conduct ops, surveys. - Survey maintainers on access pain points. - Tighten moderation for incident threads. - Internal/external/cross-project: align goals, SLAs, and feedback loops. - Define SLAs for permission requests and removals. - Establish escalation paths across teams. - OSPO - Policy & Governance: contribution policies, decision rights, charters. - Publish charters and decision matrices. - Define consent and quorum thresholds. - License Compliance: policies, scanning, review, and training cadence. - Maintain license scanning pipelines. - Schedule quarterly compliance refreshers. - Security Management: vuln intake, embargo policy, signing, attestations. - Adopt signing for releases and org-level attestations. - Document embargo rules and timelines. - Software Inventory: SBOM strategy, ownership, freshness SLOs. - Require SBOMs for critical dependencies. - Track freshness and owners in dashboards. - Developer Support: training, tooling, legal guardrails, consultation hours. - Offer access-control tooling guidance. - Set legal review office hours. - Community Engagement: upstream funding, MoUs, operator agreements. - Use MoUs for governance and control boundaries. - Tie funding to transparency milestones. - Strategic Alignment: KPIs, OKRs, executive reporting, initiative roadmaps. - Report governance health KPIs quarterly. - Maintain an access risks register. - Community - Maintainers: roadmap clinics, governance templates, release hygiene. - Host clinics on owner rotations and backups. - Contributors: onboarding paths, “first issue” rotations, pairing sessions. - Clarify access prerequisites and sponsor roles. - Sponsors: transparent budgets, milestones, deliverables, impact reports. - Require incident transparency clauses. - Ecosystem: cross-project incident drills and coordinated disclosures. - Run joint tabletop exercises twice yearly. - WordPress - Core: priorities, issue triage, performance budgets, release criteria. - Add maintainer-of-record and backup roles. - Core Performance: profiling plans, metrics dashboards, perf bounties. - Gate bounties with governance compliance. - Core AI: responsible AI guardrails, evaluation sets, pilot projects. - Track model and dataset provenance in SBOMs. - Core Program: coordination rituals, cross-team dependencies, retrospectives. - Include access control reviews in retros. - Mobile: app backlog, telemetry review, offline UX improvements. - Audit release signing and key custody. - Playground: browser labs, reproducible bugs, education modules. - Provide governance labs and fixtures. - Community: meetup kits, WordCamp playbooks, speaker mentorship. - Add talks on org security and governance. - Training: lesson plans, learning paths, certification pilots. - Offer a “Governance 101” path. - Marketing: campaigns, narratives, social editorial calendars. - Spotlight governance success stories. - Support: response SLAs, knowledge base gaps, escalation paths. - Document permission recovery steps. - Design: UX audits, design tokens, research backlogs. - Add admin audit trails to design reviews. - Documentation: DevHub/HelpHub gaps, examples-first patterns, style guide. - Publish incident templates and checklists. - Photos: content drives, moderation guidelines, taxonomy hygiene. - Curate visuals for governance materials. - TV: submission guides, caption quality, content indexing. - Record short governance primers. - Polyglots: translation sprints, glossary alignment, locale coverage. - Translate governance docs early. - Accessibility: WCAG reviews, tooling, issues heatmap, audits cadence. - Ensure governance docs meet WCAG. - Meta: .org roadmap, API reliability, contributor tools. - Provide audit logs for privileged actions. - CLI: command coverage, UX docs, plugin scaffolds, smoke tests. - Add “who-has-perms” commands and reports. - Hosting: cross-host checklists, defaults, telemetry for reliability. - Standardize access rotations and emergency contacts. - Tide: scoring transparency, false-positive review loops, plugin outreach. - Include governance signals in scoring. - Openverse: ingestion pipelines, moderation policy, education tie-ins. - Define content escalation rights clearly. - Themes: review throughput, lints, mentoring, test matrices. - Separate reviewer rights from org owners. - Plugins: review throughput, security liaisons, provenance checks. - Require signed releases and owner backups. - The WPCC - Programs: fellowship tracks, microgrants, maintainer stipends. - Fund governance and security sprints. - Projects: governance clinics, documentation sprints, release teams. - Offer clinics on charters and MoUs. - Funding experiments: matched grants, milestone payouts, transparent ledgers. - Tie payouts to governance milestones. - FAIR - Technical independence: local metadata, provenance, and signature checks. - Maintain verifiable provenance for releases. - Policies and covenants: funding transparency, sunset clauses, anti-capture. - Add anti-capture clauses to agreements. - Productized governance artifacts: charters, operator agreements, scorecards. - Publish reusable governance scorecards. ## 🧪 Hypotheses - Transparent charters reduce unilateral access changes. - Owner rotations lower capture risk for OSS orgs. - Signed releases increase trust after governance disputes. - Public incident reports improve stakeholder confidence. - MoUs reduce scope creep by fiscal sponsors. ### 📊 Methodology - Study designs, data sources, and analyses to test the hypotheses. - Run controlled audits across OSS orgs with and without charters. - Compare incident rates pre/post charter adoption. - Survey developer trust after signed releases. - Analyze MoU presence versus dispute frequency. - Use mixed methods with repo logs and surveys. ### ❓ Questions - What logs corroborate the permission changes? - What due process existed for removals? - What constraints limit sponsor control? - How should ownership rotate safely? ### 🔮 Future Research - Model optimal owner-to-maintainer ratios. - Define minimum viable governance artifacts. - Measure recovery times after access disputes. ### 💡 Implications - Practice: adopt charters, rotations, and runbooks. - Policy: require MoUs for governance boundaries. - Security: sign releases and audit privileged actions. - Education: teach access management as infrastructure. - Funding: tie grants to transparency deliverables. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~8–9. - Visual learners - Present: simple timeline in prose. - Improve: timeline and RACI diagrams. - Aural learners - Present: none. - Improve: 3-minute narrated summary. - Verbal learners - Present: definitions and examples. - Improve: glossary and term contrasts. - Kinesthetic learners - Present: none. - Improve: governance lab exercises. - Logical learners - Present: sequence of events and claims. - Improve: decision trees and metrics. - Social learners - Present: community framing. - Improve: moderated Q&A sessions. - Solitary learners - Present: reflective stance. - Improve: journaling prompts. - Naturalistic learners - Present: limited. - Improve: ecosystem risk analogies. ### 📊 Accessibility Assessment - Screen reader semantics - Present: clear headings. - Improve: structured landmarks and alt text if images exist. - Keyboard navigation - Present: not applicable to PDF text alone. - Improve: tagged PDF and logical order. - Contrast and readability - Present: depends on PDF styling. - Improve: ensure 4.5:1 contrast and spacing. - Text resizing and reflow - Present: unknown for original PDF. - Improve: provide HTML version with reflow. - Media and captions - Present: text only. - Improve: audio narration and transcript download. - Forms and interactions - Present: none. - Improve: accessible feedback form. - Standards reference - Map gaps to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment - Cultural breadth - Present: global OSS relevance. - Improve: multi-region maintainer perspectives. - Inclusive language - Present: mostly neutral and direct. - Improve: add plain-language summaries. - Neurodiversity support - Present: chunked sections. - Improve: consistent summaries and icons with text. - Representation - Present: maintainer viewpoint. - Improve: balance with diverse stakeholder quotes. - Psychological safety - Present: respectful but urgent framing. - Improve: community guidelines for discussion. ### ✅ Logical Validity - Strong reasoning - Inductive: repeated access removals imply pattern. - Causal: permission changes led to control shift. - Explain why each is strong and how to clarify further. - Evidence aligns with a timeline and actions. - Add logs and confirmations to strengthen claims. - Fallacies - Possible hasty generalization risk. - Propose a fix: include corroborating statements. - Tone of voice - Urgent, assertive, and personal. - Uses clear, direct statements. ### 🛡️ DARVO Analysis - Deny - “Mistake” language minimizes the action’s severity. - Attack - No direct personal attacks are presented here. - Reverse victim/offender - Framing could imply leadership as careless, not malicious. - The author positions maintainers as harmed parties. - Include emotional cues, rhetoric, and any related fallacies. - Strong wording signals breach and distrust. ## 🎯 Conclusion - Restate the bottom line. - The author reports power consolidation over Ruby tooling. - Actions occurred twice and eroded trust. - Note practical next steps for readers. - Publish charters and MoUs. - Rotate owners and log permissions. - Sign releases and report incidents. - Fund governance work via The WPCC programs. ``` <!-- deep-read:sections end -->