Ruby’s Benevolent Dictator

The Ruby Logo

The Ruby Logo

The first version of the Ruby programming language was developed by Yukihiro Matsumoto, better known as “Matz,” in 1995. Since then it has become especially popular for web development thanks to the advent of Rails by DHH. A variety of Ruby implementations have also sprung up, optimized for various uses. You may recall our recent discussion of RubyMotion as a well to develop iOS apps in Ruby. As with human languages, the spread and evolution of computer languages raises an interesting question: how different can two things be and still be the same?

To run with the human language example for a bit, consider the following. My native language is American English. (There are a number of regional variants within the US, so even the fact that American English is a useful category is telling.) I would recognize a British citizen with a cockney accent as a speaker of the same language, even though I would have trouble understanding him or her. I would not, however, recognize a French speaker as someone with whom I shared a language. The latter distinction exists despite the relative similarity between the languages–a shared alphabet, shared roots in Latin, and so on. So who decides whether two languages are the same?

In the case of human languages this is very much an emergent decision, worked out through the behavior of numerous individuals with little conscious thought for their coordination. This is where the human/computer language analogy fails us. The differences between computer languages are discrete, not continuous–there are measurable differences and similarities between any two language implementations, and intermediate steps between one implementation and another might not be viable. So who decides what is Ruby and what is not?

That is the question Brian Shirai raised in a series of posts and a conference talk. As of right now there is no clear process by which the community decides the future of Ruby, or what counts as a legitimate Ruby implementation. Matz is a benevolent dictator–but maybe not for life. His implementation is known to some as MRI–”Matz’s Ruby Implementation,” with the implication that this is just one of many.

Shirai is proposing a process by which the Ruby community could depersonalize such decisions by moving to a decision-making council. This depersonalization of power relations is at the heart of what it means to institutionalize. Shirai’s process consists of seven steps:

  1. Ruby Design Council made up of representatives from any significant Ruby implementation, where significant means able to run a base level of RubySpec (which is to be determined).
  2. A proposal for a Ruby change can be submitted by any member of the Ruby Design Council. If a member of the larger Ruby community wishes to submit a proposal, they must work with a member of the Council.
  3. The proposal must meet the following criteria:
    1. An explanation, written in English, of the change, what use cases or problems motivates the change, how existing libraries, frameworks, or applications may be affected.
    2. Complete documentation, written in English, describing all relevant aspects of the change, including documentation for any specific methods whose behavior changes or behavior of new methods that are added.
    3. RubySpecs that completely describe the behavior of the change.
  4. When the Council is presented with a proposal that meets the above criteria, any member can decide that the proposal fails to make a case that justifies the effort to implement the feature. Such veto must explain in depth why the proposed change is unsuitable for Ruby. The member submitting the proposal can address the deficiencies and resubmit.
  5. If a proposal is accepted for consideration, all Council members must implement the feature so that it passes the RubySpecs provided.
  6. Once all Council members have implemented the feature, the feature can be discussed in concrete terms. Any implementation, platform, or performance concerns can be addressed. Negative or positive impact on existing libraries, frameworks or applications can be clearly and precisely evaluated.
  7. Finally, a vote on the proposed change is taken. Each implementation gets one vote. Only changes that receive approval from all Council members become the definition of Ruby.

Step 3B is a particularly interesting one for students of politics. As you may have guessed, Matz is Japanese. (This is somewhat ironic since Ruby is the currently the most readable language for English speakers–see this example if you don’t believe me.) Many discussions about Ruby take place on Japanese message boards, and some non-Japanese developers have even learned Japanese so that they can participate in these discussions. English is the lingua franca of the international software development community, so Shirai’s proposal makes sense but it is not uncontroversial.

In Shirai’s own words this proposal would provide the Ruby community with a “technology for change.” That is exactly what political institutions are for–organizing the decision-making capacity of a community. This proposal and its eventual acceptance, rejection, or modification by the Ruby community will be interesting for students of politics to keep an eye on, and may be the topic of future posts.

3 thoughts on “Ruby’s Benevolent Dictator

  1. Good thoughts, Matt. I understand the issue at hand and the desire to have a sort of “POSIX-compatible” style descriptor for Ruby.

    But I have a built-in aversion to organizations and processes like this as they tend to slip to the “lowest common denominator” and impede progress rather than accelerate it.

    Also, there are some questions about the approach, such as what constitutes a “significant” Ruby version. If I take Matz’s Ruby and tweak one line, can I call it my own implementation and have a vote?

    - Jamon

    • You raise an important question–one that gets to the root of who gets a seat at the table. I haven’t seen anything on the topic yet that indicates how often the makeup of the council would change or on what basis. If the process were implemented next year, could a new member be added next year? What if a currently “significant” version goes by the wayside some time in the future? From what Shirai has said/written I think he would count JRuby, Rubinius, and MRI as significant versions but I’m not sure what else. This is especially important because of the one-implementation, one-vote proposal (rather than votes based on some measure of popularity, for example). Thanks for contributing to the discussion!

  2. Pingback: JavaScript Politics | You Study Politics, Right?

Comments are closed.