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?

I've spoken out in support of Matt Mullenweg, WordPress, the GPL, and general open source community principles before. It seems like we keep having this discussion, and that it often degenerates into a battle of personalities.

Here's what I continue to believe about licensing and the GPL, which started as a comment on Why the GPL does not apply to Premium WordPress themes, which is part of the #thesiswp running battle. For context, you may also want to watch the Chris Pearson / Matt Mullenweg interview.

Bottom line: Themes and modules are derivatives and should be licensed under the GPL. You can use trademark and other non-code protections that will let you sell them and limit distribution if that is your chosen business model.

The rest of this is the comment I posted.

The way that PHP is executed means that everything runs together in the same space, with no separation (this is a simplification, but essentially correct). So, not the same as the red herring about software apps and operating systems (this comes up all the time).

The Drupal community generally agrees with WordPress in that all themes and modules are derivatives and thus must be licensed as GPL *if* you distribute.

I'm kicking myself because I've been taking far too narrow an interpretation of "an open source approach". I've been focused on getting people to release data. That's the data analogue of tossing code over the wall, and we know it takes more than a tarball on an FTP server to get the benefits of open source. The same is true of data.

Open source discourages laziness (because everyone can see the corners you've cut), it can get bugs fixed or at least identified much faster (many eyes), it promotes collaboration, and it's a great training ground for skills development. I see no reason why open data shouldn't bring the same opportunities to data projects.

And a lot of data projects need these things.

I've been saying for a while that open data is a sort of new frontier. Open source is relatively wide spread and there is a general low hum of understanding about it in many places. For me, I sum it up by saying to people that they need to understand that their "code is worthless".

The next step is coming to understand about open data, and why we should care. Why we should convince people that their "data is worthless".

[Aaron Seigo, leading KDE developer] latest article is one that is of particular interest to the Drupal community, I believe, because as a large, minimally-structured, Open Source development community we face many of the same challenges that other such projects do, such as KDE. In particular, the challenge of who to listen to.

I’ve been joking for years that I’m going to write an email client and charge $500 for it — an email client that actually meets the needs of developers and professionals who rely on email, folks who type for a living.
…

Nevertheless, we need that email client. The only way to get there is via open source: there might be enough interest and energy in the community to make it happen.