Drupal Camp

Heads up! Noel Hidalgo has started to organize the first "Drupal Camp", a multi-day intensive Drupal developer training program. (The CivicActions folks are very keen on making this happen as well.)

Every Drupal shop I know of is in a crunch of Drupal development talent. The limit on their ability to take on more and bigger projects is not from lack of sales leads or lack of management capability, it is simply there are not enough seasoned developers on hand to pay to work on Drupal development projects. An experienced and talented web-application developer will take a bit of time to learn Drupal inside and out and get up to speed developing complex websites, so it is not simply a matter of bringing in fresh talent, we need fresh Drupal talent. The Drupal economy is rocketing skyward and this problem will only become more intense in the forseable future. This is an immediate and growing problem that we need to start solving now.


  1. Drupal newbies sponsored by their parent companies (CivicActions, Trellon, etc)
  2. Drupal engineering experts to lead the class. Anyone up for this? :) (Matt Westgate and/or Crunchywelch provided he doesn't drown? Anyone else interested?).
  3. Other Drupal folks in the neighborhood also might want to get together for a code sprint or to discuss Drupal projects.

At Vancouver Josh and I floated out the idea of doing it in conjunction with the Personal Democracy Forum on May 15th. This dates works with me, does it sound reasonable to you?

If we do it in NYC in conjunction with PDF, I can think of two possiblities off the top of my head:

I will follow up with my contacts at both of these venues tomorrow. Does anyone know of another possible venue?


We should make sure that whatever is taugh and learned at "Drupal Camp" is recorded and synthesized for posterity. We want to have many more of these in the future so we should aim for publish-able curriculum that can be later posted on Drupal.org.

Next Steps?

  1. Gregory Heller is organizing a consultant conference call to talk about this and other issues shortly on the consultant mailinglist.
  2. David Geilhufe proposed we look into the former Ars Digita training camps. I'll sign up to follow up and do some research and try to talk to folks involved in organizing them.
  3. We need to figure out a data / location. Unless someone can come up with a better data / location than PDF on May 15th I say let's go with that. I will start looking seriously into venues tomorrow.
  4. We need to line up the teaching staff and get firm commitments from vendors to sponsor newbies. I can take this on starting Friday.


Update: Some folks on the consultant mailinglist are motioning to do a training sooner (next 2-3 weeks) and somewhere less expensive than NYC.

Elgg and Drupal: Benefits to competition?

Bill Fitzgerald from the Elgg project recently responded to my previous post, "Moodle, Elgg, CivicSpace, CiviCRM and Drupal should join forces".

"All in all, it's an interesting idea, but not one I'd get behind. The different apps -- particularly Drupal and Elgg -- have some overlapping functionality, that indicate against joining the projects..... Variety is a good thing. To create a loose metaphor, I see it as akin to genetic variability. Differences within the open source community make us stronger."

Ben Werdmuller, the technical lead on Elgg followed up by saying:

"We're big on integration through open standards and would like to encourage that wherever possible; we're not so big on merging and creating bloated, monolithic systems."

In my experience with CivicSpace, Drupal, and now CiviCRM I have found the opposite of what Bill and Ben have said to be true.

Tight interlocking of open-source projects make us stronger, not differences

  • I can garuntee you that if we had chosen to build CivicSpace as a stand-alone app like Elgg instead of on top of Drupal the project would have failed.
  • At the recent Drupal Con in Vancouver there were well over 100 attendees, many of whom make a living around the platform. By my estimates about nearly a third of those people came to Drupal via the CivicSpace project. While our core code contributions to the Drupal project so far have been pretty modest our evangalizing and community support efforts (like DrupalDocs) have had a notable impact to the Drupal ecology.

Building on the same web-app stack makes for a cleaner implementation

  • If two web applications were not built from the ground up to work together they will not be easily integrated. We've seen numerous efforts in the Drupal community to try to integrate external user / content management applications such as PHPList and Gallery but even though the applications provide unique functionality, the integration difficulties are so intense it is yet to be seen if the effort is worth it in the end.
  • Drupal's succesfull Ecommerce module package is a full blown commerce system that handles all product point of sales, billing, and shipping, and tracking inside Drupal. It is a great example of the avantages afforded by building on the Drupal application framework rather than integrating an external specialized application like OSCommerce.
  • Even with an application like CiviCRM that was built from the ground up to be integrated into CMS's like Drupal it is still very costly to integrate.

Building Elgg independently from Drupal will lead to unnecessary competition instead of collaboration between the two projects

  • Not a single functionality point of Elgg is unique. Drupal + contributed modules can be configured to power a site that does _basically_ what Elgg is designed to do. This means virtually all engineering effort going into Elgg is in duplicate to work done in the Drupal community.
  • Decision makers in Universities IT departments will be forced to choose between adopting Elgg or Drupal instead of being able to invest in a solution that captures the best of both projects.
  • The KDE vs. GNOME battle is a great example of the negative effects of open-source project competition vs. the dramatic recent success of the Ubuntu project built on top of Debian.

Costs of forking

A lot of full time Drupal/CS consultants I've been talking to here in Vancouver have been sharing concerns about how to meet the needs of their clients while still being able to contribute code they development back to the Drupal community. The general assumption is that most clients are oblivious to the mechanics of open-source communities and assume that they are paying simply for an engineer to develop new functionality and ignore all the time required to work with the Drupal community to make sure contributions and patches are accepted and merged back.

I think the simplest solution is to figure out a way to asses costs to forking code that can be communicated to customers upfront when contracts are negotiated.

How about this estimate?

  1. Costs to mantain your own forked module: 25 developer hours X $100 an hour X 2 times a year = $5,000 a year per module.
  2. Open-Source development resources lost: 5 hours per patch X $100 an hour = $500 per patch.

Using these estimates I would think that consultants should be able to justify adding in a line item to their contracts up front to cover their costs to contribute their code back to the community. Do you think this will work?

Supporting Drupal platform development

I am posting from the basement of 800 Robson Center Vancouver BC at the Open Source CMS Summit / DrupalCon 2006. This is without a doubt the most fun work-travel event I've taken part in (I've done more than twenty in the past year). One year ago at the DrupalCon in Vancouver there were about a dozen of us. In Portland six months ago there were thirty or fourty. Today there are well over one hundred Drupaler's in attendance hanging out, learning, hacking, discussing, drinking beer, and scheming for Drupal world domination.

