Last week Development Seed launched Open Atrium, an "intranet in a box" that acts as a foundation for developing custom team collaboration and knowledge management tools. Drupal's strength as a framework and its strong developer community are clearly the reasons we love Drupal, but in this post I specifically want to focus on how installation profiles and the Features module have allowed us to create a tight out of the box experience for Open Atrium.
The Open Atrium package for download can be set up through a simple Drupal installation profile. Installation profiles are a mechanism for packaging and deploying Drupal based applications very efficiently. Although they were initially introduced in Drupal 5, there have been a number of factors that have negatively affected the developer acceptance of Installation profiles in the Drupal community. Lots of energy right now is focused on fully unlocking the power and flexibility of installation profiles and subsequently growing the range of Drupal distributions available to Drupal users. With the work on Drupal 7, we are confident we can reduce the learning curve involved in the development of installation profiles and make them simpler to write than ever before. Adrian Rossouw's post titled "Fix some conceptual problems with install profiles and make them actually usable" is the place to go to read about the details.
Now, add the Aegir project into this once you have your installation profile set, and Drupal shops and other organizations could offer a pretty awesome service for clients. We just recorded an example of Aegir being used to squirt out Open Atrium sites to our cloud infrastructure. The Aegir project is entirely open as well and under active development. You can expect it to only keep getting better thanks to the hard work of its contributors.
Open Atrium installs with six "features" out of the box: a blog, a wiki, a calendar, a to-do list, a shoutbox (aka microblog), and a dashboard. What makes Open Atrium really powerful is that you can add additional features yourself. This is all possible because the "Features module" allows you to capture and manage your site configurations in code. Individual features are just meta modules – exported defaults like views, imagecache presets, contexts, content types, cck fields, and so on. To see how features work, you might want to check out this screencast on "Making and Using Features", and read a recent blog post about how exporting configurables can help address basic staging --> deployment issues. We are currently working on documentation on "How to Build a Feature" specifically for Open Atrium.
We think the "feature" thing is a big deal, perhaps most of all because the features paradigm allows for sharing of features that can be turned on easily by end users, rather than offering them a set of modules that require some know-how to set up and configure. In the future, it will be possible for Drupal shops and other organizations to run "feature servers" that allow them to share niche features with the world. Organizations would be able to set up their own feature server behind their firewall to support their internal networks of sites, and they could also go public with those features when ready. The best way to visualize what feature servers might look like is to look at Young's recent blog post on Distributed Feature Servers in Drupal. We also blogged about what it could look like to get a new feature from a feature server.
We will be blogging more about feature servers in the next couple of weeks. If you are working with Open Atrium there is a lot moving over on github, and we're looking forward to seeing you in the issue queue. If you want to get involved, check out the video intro below and download the code here.
Open Atrium started as our own intranet solution about three years ago, and our whole team has worked in different capacities to update and grow it to the point where we realized others could make good use of it too. We have bootstrapped the project all the way through development.