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

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.

• 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.

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