Even after 40 years of intense genetics in the model system C. elegans, a large majority of genes have not yet been disabled by deletion. Although targeted deletions have been possible in flies and mice for years, the technology has been elusive in worms.
At WormBase, we’ve been busy re-writing the website from the ground up to build a modern information discovery space that will generically handle genomic data.
As the project manager, I made the executive decision to switch from CVS/SVN to a distributed version control system (DVCS). I’d used both git and mercurial personally for over a year and enjoyed their flexibility.
And given the already distributed nature of our project, DVCS was a natural fit. (In fact, I believe that DVCS should be roundly adopted across the genomics/bioinformatics research sector precisely for this reason).
If you’re considering or in the process of switching to Mercurial, I highly recommend checking out Joel’s tutorial and circulating it to your team.
As the number of online biological databases explodes, how will we ensure their availability over time?
I received a help desk request this morning from a user looking for an old bioinformatics project. The user had stumbled across a broken link for the project’s supporting website listed in the publication just a few years ago.
This project is now completed, no longer funded and no longer staffed. It may be over but expectations that the resources it created should continue to exist live on — in links from the original publication, in citations, and in search engines.
This particular project happens to be hosted on a heavily taxed machine that I administer. This machine itself is nearly obsolete, out of warranty and chugging along on its last legs. And as an essentially redundant production node in a cluster, it isn’t backed up.
Now, I know in part I should be responsible for anything that’s on a machine under my purview. But I’m not a system administrator by interest, job description, or training. It’s just one of the hats I necessarily wear.
But software and operating systems evolve, security updates are released and legacy software breaks. Without dedicated maintainers who know precisely what they are to maintain and how, legacy resources will quickly become obsolete. Ironically, perhaps only the printed record will testify to the fact that these online services once existed.
This conundrum raises a number of interesting questions.
What responsibility do we have to ensure that online resources generated (directly or indirectly) as part of publically funded projects remain available after their funding has run dry?
If we have a duty to ensure that these resources remain available — and I believe that we do — what is the easiest way to do it?
Should there be conditions on grant funds that code be documented, hardware requirements stated, and maintenance details described? Like reagent sharing requirements, perhaps there should be a burden-of-proof of resource longevity provided as a condition of publication?
Should there be a final review from funding agencies at the time of project completion to ensure that suitable plans exist for maintenance of the resource?
Minimally, when a project winds down, there should be a final document drafted describing in detail the maintenance of the resource. It should include a simple manifest describing the data, the website, software version dependencies and hardware requirements. And an accompanying tarball when feasible for facile restoration would be appreciated, too.
Virtualization is also an attractive approach. But virtualization — like the transfer of data from one storage medium to its successor to prevent obsolesence — has maintenance overhead to be factored in.
But after 10+ years of the development and disappearance of online biological resources, perhaps we need to consider a consolidated public repository, one established under the auspices of Ensembl, NCBI, DDBJ, or NHGRI — to host and maintain orphaned projects.