What Can Go Wrong in an Open Source Project?

WooCommerce is an open source project. Yeah, I know, we all know that. But in a conversation we had with Matt Mullenweg, it was asked, what can go wrong in an open source project.

It Starts with Something That Inhibits the Next Stage of Growth

You can have a version of regulatory capture where what made the project successful inhibits it from reaching the next stage of growth. Maybe some historical examples from other open source projects. I feel like it was tough in the early days for Drupal to get the ease of use and really focus on that end-user usability because so much of its early success created these really big agencies that made all their money building huge Drupal sites to make their model work with six figures or higher to deploy the site, so this was fantastic.

There were lots of really high-end Drupal sites created, but their business model just didn’t support a 10K site or 1K site and there were also a lot of contributors, so they never really had an incentive. So like make it easy-to-build that 100K for 1K. With us, coming from the other end, we’re incentivized to do that and we did do that. It looks like that will cost you half a million dollars 15 years ago, you can now build it with a theme for WordPress, which is kind of wild. So you get these incentive structures.

Maybe Joomla is another one where they have this third-party, paid plugin system that strongly encouraged people to do those, but discouraged different developers from working together and solving the same thing. They would each create their own version of sitemaps or something. And as a user, then all of a sudden you’re being nickeled and dimed where you’re like, “Okay, I just want a sitemap, which $5 thing do I buy?” And you may have to buy 20 other things to do something. We have to be careful of that with Woo, which has a lot of commercial extensions.

What you create as incentives over time can prevent you from reaching the next stage. But to avoid that, what we do in WordPress is one, we try to avoid committees wherever possible. Almost nothing great has ever been created by a committee, so we try to give people autonomy, ownership and accountability, right? You’re in charge of XYZ, be in charge of it and let’s see how that goes and if it doesn’t work out, we’ll put someone else in charge of it. But I’m not going to just create and cover my butt with a committee of 10 people voting on every single change and end up getting the lowest common denominator. You’re not going to create great software that way.

And then being very close to users. So, we always have. Woo is very much a developer product today, but our aspiration is to make it easier for users, which by the way, will get developers a ton of more work just like we did for WordPress. So this is again, one of these flywheels that if you’re not careful, we said, Woo is just for developers forever, like that would get here, and then it will stay there forever and then probably start declining. But by saying we really want to radically open up the audiences that use Woo, it then also makes what is the audience for developers to build things for much larger down the road.

You can listen to the full episode here.