The Drupal software, the user base, and espescially the economy around the platform have seen an explosive growth in the last year. When we started CivicSpace a year and a half ago there were only a few of us who made a living in and around Drupal. Today there are well over one hundred people employed to hack on Drupal between the contract firms and the user-developer base. With a little napkin math I estimate that in a year the Drupal economy has grown from ~$500K a year (10 X $50K) to well over $5M a year!

Despite this phenominal growth I have some concerns about what the next year holds in store for the Drupal platform and the community around it. As I see it, most of the value created by the Drupal community that vendors and consultants rely on to sell as services to customers come from unpaid core contributions. Examples of this are the majority of 4.7 improvements: multiple block regions, new forms API, installer work - these were all unpaid contributions to the community by volunteers or pro-bono work from Drupal firms. At the same time, many of the seasoned Drupal core hackers are getting job offers left and right to come and do Drupal consulting full time. This is creating a scenario in which while many more people are paying their bills through Drupal hacking and more and more business are built around business value created by the Drupal community, it is not getting any easier to make sure the heavy lifting on core work is getting done. For example: I know of no funding availiable to support key Drupal core projects such as continued forms API work, actions & workflows development, CCK, and most importantly; usability improvements.

In the next year I am expecting the economy around Drupal to continue on it's fantastic pace. I would not be surprised if by 2007 the economy was well over $20M annually. My big question here in Vancouver is: What can we do now to make sure that some of the money coming into the community over the next year is put back in to supporting the core work that we as a community are relying on?

Moodle, Elgg, CivicSpace, CiviCRM and Drupal should join forces


  • save development effort across projects
  • collaborate on fundraising, marketing, etc.
  • deliver complete solution across application domains on one web framework: CMS, CRM, Course Ware, and Social Apps


  • Phase 1: light integration (single sign on / common installer / unified interface)
  • Phase 2: Leverage Drupal frame-work as appropriate

