I was very interested to read Paul Withers’ article, 10 Reasons All Companies Should Use Open Source. I agree with many of its points, but wanted to bring up one caveat that seems too often ignored. If I might throw some caution on his first point, 1. Good Developers Write Good Code, Great Developers Steal Good Code, it would be to remind people that great developers can steal bad code as well.
As the Goto Fail vulnerabilty
, and even more the Heartbleed Bug
should remind us, the fact that code is widely used or open source, even widely used open source, does not absolve a company using it from testing. It should be assumed to be buggy, insecure and incomplete until proven otherwise. Personally, I think any open source library added to your own software should be treated as if it were written by the most junior developer. It might be great, but it also might have glaring holes that are waiting to trap the unsuspecting. As I wrote
when the Goto Fail vulnerability surfaced, the great failing was not that the code had a bug. All software has bugs. The great failing was that Apple’s QA didn’t adequately assume it might be vulnerable and try to attack it to see if they could get through. As the Heartbleed bug proved shortly thereafter, the problem was even more prevalent when the code was open source, as it seems that many companies trusted OpenSSL when a relatively straightforward QA test should have shown that the vulnerability existed.
Trust but verify. Open source code (and your own code for that matter) may be very, very good, but you should test it as if it were buggy, insecure and incomplete. Do not trust "the crowd" to do your verification for you. In fact, with open source code you should add the element that a nefarious somebody may have planted a subtle vulnerability, so you should push the limits and assume the worst.
Note: If you find any problems, especially security issues, you should make sure the open source code is fixed and submitted to the originator as well.