One of the great things about Rails are the many gems and plugins that help you save time. With its comprehensive public API Rails offers a fertile breeding ground for all kinds of useful abstractions. It's one of the great success stories in plugin architecture, up there with Eclipse, Wordpress and others.

Some of that might change with Rails 3.

You see, a big theme for Rails 3 is framework agnosticism, meaning that you can take the ORM layer, templating engine or another component of Rails and replace it with a framework of your choice.

For the most part, this is awesome. We're already using RSpec, jQuery and Haml in lieu of the default Rails stack and it will be great to integrate those tools without the hacks that used to go with it.

But I'm not sure what will happen to the plugin ecosystem now that a plugin can no longer assume that ActiveRecord is handling the persistence. Where there was once a consistent API to manipulate and hook into the lifecycle of a persistent object, plugins must now perform very careful checks whether an object supports more advanced traits like transactions, observers or dirty attribute tracking.

Take the latest state_machine gem, which comes with adapters for four and a half persistence layers and selectively disables features depending on what ORM is available. While I applaud Aaron Pfeifer for going through the pain of writing all that scary integration glue, a lot of perfectly good code might not get published because the bar for being a good Rails plugin is now so much higher than it used to be.