”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.
-JK
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.
In fact, this open-source development environment already exists in many forms. See github and bitbucket for general approaches that lead to code sharing, crowdsourced metrics (followers, commits, etc.), and communication (issues) and feeds. Some of the most popular and successful open source projects are now housed in public, social repositories.
Hi Sean,
Thanks for your feedback – this is a great point. We are, in fact, actively investigating depositing much of the code into one of these public repositories. It helps tremendously that the federal government already has terms of use negotiated with some of them, including GitHub and SourceForge.
Best,
Juli
Wonderful post, Juli. It’s great to see that something is coming of our Community Code Contributions and Integration Working Group. We had were tons of great discussions there that, I think, will hopefully play out in a positive way over the coming months/years. I can tell you that the community is ready to innovate.
I read your comments and skimmed the minutes of the meeting but nowhere did I see anything about involving end users in the softward development cycle. Everything is geared toward the technical users and this was one of the biggest problems, from my prospective, in the 8 years of caBIG. The needs of the community, needs to be representative of the needs of the people who the software is developed for, not just the people responsible for writing the coding and maintaining it. This should be one of the first precepts laid down in this new process in my opinion.
Hi Diane –
Thanks for your comments and for taking the time to read my post as well as the minutes of the meeting. Your point is well-taken – keeping the users’ needs front and center is critical to any successful software development effort – and that’s one of the reasons we are moving to the OSDI model. By moving the software to an open-source environment and opening it up to a wider community, it creates the opportunity for every participant in that community – whether a developer, an end user, someone representing an organization, a government representative, or a patient – to have as much influence as any other in the creation of requirements and the priorities for development. It also allows those who are engaged to invest in the development if they have specific needs. Clearly, an organization or individual will not invest time and money in something that doesn’t have a direct benefit to them.
In our meeting on June 1, which the notes captured, we were quite focused on the process of transitioning our components to this new OSDI environment (i.e., “getting there from here”), and not so much on how the development life cycle might be run once this transition has occurred. By definition, a well-run open-source environment must be driven by the community itself – the participants will determine governance and process. This is another way we are ensuring that control of the applications is in the hands of the community, and that’s really what I meant by two of the main points in my blog post – “let the community decide” and “purpose-driven requirements”.
Thank you again for your thoughts – keep them coming – and for participating as a patient advocate in our programs.
Best,
Juli
Great post! If NCI really follows through on this plan, I have great hope for the future. The one thing I would add is that it is important for NCI (and all of the NIH) to understand how essential their funding is to the academic research ecosystem. There is lots of room for discussion on what and how to fund, and how that funding should interact with open source software, but without funding, an academic biomedical informatics community will not exist.
Hi, interesting post. I have been wondering about this topic, so thanks for posting. I’ll definitely be subscribing to your site. Keep up the good posts.
Everything is geared toward the technical users and this was one of the biggest problems, from my prospective, in the 8 years of caBIG. The needs of the community, needs to be representative of the needs of the people who the software is developed for, not just the people responsible for writing the coding and maintaining it.