Intriguing Interview With Matt Mullenweg By Japanese Magazine

Intriguing interview conducted by Gihyo.jp which is a Japanese focused developer resource site.

As your experience straddles both, where do you think open source excels? And where is it weak?

The open source model is probably best in the world at bringing together hundreds of people, from casual passersby to those who are deeply involved, to make constant, incremental improvement to core software. For projects with a clear goal―like the Linux kernel or Wikipedia―having an efficient method for people to contribute outstrips anything any proprietary company could do. The weaknesses are that it’s harder to make radical changes and do design. And those two are very much related. Open source is best at incremental improvements of things you already do, as well as responding to user requests. But with open source, it’s a lot harder to move the community to do something that users have never imagined they want. The problem is not impossible to overcome. But it means that whoever is leading the change must lay out the case as a compelling direction for the future―and to do it before a single line of code is written.

I can imagine those who have witnessed the development of WordPress for at least the past two years may take exception to the last sentence in that quote. In my opinion, that is not how most WordPress development works. I might as well cite the classic example known as the Capital_P Dangit function. The so called compelling direction was laid out after the change was added to WordPress 3.0. The change occurred without a trac ticket attached to it which further illustrates the point that sometimes, the compelling case to add something to WordPress never happens before one line of code is written.

While I’d definitely like to see dialogue occur between users and developers on certain proposed features before one line of code is written, it’s often been said to me that we’ll end up talking in circles with no lines of code ever being written. It’s easier to talk than code. So where does the balance come into play? WordPress history shows us that plugins appear to be the balance makers. Additions or reverts to core are often remedied by someone releasing a plugin, after the fact. This is the road WordPress development has chosen to go down more often than not. It’s definitely annoying at times but I’m happy to see that WordPress has such a large user base that someone, somewhere, will most likely develop a plugin to right the wrongs of WordPress. Those wrongs are considered from a per user basis as even I realize WordPress can’t hit the sweet spots for all users.

In the life of WordPress, there are both good and bad milestones. One year later, I still consider the addition of the Capital P function as a big mistake that will go down in my history book as a bad milestone. I chose to use this example as it best reflects the complete opposite of Matt’s response to the original question. I’m hoping that things change and that at some point, what Matt says becomes the norm for how WordPress development works, not the other way around. We need to see more events like this complete with published results and open discussion about those results.

4 Comments


  1. But with open source, it’s a lot harder to move the community to do something that users have never imagined they want.

    I’m pretty sure he was referring to the developers, i.e. the people that would actually have to implement those changes in Core or those who would have to upgrade their plugins and themes. That’s why backward-compatibility is so important.

    So, from this point of view, Capital P fails as a counter-example, since it was trivial to implement and had no back-compat implications.

    The only thing you have to convince end-users to do is upgrade to the latest version.

    Report


  2. @scribu -Jeff didn’t use the Capital P example in the context to which you are referring. So saying that the Capital P example fails is just wrong.

    So, from this point of view, Capital P fails as a counter-example, since it was trivial to implement and had no back-compat implications.

    In the end it did however break things for some users. It was also unnecessary and was just an egotrip on the part of Matt.

    Report


  3. Regardless of the Capital P controversy, I think Matt’s comment rings true to my own experience.

    When you have a largely democratic process for development, any significant changes are ALWAYS met with a huge backlash from some percentage of the populace (see flyout menus). In a private company, decisions can be made by a single leader that can be dramatically different than the original intent of the software.

    It may well be that “benevolent monarchy” is the way of the future with open source – see Ruby on Rails as a good example of this in action. A core team led by DHH makes controversial decisions seemingly with every release. It’s not a democracy on major decisions, but perhaps that’s why it’s so successful? I tend to think so.

    Report


  4. In the military, one is “stationed” at a particular Base, or with a Command, for some nominal period of time, and is then arbitrarily uprooted and reassigned elsewhere. And so it goes for one’s entire career, always being shuffled from one place to another … always about the time one is getting nicely settled.

    The longer folks remain in a given role/situation, the more comfortable, the more empowered, and ultimately the more “entitled” they feel. Or, “are”. The French Revolution was considerably more driven by exactly this dynamic, than we like to acknowledge. (Because it means that some of our fondly-held ideals, are both unlikely, and counterproductive.)

    Matt Mullenweg will have to become Mr. Mullenweg, if he is going to “take” or “drive” WordPress … pretty much *anywhere*. The more the project comes to “belong” to the “community”, the less traction & authority Matt will be able to exert. Or, “have”.

    Report

Comments are closed.