Open source: you’re doing it wrong

If you like my WordPress work, check out my new plugin, Bylines. Thanks!

Yesterday, I let my emotions out on Twitter:

Ugh.

Seems like people only want to use open source for free. When it comes to paying for support or fixing bugs, no one sees the value.

So many good projects on Github living semi-abandoned, decrepit lives because there’s no economic model for maintaining them.

Feeling quite discouraged right now 🙁

For the last several months, I’ve been slowly, steadily working to solve this problem with runcommand (albeit in a limited domain, WP-CLI commands). Eventually, I’d like for runcommand to become a healthy, for-profit company, with an entire team to work on these two problems:

  • Provide ongoing maintenance and general improvements to existing infrastructure many businesses depend upon.
  • Collaboratively create new features, to reduce the development and maintenance burden for those who use it.

"Sparks" is my first iteration on the collaborative roadmap concept.

For instance, every single managed WordPress hosting company would benefit from a diagnostic tool for WordPress sites, yet none of them have invested in an open source solution because the cost of maintenance is too high (one actually started a project but hasn’t improved it much over time). Similarly, every single WordPress agency would benefit from a Drupal migration command, yet none of them have open-sourced their internal abstraction because the cost-benefit ratio makes zero sense.

The key idea behind Sparks is to create a space where WordPress-based businesses can contribute to an open source roadmap, collaboratively prioritize, and then share the cost of development and maintenance. I see this as a huge opportunity for businesses predicated on access to reliable open source software.

As I mentioned in my WCEU presentation, Nadia Eghbal is doing wonderful research into the economics of open source. She’s even put together a Github-based guide to financial support for open source projects. I’d like to highlight a passage from her kickoff post:

Most developer tools have nothing to charge for, and are not big or centrally organized enough to get venture or corporate funding. Projects that we use, or indirectly benefit from, every day. (Every app on your phone right now is using one of these projects in its software. I guarantee it.)

In other words, everybody is building software, but ignoring the tools we need to build them.

To support that, a couple of thoughts:

  1. There is an enormous disconnect between project owners and their stakeholders. Every open source developer I spoke to thought there was a “funding problem”, even if there was disagreement about how to fix it. But hardly any founder, VC, or big tech employee was aware of the issue, even when they used or benefitted directly from these projects.
  2. This is a relatively new problem. Open source has been around for 30 years. It worked well in the early days, but from 2008–2013, GitHub and Stack Overflow made it go hockey stick. Today, more people use open source, but fewer people contribute back, than ever before. And everybody assumes that somebody else is doing it. (This is also known as the “free rider problem”. Left unchecked, it leads to a tragedy of the commons.)

What could go wrong? Well, this, or this, or this. People getting burned out and quitting. Bugs or security vulnerabilities that go undetected. But also, people just making less stuff. Society moving a little more slowly.

The better we make open source, the better we make technology as a whole. When we have really good tools, it’s easier for everybody to use them to do creative and interesting things.

The pricing aspect of runcommand’s hybrid support and custom development model has been a tougher sell than I expected. I don’t yet have a one-line answer to "what development effort do I get for my money?". I’ve thought long and hard about the idea that each pricing tier gets you a certain amount of votes on Sparks. But, a voting mechanism implies a certain number of votes are required for each Spark, which implies level of effort estimations and harder to manage expectations. Plus, the price doesn’t just go towards development of new features, it goes towards everything else too.

Ultimately, I know this is a positioning issue — not one of the idea itself. When I explain the concept of Sparks to a prospective customer, they get it. It makes a ton of sense to share the burden of building and maintaining boring, business-critical infrastructure. High-touch support and custom development is expensive though, which makes it challenging to offer more affordable pricing options. But I also know that phrased differently (props to Tim Dobson), businesses would willingly pay hundreds or thousands of dollars for solutions to some of the problems on the roadmap. And the cost of building and maintaining any of these solutions in-house is easily tens of thousands of dollars.

Just so it’s stated, philosophically I believe commercial enterprise can be an enabler of healthy open source communities. The problem with patronage is that it’s very hard to get a "real" amount of money; I, for one, can’t pay my mortgage on $500/month. Patronage also sets the precedent that you should be a martyr. I think maintaining open source should be profitable.

If you think open source is building your business on semi-abandoned or poorly-maintained public code, you’re doing it wrong.

Every single managed WordPress hosting company is spending tens of thousands of dollars right now to build an automated testing solution for WordPress plugin updates. What if they didn’t have to internalize the cost, but had a means to work together on a common solution? Or, what if those plugin updates were trustworthy in the first place, because each plugin was reliably maintained and supported? The WordPress.org plugins directory has clearly become a tragedy of the commons; WP-CLI, and open source broadly, doesn’t need to be.

Think WP-CLI is cool now? You haven’t seen anything yet. Let’s work on these impossible problems, together.