Over the last three months, I have reviewed probably three hundred Open Source projects. When I say “reviewed”, this goes from installing and playing with it extensively (like Celestia and MuseScore) all the way down to reading the website, looking at the screen shots, and trying to figure out what it does.
This latter category is usually for projects that aren’t available for a platform that I use regularly.
Not pointing any fingers, but there have been times when I simply couldn’t figure out what the project was for.
In your project admin interface, you have three opportunities to describe what your project is, in three different ways.
You have a summary statement, which is 70 characters or less, and is intended to be one memorable phrase or sentence that best describes what your project is. Good examples of this are “TORCS – The Open Racing Car Simulator”, and “TuxPaint – Art software to let kids draw and paint. For children 3 to 12 years”, and “Arianne is an engine to develop multiplayer online games like Stendhal”. They are completely lacking details, but give you an immediate understanding of the central idea of the product.
Web usability folks tell us all the time that you have just a few seconds to get someone’s attention before they move on to the next link and forget about you. This summary statement is your opportunity to get their attention. Omitting it, or making it inscrutable, ensures that they’ll move on.
Next, you have the description. This is longer, and gives you the opportunity to describe what the project does. However, here too, you need to focus on what makes you distinctive. Saying that the project is Open Source is redundant. Saying that it is “full featured” is meaningless.
Imagine that you’re in an elevator with someone that is looking for a project to invest their money in. You’ve just met them, and you don’t know their level of technical expertise. They ask “what does your product do?” You have two minutes before they get to their floor and forget about you.
Ok, now go rewrite your project description. Tell me why I should choose yours over that other one, or what yours does that is unique or exciting. If I encounter another “free, open source, secure, easy-to-use and light-weight” product, I think I might scream.
(In the marketing business, they call this your elevator pitch, but’s also called the value proposition, or unique selling point, or the Big Idea. If you don’t know what yours is, then nobody else will either.)
Finally, you have the list of features. This is where you should throw around the technical terms that those in the know will be looking for. The acronyms, RFCs, and standards names. But here, too, you need to focus on what’s impressive, and what matters. Don’t tell me that your product is fast, responsive, secure, or error-free, because I assume those things.
Now, think of your friend or coworker who is least knowledgeable about your Open Source project, and show them your project page. Give them 60 seconds, and then ask them what your project is for. If they don’t know, go back and do it again.
Now, I know that you’re in this for the fun of developing the project, and sometimes, it doesn’t seem like marketing is something you want to spend that time on. But it’s more fun when more people are using it, and more people are playing along with you, and this is a worthwhile investment.
Also, please remember that this is my job, as well as my passion. If you want me to evaluate your project summary page, please JUST ASK. I’ll be brutal, and specific, and will even help you rewrite, if you want. I am a writer. And I want your project to succeed, because I love Open Source. Please just ask. It’s what I’m here for.
Special thanks to the members of the Arianne project, and especially Katie Russell, for discussion and suggestions on the #arianne and #sourceforge IRC channels (on freenode.net) which led to this article.