Tag: open source

Matt Mullenweg v. WP Engine

Automattic CEO and WordPress co-developer Matt Mullenweg published a post on September 21 calling WP Engine a “cancer to WordPress”. For the uninitiated: WP Engine is an independent company that provides managed hosting for WordPress sites; WordPress.com is owned by Automattic and it leads the development of WordPress.org. WP Engine’s hosting plans start at $30 a month and it enjoys a good public reputation. Mullenweg’s post however zeroed in on WP Engine’s decision to not record the revisions you’ve made to your posts in your site’s database. This is a basic feature in the WordPress content management system, and based on its absence Mullenweg says:

What WP Engine gives you is not WordPress, it’s something that they’ve chopped up, hacked, butchered to look like WordPress, but actually they’re giving you a cheap knock-off and charging you more for it.

The first thing that struck me about this post was its unusual vehemence, which Mullenweg has typically reserved in the past for more ‘extractive’ platforms like Wix whose actions have also been more readily disagreeable. WP Engine has disabled revisions but as Mullenweg himself pointed out it doesn’t hide this fact. It’s available to view on the ‘Platform Settings’ support page. Equally, WP Engine also offers daily backups; you can readily restore one of them and go back to a previous ‘state’.

Second, Mullenweg accuses WP Engine of “butchering” WordPress but this is stretching it. I understand where he’s coming from, of course: WP Engine is advertising WordPress hosting but it doesn’t come with one of the CMS’s basic features, and which WP Engine doesn’t hide but doesn’t really advertise either. But I’d hardly call this “butchering”, much less in public and more than a decade after Automattic invested in WP Engine.

WP Engine’s stated reason is that post revisions increase database costs that the company would like to keep down. Mullenweg interprets this to mean WP Engine wants “to avoid paying to store that data”. Well, yeah, and that’s okay, right? I can’t claim to be aware of all the trade-offs that determined WP Engine’s price points but turning off a feature to keep costs down and reactivating it upon request for individual users seems fair.

In fact, what really gets my goat is Mullenweg’s language, especially around how much WP Engine charges. He writes:

They are strip-mining the WordPress ecosystem, giving our users a crappier experience so they can make more money.

WordPress.com offers a very similar deal to its customers. (WordPress.com is Automattic’s platform for users where they can pay the company to host WordPress sites for them.) In the US, you’ll need to pay at least $25 a month (billed yearly) to be able to upload custom themes and plugins to your site. All the plans below that rate don’t have this option. You also need this plan to access and jump back to different points of your site’s revision history.

Does this mean WordPress.com is “strip-mining” its users to avoid paying for the infrastructure required for those features? Or is it offering fewer features at lower price points because that’s how it can make its business work? I used to be happy that WordPress.com offers a $48 a year plan with fewer features because I didn’t need them — just as well as WP Engine seems to have determined it can charge its customers less by disabling revision history by default.

(I’m not so happy now because WordPress.com moved detailed site analytics — anything more than hits to posts — from the free plan to the Premium plan, which costs $96 a year.)

It also comes across as disingenuous for Mullenweg to say the “cancer” a la WP Engine will spread if left unchecked. He himself writes no WordPress host listed on WordPress.org’s recommended hosts page has disabled revisions history — but is he aware of the public reputation of these hosts, their predatory pricing habits, and their lousy customer service? Please take a look at Kevin Ohashi’s Review Signal website or r/webhosting. Cheap WordPress in return for a crappy hosting experience is the cancer that’s already spread because WordPress didn’t address it.

(It’s the reason I switched to composing my posts offline on MarsEdit, banking on its backup features, and giving up on my expectations of hosts including WordPress.com.)

It’s unfair to accuse companies of “strip-mining” WordPress so hosting providers can avail users a spam-free, crap-free hosting experience that’s also affordable. In fact, given how flimsy many of Mullenweg’s arguments seem to be, they’re probably directed at some other deeper issue — perhaps what he perceives to be WP Engine not contributing enough back to the open source ecosystem?

An opportunity to understand the GPL license

Featured image: Matt Mullenweg, 2009. Credit: loiclemeur/Flickr, CC BY 2.0.

Every December, I wander over to ma.tt, the blog of WordPress founder Matt Mullenweg, to check what he’s saying about how the CMS will be shaping up in the next year. Despite my cribbings as well as constant yearning to be on Ghost, I’m still on WordPress and no closer to leaving than I ever was. And WordPress isn’t all that bad either (it runs The Wire, for example). In fact, I’m reminded of the words of a very talented developer from earlier this year with whom we at The Wire were consulting. When I brought up the fact that PHP (the programming language on which WordPress is a script) isn’t very conducive to scaling, he replied, “Anything can be built on anything.” So, for all its problems, WordPress does do some other things well that other CMSs might usually struggle with.

Anyway, lest I digress further – On a post on October 28, Mullenweg described the impact of the GPL license on WordPress’s development as “fantastic” – possibly because, as Linus Torvalds, who created the Linux kernel, has noted, the GPL license enforces itself: code derived from GPL-licensed code also has to be GPL-licensed. As a result, those making modifications to WordPress for their own use could not wall themselves off, preventing fragmentation as well as, in the words of University of Pennsylvania law professor Christopher Yoo, persevere in an environment that allows “multiple actors to pursue parallel innovation, which can improve the quality of the technical solution as well as increase the rate of technological change”.

