Validation is a key element during the whole software life cycle process. Its purpose is to build quality into a software system and to ensure its reliability. For this reason, it is understandable that companies rely on well-established commercial software products.
High license fees and the call for flexible ad hoc analyses, especially in research departments, are just two arguments that lead to the use of OSS. For this reason, the software environment R for statistical computing and graphics has made its way into pharmaceutical companies. However, once particular regulations are required, e.g. in the context of a FDA submission, the code must be re-implemented for example with C++ or C#. This is cost and time intensive.
One would be lucky to pass down R code developed in a research department to a validated environment. In general, I believe it is a matter of could one find arguments to trust an OSS or not. Here one of the key feature of OSS that the code is visible to everyone can help to make this decision. The possibility of critical code reviews, evaluation of risks and re-engineering of flawed or missing code may make this a suitable alternative to expensive commercial software.
This paper focuses on general strategies to extend trust in the OSS R and in particular attempts to bring R closer to the terms Installation Qualification, Operational Qualification and calling R from other software systems (e.g. Java-, C++ or C#-applications).