The move to Github is a powerful one, and one that we know will foster a strong, active community.
When we started building OpenClinica more than eight years ago we wanted to build a community around it and one has really emerged. I’ve personally been able to interact with hundreds of users over the years and I’ve learned a lot from them. People have been pushing the boundaries; starting their own user groups (all over the world!) and building cool tools and add-ons for OpenClinica. The only downside is that I don’t think there has been enough visibility into what other people have been building – but why? Perhaps the right tools for sharing weren’t in place.
Github lets you fork, pull request and merge! Not only that, but you’ll get credit on your Github profile for pull requests that get merged. It’s like the social networking of code contributing. We really want to lower the barriers to solid contributions. In the past two months we’ve gotten five pull requests and two are in the process of being merged and will be in the next release (3.4). Of course, we’re really excited about this and look forward to more contributions. We really want this process to be simple, transparent and fun. Let us know what you think!
You can find us on Github here: https://github.com/OpenClinica/OpenClinica
And for more info on our road map, you can check here:
The impact of the open source model on security is an oft-studied topic. Rather than try to add anything new, I wish to point out some helpful references and try to address a couple of common misconceptions I have encountered in the clinical trial software and enterprise IT communities.
First of all, using an open source application, database, server, etc. DOES NOT mean that your data is accessible to anyone who tries to access it! Astonishingly, this is a fairly common misconception for people who only have a casual understanding of what open source software is. In fact, open source software powers some of the most secure software systems on the planet that require highly regulated, very fine-grained control over which users can access certain data.
Security in open source software is based on a rejection of the “security through obscurity” concept, and instead relies on an approach far closer to the centuries-old scientific model of peer review. From the beginning of a project, open source developers understand that their code is going to be subject to review and critique by a potentially large community. Rather than simply making vulnerabilities hard to find, open source developers have to rely on sound architecture and design principles. System access privileges, user authentication rights, and encryption features cannot easily hide “back doors” and each programmer is motivated to not only produce code that will pass a test suite, but produce code that will stand up to the (often severe) scrutiny of their peers and users. In this fundamental way the open source model has been proven to result in more secure solutions than a closed-source, proprietary development model.
This is not to say you cannot find counter-examples! Of course, any specific technology, open source or not, should be evaluated against your particular security criteria. For further information on this topic, check out David Wheeler’s reasoned, in-depth discussion of open source and security here.