GPL stands for ‘general public license’, and is widely used on the creation, modification, deconstruction, use and distribution of software on the web. Mullenweg’s broader post was actually about him noticing how the UI of the mobile app of Wix, a platform that lets its users build websites with a few clicks, closely resembled WordPress’s own, and how there was – as a result – a glaring problem. In its composition, WordPress uses code that’s on the GPL. GPL’s self-enforcement feature makes it a copyleft license: works that are derived from GPL-licensed work also have to be copyleft and distributed on the same terms. As a result, the code behind Wix’s mobile app had to immediately be made available (by, say, making it available on GitHub) and publicly accessible. It wasn’t.

Last I checked, the post had one update from Wix CEO Avishai Abrahami and 120 comments. And all together, they illustrated how the terms of the license, though written in language that was lucid enough, were easy to confuse and the sort of impedance that poses to its useful implementation. I spent an hour (probably more) going through all of it; if you’re interested in this sort of thing – or learning something new – I highly recommend going through the comments yourself. Or, if you’d like something shorter (but also trying to be wider in scope), you could just keep reading.

The tale has four dramatis personae: the GPL license, the MIT license, Wix’s mobile app and WordPress’s code (plus a cameo appearance by the LGPL license). Code derived from GPL-compatible code also has to be GPL-compatible – a major requirement of which is that: “… you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things” (emphasis added). This is also the clause that’s missing from the MIT license. As a result, code that’s originally under the MIT license can later be licensed as GPL (i.e. its source code made available) but code that’s originally under the GPL cannot later be licensed as MIT (i.e. source code that a GPL license has made accessible cannot be hidden away by the MIT license) – unless all the relevant copyright holders are onboard with the shift.

Paul Sieminski, the general counsel of Automattic – the non-profit company that originally built WordPress – commented on Mullenweg’s post thus: “[Wix would] probably be in the clear if you had used just the original editor we started with (ZSSRichTextEditor, MIT licensed). Instead, Wix took our version of the editor which has 1000+ original commits on top of the original MIT editor, that took more than a year to write. We improved it. A lot. And Wix took those improvements, used them in their app… but then stripped out all of the important rights that they’re not legally allowed to take away. We’re just asking Wix to fix their mistake. Release the Wix Mobile App under a GPL license, and put the source code up on GitHub” (link added). So far so good.

Wix CEO Abrahami’s response – posted on his blog on Wix – though cordial, makes the mistake of being evasive and in denial at once. As many commenters pointed out, Mullenweg’s ask was simple and clearly articulated: bring the source code behind Wix’s mobile app under the GPL and upload it on GitHub. Abrahami, however, defended Wix’s decision to keep the source code proprietary by saying that it only used an open source library modified by WordPress (“that is the concept of open source right?”) for a “minor part” of the app, and that he would “release the app you [Matt] saw as well”. The latter statement should have resolved the dispute because GPL only mandates that the source code be made available when asked for – not necessarily on GitHub. George Stephanis, a developer at Automattic, added: “The source code has to be freely available to everyone that has the software. If you want a paywall, it has to treat the software and source as a unit — you can’t distribute the software, but then charge for the source code.”

Some commenters pointed out that Abrahami may have been confusing the GPL license with the Library GPL (LGPL), and as a result not be entirely clear about the “viral” nature of the GPL license. When code is LGPL-compatible, extensions to the code needn’t be GPL-compatible. For example, in the Wix case, if the WordPress-modified open-source library was LGPL-, instead of GPL-, compatible and the mobile app had used parts of it, then the app’s source code doesn’t have to be GPL-compatible. In colloquial terms, the LGPL doesn’t infect code it is associated with the way the GPL does; it is less “viral”.

Nonetheless, I’d think it’s arguably harder to know Wix’s code has to be GPL-compatible, or even to know what the license on it ought to be, if it isn’t publicly available at all times. In support: the relevant part from the license’s preamble, which I quoted earlier, is “that [the users] know [they] can do these things”. I use the word ‘arguably’ not in the legal sense but in the spiritual one – the spirit being that of the free-software movement. And this is why I’m glad Mullenweg chose to hammer this issue out in public (via his blog) instead of via email. Moreover, I’m also glad that he didn’t initiate legal action immediately either: the conversation between Mullenweg, Abrahami and all the commenters – despite the occasional passive-aggressive animus – deserved to happen instead of the groups splintering off and blocking each other. The open source community always needs more unity.

Then again, the licenses that help sustain these communities could do more harm than good if they become too restrictive – especially when they fall out of step with changing governance practices while striving to keep the open source ideals we’ve associated with Richard Stallman alive even as they don’t offer too much freedom to users, which could result in a proliferation of alternatives that deprive useful software of its coherence. For example, Yoo writes in the paper I quoted from above,

… some restrictions on what people can do with open source operating systems are necessary if consumers are to enjoy the full benefits of competition and innovation. My point is not to suggest that open source software is inherently superior to proprietary software or vice versa. Both approaches have distinct virtues that appeal to different users. Moreover, any attempt to cast the policy debate as a choice between those polar extremes [i.e. open source and modular development] is based on a false dichotomy. Instead, the different modes for producing software platforms are better regarded as occupying different locations along a continuum running from completely unrestricted open source to completely proprietary closed source. Indeed, companies may even choose to pursue hybrid strategies that occupy multiple locations on this continuum simultaneously. The diversity of advantages associated with these different approaches suggests that consumers benefit if different companies are given the latitude to experiment with different governance models, with the presence of one open source platform serving as an important competitive safety valve.

Subscribe to The Wire‘s weekly science newsletter, Infinite in All Directions (archive), where I curate interesting science news, blogs and analyses from around the web.