The following applies to the authoring of all software libraries, not just jQuery plug-ins, but I’ve been looking at lots of jQuery UI widgets lately, so….

As the author of a shiny new jQuery plug-in, I’m sure that after all of your hard work, you would be very pleased to have other programmers / web developers actually use your plug-in. For many of you, that’s just not going to happen. Here’s why:

  1. Documentation is not optional. Code samples are really nice to have, but are not a substitute for complete and accurate documentation.
I can't tell you how many jQuery UI widgets I've looked at that have no documentation ("I haven't had time to write it yet"). There's a little thing in the software community known as the "ten minute test". If I can't figure out how to use the major features of your library/widget/plugin in ten minutes, I'm not going to spend any more time on it, no matter how "great" it is.
  1. For data-bound UI widgets, Ajax support is not optional. Nor is adding / editing / deleting data programmatically after the widget is first rendered.
Transforming html into a data widget (e.g. an html table into a grid) is great for a demo, but most real-world applications will need data from a server.
  1. For data-bound UI widgets supporting Ajax, JSON support is not optional.
No - I'm just not going to use XML. Get over it. (see #3)
  1. For data-bound UI widgets supporting Ajax, data samples are not optional.
It's nice to provide server-side code samples for producing the data that the widget consumes, but they are no substitute for actual examples of the xml and JSON data. I don't generally program in PHP, and I'm not going to sit and decipher your sample PHP code to try to figure out your data format. Folks who are contemplating using your plug-in are programmers, and should be able to figure out how to produce the required data format in their chosen server-side language - just tell them what it is.