Drupal and Feature Portability

How do you build a feature that is going to work on any Drupal website? The question is more complex than it seems, and there is an important discussion going on around it in the Drupal community. It's playing out in a number of different areas where smaller groups of developers seek to leverage features as a tool for sharing functionality, and this issue is going to have an impact on the way people think about building websites over time.

For those of you who work with features regularly, this conversation is about building small, useful applications that can be added to any Drupal website to extend its functionality. It goes beyond packaging up a bunch of presets to move code between test and production environments, or bundling a set of features that are going to work together as part of a single distribution. The common idea people seem to be wrestling with is how to build features that will reliably work together regardless of where they are deployed, and ensuring they will not conflict with others people might be building.

Nejo Rogers from Chocolate Lily wrote a great article about code portability back in July 2012 that summarizes some of the different approaches to this problem, and the challenges that come along with each one. Basically, the standard approaches to the problem are apps, distributions and writing standards around compliance. You can read about the benefits and limitations to each approach over there. Suffice to say, there is no solution that completely addresses the issue of portability in a manner that is free from conflict.

Part of the reason this is such a tough challenge to deal with has to do with the standard ways we think about application development. When bundling a feature, you get into questions about how data is stored, how the interfaces will work, and business logic associated with the code. If you are doing some really fancy with custom entity types or integration with external services, the feature itself gets a lot more complex. No one really builds features the way they build modules - the standard practice is to bundle content types (along with their fields), various displays, and other elements together into a single package that is then ready for distribution.

There are some the ways this can break down, which might not be obvious when someone is packaging a feature. These are the kinds of questions various groups are trying to tackle. Let's say we are building a feature around timekeeping, it has its own content types, and it ships with various interfaces built around contexts and panels. You can run into issues that break the portability chain in situations like this:

• The feature is useful, but the interfaces aren't going to work in my use-case. How can I just get the entities?
• I have this other content type called timekeeping, and it does something entirely different. How do I reconcile the very similar content types?
• I have a bunch of fields that share names with the ones used in timekeeping content types. How do I keep the conflict from affecting my site?
• The feature requires some fields to be configured on other content types. How can I build portable features if I don't know if the other fields will be there?

When any of these issues affect a site, portability is lost and suddenly developers are dealing with questions of integration and customization. Some of them can be easy to deal with, others not so much. They all have the potential to create situations where a feature is only as useful as the day it was installed, as customizations can make it very hard (if not impossible) to upgrade a feature over time.

Groups are starting to spring up, where developers are looking to build communities of practice for building Drupal sites using features based approaches. They are concerned with using features as a tool for more efficient web application development, where questions around portability of code are key to their success. Many of these groups are focused on niche use cases that may not affect the way everyone wants to work with Drupal, but the way they are addressing the issue is important to pay attention to.

For example, this is happening at Stanford University, where Drupal is becoming a standard platform for web application development. Ease of use and code portability concerns are important there for reasons going beyond supporting a single cluster of sites, they affect how people perceive the viability of the platform. Some of the people working on the problem aspire to build communities that go beyond the boundaries of a single institution. Check out the Drupalcon session that talks about his vision for building an education consortium around the use of portable features.

I happen to know Zach and am familiar with his approach for dealing with the question of code portability. It's a standards-based approach that draws from the Kit standards for feature development and extends it in some important ways. While his efforts in this area are just ramping up, it's going to be useful to watch the way this comes about. His group's efforts are important as an example of breaking down institutional boundaries and leveraging the work of a larger community in an area that could really benefit from some innovation.

Trellon deals with this as well. We recently released the first stable version of CRM Core, which incorporates some good approaches to portability and feature sharing within Drupal websites. The next step for us is to build a community that shares features around the module, and we have run into all kinds of questions about best practices for how to deal with issues around portability. There are some best practices listed over on Drupal.org that haven't reached the point of becoming standards, but are on their way to getting there. In this case, we are dealing with thoughtful ways for how to work around a set of common entities that can be deployed in a lot of different ways. Some of the solutions are obvious, others are really counter-intuitive and not what you would consider when architecting a solution unless you really took the time to think through the issue.

It seems like the Drupal community is on the road towards dealing effectively with the question of portability in features, there is a lot of promise as well as questions for how things will be worked out. What is important to recognize in the cases of Stanford and CRM Core is that these approaches are built around standards for how a community would share features. The way I think about standards is they are an operator solution to a problem that has yet to be tackled by technological means. The work of each of these communities deals with them is instructive in terms of the kinds of challenges the greater Drupal community has yet to tackle.