Paying for the plumbing - How can we get better distribution of the costs of open source?

I just attended a very interesting session at Drupalcon Paris called Paying for the plumbing. It's a panel involving Allie Micka (Advantage Labs), Angie Byron (Lullabot), Karen Stevenson (Lullabot and recently a freelancer), Tiffany Farriss (Palantir relatively new to Drupal but a long lived company), Eric Gunderson (Development Seed).

Some choice quotes on coordination and business of open source

After some introductions and Allie saying that she didn't want to hear the same old tired platitudes (which was a brilliant start to the session) we got into some discussion with the panel and the audience. Here are a few quotes and paraphrases of what people had to say.

Tiffany Farriss of Palantir gave the perspective that we should

Budget in 10% to every project for "patching."

I assume "patching" means communicating with the module maintainer and re-rolling the patch and making it awesome.

Which is a decent point, we do need to kind of just do this as part of our normal business, but that doesn't pay for the big things nor the "plumbing" but just for incremental improvements.

Further, Tiffany said:

Require all your code to be GPL and tell clients you're going to release it and announce it as best you can.

Which is a great point. Drupal.org requires all code hosted there to be licensed GPL Version 2 and later and if your client claims it isn't then there can be big problems for all involved.

Benjamin from Agaric Design Collective said:

We need better coordination tools.

Which is pretty true, and we have a decent tool at Projects Needing Financing. This points out what I think is the real problem of the whole collaboration idea: coordination.

The only way coordination on a feature works for us is when 2 of our customers want the same thing and we do all the work.

Was the perspective of AlexUA from Zivtech, and I tend to mostly agree.

As a shop, get really niche and do $200 worth of work for 3 clients who all pay you $100 each then make it a general product and keep leveraging it and release.

Eric Gunderson from Development Seed took Alex's perspective and turned it into a business strategy. The best way to get into a place to coordinate on your multiple client's needs is if you have similar clients.

Drupal is about scratching your itch, so part of this is that you have to find someone else who has the same itch.

Tiffany Farriss

Coordination Problems

These point out that "paying for the plumbing" is a real coordination problem. What coordination points are there?

• Clear sense of what is being done. That's hard.
• Clear sense of who is the client, who gets a contract, what the terms of the contract are, and what happens if things go wrong.
• Finding other people who are interested in the same problems.

Examples of "solving" these coordination problems

Derek Wright and Chad Phillips of 3281d consulting solve these coordination problems by making an investment in doing the specification for their work up front and making an estimate and then publicly advertising that he will work on the issue. That way prospective clients know what they are getting when they sponsor the work. I've donated to Derek's work in the past and will do it again in the future.

Eric and Alex's point is that the best way to fix coordination is to get all your clients needing something together as clients of one company (or a small set maybe) so that the communication happens with one company and they have existing business relationships (contracts) so that the contracting and payment problems are solved. That solution is mostly only available to larger companies, or small companies who can have a multiple clients (which usually means small ones).

So, we likely haven't had the last conversation on this topic, but at least we can make progress toward better coordination with a variety of solutions.