Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

closed as primarily opinion-based by HopelessN00b Dec 5 at 12:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

7 Answers 7

up vote 17 down vote accepted

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.
share|improve this answer
    
How do you determine the maturity of a program? It's not like version numbers mean anything, and lots of projects sit at odd version numbers for years in wide use. (I'm looking at you NetworkManager). What would be a red flag of immaturity? –  jldugger May 28 '09 at 4:38
    
Correct, while it is possible for version numbers to have some specific meaning to the developers, that is an internal thing - the the outside world it is merely an indication at best - one that enterprise software seem to try and exploit with ridiculous version number jumps. To get an idea of maturity, you can look in a few places, specifically the ticketing system - lots of tickes is a good thing - specially if you can see the developers have made a real effort in fixing and closing them. On the other hand if you have no tickets, or worst, no ticketing system, well it's not a good start. –  Xerxes May 28 '09 at 4:55
  • 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.

share|improve this answer
    
++ for activity requirements. –  sh-beta May 27 '10 at 20:33

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.