“So what do we do? Anything. Something. So long as we just don’t sit there. If we screw it up, start over. Try something else. If we wait until we’ve satisfied all the uncertainties, it may be too late.” Lee Iacocca
I came across Iacocca’s statement late last week, and it struck me as an appropriate summary of the meeting we had on Friday, June 1, with a number of thought leaders from the open-source software community. For almost two years now, we at the NCI Center for Biomedical Informatics and Information Technology have been talking about how to create an open-development ecosystem around the digital resources that have been developed through the caBIG program. We recognize that meeting the challenge of creating robust and useful tools to support the rapidly evolving needs of the cancer research community requires an open and collaborative approach to software development. The good news is that is that all of the software that has been developed through this program is already open source, under the non-viral caBIG Open Source License, and in fact, several groups have downloaded code and customized it for their own local needs.
But this is only a start. The software release cycle for these tools is still managed by the government through government contractors, and there is no straightforward mechanism for community members to contribute enhancements and bug fixes back to a project. Therefore, customizations that may be freely offered and broadly useful are not readily available to other groups. Moreover, organizations that have a locally customized version of the code who want to upgrade to the latest version cannot readily do so, and therefore will be out of synch with regular releases.
“You can’t get there from here.” – common New England saying
This saying has come to my mind on several occasions as we’ve struggled with the challenge of moving from our government-controlled style of software development to one that is collaborative and community governed. The saying doesn’t literally mean you can’t get there, but rather that it might be hard to do so. And indeed, finding the roadmap to get “there” from “here” has not been easy. For starters, we studied other successful open-source communities, including those of Apache, Eclipse, Mozilla, and Google. And we have watched with great interest the efforts of the Veteran’s Administration and NASA to create open-development communities around their software products. We’ve attended OSCON, POSSCON, and a variety of open-government meetings to educate ourselves about the breadth of issues and challenges we need to consider.
We have taken a few early steps in the direction of building an open-source ecosystem around cancer research informatics. One has been to establish a Community Code Resource Directory, a simple “yellow pages” of open-source tools developed by the cancer research community. To be listed in this directory, we only require that 1) the code is open source and readily available; 2) the license for the code is made apparent; and 3) there be some minimal documentation on how to install and use the resource. We have also fostered the community of interest that has grown up around the open development of caLIMS and have found that people are happy and willing to volunteer their time when a project directly aligns with their scientific priorities.
Last June (2011), we issued a broad Request for Information (RFI) to seek input from the open-source community about what our larger open-development ecosystem should look like and how to get there. It was clear that getting these folks in the same room with us and hashing out how to initiate and foster our open-development ecosystem would be immensely valuable. And while it took some time to take this next step, that’s exactly what we did. While the total number of responses was modest – about 20 – we received salient advice from a representative cross section of open-source thought leaders. Twelve of the RFI respondents came to our Rockville offices and spent a full day engaged in a wide-ranging, thought-provoking conversation about how to effect this transition. Their advice can be summarized fairly succinctly:
- Keep it simple. Make barriers to entry as low as possible, and reuse available resources. NCI should adopt a standard open-source license, and move away from the custom license currently in place. The existing open-source licenses are vetted, available, and well-understood. Move the code off of NCI servers as soon as possible and deposit it into one of the open public repositories like GitHub or SourceForge.
- Let the community decide. For an open-source development ecosystem to be successful, it needs to be truly owned – and thus built – by the community. The community needs agree on the appropriate governance processes and determine the ultimate success or failure of the applications. NCI’s role should be to convene the community, but not to make top-down decisions. NCI will have a seat at the table and be a participant, but it will not have more control than any other community member.
- Purpose-driven requirements. The use of standards and any concept of “certification” should be established based on real needs and use cases. Even the concept of “compliance” should be crowd-sourced as much as possible.
- Don’t over-think the process, and stop waiting to do something – fail early. Don’t wait for the code or process to be perfect. Put the applications out there and let them fail or succeed, as determined by the community.
So getting “there” from “here” isn’t a matter of asking GoogleMaps for the shortest route. Rather, the process involves heading out in the general direction of where we want to go and maybe taking some wrong turns. But very importantly, it involves finding the way together with the community.
Juli Klemm, Ph.D., is Associate Director of Integrative Cancer Research Products and Programs at the Center for Biomedical Informatics and Information Technology (CBIIT), National Cancer Institute (NCI). You may connect with Juli via LinkedIn.