Distributed Feature Servers in Drupal
Strengthening the Grid of the Drupal Community
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.
Very promising indeed!!!
This is quite true actually!!! Many many times private on the spot builts have come to rescue the day when building a site with Drupal’s underlying framework. And maybe, some of these stuff could be useful to others!!! So, why not just share them along? I believe, the aforementioned approach is the next being thing, that will make Drupal accessible to more people out there!!!! And if you ask me, this is enormous. Very well thought!!!! Well done!!!
Nice work devseed
and nice work Saman Bemel-Benrud..
Looking forward to adding our small shop to the grid..
I remember talking with
I remember talking with Adrian about this in Drupalcon DC on the way back from seeing the Watchmen, good film, brilliant concept. This and Aegir together are going to make a really powerful combo.
Also for what its worth, dont forget about BZR, just as good (or imho better) than GIT ;)
Benefits of being "on the grid"...
This post seems to omit a lot of the very real, tangible advantages to being “on the grid”:
Regarding:
No, they don’t. You can turn off the issue queue on your project if you don’t want to support it. It’s a checkbox on node/X/edit/issues. You don’t even need to make any public-facing releases at all, if you don’t want to. Heck, you don’t even need to make a project page at all — simply keep the code in CVS.
In my view, this mostly comes down to a matter of education. Teaching clients about the real, tangible, cost-saving benefits to embracing the open source model if they’re going to go with an open source platform. That’s the job of each of us who count on open source for our primary source of income.
I’m curious how your next article plans to improve upon the existing system without throwing away all of the strong benefits we currently enjoy from add-on code all being centralized.
Read carefully
Angie – this is automated sharing of recipes and config. Have you tried the Features module yet?
Say Bob creates a great “recipe” with a block that displays a Lightbox-powered login block. He can use features to turn that into lightbox_login.module, which depends on lightbox.module (plus the Features dependencies – Context, etc. etc.).
Only, it’s not really a module. It’s just a bundle of config and exported definitions.
And Bob can share that recipe in a way that anyone can immediately download and enable it.
In many ways, this might be the future evolution of install profiles, which we know are not the answer, but are the answer, today.
Now imagine Lullabot hosting a feature server with all your recipes. Some of them might be public, and some of them might be internal and be how you start projects in the future. Login workflow from Project A, great Photo Gallery from Project B, etc. etc.
For further reference, check out Hoist, which has many things that remind me of this.
Anyway, I think the “don’t use Drupal.org” triggered some reflex answers in your thinking :P Look into this a little further and you’ll see some incredible stuff.
We need GIT first
As we are aimed to not reinvent the wheel and avoid duplication, what about looking at our neighbors? I’m sure GIT is the answer and the future. More about at: www.youtube.com/watch?v=4XpnKHJAok8 and hopeful work in progress http://drupal.org/project/versioncontrol_git
Actually, best of both worlds
Angie, this is why this grid system is all powered on top on Drupal core + contributed modules – it is taking advantage of all of the perks of the network that lead us to Drupal. The dependencies for different features (like the modules needed to power a feature) get all the benefits you are talking about and we enjoy + all the goodness of features that can be passed around.
Features are just meta modules – ie, a bunch of big exported defaults, like views configs, imagecache presets, context types, faceted search environments, cck fields etc.
Positively brilliant
I’m building a drupal-based product right now and this is exactly what I need for my business. I definitely want to start playing with this. Are the “servers” still purely conceptual or is there some code available?
Hey Kyle, There’s more than
Hey Kyle,
There’s more than concepts — do you think we just draw pretty pictures all day? : ) We’ll be posting more later this week.
Ha!
Well. . . judging by how long it’d take me to draw pictures as pretty as yours. . . I might say so :)
Looking forward to your next post.
To set the record straight,
To set the record straight, these awesome concept images are the work of Saman Bemel-Benrud (http://www.flickr.com/photos/samanpwbb) who also went batshit crazy on the illustration for http://openatrium.com.