Free software has to break out of the customer-vendor mindset

I was able to spend some time in the DrupalCon Community Summit yesterday. One of our topics was how a paid ecosystem could align with Drupal core values. We have developers who are not getting paid for the work they do to support their projects, and users who complain about the support they are given as if they had paid for it. Developers feel like users are bad customers because they don't pay, and users feel like developers are bad vendors because they don’t provide support.

In my experience as a free software developer, I have never worked for free. I either developed for myself or I asked others to pay me to develop for them. The reason I participate in free software development is that my work is more valuable to me when others are free to improve it. Free software development means that when a project stops helping me reach my goals I can walk away and wait for someone else to step up and carry it forward. Of course, I do my best to make it easy for someone else to take over because the progress they make may benefit me in the future. Stepping back is difficult when you have become closely identified with your project. But you are not leaving a part of yourself behind. The work that you did will always be part of you, and if you decide to later you can continue it.

Free software development doesn't make sense if it just means users don’t pay. Free software only makes sense when its developers are also users and having more users makes it more valuable to its developers. If users do not participate in developing software, the developers are vendors and the users are customers. If a software project’s developers are going to be vendors rather than users, and its users are going to be customers rather than developers, it should not be provided for free.

The WordPress community has embraced the customer-vendor model. Developers create plugins and themes, and users buy them. The result has been that developers do not have an incentive to encourage users to participate in development, and they do have an incentive to create copycat versions of other developers’ plugins and themes to capture sales. The Drupal community in contrast has embraced a build-what-you-use model, encouraging all users to contribute to the projects that they use in any way they can and share the benefits with everyone. To keep our community healthy, we must replace the customer-vendor mindset with the build-what-you-use mindset.

The build-what-you-use model is not enough to sustain hero developers, who just want to spend more time contributing to Drupal. But in the long run, the community will be better off with a wide contributor base than it would be if it relied on a few heroic contributors. And when the customer-vendor model is a better fit for a project, developers can distribute it independent of the community and users can pay them directly.

Fund raising ideas

Community-led projects still have staff and bills to pay, and new users need support before they can become contributors. So here are some suggestions for how the Drupal community can raise money that are consistent with the build-what-you-use model. The idea is to charge to do for others the same things that we already do for ourselves.

• Audits of Drupal hosting providers. Providers who pay can display a badge certifying their level of support for running Drupal sites.
• Private collaborative development environments. We have already built a public version for the community. We could offer a private version for companies.
• Automated testing. This is available for contributed projects. It could be made available as a paid service for private projects.
• Hosted Drupal. Like simplytest.me, but you can pay to keep your site up and use your own domain name.
• Site management dashboard. Something like a hosted version of Aegir that lets you administer all your Drupal sites, no matter where they are hosted.
• Project status server. This is already provided for contributed projects, but could be a paid service for developers who want to distribute modules and themes only to paying customers.
• Security coverage. Provided free for community projects that opt in to it, but could be made a paid option for private projects.