First of all, congratulations to Roland Weigelt for winning the first prize in Roy's Add-in contest!. I think his entry deserved the first prize without a doubt as the tool is amazing and, when extended with some additional logic/features, could become a big commercial success.
As a judge in the add-in contest, I had to test all the add-ins submitted, and judge them on quality and if they deserved any of the big prizes available. I can tell you it was hard. Not because there were so many good entries, but because it was often very hard to even get the submitted code to run, left alone to find any documentation what to do, how to get started. This really surprised me, I have to say, and I don't think it's a good sign.
There was just one add-in which had proper documentation how to get started, what to do to see it in action, complete with a well working installer (so it does get uninstalled properly as well, lots of add-ins failed in this, which is annoying to say the least). That add-in turned out be the winner: Ghostdoc. What surprised me was that of all the add-ins submitted, only a small part of the add-ins even had an installer which was ready to use. Most of them came with just the sourcecode. I even tried to compile a few, some failed during the compile! So, as a judge I was sitting there.. "What to do with these add-ins?" I asked myself... Some had nice ideas behind them, but if it doesn't work, the idea just stays an idea.
After a while I simply gave up. It would just take too much time to wade through the sourcecode of these add-ins to get things starting, compiling the installer projects and fail doing that (that was the irony: some had installer projects, but not the compiled binary!) and to figure out what to do with it. Till now I really can't understand why all but one (Ghostdoc) failed to include proper documentation to get started within a few seconds, get it working, where to look at, what are the highlights. I mean, if you want to win a contest, you want to make sure the jury can at least run your add-in and try the killer features of it, right?
Documentation, how to get started, simple demo apps, it's all part of the tool / add-in you're delivering. If there is just sourcecode in a directory, that's not enough. Users don't have time to figure out how brilliant you or your code is, nor do they want to. They want to use it, because they have better things to do with their time. If there is severe lack of documentation, info on how to get started, even a proper working ready-to-run installer, the overall quality of the tool / add-in is close to 0, zero, zip, nothing, void, null: it is then nothing more than a bunch of files with data, but how to use that data, how to utilize that data to be more productive, produce better code, have a better life or whatever, that's unknown. And to me that's unnecessary, because it doesn't take that much time to explain simple things like getting started, what to do to see it in action (yes, this sounds silly, but try the add-ins for yourself and you'll find out very soon it's not that easy), and the most simple thing of them all: how to get it installed.
It's sad to see some hard work not ending up in the top 3 of the contest. I'm sure if some add-in writers would have spend 5 minutes on a working installer and a proper readme.txt how to get started, the top 3 might as well have looked completely different, at least from my judgement, although Ghostdoc would still be a winner I think. I must admit that the 2nd and 3rd prize winners weren't my choices for these spots but luckily for them there were more judges in the jury . To the add-in writers competing in this contest I'd like to say: thank you for participating in this contest, but try to learn from what Roland submitted: look at the overall package, the quality of what was submitted was almost near the quality you'd expect from a commercial tool/add-in. Often it requires just a few extra hours of work, but it will increase the quality the tool/add-in you're producing tremendously, and that's what counts, trust me.