A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.

However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.

Suppose your enterprise is one of those which are attempting to “do more with less” (as we all are), and further suppose that the task of building, testing, and deploying “something new” falls to the technology group that has expertise in doing “other things.”   It isn’t too much of a leap from here to see where the technology choice for “something new” might be guided by price.  After all, if the CFO’s daughter’s grade school can download a “something new” and make it work then surely the enterprise technology group can do at least as well.  Does this sound familiar?

Returning to our theoretical DIY (do it yourself) technology team, we find them diligently at work deploying and debugging the aforementioned “something new.” As is often the case, something goes awry when following the published documentation. As you are undoubtedly aware, when technologists find themselves in unfamiliar territory they tend to rely on the “wisdom of the collective” to solve problems.  This phenomenon is well expressed in the Tech Support Cheat Sheet published in a recent XKCD.   The prevailing thought goes along these lines, “surely someone else has had the same problem, and was diligent enough to document the experience for the good of the order.”   Therefore, after plugging the salient details into their favorite search engine, the erstwhile tech team awaits the wisdom of the oracle.

What follows are excerpts from  “free advice” to searches related to diverse “something new” deployments on a lab test bed over the past several weeks:

-                       chmod 777 fixes  this

-                       grant all on database.* to  …

-                       allow tcp any  any

-                       community  public

-                       allow tcp  23

-                       do not change the default  password

-                       allow from  any

-                       security  manager=”no”

-                       disable rules which generate  excessive log entries

-                       allow root login:  yes

-                       everyone  fullcontrol

-                       chown -R www-user  *

-                       allow-update { any;  };

In almost every case the first several rounds of online advice included advice to RTxM in various states of  dudgeon, and if reading the fine manual didn’t suffice there was always some  well meaning individual with an expedient (though potentially dangerous) solution: “I did X and it works!”

And what about the water heater? One of the Risk Team members’ water heater died a few weeks ago, and as he had never experienced a water heater replacement in any home, he asked for any advice his colleagues might have to offer.  After much discussion about what sorts of plumbing problems qualify as “DIY” , Bill Murray of the RISK team gave the following advice: “Do it  yourself. You will learn a lot that you will never use again.  You will also learn that even when the pros are not cheaper, they are still worth the difference.  You will use that over and over.”

So, in wrapping this together I would say that one of the significant risks posed to the enterprise by “economically driven DIY” could result from situations where “community advice” might make its way into production without appropriate review and control.  Clearly this is not the problem when the enterprise has “the pro” plumbers on staff or on call.

Tags: open source code, opensource, risk

This entry was posted on Monday, September 21st, 2009 at 9:13 pm and is filed under Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.