10 Tips When Considering Open Source Software - Page 3

By Joe Brockmeier
  • Print Article
  • Email Article

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 jzb@zonker.net 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!

Page 3 of 3

Previous Page
1 2 3
This article was originally published on January 10, 2011
Thanks for your registration