I don’t want to get into the whole debacle around Matt Mullenweg vs. WP Engine as it is covered thoroughly all over the web (see The Verge or TechCrunch for more context). For this post, you just need to know the basics:
- WP Engine is a WordPress hosting service
- WordPress is a open source project under the GPL
- Matt Mullenweg is the original creator of WordPress, CEO of Automattic and Board Member at the WordPress Foundation
- WordPress Foundation holds the WordPress trademark and runs theme and plugin hosting via wordpress.org
- Mullenweg wants WP Engine to purchase a commercial trademark license OR contribute more to the WordPress open source project, otherwise they’d loose access to wordpress.org’s infrastructure and potentially face legal action
There’s currently a significant amount of backlash in the community with some critizicing Mullenweg’s handling of the situation as sudden and quite harsh and as abusing his powers. Personally, I don’t think restricting WP Engine from access to wordpress.org is wrong, but the communication around the whole debate could’ve been handled differently.
Instead of talking about morally using open source, I want to quickly talk about what I believe are deficiencies in WP Engine’s Open Source Risk Management. This case is a very popular and acutally quite atypical example in the open source world, about how over-dependence on one vendor can have a negative impact on your business.
Evaluating Open Source Dependencies
It’s pretty safe to say, that WP Engine knew that their whole business model depends on the WordPress open source project. If you build a business around a single project like this, you better make sure this project doesn’t disappear. This involves determining overall activity of the project by analyzing how many commits are made, how many issues resolved, how many PRs opened and so on. A project with thousands of commits every year and hundereds on PRs closed is way less likely to disappear than a project that gets a couple dozen commits in a year.
But this also involves evaluating legal risks, like license changes towards more restrictive, less open ones. Company-run projects that require Contributor License Agreements (CLAs) to be signed, that give all rights to the company are probably the riskiest here, as the company can decide about the license how they see fit (see Redis).
Other risks include the project disapperaring because a single or a small group of maintainers stop working on it (called the Bus factor or contributor absence factor), this also applies to companies that stop supporting a project. Usually, you also look at code quality and security. To learn more, CHAOSS provides some great resources.
Going further
WP Engine probably did its due diligence in evaluating WordPress in general and came to the conclusion that the project doesn’t have a high risk of vanishing, has a clearly understood open and unchangeable (the amount of contributors makes this virtually impossible) license and it is currently fairly safe to have a strong dependence on the project.
What ultimately caused this issue had nothing to do with any of the WordPress code, but came down to bad business decisions. It is never a good idea to just rely on open source without contributing back to the projects you use. By contributing you are helping making the project more reliable and sustainable for the long term and you can influence the direction of the project somewhat. WP Engine decided not to invest in their most important dependency, probably to save the cost. While the WordPress ecosystem is quite sustainable without WP Engine, it makes them look like a freeloader that profits from open source but gives nothing back – at least to one very important person: Matt Mullenweg.
And this is where another flaw in their risk management comes to light, as WP Engine did not see their use of the WordPress trademark as particualar risky as other hosting providers use the trademark in similar ways. But combined with Mullenweg expecting more contributions and his power in the WordPress Foundation (he is one of just three board members) which controls the trademark, this creates an opportunity for legal action. The same can be said regarding the dependency of all WordPress installations on wordpress.org to get themes and plugins. This resource is unlikely to disappear overnight, as millions of sites depend on it and the WordPress Foundation has a hightened interest in keeping the service available. Restricting access to wordpress.org is just another tool that is available to Mullenweg to nudge or force WP Engine to comply with his requests.
I strongly believe that good Open Source Risk Management involves contributing back to the projects you rely on and to be seen as a generally good community member. It also involves thinking outside the box – the high dependence on not only the WordPress project but also Matt Mullenweg as a person could’ve been caught earlier and maybe lead to decisions like hosting your own plugin and theme mirror. Had they contributed back more from the start, they probably wouldn’t be in the situation they are now and WP Engine could’ve gotten away with less contributions than are demanded by Mullenweg now.
Final comments
While this isn’t the textbook case of ‘Open Source Risk Management could’ve saved you’, I still believe exactly this: good Open Source Risk Management would’ve saved WP Engine from this trouble. It would’ve demanded significant contributions to the one thing their business model depends on.
For a very interesting discussion with one party of this whole tragedy, watch Theo’s interview with Matt Mullenweg on YouTube. Theo also shares ideas for better communicating issues like that with the community to reduce public outcry, which is something a lot of business operating in the open source space should keep in mind.
0 Comments