10 Tips When Considering Open Source Software - Page 2

By Joe Brockmeier
  • Print Article
  • Email Article

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.

Page 2 of 3

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