Why was WordPress 2.0 released when there were still so many known bugs?

THIS POST HAS BEEN MOVED TO:

http://www.emilyrobbins.com/how-to-blog/why-was-wordpress-20-released-when-there-were-still-so-many-known-bugs-310.htm

Please update your bookmarks to reflect the new, permanent location of How to Blog.  Comments and trackbacks on this post are now closed.  If you wish to comment on this post, please visit the new site!  Thank you!

-----------------------------------------------------------------------------------------------------------------------

Over at Something Unpredictable, under the post entitled, “What’s Already Broke in 2.0”, there’s a lively discussion about why WordPress 2.0 was released when:

“Many people knew that it was terribly broken. Many people begged on the wp-hackers list, the wp-forums list, the wp-testers list, and at the last IRC meetup to get the release delayed <large snip> The release candidates were severly broken for a number of people, the rate of bug reporting and committing over the past two weeks is staggering. With all the changes going in, nobody stopped to take the time to test for regressions caused by the changes. Its 1.5 all over again.”

One commenter, Olly, pointed out:

“To be fair to them they have the problems that most commercial developers of popular software find, and that’s that no matter how much beta testing they do, the program will inevitably get hundreds of hours more use on the day of release than they could possibly to in the whole of testing.”

To be clear, these are indeed problems that even commercial developers face. And having worked for several years as a Software Quality Assurance Engineer for a major software company, I can tell you for a fact that expensive commercial software ships with MANY known bugs. The sad truth is that there is no such thing as bug-free software. Introducing new features, and even performing bug fixes, often break existing features (which is why regression testing is so critical). However, in the commercial software world, even when the programmers and the testers are wanting to push back the release date, it’s often the marketing department that controls when the software ‘goes gold’ – unless you found what was known as a ’stop ship bug’, which would only be a bug that would be easily encountered by a regular user AND would be bad enough to crash either the program or their entire system. Beyond that, it was do whatever it takes to get the product out the door on time (even if that means working yourself to death), and sorry ’bout the bugs that still remain.

Nonetheless, even with the idea of being ‘bug-free’ being thrown out as an impossibility, it still stands to reason that users can only tolerate a certain degree of bugginess in a product before the uproar starts. And if many of those bugs turn out to have been known for weeks or months before the release, it does beg the question as to WHY was this product released so early? Given that it is an open-source, community backed FREE piece of software, there is no monsterous marketing team breathing down your back to finish the software that they already SOLD to many customers (and promised them a ship date). There are no numbers that your sales team has to make for any particular quarter, and no shareholders to appease.  So far as I can tell, there is no monetary reason to deliver the product before it is truly ready.

Also, I don’t know how open-source projects (and WordPress in particular) work when it comes to Quality Assurance — is there even a QA department, or is everyone associated with the project just expected to do continual bug testing and keep their eyes peeled for problems and anomilies? If it is the latter, that could explain somewhat why there are so many more bugs being found now that the release version has been delivered. There’s more to software testing than just looking for bugs. It involves creating test plans, regression testing, negative testing (wherein you do things with the software that you’re not supposed to and see if it handles the problem gracefully), etc. And different people need to be assigned to different areas of the software so that they are focused and really become experts in their area. It was hard enough to do with a team of well paid developers — I honestly don’t know how you get that done when it’s all volunteer effort (although I’m not saying that the WP team hasn’t incorporated all of these areas of testing as I’m not in a position to know).

But given that it is an opensource project, and apparently reliant on much of its userbase for unearthing the bugs, it would behoove both the WP community and the WordPress team to provide clear and easy to use directions on how to search for a bug in Trac and, if it’s not already listed there, enter it yourself. I’d venture to say that less than 5% of users know about Trac (WordPress’s bug tracking software), nevermind how to submit a bug they’ve found. (I just submitted my first bug: Ticket #2218: Pop-up window for inserting hyperlinks truncated on FireFox 1.5)

On wordpress.com, there is a handy little ‘Feedback’ button that appears on every admin screen designed for sending ‘bugs and hugs’, which I though was really great. I don’t know why that was omitted from WordPress 2.0 — it’s a great way for the WordPress team to interact with those WordPress users who don’t hang out in the support forums, etc.

In sum, any software project of this scope and with this large of a user base is extraordinary challenging to QA, even in the commercial world. I’d imagine it’s that much more difficult to do when everyone is working on a volunteer basis. That said, open source software has a luxury that commercial software doesn’t in that you don’t have to get the product out by a certain date in order to meet your numbers for a certain fiscal period. Any .0 release is a major release, and should have enough new features and bug fixes as well as improved existing functionality to entice existing users to upgrade. As TheBisch has mentioned, I’m not sure the features in 2.0 are compelling enough to get existing users to upgrade, especially when there are so many bugs and broken plugins, not to mention that it is likely that we’ll be seeing 2.0.1 and 2.0.2, if not 2.0.3 coming down the line shortly and have to upgrade again and ugain, all with potential upgrade fiascos (after all, that’s what we experienced with the 1.5 release, and that one seemed more stable than 2.0…) Which leaves me wondering — why was WordPress 2.0 released when there were people purportedly begging to push back the release date until more bugs were resolved??