The framework that manages best, manages least”  or something like that.
Even in the original it didn’t necessarily mean the least amount of government, but that because of the structure, less intervention was required.

This doesn’t directly boil down to simplicity,  but simplicity is the easiest way to reduce management overhead.  That’s why things like wikis, agile programming, and lightweight project management tools like Basecamp are so popular.  But what do you do when complexity is needed?  Fine grained authorization, detailed workflow, complex views, localization, etc. (More on this later.)

A good framework should not have complex configuration, obscure conventions, or rigid patterns.

On the one hand, Rails is very good at this.  You can build sites with Rails without really understand Ruby or Rails.  On the other, it’s very difficult to go outside the Rails box.  Rails has improved, or rather techniques have been learned that make this doable.  For the most common 80% of tasks, though, I’d say Rails sets the standard for getting out of the way.

Rails’ philosophy of “convention over configuration” works in Rails because for the most part, it gets the intuitive part of convention right.  It also benefits from being an early comer (in at least the current round) among frameworks.  Many imitators who diverge do so at their own peril, first because Rails did an exceptionally good job, and second, because “The Rails Way” (good book by the way, by Obie Fernandez.  Don’t think I’m plugging for him though, I don’t know him, but my uninformed personal opinion of him isn’t positive.) has become a de facto standard of comparison with most other frameworks that came after it.

ActiveRecord, however, does a great job at first –it was arguably the defining feature that made Rails popular, but then falls down when you want to go outside the class-is-a-table pattern.  Not saying it blocks you, but it gets in the way.  ActiveRecord is so valuable for prototyping new applications, however, it’s almost a must for a good framework to support it.

I’d argue a good framework should allow things like ActiveRecord, not necessarily support them.  I haven’t yet seen the tool, method, pattern that makes transitioning from ActiveRecord smoothe.

When convention falls down and configuration is needed, then things can get in the way, and perhaps one of Rails’ stumbling blocks is the advanced beginner has had it so easy so far with sensible defaults, that transitioning to manual configuration is as like hitting a wall as hitting the water at high speed can be.  If you weren’t going so fast to start with, you’d slip right into the configuration.  And after something like Struts or Spring IOC, Rails configuration is like slipping into a jacuzzi after a long traffic jam.

Similar story with URLs.  Rails’ page-controller default routing is a thing of beauty, and a true aid to site design all around.  But when the page-is-a-controller metaphor breaks down, it’s a pain.  Probably more because you tend to think that way and choose that as the wrong pattern when you shouldn’t have.  Also, without an easily customizable front controller, pages classes tend to have too much “baked” in, and the complexity is in the wrong place.

The thing I like most about Rails is how well it does “get out of the way”, and the thing I like about CodeIgniter is that it accomplishes it almost as well,  but transparently, and could benefit from some of Rails’ magic.  Which leads to my next requirement for the ideal framework:

Being obvious about what it’s doing.