I’ve been semi-lurking of late on the PicoContainer’s developer mailing list, where much of the discussion has been over to the topic of the refactoring of the existing PicoContainer, PicoExtras and NanoContainer products. Given the nature of the list, the focus of the refactoring work has primarily been in order to make development and reuse of the products within other projects easier – quite often the topic of build dependencies gets mentioned. Given that I want to use PicoContainer/NanoContainer at work, it got me to thinking as to what I would need the projects to have in order for me to be able to use them. More generally, what do I need from any Opensource project in order for me to justify its use in a development project, be it Opensource or Commercial? On a post to the list, I summed this up as being able to say to my colleagues (be they fellow developers or management): “That’s what it is, here’s what it does, here’s how to use it and that’s why we are using it”.
That’s what it is
An Opensource project needs an identity. That is to say it needs a name, and something along the lines of (I’m going to hate myself for saying it) a mission statement:
Project Zebra aims to provide an Opensource, cutting edge monochrome solution to the ongoing shortage of food for lions.
It should also be available in a nice, downloadable package (or one or two at most). I want to be able to say “I just downloaded it, we have the Jars”, not “I started up SmartCVS and grabbed the most recent version”.
Here’s what it does
This should be more specific than a mission statement. I want a feature list, and perhaps even a nice comparison matrix if there are similar products available. If I can’t work this out from looking at your website for less than five minutes then why do you have one?
Project Zebra can:
* Merge into black and white foliage
* Look like a horse and yet not be able to be riden
* Provide either black zebras with white stripes, or white zebras with black stripes
Here’s how to use it
Probably the most important thing – good documentation and example programs. I may well be able to work out how to use project Zebra by looking at the code, but what about the developer sitting next to me who might have to fix my code when I’m on holiday? Having no documentation or examples might be fine for in-house development, but please be nice to your potential users.
That’s why we are using it
You need to be able to justify your use of project Zebra, and this can only be done if the previous questions can be answered. If your Opensource project cannot answer the above questions when asked of it, perhaps it should, or perhaps you should reconsider who exactly your target audience is.