Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Tuesday 4 March 2008, 9:56 AM
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?
PreviousComments on this post
"Specifically, I mean that there is often less documentation, annotation, reporting and recording in open source."
A gross generalisation that also misses the point.
The distributed nature of OSS development makes comparing its methodology with old fashioned proprietary models misleading. What do you think Google's for?
Also Open Source projects exist in their tens thousands - some better documented than others. This fact makes you comment redundant.
Thanks dogStar,
I really appreciate you taking the trouble to comment on this subject as it's clearly a technology topic that you feel passionately about.
While it may be a gross generalisation on the one hand - on the other it is a fundamental truism. It's rather like talking about bread production without mentioning yeast, obvious - but part and parcel of the process.
The software development landscape is indeed as multifarious as you yourself have noted - so to comment concisely on all topics related to it, epsecially in an open source environment, is like putting your head in the lion's mouth everyday.
It's worth it though.
Yes, given the fact that most OSS lacks documentation, discrepancy reporting mechanisms and integration assistance, more visibility would be very useful. As a software engineer, I would definitely prefer to have more than just an API for guidance.
And to counter the prior comment, Google is great, but it does not always provide all the answers. Furthermore, you could spend hours searching for one programming solution via Google; however, if more OSS visibility was available, a programmer could reconcile problems much more timely.
Adrian, thanks so much for the mention of our report. I am encouraged by the words of Terry-Lynn here in the comments section. Palamida is a company founded by developers FOR developers, and thus, it has always been our aim to provide solutions that allow developers to do their job in a more thorough and secure manner. I have to confess that I have not used Google code search for a multi-million line code audit but I have to assume it would have limitations.
When I think about application development, I am considering the tight deadlines, lack of resources, and intense pressure that most developers are under. If you need a piece of code, you're going to go to the Web and download it. Why reinvent the wheel? You include it and move on. However, if you didn't document it (and if it were a smallish piece, would you?) and it turns out that it was somehow an unstable version, you have now included a vulnerability in your application.
Palamida's Vulnerability Reporting Solution was designed with this scenario in mind. You run it at various stages of the build and detect known license and vulnerability issues with open source. You can pinpoint the issues right down to the line in which the code lives in the code base. With this sort of accuracy allowing for immediate remediation, you remove a lot of the headache associated with rebuilds and you produce a more secure piece of software - using open source to its fullest potential. It's a win-win.
Melisa LaBancz-Bleasdale, Palamida
