In light of the current fiasco surrounding TrueCrypt, I have received considerab

Question

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.