Open Source Software and Quality Assurance: A Critical Review
As well as QA, other factors mentioned in the intro are cost/risk analysis and usability of desktop systems. My aims are to find some literature that will be useful for my purposes, not to critique the content. Though I have noted my thoughts on some of the point, it's more as ideas for future research.
Overall, the story is told as a conflict between OSS/Linux and Microsoft. But it's more complex than that – eg the use of Symbian on embedded systems in competion with Windows CE and Embeded Linux not mentioned. Also Sun's ambiguous relationship with Zend (creators of PHP), and retention of control over Java are not mentioned.
I think there is no axis of Evil (or even a monopole of evil). It shouldnt be seen as a battle between good and evil. We've seen where that leads.
Another thought: Non-english language markets maybe protected from MS to some extent…
In conclusion, this paper has provided some useful pointers and food for thought – and debate. But then debate's good for thought!
If you want to see my detailed notes, read on…
Feller & Fitzgerald 2002. The starting point. Describes OSS variation of SDLC, seeing the planing, analysis and design as happening by the founder before the OSS community is created; the community is there to implement the leader's vision.
Locke "Open Source solutions to small business problems " 2004. OSS development is driven by engineers worrying at a lot of small problems
Vixie 1999. (Not in the bibliography; from scholar.google.com, I guess it's P Vixie – Open Sources: Voices from the Open Source Revolution, 1999 – O’Reilly & Associates.) Anyway, the story is that requirement analysis is done by the founder, and that a final product is created and released.
In contrast, my experience is that the community soon takes over the direction of the app, and release is never final, always what's 'good enough'. There's a superstitious fear of reaching version 1.0. Even good, stable products stay at 0.9 at best.
The history of the growth of OSS is given, starting with the development of closed source Unix in 1980s. Microsoft picked up on the resulting changes in the market, and are now the main bad guys keeping source code secret (ignoring recent movements like shared source and standards compliance eg xml – both under duress, admittedly)Stallman's massianistic role in the FSF and its love of 'freedom' as a moral crusade (so american) is the antithesis.
F&F framework of micro/macro motivational factors. Business motivations for IBM and HP support for Linux and Apples for use of BSD are touched on: Apple is seen as free riders, and IBM as oriented towards hardware/consultancy sales.
Raymond 2001: Described as thinking that having access to source code removes a strategic risk. FLOSS report 2004 – 4: Developers survey is also quoted briefly
Development of OSS and SW Development methodologies uses Linux for examples of OSS in both server and desktop environments. Linux's move to increased user-friendliness, desktops and Windows support is described. Wine is used as an example of desktop Linux – but started in 1993 and is still not ready. Maybe this is more typical of a OSS app than Apache or Lunix?
In the section describing Business Use/Standards there seems to be an assumption that Java is open source. In fact, it's propriety to Sun, though the JRE is freely distribute and available on non Windows platforms. Sun uses their 'Community Source licencing' model.
The concluding sectios a review of the reasons for high OSS quality: Large number of developers = quality code (Raymond 2001). A report by Reasoning Inc is quoted: quality measured in KLOC (Errors per thousand lines of code). OSS seen as objectively better.
For me, the crucial question is: if an OSS app cant achieve the critical mass in its community, will it fail or be worse than a commercial product?
Finally, the future of OSS is seen to be in its potential markets: eg embedded systems, government policy such as developing countries want to save money, governments wanting to avoid backdoors. Against that hassles resolving pontential legal issues, though they possibly been resolved by Munich + training and confidence in the futureResearch issues + techniques Getting responses to questionnaires from businesses was an issue…
The appendix details an interesting Perl app to analyse Apache mailing lists to count mailing frequency and time. to close bugs