layout: post title: Elephants like community ROI too created: 1280685931 categories:

• Drupal tags:
• Drupal Radar
• Capgemini
• community ROI
• Open Source

Steve Parks wrote an article over at Drupal Radar about "elephants" (aka large global IT / services / consulting) shops like Capgemini starting to adopt Drupal and what that means for smaller shops.

Jo Wouters from Krimson left a comment that made a couple of good points. The first part of his comment was that adopting Drupal is a strategic choice, where community was part of the value of adopting Drupal in the first place. I'm quoting the last bit of his comment directly:

Some anecdotal evidence: we are working on a proof of concept for one of the elephants. The spreadsheet they provide us to calculate budgets, has fields for all traditional costs (debugging, project management, contingency, …) and for this project they added an extra field with the label “Community 10%”.

via drupalradar.com by Jo Wouters, Krimson

(emphasis mine)

Budgeting for "community" is absolutely the right thing to do. I've spoken for years about the concept of "Community ROI" (return on investment).

It's very much the language of business - that investing in the community will see a return. Many from the community side find the language of business problematic - we do this because we love it. I've tried to be more pragmatic: having a sustainable business means that you can be funded to continue to do the things you love. In any case, it's clear that these strategic decisions see the value of the community, and see the return in investing in it.

There are, of course, many shops that don't contribute to Drupal. Sorry, writing case studies doesn't cut it - I'm looking for links to patches, module maintainership, contributing handbook documentation, and so on. That, and as I just wrote, actively contributing patches back as part of the client development process. I honestly believe that any shop that doesn't follow community practices as part of developing a site is doing their client a disservice.

Of course, if you don't have experience doing this, it can be hard to get started. Especially, it can be hard to "sell" to clients. One concept I've been tossing around is a line item labeled "Platform Maintenance". If your shop absolutely can't get past the mental hurdle of selling community involvement, then explain to clients that you add (some percentage / some hours) in order to keep their website future proof, secure, more maintainable, etc. Take this time and follow best practices for patching / features for contrib as part of development. Take the time and bundle a module or feature and post it to Drupal.org (the client gets a sponsored by link on the page -- Drupal being a high traffic website, this counts for a lot).

Back to the elephants. We've been lucky to build a critical mass of community before larger players arrived. The Drupal community has always been an ecosystem. There are larger players and smaller players, but we all orbit around the Drupal.org community space. The actions of Capgemini and others are showing that they are stepping up to be part of the ecosystem, which is fantastic. It means, for smaller players, that they need to step up their game when it comes to business planning and other aspects that many have just "grown into".

I'm interested in how you / your shop "sell" Drupal community and/or open source. Many shops have a standard "what is Drupal / why is it awesome", but it tends to focus on features or perhaps low cost. What are the specific open source points that you sell? How do you budget it - do you just work it into your cost, or show line items to clients?

Related to this discussion, I recommend reading The 451 Group blog on enterprise open source. I also really like Stephen Walli's post on Open Source Communities and Customers in Pictures. I've included Stephen's final graphic on how community and sales pipeline for enterprise customers interact: