Every day I'll be doing a round up of the key takeaway points from sessions I attend and supplying you with the hottest Drupal gossip to come out of Drupalcon San Francisco.  

To give you a bit of background, this is the largest Drupalcon ever, with around 3000 attendees.  That's regardless of the fact that many people were unable to attend because of the giant cloud of volcanic ash which is currently shrouding Northern Europe.  I was lucky to get here just before the volcano erupted but unfortunately Leon and Michael are still stuck in UK airspace.  Sorry guys, I hope this blog will be enough of a substitute for the glorious California sunshine :)

In true open source hacker form, Drupalists have routed around the problem and are holding mini-Drupalcon events all over Europe.  If you're stuck in the UK then you'll probably already have heard about DrupalVolCon - http://uk.drupalvolcon.com/

Well, it's been an eventful and surprisingly tiring first day, not least because the supply of free coffee was depleted by 3pm.  Without further ado, here are the sessions I managed to take in:

Dries' Keynote

Perhaps the best keynote from Dries yet, packed with astounding stats, here are some of them:

• Drupal now powers 1% of the web (according to the crawler)
• Drupal powers 2% of the top 1 million sites, Wordpress holds an 8% share
• Joomla & WordPress include custom content types in their latest versions, this has traditionally been a popular advantage of Drupal over either of these alternatives.
• There are still 114 critical bugs left in the D7 issue queue, if we extrapolate the graph of bug fixes, it looks like Drupal 7 will be released somewhere between June and September 2010.
• Drupal 8 will use git!  No more CVS!

Dries showed the richness / reach graph with Drupal in the top right quadrant, of course!  It was interesting to see Jive software in the bottom left, I'm not sure whether that was there when he showed the same graph in Drupalcon Paris, something to do with the recent beef which Jive started with Drupal perhaps?

The Heart of Open Atrium: Context, PURL and Spaces

Young Hahn from Development Seed presented some of the modules which comprise the "hot sauce" in Open Atrium.  For me right now, Development Seed is one of the most forward thinking and pioneering Drupal shops, consistently changing the way in which we use Drupal.

We use Context and Features all the time but Spaces and PURL are just another level of awesomeness.  Spaces allow you to set context and site-wide variables based on where you are within the site, for example it's possible to turn on/off features per organic group.  PURL allows you to store information in the page request that you would commonly have to store in the session, it'll also rewrite all the links within the page to maintain your information in the query string.

The state of Drupal as a Web Application & Product Platform

This is the age of the Drupal-based product, that is clear from the sea of hands which were raised when Alex asked the room "Who here is building a product with Drupal".  The panel of experts from Phase 2, Development Seed, Acquia and Chapter 3 discussed business models, Drupal core as a framework, how to fund building your product and licencing.  It was interesting to hear that Development Seed use the BSD license on all their features.

Deployment BOF (dev - stage - production problem)

The age old Drupal deployment problem of moving content / configuration changes between dev, stage and production environments. chaired by Webenabled.  The same solutions which have been rattling around for years were discussed, people seemed to feel that hook_update_n was still the only solution which, though laborious, works in an enterprise environment.  There was an interesting suggestion to improve this method which was to include the install profile API module in your update hook, and use it's helper functions to perform your config changes, helping you to avoid directly touching the database.

The guys from WebEnabled proposed a macro and Form API based approach, where every form action is captured and can be played back on another site.  Personally I'm not a fan of this approach for the following reasons;  a) it's not reversible, you can't roll back,  b) only changes (or actions to change) are described, so it's impossible to diff the actual state when multiple developer's changes conflict  c) the developer still has to go through a process of deciding which form actions they want to be played back, there is the possibility to miss dependencies here.

I personally feel that effort would be much better spent writing features support for the modules where it is missing.  For me it's exportables all the way!