It will work because

  • Funders love joint projects
  • LAMP is way cheaper than JSP/J2EE
  • This is exactly what CTO's / CIO's at Universities want
  • We have the community! (Drupal: 55,000, Moodle: 8,900, CivicSpace: 2,000 installs)


  • Sakai / uPortal / OSPI
  • CivicSpace / Drupal / CiviCRM


  • application integration
  • business models


  1. Project leads sign on
  2. Line up University partners (some paying members)
  3. Get industry partners to back project
  4. Merge fundraising targets
  5. Raise seed round from private donors to investigate
  6. Create prototype integration
  7. Raise real money from foundations
  8. Execute
  9. Win

What does it take to make Drupal easy to use?

Dries, the founder and lead developer of Drupal, just posted this on his weblog:

For long I focused, completely and utterly, on the aesthetics of Drupal's code, neglecting eye candy and ease of use. I spent days trying to do something better, with fewer lines of code and more elegant than elsewhere. The aesthetics of Drupal's clean code has attracted many developers, but has also given Drupal the reputation of being developer-centric and hard to use.


For Drupal to remain competitive in the future,

  1. we'll have to offer critical functionality not available in other content management systems, or
  2. we'll have to make Drupal easier to use and improve the aesthetics of Drupal's user interface design, and
  3. we have to maintain the aesthetics of Drupal's code.

As other systems are catching up in terms of critical functionality and because the amount of critical functionality is limited, we have little control over (1). Hence, we should focus on (2) and (3). To grow the number of users we should focus on (2) and to grow the number of developers we should focus on (3). Because the ability to make changes to Drupal's code is restricted, we can easily enforce (3). That pretty much leaves us with (2) to worry about

First reaction after reading this: Yes! Yes! Yes! (and more yes!)
Second reaction: Ok, but how?

The potential for Drupal's success on the web is staggering. If Drupal can rock all three: offer all critical functionality in an easy to use package built on a beautifully constructed and extensible framework - it will compete on a level no web-platform currently can.

But #2 seems to be the sticking point. For every message that goes by on the developers list or every CVS commit what percentage come from someone with training in usability? For every thought or effort that goes into building a new feature, what goes into trying to make sure someone can figure out how to use it?

Very succesful consumer mass market organicaly grown open-source applications are extremely few and far between. Heck, maybe they don't even even exist yet come to think of it. Firefox is just now nearing 10% market share, and they've had helping hands with pretty deep pockets since the start. Wordpress has big install base, but their blogtool market share is a relatively small slice so far, and their slice of all internet publishing tools is vastly smaller.

But more troubling, both these applications are - relative to drupal - in much more well defined application spaces. By the time FireFox came around browsers had been used for 10 years. Likewise, when WordPress was started blogging tools were well understood and are pretty straight forward and simple applications. But Drupal is off the map - innovating on many fronts at once. For code development this works out ok, developers simply adhere to Dries's oversight or their code doesn't get checked in. But for making the interfaces easy to use and aesthetically pleasing? That is hard work I don't think the Drupal community has the expertise to pull off currently.

But we certainly can get a lot farther along than we are right now. The before and after photos are impressive, Drupal has come a long way in a fairly short amount of time. Dries' consistant insight has gotten Drupal to where it is today. Just as Blake Ross' commitment to making a browser for his grandma turned Mozilla into FireFox and Matt's comitment to aesthetics and usability made WordPress into a work of art, Dries' commitment to making Drupal usable is a pre-requisite for what it takes to transition Drupal from a powerful gadget into a pervasive utility.

But Dries is going to need a lot of assistance. How can we help?

Here are some options that I see...

  1. Rally the troops: consistantly press on Drupal developers to contribute interface and usability improvements. Make it a chief objective of each point release. Dries is already doing quite a bit of this.
  2. Find allies: figure out a process for better integrating outside usability oversight and go find usability experts to contribute back to drupal pro-bono. Kieran is pursuing this.
  3. Hire mercanaries: go raise money to employee usability experts and interface engineers to reshape Drupal's interface. I will soon be in a position to pursue this.
  4. Clone Steven Wittens en masse: any takers?
Syndicate content