How To Evaluate Open Source Small Business Apps
I'll cut right to the chase. This article by Roberto Galoppini runs through how to go about finding some of the less popular (but no less important or functional) open source apps out there. This statement in particular:
"Google search might not be your best solution to find specific open source software to suit your needs.
For example, if you search for an open source web editor on Google, you won’t find BlueGriffon, a web editor based on the Firefox rendering engine Gecko (a tool I recommend to try either if you are an experienced or a beginner web author)."
confirms what I've been wondering about for a while now. Google seems to be getting worse at giving me valid results when I search for new open source applications.
Anyway, in his article he first gives a good list of places to find what you need. I've only recently began looking at OSALT, and it's quite the place. Sourceforge and Freshmeat are the two places I usually go when I'm hunting for an app. A lot of times, if you're using Linux, there will be something right in your distribution's software repositories.
That's where to start anyway. Roberto has quite a list of criteria you'd use when having a look at any software you find that might do what you want. I'll highlight some of his points, but check his more detailed list out…
Is the code mature? The nest question is "Does it matter?" and I guess that depends a lot on what it is you're trying to do.
Is it popular? Again, does it matter, especially if it gets the job done?
Are there books written about the software? As much as I use the computer, there's something to be said for being able to quickly switch off reading page and diddling on the computer with what you just learned. I find it easier sometimes to have the book right next to the screen. Of course, you can always print out documentation if O'Reilly hasn't taken an interest in this particular piece of software…
Is there documentation? This is actually pretty important to me. No documentation, or documentation that sucks, sucks. Unfortunately, this has got nothing to do with open source. I use a proprietary ERP at work that has very shoddy documentation. We're constantly wasting time either figuring stuff out, calling support for something that someone else just called them about, etc, etc.
How big is the community? This can have quite an impact on how well your experience with the project goes. If there are a lot of people working on project X, and there's a fairly active message board (or an irc chatroom if you're really lucky — with people actually in it) you can get away with a little less documentation. Another end user to hold hands with while you cross the street together is always nice too.
These are a few of the things I look at; Roberto talks about more. Give his article a read.