Welcome to 2011. I hope one of your New Year’s Resolutions is to use more open source in your small business. If so, there’s no time like the present. But before you jump in, take the time to consider a few tips on how to evaluate an open source project.
Of course your first step should be to evaluate the software. That’s one of the beauties of open source — you can get hands-on experience without having to buy a license or deal with sales folks (well, for the most part. See the single-vendor discussion later in this article).
How to Evaluate Open Source Software: A Primer
Features and stability aren’t the only metrics to use to evaluate an open source project. You should also think about its long-term implications for your business. Is the project going to be around for the long haul? Is it always going to be available under the same terms? What kind of support is available if you really need it?
This primer will help you evaluate open source projects to ensure they’re not only suitable for your small business today, but tomorrow and next year as well.
1. Start with Documentation
It might be because I’m a writer, but the first place I look to evaluate the health and suitability of an open source project is its documentation.
Does the project have reasonable documentation for installation, setup, troubleshooting, etc.? What about more advanced topics that you’ll run into long-term? Are you going to be able to find any support materials from the project or from publishers like O’Reilly? Is it popular enough to be covered in mainstream tech publications?
Selecting a project with sub-standard documentation can be a sure path to pain if it’s a complex product. Further, decent documentation usually indicates that a project has a community beyond just the development team, or that the vendor behind the project is investing in documents.
2. Packages and Distribution Support
If you’re running systems on Linux, look to see whether the project is being packaged for your Linux distribution of choice. Is it available as part of the distribution, or do you need to install it separately? If separately, does the project provide native packages (Debian packages for Ubuntu, RPMs for Red Hat, CentOS, Fedora, SUSE, etc.)?
The objective is to determine how much difficulty (if any) you’ll have in installing and maintaining the software. Apache, for instance, is a no-brainer — every major Linux distribution packages Apache, so you don’t have to compile it yourself.
Compiling software isn’t overly difficult, but it can be time-consuming and frustrating if you’re not familiar with the process and how to troubleshoot missing dependencies. If a project doesn’t provide native packages, you may want to think twice about depending on it. Avoid projects that require a version control system (like CVS, Subversion, or Git) to pull a release, unless of course, you’re already conversant with those systems.
3. Project Roadmap
Even small businesses should have a business plan for the next year and beyond. If you’re choosing a Free or Open Source Software (FOSS) solution that’s important to your business, you should have some idea where that project is going as well.
Look into the developer materials on the project site — is there a roadmap for the project? Do you have some idea what features are on the table for future releases, or is the project flying by the seat of its pants? If you can’t glean some idea where the project is going in the next year or two, be wary.
You can also do a reality check for many projects, if they’ve kept a roadmap in the past. Did they meet the roadmap? A few dropped or delayed features are nothing to worry about in many cases — but missing the deadline by a mile is something to be concerned about.