IT Survival Guide: Exercise Caution Amid Open Source Options

Open Source software is generally reliable, but GPLv3 can cause problems. Here are ways to avoid pitfalls.
Open source is typically of high quality and can be counted on to run reliably. That doesn't mean you don't have to do your homework before deploying it.

First and foremost, you now have to contend with GPLv3, the recently updated version of the Free Software Foundation's General Public License. GPLv3 imposes restrictions on digital rights management and embedded Linux that might prove troublesome if your company plans to resell code based on open source.

InformationWeek Reports

GPLv3 applies to a minor part of open source code so far. Only 693 projects are issuing code under it. By comparison, 5,219 projects license under GPLv2 "or later," meaning the same code is available under both licenses. GPLv2 projects were never expected to convert en masse to GPLv3. That will happen gradually as developers decide on the merits of GPLv3 when releasing new or updated software.

The Opportunity
With open source, you avoid front end license fees. Support subscriptions are often priced below commercial product support, or support is available in free, public forums.
Projects generate market-leading products, such as the Apache Web server. Strong projects attract top programmers and become self-sustaining.
Make sure there's a thriving community around what you adopt to assure continued code development and support. Examine how fast bug issues are addressed; long delays may be a flag for trouble.
The Linux kernel still is issued under GPLv2, but some of the add-ons, such as the Samba file translation package, will soon be out under GPLv3. So Linux from Red Hat, Novell, and other major distributors will contain both GPLv2 and v3. That means "you've got to evaluate open source code before it comes in behind your firewall," says Theresa Bui Friday, co-founder of Palamida, an open source code auditing company.

The reliability of Linux, Apache, and Samba is well established, but that's not the case with newer projects. If you're assessing prototype code, project mailing lists provide a view into issues and features and give potential adopters a sense of what to watch out for. A list that airs a bug or security exposure also will supply the dates around when a problem appeared and got fixed. A project that has a major exposure that endures for six months might be code to avoid.

Sites such as and provide stats on a project's activity level. How many contributors are there? How frequently is code posted to the core build? How many bugs are awaiting fixes? The degree of activity can be signs of whether a community is thriving or waning.

There are a few ways that new code can be quickly vetted. Tools shown to work inside the Eclipse programmer's workbench or applications that work with have already passed a fundamental test of reliability and compatibility. Software that's been OK'd for inclusion in one of the software stacks, such as LAMP (Linux, Apache, MySQL, and Perl, Python, PHP) is another quick measure of reliability. SpikeSource, Covalent, Red Hat, Novell, and SourceLabs vouch for certain pieces of code working together. Sun Microsystems also tests and distributes PostgreSQL, MySQL, and the Apache Foundation's Derby Java database to work with Solaris and other Sun software.

Such ratifications by experienced groups are important. But you don't want to get in the situation where the software is theoretically compatible but the companies or groups behind it aren't and will stop short of troubleshooting joint operational problems.