The perceived risk of OSS

>> Sunday, September 27, 2009

It is my experience that managers in most large corporations still feel threatened by OSS (open source software). Managers are insecure with the idea that software modules (I will adopt the term "artifact" from the Maven parlance) can be introduced more or less intentionally and very easily in software systems. In the Java world, OSS modules are just part of the landscape and nobody reasonably envisages the development of general business applications without taping into the rich OSS ecosystem. Furthermore, a build system like Maven works on the premise that it has direct or indirect access to different public artifact repositories. Moreover, industry standard frameworks such as Spring are built and operate on top of a stack of freely available and industry standard open source artifacts.

I recently performed an audit on various Java-based applications under development in a large organization. The assignment was to generate the list of artifacts used by the various sub-projects. The concern was that developers were using "unapproved" and potentially "dangerous" artifacts. A first analysis revealed that, all in all, the various projects used or included approximately 140 different OSS artifacts. That revelation came as a shock to most managers but was not a surprise to me. In any event, the result of the audit did not calm the worries inside the organization.

In an effort to get a better grasp on the issue, we removed from the list all artifacts that came as dependencies of either Spring or Axis2 (the two main frameworks used by the projects) and of a third, commercial system that was central to the overall solution. This reduced the number from 140 to less than 20. In other words, what was first perceived as the result of somewhat uncontrolled, developer initiatives ("anybody could and was adding dependencies to more or less obscure artifacts") was in fact the result of using industry standard OSS frameworks (Spring and Axis2) and of a commercial system that has dependencies on a large number of OSS artifacts.

To me, the paradox is that many managers perceive OSS as a threat or, at the minimum, a risk while it should be perceived as an opportunity. When you stop and think about it for a little while, if managing risk is an important concern (and it should be)  for an organization that develops and uses software then how do you mitigate risk when developing software? To me, that is a very real and important question.

I agree that risk is a somewhat fuzzy concept and that it can be evaluated from many different perspectives depending on whether you are a legal advisor, a financial officer, a quality control specialist, a security officer, an operations person, a marketer, a software developer etc. You may be concerned by eventual law suits, by the eventuality of  intrusions and/or theft of corporate data, by the perrenity of your supplier and his solution, by the stability and performance of the software, by the short and long-term TCO of a given solution etc.

Now, consider the following options and assess the importance of risks of each one:

Option 1: Develop most, if not all, your software in-house using a large number of freshly hired staff or consultants and go live with N thousand lines of more or less proven code.

Option 2: Minimize the amount of in-house written code and favor the use of mature and well supported and recognized commercial but closed source software.

Option 3: Minimize the amount of in-house written code and favor the use of mature and widely accepted  and recognized open source code.

My own opinion is that from whichever perspective you look at the problem of risk management and mitigation, option 3 is very often the less risky and thus, the better one. This does not imply that OSS should be used without any precautions and guidance. In fact, in the modern world, a new role is required within organizations. I call this role "artifact librarian" and with it, one must put in place systems and procedures to ensure that teams follow guidelines and policies from both a technical and a legal standpoint. That being said, the objective of the organization should not be to restrict or limit the use of OSS. On the contrary, it should be to encourage it while managing the OSS selection and introduction process.

So long,


0 commentaires:

Post a Comment

  © Blogger template Webnolia by 2009

Back to TOP