Do we need visibility into open source?

The searchlight seems to be shining on open source software more than ever right now asking for visibility into form and function to ensure vulnerabilities and instabilities are avoided. HP’s recent FOSSology announcement claimed to launch an initiative to, “Facilitate the study of free and open source software by providing free data analysis tools.”

While these developments appear to be, on the surface at least, creditable programmes to further the cause of quality code creation – one can’t help being drawn to a quietly sceptical thought that these processes (even in the world of open source) will always be engaged in by vendors with one eye on profits. So what’s the real issue at hand here?

The problem, I think, may be down to the fact that open source software development is not inherently more risky - but it is the nature of the way development is done that allows potential issues to arise. Specifically, I mean that there is often less documentation, annotation, reporting and recording in open source.

I read a research study on this from Palamida (a company that bills itself as a specialist in application security & vulnerability detection for open source) and they say that their professional services group last year viewed hundreds of millions of lines of code in applications across multiple industries – and that it was rare for them to find an application that was not made up of at least 50% open source.

Palamida’s study says that these are the factors to question yourself on if you work in open source: what open source code are you using, where are you using it, how much do you have, what security vulnerabilities are associated with it and what are your rights for using it?

So where do we go from here? Well, some say that as open source software gets better and better – there is a possibility that its success will form part of its downfall (or core flaw least). If it works just “too darn well” then a programmer may simply pull down some code from the web, configure it into his or her system and then forget it – leaving no documentation or records to support a fellow coder who comes along three years later with the task or a major reconfiguration and system upgrade.

But no need to worry – that type of thing never happens in the real world. Right?