BioPerl

Like any good organism, BioPerl appears to be evolving in response to selection. I love BioPerl, and it's become indispensable to me, but I'm a core dev, so that doesn't count. What does count, IMHO, is that though BioPerl is mature, it isn't ossified.


Last year, one of the cons on Ohloh's quick facts sheet was "declining year-on-year development activity". This year, that's become "increasing", in part because of a big push within the community to provide tools relevant to sequence bioinformatics today, which increasingly revolves around public data retrieval and next-generation sequence data handling. Rationalization of the enormous rats-nest of BP documentation is also underway--which really comes down to creating user-friendly entry points and natural link paths. Perhaps one of the best development efforts this year was simply improving the look and feel of the wiki homepage (http://bioperl.org), with the hope of making it more inviting, and more relevant to *users* seeking answers.


There has been a movement away from BioPerl and towards faster and more efficient tools in C in some circles of the sequence-crunching world. In some respects, this may be due to a drift away from the "glue code" focus that made BioPerl so very relevant during the years of the human genome race. Now, for many devs, OO Perl is just plain fun (= obnoxiously unintuitive and bloated, for others), and it may be that this has contributed to the drift into heavyweight and calculation-intensive modules. Current developement efforts (at least, MY current efforts) are taking the 'Art of War' approach of 'taking whole', providing run wrappers for popular and efficient external programs, and making it easy to plug their outputs into their inputs, and parse the results. Perhaps a return to its roots is just what BioPerl needs to stay fresh and relevant.