Features Module, Then, Now, and in the Future

Between the issues queue, Twitter, podcasts, and ad hoc discussions, there is a lot of confusion about what the Features module is all about. As someone that has used and developed in it for a long time, I thought I’d lend my perspective. My sense is the maintainers are on the same page, but don’t hold them to this post.

Then

Features is a module to help site builders and command-line gurus easily package up the configuration associated with a specific use case (like a blog), and manage it in code.

Unfortunately, there is no standard for doing this, so Features develops a mechanism for wrangling exports. This is sad, because it confuses the use case of the Features module itself.

Now

Unless you are active in the Distributions movement or style of site-building, the sense I get is that this is a common thought process for those that run across Features:

I need to toss my configuration into code so I can ship my website around. This Features module things has traction. Darn, the UI sucks, I have to click all these little boxes. And all these info hooks, info alter hooks, and caching layers complicate my day.

Meanwhile, in #drupal-features, a paraphrase:

We totally need to get the exporting out of Features. It adds complexity and attracts all these irrelevant use cases to the issue queue.

Future

The Configuration Management Initiative is exciting. From the perspective of a Features user and developer, it finally defines the standard and mechanism for configuration. That means Features finally has a target for how to pull the out-of-scope pieces out.

After several conversations at DrupalCon, I’m expecting we’ll be seeing a 2.x architectural branch for Features that drops the export stuff. That doesn’t mean it will become an inconsequential module–it turns out capturing use cases in configuration is surprisingly complex. People do not agree on what bits and pieces naturally fall together. But that’s okay, because we are reviving the Kit specification. Expect more from me on that in the future, I think standards like that are key to keeping Drupal intuitive as the Distributions-driven approach to Drupal continues to accelerate.