What warning flags should I watch for when selecting open source software?

Question

When comparing open source projects to commercial software, or even other open source projects, what situations raise a red flag and cause you to hit the eject button and look elsewhere?

Answer 1

Open Source

Look at the project web site

• Look at the documentation
• Look at the mailing list archives
• Look at the SCM (svn, git, hg, etc)

In doing so, pick up on the following points...

• How mature is the software
• What is the user-base size (lots of people? 3 people?)
• Who are the people in the user-base (corporate, home user, small business, etc)
• Is development active? How long has it been active for?
• The mailing list archives also leak a lot of information about the "team spirit" amongst the developers, amongst other things. Does it look healthy, hostile, bored etc?
• Is the documentation decent?
• Has the package/project been accepted into any Distros such as Fedora, Debian, RHEL, SLES, Ubuntu etc? If so - that's a good thing - at least more than one other person out there has faith in the project.
• Does the site have a proper ticketing system? If so - How many tickets are open from 5 years ago? This is another indication of how "live" the project is.

Also, make sure that you take note of the License under which the software is distributed. Some may not be suitable for your needs.

Enterprise Software

I don't have too much to say here other than...

• Make sure (don't ask the sales guy - he'll just lie) that the application does not run as root. Specially if it is going to be listening on a TCP/IP port. * Looking at the reputation of the vendor
• Make sure that the vendors are aware that people administrating this product (i.e. will not be given root access, and so the product must support sudo. Anyone who argues that sudo is not supported is generally just senile, but they're the vendors, and they will be the ones that have to support you - you don't want to buy the product and later have them tell you "No you can't use sudo, you must su to root".
• Never ever buying any closed-source security software - ever
• (subjective): ...and never never trust anything a sales rep says - they're all liars and snakes, no exceptions.

Answer 2

• Lack of activity. If the project has not released new code, show lots of unclosed bugs (or bugs that are very very old with no new bugs), or have user forums that have a very high spam-to-post ratio, that's a sure smell of a decaying codebase. Active projects have regular releases, bug-churn that indicates new ones openned are not outpacing the old ones closed, and user forums with daily activity. All three of these are vital to keeping the code alive and well - release, feeback, and debugging/refactoring, forming a complete loop.

• Activity is proportional to the size, complexity, and maturity of the codebase. The larger the program/project, the more infrequent the point-releases, but there should be a consistent stream of point releases. For a project like Samba, with a large complex code base, expect point releases after a month or so. For a project like gcc, which is a matured codebase with more conservative design goals, point releases are longer in-between, but larger. Fast-moving targets on very small amounts of code also shows potential issues - it could be that the developers are still battling bugs or don't have all of the goals/features coded yet.

• Source code must be readily accessible. Point blank, if it's true open source, there shouldn't be any magic handshake, voodoo offerings, or candlelit incantations involved to see the source code. It doesn't matter if it's accessible through CVS, SVN, Git, Mercurial, or even carrier pigeon, provided that you can get to it without a click-wrap license agreement. If you sign a waiver, NDA, or agree to some un-heard-of license scheme, you're not dealing with open source, you're dealing with a commercial vendor that has agreed to open their source to you - for a price.

Answer 3

There are plenty, really.

Deceptive Licensing - Too many solutions are trying to nickel and dime me to death. The package costs X, but if you want advertised options 1, 2, and 3, that'll be $500-1500 more per option. No thank you.

No one uses it - Or at least, Google can't find anyone talking about it. It's either brand new (in which case, you're a guinea pig) or so bad that everyone knows better

It's the root of several forks - If something has been forked many times over, there's probably a good reason for it, and one of the forks has probably solved the problem better than the source did. Investigate those instead.

Consistently bad interface design - I don't just mean the GUI. Crazy, unidentified, or mislabeled CLI flags or options drive me insane

It doesn't work - or it pretends that a situation that needs to be solved shouldn't (or doesn't) exist, and therefore doesn't address it

Answer 4

I would also add that the code churn rate is consistant and done by many people, not just a few. You don't want one person cranking out code part-time when he gets excited about his project then gets bored of it and leaves it up for community to continue to support. Drupal and Joomla are two good examples.

Answer 5

If you are looking at the software for your company, to sell it, change it, etc. the most important aspect is the license. Looking at the inclusion of busybox on WLAN routers and following legal actions, companies think "open source = do whatever you like".

Some other things: I am also looking for the date last updated and an active community, so forum, maybe other pages that have the software as topic.

Answer 6

On Linux, I would check to see what software is packed by your distro. Packaged software is not limited to just just opensource/GPL - Ubuntu, Gentoo and SLES at minimum include proprietry software in their package lists. While there is no guarantee that these packages will work as effectively as the core software in the distro - someone has invested time and effort to prepare a package.

Answer 7

I'd look mainly at maturity and activity. If it appears reasonably mature and there seems to be a decent amount of activity (forum or wiki activity for instance) then I can feel pretty comfortable. Then I know that there's a good chance that bugs will be solved and that I can get help with issues that arise. I'd choose an active project that doesn't match my needs perfectly, over a project that seems like a perfect match but appears dead, any day of the week.

When it comes to maturity it pretty much depends on the intended use. If it's something that I need to roll out instantly and that cannot be allowed to fail or cause trouble, maturity will obviously be a pretty important factor. If I can live with a few quirks and it's not critical with some downtime, then I'd rather look at the future outlook.