[wp-hackers] Long term suckage

Fri Jun 18 22:08:32 UTC 2010

Hi Matt,

I've got huge respect for you and your accomplishments in building the community that you have. And it's in large part to your instinct and idealism.  So kudos.

OTOH I think that philosophy is at least a tad unrealistic.  But knowing you and knowing the community I'm not going to challenge your position.  It is what it is and what it will be.  Still I would like to bring up a concern I have that could minimize issues if the core committers could take certain criteria into consideration when deciding upon which patches have higher priority than others.

======
The primary concern is lack of apparent priority given to patches that can potentially make existing plugins more robust to potential future changes made in core.
======

With custom post types more companies (especially agencies) are likely to be building custom vertical functionality on top of WordPress. I'm in Atlanta and we have over 100 agencies that build websites for clients, and many of them do it for the 11 local Fortune 500 companies.  These agencies and others are going to be commissioned to build enhancements to WordPress on projects with a fixed budget and they are going to do it in whatever way they can that minimizes their time spent and their effort required. After the site is deployed there will be a skeleton budget for maintenance, but not enough of a budget to rebuild functionality broken by changes made between versions of core.

When a new version of WordPress comes out and someone upgrades it's often possible that a major corporation's site will be broken. Fingers get pointed every which direction and there is no budget to pay the agency to fix it.  And head's roll when that happens.

What I'm describing actually happened for a site I built for a company whose name everyone on this list would recognize. The site broke after I was out of the picture but the agency (who was my client) told me all about it.  It got ugly for them.  What happened?  I had to hack NextGen Gallery because it's database wasn't relational and simply could not do what the client required. I forked it so it wouldn't automatically upgrade. But a forced security upgrade of WordPress caused the forked NextGen to break because of a hack that NextGen had used which required my client to use the new version of NextGen which lost my modifications. All in all I think they had to eat over $5000 in billing to correct the problem. 

Think that agency will ever chose WordPress again? Think that large company will ever let WordPress be used again? I can promise you the answer is no, at least not as long as anyone involved on the project has anything to say about it. (It also means I get no more work from that agency since I only work on WordPress at this point.)

So the negative upshot is that either agencies or clients says "Never again will we EVER allow a site to be built on WordPress."  Clearly we wouldn't want that happening often, right?

Again, I know Matt you are going push everyone to upgrade and we just have to accept that.  But one of the problems is that developers need to write hacks to parts of WordPress to make custom plugins do what their clients want and those hacks make the plugins fragile to improvements in the core. Then developers (like me) request mods to core to protect against future changes but those patches are often ignored or just punted to future versions.

As an example I'll present ticket #13694 [1].  It's not a perfect example nor it is a huge hot-button for me because it was simple and I could work around it but it is the best example of my concern which I can dredge up on short notice. On that ticket filosofo said "I don't think the public menus API should expose or depend on the fact that menus are actually taxonomy items" [2] for which I am in 100% agreement with.  He suggested a simple patch that would introduce a hook that would have allowed me to code my plugin so that it didn't depend on knowledge of the underlying storage of menus but Nacin punted that patch to a future version. So now I have to write my plugin to depend on the knowledge of how menus are stored[3] and it might break in the future. (I'm not 2nd guessing the decision to bypass 3.0 on this specific patch, just using it as the best example of the concern I have.)

======
So in summary, if priority could be given to patches that help future proof APIs just like priorities are given to security issues then much of these concerns would be rendered moot.
======

JMTCW, and thanks for considering.

-Mike
P.S. If priority is given to these types of patches and I just am not aware of it, please forgive me for voicing the concern.  I'm just trying to help...

[1] http://core.trac.wordpress.org/ticket/13694
[2] http://core.trac.wordpress.org/ticket/13694#comment:1
[3]  I have lots of other code now that I've recently written with the deep knowledge of how menus are stored because I couldn't make it work any other way and I'm afraid a future upgrade will break my client's plugin and he'll blame me for it breaking.

On Jun 18, 2010, at 11:49 AM, Matt Mullenweg wrote:

> On 6/17/2010 5:12 PM, Dan Gayle wrote:
>> I once again wish that Wordpress would adopt a two-pronged release strategy.
>> Yes, go ahead and release the latest, greatest bleeding edge version as your
>> main release. But please, PLEASE, start a long-term-support (LTS) branch.
>> Backport all the security fixes and keep something stable for at least the
>> previous release version.
> 
> I used to think this was valid, hence the 2.0 LTS branch. Now, after working with hundreds of the largest companies and media properties in the world, I am philosophically opposed.
> 
> While I like the theory of LTS, what happens in practice is it covers up the incompetence of IT or developers because they put off small slightly painful upgrades until they get so out of date of trunk (3 years? 5 years?) and you have to go through a giant, painful, screws everybody over upgrade.
> 
> At a deeper level, it's disrespectful to your users. A good example is WYSIWYG, which we improved dramatically in the releases following 2.0. I would run into businesses who were sticking on 2.0 because it was LTS but their users were HATING WordPress because "making the WYSIWYG not suck" wasn't backported as a security fix.
> 
> I would rather have them hating some other out-of-date CMS. I would rather the IT department do two hours of work every 3-4 months than a two-month death upgrade project every 5 years.
> 
> Not backporting is a conscious decision. I would rather invest 100 hours in backward compatibility in a new version than 2 hours in backporting a fix to an obsolete version of WordPress. Plus, as noted by everyone else, backporting was often impossible because it wasn't one or two line fixes, it was architecture changes that would touch dozens of files. The LTS was actually *less* stable with these "fixes" backported because it had almost no one using it. Why?
> 
> So if we had been able to stick to the 5 year cycle for 2.0, you would still be on something roughly like this version of WordPress:
> 
> http://wordpress.org/wordpress-2.0.11.zip
> 
> Please download it. Install it (someplace private). Make a post. Edit a theme. Upload a photo gallery. Use a custom post type (oh wait). It sucks. It's embarrassing we used to promote this software. We've learned so much, gotten so much better, and we're going to continue to.
> 
> You don't even need to go that far back. Use 2.6 for a month. It's only about 2 years old.
> 
> The best thing we could do for the savvy people inside these big companies is to give them a scapegoat they could blame the constant upgrades on (those open source hippies! keep making new software.) all the while they know it's really best for their site and their users.
> 
> Plus, this is wp-hackers, we know upgrades aren't that bad. Half the people here run trunk. So does WP.com a good chunk of the year (and all the major sites hosted there).
> 
> As the wizards of WordPress, the question we should be asking isn't how do we trap people in the jail of old versions for years at a time, but rather how do we make upgrading as easy, safe, and painless as possible to the point where we could even start auto-upgrading.
> 
> -- 
> Matt Mullenweg
> http://ma.tt | http://wordpress.org | http://automattic.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers