After my previous post introducing Features, people had some very good questions. How can you share features that you’ve built? And how can other users get your features?

We think the answer to these questions is to use a feature server. At its simplest, a feature server is a website where someone can get features and get updates for those features. It could be a private repository for a network of Drupal sites within an organization, or it could be a public facing site from which anyone can download and add features to their own Drupal website.

Off the grid

One point we wanted to make explicitly is that features shouldn’t only belong on Drupal.org.

Drupal.org is an excellent tool for capturing the work of the Drupal community. But it’s not enough. Despite everything going on there, there is also an enormous amount of off the grid Drupal work. This is work that happens by freelancers, Drupal shops, companies, universities, or other organizations that for a variety of reasons doesn’t make its way back to Drupal.org and get shared with the community. Why is that?

Much of the work going on off the grid is aimed at meeting specific use cases. This has historically been difficult and expensive to capture and share with others. Hopefully Features and other packaging and deployment projects will make this easier.

Drupal.org projects require issue queue maintenance and obligations to a very large audience that are not always appropriate for specific use-case builds.

Not everyone has or can have a radical, open source culture within their organization. The kind of workflow and social norms on Drupal.org often do not jive well with those found in companies, organizations, and other institutions.

There needs to be a way for those operating off the grid to share the work they are doing with others who are interested.

Distributed feature servers, strengthening the grid

Imagine using a feature built specifically for your needs — collecting data for an on-the-ground NGO, courseware for managing a class, or data visualization for your business’s quarterly performance. The feature is maintained by an organization that has very similar needs to yours. On the same site is a different feature built and maintained by a different organization. And all of these are based on solid library modules from Drupal.org.

You should be able to share your features with others on your own feature server. And anyone running a Drupal site should be able to use and pull features from multiple sources, not just Drupal.org.

A distributed model for feature servers will make the Drupal community more flexible, serve more diverse needs, and give us the infrastructure to scale for the next generation of Drupal websites. Later this week we’ll show you what this future could look like.