Apparently, several people have had issues with WordPress 2.9 since its FCS release just a few days ago.
In fact, this has caught on such attention that there has been mention by Jeff (at Weblog Tools Collection), Keith (also at Weblog Tools Collection), and at the WordPress development blog about a beta version of WordPress 2.9.1 making its way out for people to try.
If you read the comments on Jeff’s post, you’ll notice that there is a sort of near-religious (for lack of a better term) indignation over the 2.9 version and presence of bugs in the product despite its beta and release candidate cycles. While certainly not to the same extent as the “religious wars” over GPL and other open source efforts, it does touch upon the conversations and arguments over whether GPL’ed products are worth the trouble for many businesses and individuals.
While it would be difficult to argue that hobbyist bloggers have the same issues about code ownership and production-worthiness that major corporations do, it is easier to understand the concern that individual bloggers (and even SMB’s that use blogs to help drive or support their work) have over some (or, in some cases, much or even all) of the open source software that they rely upon.
And it does not make it any better when the fervent GPL’ers and open source fanatics turn the frustration around upon the users and accuse them of not “helping out”. As if every user of open source software is somehow financially and technically equipped to deal with the intricacies of agile and automated testing…?
Perhaps the lesson here is: You get what you get, and that’s all.
“Well, what does that mean?!?”
Another way of stating it (and a bit less obtusely) is that when you get software like WordPress, despite being GPL’ed, it is still nothing more than software. And like most software released into the wild today, its code complexity makes it prone to having bugs introduced with every successive increment, and coupled with its existing bugs, some of the combinations and permutations of the population of defects would be truly wicked and pervasive. So if you choose to use it, or any other software, you have to be cognizant of this reality and decide how you are going to deal with it.
In the realm of COTS, it was fairly simple: you abide by the terms of the EULA or basic software licensing contract. If there was a support clause, you could exercise it. If you decide the headaches of using the software are not worth it, you have the option to just stop using it. A common example that is being played out in the marketing arena, and in mass media, is of course, the Exodus Away From Windows of the 2000′s: whether it’s OS X, Linux, Solaris, or something else, the choice to stop using Windows has become not just viable but extremely attractive. And while some have chosen to stop using Windows, others have decided to stay with the versions that they are already using, and still others have taken the plunge to Windows 7.
The FOSS arena has generally been fairly simple as well: if you choose to use the software, you need to understand the terms of acceptance and make arrangements for support. Since several of the open source licenses do not place restrictions on customizations or modifications, it is a laissez-faire market for hiring developers to manage the code. This frees the users who are less technically adept to focus on their business needs and be what the software expects them to be: users.
The WordPress-GPL realm has been a bit murkier when it comes to the separation between user and developer in some respects; some of the comments being bandied around about how WordPress users should somehow transform themselves into volunteer developers or QA testers for unstable versions of the blog package indicate how misinformed those writer are. Other comments about how the WordPress users with problems should consider hiring some developers to correct the bugs for them are a bit more reasonable since, after all, it’s just software. But judging from the types of comments being written by the user types, a lot of them are looking for constructive advice on how to get back on track and just being productive users of the software, but not heckling or the typical “you-should-have-backed-everything-up-every-second-of-every-day” lecture.
Recommendations
Well, by now, you probably figured that this section would be here, right? 
Here are some recommendations for WordPress users, especially the ones who are discouraged and frustrated by all of the people who are giving you grief for being, frankly, users of WordPress:
- Use the software for all it’s worth, but don’t expect more from it than it really is… skip the hype about how it’s the end-all-be-all of software… It’s Only Software.
- Whether you’re a casual user or a power user, use the features you like or need to use. Blog as much as you want and how you’d like to, based upon what the software provides for you.
- Sometimes you’ll have to check the WordPress.org support forum for information or help. Don’t be afraid; just ignore the hecklers– the rest of us do.
- If you are motivated and spot a bug, there is documentation on WordPress.org, including in the Codex, about how to report a bug. It’s a lot of didactic to wade through, but it discusses the formalities behind researching the bug to see if it already exists, and then posting it (if it’s not anywhere) into the Trac issue tracker.
- If you want to focus on being a user, use the support forum to discuss the bug… take your best guess at the most appropriate topic for now (you’ll see what I mean when you get there).
And not to leave Matt and the other WordPress folks out of the recommendations, here’s a feature request of sorts:
- If I couldn’t persuade a few hundred project managers at a large Fortune 500 company to submit and track bugs in something like JIRA or Trac, I seriously doubt I would be able to offer Trac as the easy-to-use, convenient bug reporting tool for end users.
- Instead, a lot of customer-facing software tend to use quick pop-up style or pre-shutdown hooked dialogs to capture the user’s note about the problem and some internal stack trace or other technical info before the software bombs.
- A good approach would be a “Report a Bug” feature in WordPress that would be accessible at multiple locations through the admin console. What information you’d like to capture would be up to you, of course, but knowing where the bug occurs and what happens when it occurs… well, y’know.
- You’d probably want to pump all of the bug report data through to a secure Web service and store the raw incoming data separate from Trac initially; then you could filter against it, or scrub the data down to unique sets for import into Trac. Or you could have the Web service import the data into Trac after a bit of transform or scrub, so you would have everything captured… just keep in mind that the data could get large and you will see a lot of duplicated reports.
- For more advanced fun, you could also provide the users with a ticket ID associated with their report, for both the raw incoming data and the eventual associated Trac ticket.
Parting Words
Users are users. Many developers are also users. But not many users are also developers. Good users are great sources for feature requests, but they should not be expected to be well-versed or experienced in reporting and investigating defects.
So, happy holidays, folks! Be kind and considerate to your friends, neighbors, and even strangers. Be of good cheer and well-wishing. And be good users of software.
{ 1 trackback }