Wednesday, November 21, 2007

Rails Is A Honda, Not An iPod

Apple embraces open-source software, and yet - bizarrely - the company takes a notoriously hostile attitude to users who want to modify Apple products they buy. It took a class-action lawsuit and general outrage to get Steve Jobs to open up the iPhone to developers. If you want to change the battery on your iPod, you're out of luck. It's Steve's way or the highway.



By contrast, the Honda enthusiast community has come up with more options, add-ons, and hacks - for lack of a better word - than anyone besides Ramanujan could ever count.



Based on my own completely unscientific survey of the Rails community, I'm basically certain that more of us own iPhones than heavily customized Hondas. But we ultimately have more in common with the Honda custom community than we do with the community Apple thought they were selling the iPhone to. The disparity between the community Apple thought they were selling to and the community they really were selling to is part of the set of misperceptions which led Apple to think shutting developers and users out of their iPhones wouldn't be a big deal. An interesting topic - but the main thing here is what Rails users have in common with people who want their cars to glow in the dark.



Exhibit A is jRails, a Rails plugin which allows you to swap out all your Prototype and Scriptaculous JavaScript and replace it seamlessly with jQuery JavaScript instead. All your Rails JavaScript helpers remain intact, which means you can migrate from Prototype and Scriptaculous without changing a single line of Ruby code. All you have to change is your custom JavaScript - and that's the whole point of the exercise, because some people prefer to write their custom JavaScript using jQuery.

Exhibit B is auto_migrations, a fantastic Rails plugin which hijacks the entire migrations system and, while keeping it intact, replaces the developer's interface to it - a potentially sprawling mess of individual migration files - with one single, infinitely more elegant, self-migrating schema file. Exhibit C is the discussion in Pat Maddox's blog about how to make ActiveRecord's implementation of Active Record the pattern more consistent with good OOP principles.

The most important piece of evidence is Rails' plugin architecture itself. The whole thing is designed so you can rebuild any piece of it any way you want to. Because he missed this fundamental idea, one Microsoft programmer wrote a post dissing Rails which seemed to almost dip into sheer insanity:

The Rails Team needs to accept that they are now a VENDOR, not radical mavericks.

I responded that Rails core isn't a vendor because nobody's giving them vendor money, and that if you want to change the framework, you've got a flexible plugin architecture and a powerful dynamic language which each make it very easy to do. He replied:

The core point of what you’re addressing here is that "just because people use it, doesn’t mean Rails has any responsibility to people" - I say that’s not so. But we could wave our arms all day about this, and really it comes down to what you’re willing to tolerate as a software provider.

Just think on it for a bit. Your livelihood (if you’re a Rails guy) is resting on this platform... you cool with that?


My opinion, of course, is that my livelihood rests on me, and always will, irrespective of Rails' future, but that's another question. I bring this up because what really caused the disagreement here was a fundamental difference of opinion on what the word "platform" means. Specifically, what kind of responsibility do you have to your users when you provide a platform? Is the way the user uses the platform your decision, or theirs? If you're Apple, you believe that by providing a platform, you take responsibility for pretty much every aspect of the user's experience on that platform. If you're Honda, you take the attitude that if some wacko wants to make their car look like a spaceship, who are you to stop them?



Rails is a platform which is designed to be easy for newbies to get started with and easy for experts to transform, adapt, and bend to their wills. This is something it shares with Ruby - if Ruby lacks a language feature you want, it's often (though not always) pretty easy to add it on somewhere. It's almost even possible to write Ruby in Python. If you want Rails to do something that Rails doesn't do, you have two options: use something else, or make like Tim Allen back when he was funny and rewire that sucker. See what you can make it do.