Open Source Feedback and Participation (The WebInject Story)

I posted a lengthy entry to the "getting feedback on tools" thread going on at the toolsmith-guild group. 

The thread is discussing how to get feedback and participation going in test tools projects.  This experience report sheds some light on this, but more generally can be applied to getting your open source project noticed and used.  I thought other open source developers might find this useful.

Here is my post:

Hi.. new to the list.

I have some experience in this area I want to comment on:

I had a specific need for a tool to test web services a few years ago ('02-'03). I had been rolling my own tools in various languages for quite a while and had some stuff that I thought others might be interested in; so I setup a SourceForge project and released it in Jan'04. The tool is called WebInject. Not many people used it at first. I just kept adding features and releasing. I was scratching my own itches and using my tool internally at a company I was working for. Eventually I got a few bites and some people started to download it and try it out.

As of today, the project site has served over a quarter million pageviews and the tool has been downloaded over 30,000 times. I've had feedback from all corners of the world.

See the Download Stats

In the early days, *any* bug that was reported, I would dive into immediately.. I was turning around fixes and new releases in crazy time. This personal attention sparked a lot of lengthy email conversations where I was starting to get real feedback. It wasn't the case where I could just sit back and expect quality feedback. I really engaged the users and asked questions. Pretty soon I was getting more feedback than I could reasonably handle. Around this time I started getting some patches sent to me. This accelerated development as you start to get various ideas from other people. A few silly bugs were also cleaned up.. stuff I never would have caught on my own. Encouraging patches is huge.. once someone gets a piece of their own code into your code base, they have an intimate connection.

I was also contacted by someone writing a book that wanted to use my tool as an example. I was really excited about this and put in some serious time getting the tool cleaned up and more useful. I never saw a published copy, but apparently it exists (I saw the PDF drafts :) It was also mentioned in a few testing magazines and articles which was cool for me to see.

I don't maintain WebInject much any more. I think it is cool and useful, but it's a rats nest of Perl code that needs some serious love. There is some stuff that bothers me so much about it that I barely want to touch it sometimes :) I spend all my time on newer tools these days, but I still keep on top of it enough to facilitate others using it and posting patches/updates to it (though I haven't released in over a year I think). Oddly, it has become somewhat entrenched in monitoring systems. Most of the users lately seem to be people running Nagios (open source monitoring system) that need an intelligent web plugin/agent.

Some basic thoughts on open source tool adoption and getting feedback:

• A tool without documentation doesn't exist.. without quality documentation, don't even bother.. nobody will touch it.
  
• If it takes someone more than 10 minutes to install, configure, run, and see the results from a simple test case.. nobody will use it. Once someone sees something work, it is tangible and they become engaged. I achieved this with my tool.. if you download and run it, you are presented with a GUI. Pressing "run" executes a preconfigured sample test case that hits my site. I wanted the most clueless of people to be able to immediately see a green "PASS", and say "hey, cool it actually did something". This satisfaction must come immediately or it will be abandoned. (unless of course you already have a user base that has made it past this hurdle and can encourage others to put in the effort to get it working)
  
• Make your tool easy to get. The online presence of your tool should allow someone to visit the website and immediately download it. I have seen tools released that take 5 levels of navigation before you get to the download options, or don't even have a website or project page somewhere.
  
• Announce your tools.. release early, release often.. who cares.. blog it, forum it, email it, digg it, usenet it, comment about it.. see if anyone has interest. Don't annoyingly spam it, bet let people know it exists. If you announce your tool once only, buried deep in a technical mailing list, don't expect people to come rushing.
  
• Encourage participation. Go out of your way to let people know that you encourage and appreciate feedback, bug reports, offers for collaboration, patches, etc.
  
• You need a forum or a mailing list with a web accessible archive. It has to be super simple to talk to you in public and let others see answers to questions and begin to participate on their own and to offer advice. Using a many-to-one scheme where you just tell people to email you isn't gonna work. It is too private.. people want to know what is going on and hear from each other and offer tips. I have had several thousand posts to my forums for this little tool.
  

- Corey Goldberg