I've been getting inquiries in IRC and in the issue queue about a module I blogged about a few days ago. The blog post I wrote may have seemed that the module we are working on is duplicating the features module and that we should instead work on the features module. I want to clarify our intentions.

The configuration module isn't a replacement for features. The vision is that they could work together. Features currently serves two purposes, 1) to group configuration together to satisfy a certain use-case, and 2) the actual export and management of configuration into a "feature" module. Features module is an awesome module when using it for what it was built for, creating KIT compliant features. The reality is most people that use features probably haven't even read the KIT specification.

Hypothetically, let's use the features concept with the concept of a bakery. Lets say a baker has a feature called "Birthday Cake". This "birthday cake" feature has several ingredients to make a birthday cake and one of those ingredients is called flour. The baker has another system that manages ingredients called configuration. Configuration manages the flour ingredient and makes sure it always stays the same type of flour.

Flour can go in a lot of recipes, not just in birthday cakes, so this ingredient shouldn't be owned by birthday cakes, flour should be free to be in any food item without creating a dependency of needing to bake a birthday cake too. If the birthday cake feature managed the flour ingredient, the baker could never bake cookies with his "Cookies" feature, without also baking a "Birthday Cake". If flour is managed by the "Birthday Cake" feature and the baker decides to never bake birthday cakes again for his bakery, flour no longer exists, because you only have flour if you bake birthday cakes.

If one of the ingredients that configuration is managing ever changes the meaning of flour to mean "spelt flour" rather than what it was, "white flour", the recipes (features) would need to be notified by the configuration system saying that flour is different now and your recipes are now different. This is how they work together.

Ingredients shouldn't care what recipes use it, and recipes shouldn't manage and own individual ingredients exclusively. The ingredients need to be managed by a different system. Ingredients are configurations and recipes are features. Recipes use ingredients, and features could use configuration.

This module simply takes the configuration part out of features, and provides a new workflow for managing configuration, more along the lines of what CMI is going to do in Drupal 8. The vision is the features module could evolve to use this module once this module matures over the coming months. When Drupal 8 comes out, features will need to evolve to not do configuration management any longer anyways, all this will be built into core. Drupal 8 will probably not be released for a while, if it follows the same development cycle as D7, hence the reason why this module was written, to incorporate Drupal 8 configuration management ideas in Drupal 7. Since Features, in a sense, already does configuration management, we used a lot of features module code to build this module.

As CMI progresses and more code is committed for Drupal 8, it's possible that this module may start looking like a back port of CMI and less like a duplication of features module.

Either way, features module will need to evolve eventually.

Features module is a great module when using it for what is was built for, creating KIT compliant features. It's once you start to depart from it's intended use, that you begin to find its limits.