Open source software can bring real benefits to small business. But in order to reap those benefits, you need to evaluate the open source software project. Here are 10 tips on how to do just that.
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, youre 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.
Choosing Open Source Software
4. Open Source Project Lifecycle
Closely related to the feature roadmap is the development cycle of the project. Some projects, like Ubuntu, are on a set six-month release cycle with well-established support periods. Standard releases are supported for 18 months, long term support (LTS) releases see three years of support on the desktop and five years on the server.
Debian, on the other hand, has a release schedule that's a bit whimsical. If you need to know when releases are going to come out, Debian is a bad idea. The support lifecycle winds up being reasonable, but waiting for a new stable release can be frustrating.
Final word on lifecycles: eyeball the project's release cycle and support periods. If they're well defined and stuck to, it's a good bet. If the release period is erratic, it's cause for caution. That may not be a deal-breaker if the project has a history of long term support for stable releases, though. If the stable release support period is less than three years, that's usually a deal-breaker. Most solutions should be in place for years without having to upgrade and break in a new version.
5. Security Updates
Major version updates should be few and far between, at least for most server-side software. Security updates, on the other hand, should be frequent -- if necessary. Then again, ask why they're necessary and if the project has a decent security track record.
For projects like Linux distributions, see how long it takes for the vendor or project to release security updates from the upstream projects. If there's a vulnerability in the Linux kernel or Apache or some other major component, is a security fix available within hours, days, or weeks? How does it compare with other Linux distros?
Ideally, security updates should be infrequent for standalone projects, but speedy when vulnerabilities are discovered. Also check to see if there are any outstanding vulnerabilities that haven't been patched.
6. Project Size
Closely related to the speed of security updates is the size of the project. How large is the project? Is it a labor of love for one or two developers, or a bustling independent project with a throng of core developers? Perhaps it's a vendor-sponsored project with tens or hundreds of paid developers, along with an external community of contributors. Or it may be a vendor-sponsored project with almost no contribution from outside at all.
Here's what you're looking for: Signs that a project has a healthy mix of developers who are going to ensure that the project evolves. If the project has a small set of core developers with little growth or outside activity, it's possible that the project will simply sputter out. Chances of burnout increase dramatically with fewer hands to do the work. Worse, if a project has just one developer or a handful, when one developer burns out there'll be no one to step in.
While you can't peek into the offices or mailing lists of proprietary software vendors (usually), you can audit the development community for open source projects. If a project is going to be particularly important to your business, sign up for the developer lists and user lists.
See how much discussion there is, how many people are participating, and the general tone of the project. Don't be put off if there's a terse exchange between developers -- that's normal. But projects that have a great deal of hostility should probably be avoided. (Note that most projects will have occasional problems with trolls and cranks on the mailing list.)
7. Beware Single-Vendor Projects
If Oracle's acquisition of Sun taught us anything, it's to be very wary of FOSS projects that have a single corporate sponsor that holds all the cards.
One warning sign: a project is billed as open source, but requires some kind of registration to actually get to a download. This clearly identifies what many of my friends in the Fedora project like to call "fauxpen source," a vendor that uses a free software or open source license, but runs the project just like a proprietary product.
Even if the company that's sponsoring the project now has a good track record with open source, there's no guarantee that it will always have a pro-open slant. Even if the company's management is pro-open today, that can change with a few bad quarters -- or after a sale. (Again, see Oracle and Sun.)
This isn't to say that you should never use single-vendor projects: But be aware of the potential for problems. It's better to go with projects that have a strong community and multiple vendors contributing than a single dominant entity.
Small Business and Open Source
8. Open, or Open Core?
Some projects advertise "open source" when they're really "open core." What's open core? Projects that are open source in part, but have some features held back for paid support. Typically this means that a project is open source and can be used for smaller deployments -- but if you want to use it in an enterprise setting, you'll wind up paying for support.
That might sound ideal for small or medium-sized businesses, right? You might not need load balancing or replication, for example, so the "community edition" may be a perfect fit. The problem is that a vendor that's holding back features A and B in the current edition may decide to hold back a feature you want or need in the next release.
Take, for example, SugarCRM. The 6.0 release brought a new interface that many community users were looking forward to, but were denied in the community edition. Again, it's not a deal-killer if a project is open core -- but it's something to be aware of and to consider whether the features being held back are worth paying for or something you can skip.
9. Lock-in or Wide Open?
Just because a project is open source, it doesn't mean that the vendor has no lock-in strategy. Any open source project that's sponsored by a single vendor is likely to have one or more control points that it uses to make it difficult to move away from the loving embrace of their paid support.
This isn't necessarily an evil thing -- everybody has to eat, and the money that goes to support the developers has to come from somewhere. Bottom line: If you want it to be good enough to run your business, have someone to turn to for support, and have a predictable roadmap and support lifecycle, some money has to be going into supporting the project.
That said, you want to make sure that you have options, and that the lock-in factor isn't too onerous. Can you get support from multiple vendors? If the project doesn't pan out for you, how hard is it going to be to get your data out and into another application?
Try to picture a worst-case scenario where you really need or want to switch away from the solution, and ask how hard it would be to do so in a year or five. If it's going to be extremely difficult, that's something that should factor into the decision. Maybe the solution is the only one that fits your needs, or maybe it should drive you to adopt another project.
10. Open Source Ecosystem and Plugins
The last test is to determine whether the project has an ecosystem -- that is, is it being widely deployed? Are developers creating add-ons, plugins, or extensions for it?
For example, look at Firefox and Thunderbird, the Web browser and mail client from the Mozilla Project. Firefox has a very healthy ecosystem. It has hundreds of popular add-ons and is widely supported by Web developers. While some sites might be IE-only, most sites today work well with Firefox as well. Thunderbird, on the other hand, is much less popular -- it has a similar add-on framework to Firefox, but far fewer third-party developers support Thunderbird.
WordPress is another example -- you'll find hundreds of plugins for WordPress that help extend its functionality. Movable Type, on the other hand? Its developer base has been shrinking over the years.
If a project supports plugins and such, you want to check the health of its ecosystem. Projects that have a lot of interested third-party developers are projects that are likely to remain healthy. In addition, it means that you can (if needed) extend the project's functionality yourself (or pay someone to do so) without straying from the project.
Why is this important? I've seen a number of companies backed into a corner by extending a project and then being unable to upgrade to later versions of the software without serious pain. If a project has a plugin/extension architecture, use it. If it doesn't, try contributing features to the main project -- but hacking in features to a project is something not to be taken lightly.
Final Thoughts on Considering Open Source
Most of these tips are good practice for evaluating any vendor -- whether it's an open source project or proprietary solutions from a company like Oracle. But many small businesses don't do due diligence when choosing open source solutions, because they treat open source differently than standard solutions.
Don't let licensing or the concept of "free as in beer" boggle you -- take the time and walk through the checklist to evaluate open source solutions just as you would proprietary software.
Joe 'Zonker' Brockmeier is a freelance writer and editor with more than 10 years covering IT. Formerly the openSUSE Community Manager for Novell, Brockmeier has written for Linux Magazine, Sys Admin, Linux Pro Magazine, IBM developerWorks, Linux.com, CIO.com, Linux Weekly News, ZDNet, and many other publications. Brockmeier is also a FLOSS advocate and participates in several projects, including GNOME as the PR team lead. You can reach Zonker at firstname.lastname@example.org and follow him on Twitter.
|Do you have a comment or question about this article or other small business topics in general? Speak out in the SmallBusinessComputing.com Forums. Join the discussion today! |