I heart plugin authors. Their work is generally amazing, a huge benefit to the community, the reason why WordPress rules so much, and deserving of much worship. That being said, plugins can do some pretty rude things sometimes…
I had a plugin that I used that liked to deactivate it itself when you upgraded it. I can’t say for absolutely sure why. Perhaps it wasn’t able to save settings after an upgrade and the default was off so when you upgraded it turned off. Perhaps there were new options so the author wanted people to go to the settings page to see all the new stuff. This particular plugin had all kinds of crap in the header of plugin about following him on Twitter and donating, so it was my suspicion that the turning off of the plugin was directed at making people look at all that stuff every time an upgrade was pushed out. He probably saw an uptick in donations when upgrades when out, so there was incentive to keep pushing out minor updates that shut off the plugin.
Plugin authors are generally smart folks who realize that plugins meant to be used by a wide audience need to be as fool-proof as possible. If the plugin is complicated and requires use of outside files or interaction with other (theoretically default) WordPress files, testing should be done against a variety of installs and in conjunction with other popular plugins to make sure there are no conflicts.
If the plugin tinkers with existing functions, every one of them should be clearly explained so users can understand that use of those functions elsewhere may not behave as expected. Even things as simple as file paths can be problematic. As basic as that sounds, file paths should never be hard-coded.
Have Bad Documentation
To the best of the author’s ability, all plugins should include plain English explanations of why the plugin was created and what goal it hopes to accomplish. Beyond that, instructions for installation and uninstalling should be included. The WordPress plugin directory does a good job of providing “tabs” at the top of plugin pages for including this information. Also important is the FAQ section, which gives plugin authors another opportunity for plain English speak that is free from the sales-y introduction you have to do on the main page.
Plugin authors know there are some hooks that almost everyone has, like wp_footer(). Hey why not add a force in a line of text down there linking back to the author site? Because that’s rude, that’s why.
Make You Sign up for a Newsletter
There was a plugin I once used fairly regularly that required “activation” that you got via email after signing up for the author’s email. That’s some strong-arm bullshit right there. And do you think this newsletter came only rarely and tastefully with important info? Obviously no, it came all the time, looked like shit, and was loaded with in-your-face proposals. Now there is a plugin that does the same thing without all that. Guess which one I use and support?
WordPress changes, users needs change, so plugins need to update. If the plugin is so simple and sound it doesn’t really need constant point releases, its still important to go in to the documentation and indicate it is compatible with the most recent version of WordPress when that changes.
Don’t Have Changelogs
When a plugin does update, there should be at least some basic text explain what was changed and why. I always much appreciate plugin updates, but I’m not going to click that button until I can read from the author what was changed.