In light of the current fiasco surrounding TrueCrypt, I have received considerable criticism from current clients and peers in the IT industry for my continued support of the open-source model. Such criticism is usually lumped in with ongoing dialogue on the virtues and failures of the open-source model following episodes such as heartbleed. I have attempted to point out that in spite of many news articles labeling TrueCrypt as open-source, the source-available label found on Wikipedia is more correct.

It conjunction with that distinction, I have argued that having the source code available for review is inherently more secure than not, but that it should not suggest the same level of trust as a project that follows an open-source development model including allowing redistribution of modified work. While my gut tells me this is a reasonable position to take, the difference is subtle and my ability to communicate it convincingly is limited.

Are there more concrete evaluations to go on than just my gut here? Is there a measurable difference in the relative security of source-available applications vs true open-source counterparts? If so, is it well established what factors exactly contribute to this? What about the OS development model specifically results in more secure code than just releasing code for review? Or does this boil down to opinion in the end?

Edit: does it make any difference whether the specific software in question is cryptography related?

  • To be fair, it is noteworthy that TrueCrypt's license still hasn't been publicly audited yet. I believe that is supposed to be Phase 3 of the current audit at IsTrueCryptAuditedYet.com - which the auditors have committed to completing, despite whatever TrueCrypt's future support status may be. It may actually be closer to Open Source than not, or it may be much more closed than anyone anticipated.
    – Iszi
    Commented May 29, 2014 at 18:24

3 Answers 3


Source-available (SA) differs from true open-source (OS) that there is no right to fork. That means when a security flaw in a SA software gets known and the developers refuse to fix it (which doesn't have to be out of bad intentions - it could just be lack of resources), users do not have the option to fork the project and continue the project under a new name with a new team.

However, should a flaw in a SA project be discovered and made public, continuous refusal to fix would hurt the reputation of a SA project badly and drive users away from it.

Some OS proponents claim that the ability of everyone to offer a patch for a OS project results in faster bugfixes. However, this only applies to a part of OS projects: Those which follow the Bazaar development model and not the Cathedral model. There are many OS projects which do not accept unsolicited contributions from 3rd parties. A bugfix could still be offered independently so users can apply it manually, but that's a maintenance overhead many administrators and users shy away from.

And forking a project because of a single issue is usually more trouble than its worth. I witnessed several forks of open source projects as part of either side of the fork. The result was always that it hurt the overall progress of both forks because development resources got diluted, infrastructure and management structures had to be duplicated and users got confused. Trying to hold a project together despite any conflicts usually pays off.


Open source and source available, as general categories, are identical in their security implications. The key benefit is faster discovery of bugs/inefficiencies/vulnerabilities; many hands make light work. In practice, the value of this benefit will vary based on the size of the community interested in the project and thus the number of people looking over the source code.

Regarding the example given: the message from TrueCrypt merely indicates that support has been discontinued. Giving advanced notice would have been nice, to say the least, but such an action is not restricted to open source (or source available) entities; private corporations discontinue products all the time. If they do it less often, e.g. because people are paying them to provide continued support, one should recognize that hiring or otherwise paying open source committers for continued support of a product slated to be discontinued is always an available alternative.

Availability of continued support has always been, and should remain, a key consideration regarding the suitability of a given product for a particular task, open source or otherwise.


In my experience the question is so broad and the prejudices so deeply ingrained that you may be wasting your time trying to argue the case on either side.

Closed source projects/organizations do not readily give up their code for analysis by an independent party - and even though will only usually do so uner an NDA, therefore any such analysis is likely to have very high sample bias. However here's a couple:

http://osswatch.jiscinvolve.org/wp/2012/02/28/open-source-matches-proprietary-code-quality/ http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/ICSOC2013_50_Open_Source_Versus_Proprietary_BPEL_Engines.pdf

For further discussion see also:

http://courses.cs.washington.edu/courses/csep590/05au/whitepaper_turnin/oss%2810%29.pdf http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/open-source-security.html http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html

Given that the facts about Truecrypt are yet to emerge, it's hardly a poster-child for either side of the argument (open-source software was not the reason RSA, Lockheed-Mrtin, Washinton Post and others got hacked).

  • 7
    Please note that I did not ask about closed source/proprietary software. That apples-to-oranges comparison and the prejudices that go along with it are beyond the scope of this question and mentioning them does not shed any light on the case of OS vs SA.
    – Caleb
    Commented May 29, 2014 at 13:00
  • True, but with the exceptiona of a small number of multi-national companies and most states, the difference in your ability to resolve issues between closed source and source-available is trivial. Having said that, if you have the source you can easily measure the likely quality with static analysis.
    – symcbean
    Commented May 29, 2014 at 13:03
  • 3
    In that case shouldn't your answer be "the difference is trivial, and here are some sample statistical analysis of the difference", not "the question is so broad you are wasting your time"?
    – Caleb
    Commented May 29, 2014 at 13:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .