I am a librarian not a developer, nor am I the decision maker on software choices, but I thought I would comment on the Hydra and Islandora discussion to just add the UCLA perspective.
We decided to stop doing a home-grown digital library system a few years ago, and we chose Islandora over Hydra at least for the next year or so. We're definitely committed to Fedora in the long term, and we might try out Hydra in addition to Islandora.
With a small shop of talented Java developers (4 full-time when fully staffed), we felt like we needed to select a system that we could contract with additional vendors for special projects. We saw Islandora with PHP and Drupal as being an easier match for hiring contract workers as opposed to Ruby on Rails. Nor did we have any Ruby on Rails experience. In addition, the platform selected for the UCLA Library website and the UCLA website is Drupal, so we feel like there is more opportunity to collaborate.
Relative to the Drupal and Islandora issue, we contracted for the development of the Islandora Sync project to alleviate the Islandora restrictions on using Drupal to its fullest.
Elizabeth "Lisa" McAulay
Librarian for Digital Collection Development
UCLA Digital Library Program
On Feb 21, 2014, at 4:31 PM, "Fleming, Declan" <[log in to unmask]> wrote:
> Hiya -
> 1) after years of doing everything ourselves, we decided to join the Hydra community for our discovery and display layer (and soon for simple ingest and metadata edit). We still have a custom back end repo with an API that can make it look enough like Fedora that we can use stock Hydra. We were initially drawn to Islandora because we love Drupal, but found that Islandora's approach to Drupal was going to be pretty code intensive to modify the way we wanted. Since we knew we'd be doing a lot of coding anyway, we gave Hydra a shot and, with help from DCE (consulting firm Data Curation Experts who did some of the core ActiveFedora work), we had a prototype up in 3 months, and just last week we announced our public beta:
> DSpace didn't fit our metadata or digital object complexity needs. We've been working with complex objects for years, devolving lots of metadata standards into RDF and putting them all into a central triple store. For an example of a complex research data object:
> On the right panel, tweak the twiddles to see the hierarchical metadata and subfiles, or click the "Data at Redshift=1.1 (RD0025) Components" link at the top of the right column to see the whole structure.
> The killer feature of Hydra was that our Java shop could absorb Ruby quickly enough to be productive quickly, due in NO small part to the community surrounding Hydra. Forums, IRC, and github got us going very quickly. The steering committee is quite active and knows how to talk innocent universities into hosting its events ;)
> 2) I think I've touched on the dev experience - Ruby has been great, and the test driven mentality has made our code very strong and reusable. We've also formalized an internal Agile method with regular 2 week sprints. Having a known code base to start from helped with this.
> Your migration question is interesting. Like I said before, we've still got our locally developed backed repo, but we're seriously investing in Fedora 4 (by committing FTE to its development) so that we could possibly move to it in the future so that all of our repo work will be OSS and sharable.
> I do love that there are at least two vibrant communities in this space, and it kinda broke my heart to pick one over the other. I keep a close eye on the amazing work coming out of Islandora and dream of an architecture where we can slap these things together with a common repo and a thick (or maybe thin and smart) API.
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Brown, Jacob
> Sent: Tuesday, February 18, 2014 2:43 PM
> To: [log in to unmask]
> Subject: [CODE4LIB] A couple quick questions for Hydra or Islandora users
> Greetings! A couple quick questions for Hydra or Islandora users/developers:
> 1) What made you choose your framework over others (for example, DSpace)? What is its "killer feature"? Flexibility? More metadata options? Availability of SPARQL endpoint? Language? The community?
> 2) What has your experience been like developing within that framework? If you migrated from another digital asset management system, what are the comparative strengths/weakness of your framework?
> Jacob Brown
> Digital Services Librarian
> [log in to unmask]