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.
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.