At ActiveLAMP, we have always been a big proponent for putting all configuration for the sites we work on into features. Much like everyone else in the Drupal community that uses features module, we figure out what configurations belong together, and create a feature to group these configurations together. Do these configurations together satisfy a certain use-case? Sure they do, for the particular site that we created it for, but for the most part, the feature really isn’t reusable on other sites unless we build another site that has the same exact requirements that this feature contains. In reality, we don’t really create reusable features that we can then use on other projects, because the projects we work on are just too different to be able to do this.

The features paradigm works great when you’re working on very similar sites, or even a distribution like Open Atrium, but not so much when working on many different sites that have nothing to do with each other, and many different requirements. When you really get down to it, we really use features module to manage configuration for the specific site we’re working on so that we can simplify deployment to dev, staging and production; we don’t use features to create configurations that satisfy a certain use-case that’s usable on other sites. In fact, I believe many of us in the Drupal community have become so accustomed to using features for configuration management and deployment, we just glaze over why Features module was really created -- to create a collection of Drupal entities which taken together satisfy a certain use-case (excerpt from features module page)

Don’t get me wrong, I love the features module, but I have to admit that I’ve run into my share of issues using features module for configuration management and deployment. Fortunately others in the community have ran into these issues too and have released modules such as features override, features plumber, and Features Tools. Not to mention entire workflows have been created around how to use Features to manage configuration for deployment that don’t even come close to creating KIT compliant features. Features module is really being misused, it’s not being used to create features, it’s being used to manage configuration and deployment.

Several weeks ago, after having multiple conversations with Alan Doucette (dragonwize), of Riot Games, this paradigm shift hit home for me. I had been using features module for configuration management and deployment so long, that I didn’t even think twice that I wasn’t using it for its intended purpose. I also realized that I had a tool belt full of work arounds to make features module kind of work for configuration management and deployment. There are a number of issues that you can run into using Features module for configuration management and deployment. In future blog posts I’ll elaborate on what specific issues we have run into.

After my discussions with Alan I was tasked to create a module just like the features module, except without the features part of it. We still think the features idea is a great idea -- to have a group of configuration to satisfy a certain use-case -- but we don’t think features module should be the tool to export and manage configuration. Our vision is that features evolves into using this configuration module to group configurations into a feature, but not actually own the configuration in a "feature" module.

Over the past few weeks I’ve been rewriting the features module without the features part of it. I’ve also taken a some concepts from the configuration management initiative, specifically the concept of the "activestore" and "datastore" architecture. This module is currently in a sandbox, as we’re hoping to get the namespace of an abandoned project. This module is definitely a work in progress, but we’re already using it on a couple production sites to work out the bugs and workflow. We want to get the community involved to hopefully push this module forward.

If you want to checkout the module, you can download it from the sandbox for now (http://drupal.org/sandbox/tomfriedhof/1412412). Once we get the namespace we’ve requested, we’ll promote it to a full project. Try the module out, file issues, and help out. Alan and I will be giving a BoF at SandCamp this Saturday, for those of you in town. Come join us, and hear about our motivations for building this module, and give us feedback.