pluses and minuses of the Manakin interface development

This evening, I'm reading an article published in the last week by five computing professionals who work at the Texas A&M University Libraries. They describe their development efforts for Manakin, which is "an abstract framework that provides for the creation of individual, customized repository interfaces." Manakin is associated with the DSpace repository software, which is employed by the WSU Libraries for its Research Exchange service.

Manakin's ability to support customization at the DSpace community or collection level is extremely valuable. The metadata visualization support described by the authors is also intriguing, such as support for timelines for date information.

Perhaps the most important benefit is using Manakin is its "extension framework" or an API, enabling the creation of new extensions to the software. Additionally, as noted at the conclusion of the article, the authors envision Manakin's application to additonal repository systems, enabling multiple repository silos to be searched from a single interface, ideally with search functionality beyond that supported through OAI-PMH.

I have to say, though, that I have concerns about the software development described in this article. As Phillips and his colleagues note, Manakin will eventually be adopted as the default interface for DSpace. But how broad is the current Manakin development community? The article is written by four computer analysts and a computer science professor. There appears to be a lack of diversity in the A&M DSpace interface design efforts, which may help explain the team's earlier decision to dead-end an earlier development path (see the Manakin-Moa discussion). While Manakin could be used to support content recruitment, as described in this article, it's unclear whether the community envisioned by the authors in the concluding section will actually emerge, given the technical complexity of this solution.