For some preliminary context, start with this description of “vanilla Drupal” compared to Drupal distros. Note, too, that the Drupal jargon install(ation) profile is technically the same thing as a distribution.

Unless you have the necessary technical staff to package up a distribution / install profile, provide user support questions, regularly update it with new module releases, and push the updates out to users -- and you expect to have that level of staffing available for at least the next 3-5 years -- you’re better off using features to share your configuration work with similar projects. Not only does that free you of the maintenance and support burden for all derivative sites, it also makes it easier for other projects to incorporate your configuration into an existing site, or make more extensive modifications to your original settings based on their needs.

Just because Features is the best option for most digital humanities projects that want to share their configuration within their discipline doesn’t mean that it’s a perfect solution. Here’s a few things you’ll need to keep in mind when creating features.

Features captures vocabularies but not terms

Because Features is designed to capture configuration but not content, out-of-the-box you can export a vocabulary, but it won’t include the terms inside that vocabulary (which Features treats as content).

To get around this, you can use the Features UUID Integration module. Once you install the module with its prerequisites, go to Configuration > Content authoring > UUID Features Integration (/admin/config/content/uuid_features) to select which sorts of things can be exported.

Check the boxes for the vocabularies where you want to export terms, and check the box at the top that reads “Auto detect UUID terms”. Doing that will automatically add terms to any feature you create that includes one of the vocabularies you’ve specified below.

Features captures content types but not nodes

In general, this is a good thing -- you usually want to share your site structure, but the groups that use that structure will have different data. On the other hand, you might want to include some data in the export as an example.

Including nodes in the export works similarly to including terms, except on the UUID Features Integration configuration page (Configuration > Content authoring > UUID Features Integration or /admin/config/content/uuid_features), check the boxes for the content types whose nodes should be available for exporting. Then, when you go to create a feature, there’ll be a new section, “Content”, where you can check the boxes for any of the nodes you want to export.

Features cause problems when doing a major version upgrade

Features packages up configuration as a module that gets installed on another site. The process for doing a major version upgrade involves disabling all non-core modules on your site, doing the core update, and replacing the modules with the equivalent modules for the next version of Drupal. The problem: there’s no new-version equivalent for the custom features you’ve created.

The approach that you end up having to take is to “consolidate” the features by saving them into Drupal’s database, at which point you’re no longer dependent on the module to provide the functionality. The code to make this work is still a little experimental, though there’s a long thread on drupal.org about it. If you have a Drupal 6 site that has features, and you need to upgrade to Drupal 7, I’ve done that successfully using the patches in this thread.