A couple of posts ago, I mentioned my concern that Merb could add too much flexibility to the Rails world, and that the abundance of options would increase the barriers to entry for new Rails programmers. Having watched the Rails/Merb 3.0 commits so far, it seems that the aim right now is to fix things rather than add things, a good approach since it should be transparent for new and old Rails developers alike.

Anyway, Josh Susser thinks that we may be facing the issue of too many options and too much to learn already, and he could be right. <blockquote> have enough experience that I don’t have to spend much time pondering. But for someone new to Rails this all must seem pretty intimidating.</blockquote> While I was thinking of framework options, the fact of the matter is that there are already a multitude of options for approaching almost any aspect of a web app in the Rails world now. Java hit this state many years ago – Bruce Tate, a leading light in the Java world who moved to Ruby on Rails, had this to say: <blockquote>Even if you do choose a popular stack such as Spring, your developers must learn potentially dozens of libraries that are specific to a given project. In this case, Java’s core strength, a plethora of libraries, works against it. In contrast, most Ruby developers know Rails.</blockquote> It’s this last sentence that is under threat. In a year or two, Rails development may be just as fractured as Java.

Now options are not a bad thing per se, but many options that are essentially the same add nothing to the game. I’m thinking in particular here of testing, mocking, and fixture replacement solutions, of which there are bucketloads in Ruby right now. As a group we’d probably be better off just letting one of them win and moving on with our lives. For instance, it seems that by-and-large we will all be settling on Passenger as the main deployment platform for the time-being. This is a good thing, and lets us speak in a common deployment language, and allows us to worry about other parts of the tricky business of web development.

Working with common options doesn’t stop new approaches and frameworks from emerging, but they will need to prove to be sufficiently better to make it worthwhile to move, which is a good thing.

All this is to say: it will be very interesting to follow the progress of the Ruby and Rails communities over the next couple of years. With no dominant vendor (such as Sun with Java), organic growth is driven by community needs, but it would be good to see the philosophy of “convention over configuration” rule in most cases.