Ruby Central’s lesson in how not to do it
Last month, Ruby Central made significant changes to the RubyGems enterprise on GitHub, renaming the enterprise and kicking out maintainers. I’m not active in that community, so I can’t judge the reasoning provided by Ruby Central. But that doesn’t matter because even if you take Ruby Central at their word and assume they acted in good faith, the change was executed poorly.
“We want to protect Ruby against supply chain attacks, so we executed a supply chain attack,” is (paraphrased) how I saw someone describe this on social media shortly after the news broke. As an outsider, that’s how I would characterize what happened if I didn’t know better. Changing a name, adding a new owner, kicking a bunch of existing maintainers out? That’s the sort of behavior you would expect from an account takeover.
Where Ruby Central went wrong is handling the process backwards. First they made the change and they they explained it. No matter how good your intentions, explaining after acting will always seem more suspicious. You can’t stop bad faith actors from having a bad faith interpretation of your actions, but there’s no need to give others the chance to go down that road.
Community-driven projects — regardless of whether they’re backed by a corporation or foundation — run on consensus. To make major changes, you have to get buy-in from the core members, at a minimum. This doesn’t mean that everyone needs to agree, but they do have to understand. Trust is easy to lose and hard to build. Changes that destroy trust can permanently damage a community.
Unless there’s an emergency, explanation and discussion must happen before you take action. This includes being honest about the motivation, even if you’d rather not. Honesty and good-faith engagement build trust, which leads to a stronger, more robust community.