Towards a Common Ruby definition
When I look at the current situation of Ruby implementations, I find myself in violent agreement with two seemingly conflicting world views:
Brian Ford believes that we should have a standardized design process so that Ruby-the-language is no longer solely defined by Matz’s Ruby Interpreter. Instead, he envisions a cooperative council of implementers who must unanimously agree upon and implement features before they become part of Ruby-the-language. This would help prevent fragmentation of the language, and so it sounds like a good idea to me.
Matz believes that it is his right to remain benevolent dictator for life when it comes to Ruby, and regardless of whether this is what is best for the community or not, I feel he does indeed have that right. Open source achieves freedom through peer pressure and right-to-fork, it is by definition a non-democratic process unless you explicitly make it one. And despite my love for the positive influence that Rubinius and JRuby have had on thinking about Ruby’s future, I do believe that no one knows Ruby’s past (or its core values) more than Matz does, and that counts for something.
In my mind, the way to marry these things is to apply a new and cooperative design process such as the one Brian outlined in detail to something called “Common Ruby” (or another name if using the word Ruby would be contentious). This new label would represent the things that Ruby implementers all unanimously agree upon, and would be the default target for the RubySpec project.
Either by trademark or by convention, only those with representation on the design council would be permitted to label their implementations as “Common Ruby compatible”, and that council would also be responsible for having a transparent (but not necessarily completely open) governance model. Of course, implementers who do not agree with the way “Common Ruby” is defined or designed would have no obligation of participating in the process.
The thing I like about this idea is that it does not require up-front convergence to succeed. Those that like the idea can continue to work on it even if it does not appeal to others. Initially, a lack of endorsement by Matz may hinder the ability for the community to trust the “Common Ruby” designation, and that means that those who supported it may need to work extra hard to champion it. If it is too bureaucratic or conservative, perhaps it will never catch on at all. But if it offers the value it claims it will, then the pressure will be placed on Matz’s Ruby implementation to participate in the process.
Perhaps one day, we’ll be able to use any Ruby implementation with a flag like --common which would help us find areas where we’ve deviated from the cross-implementation definition of the language. This would be useful for those wishing to develop cross-platform applications and libraries. But for now, we could use the RubySpec as our guide, we’d just need to add a new implementation label.
I have to admit that I know little about the details of implementing a programming language, but as someone who has been in this community for a better part of a decade, I figured I’d throw in my two cents in the hopes that they might move the conversation forward. If you have a clear sense of why this idea wouldn’t work or couldn’t, please do leave a comment, even if it’s just a link to a discussion elsewhere. I don’t have a dog in this fight, so I’m happy to consider all angles.
