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:

http://library.ucsd.edu/dc

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:  

http://library.ucsd.edu/dc/object/bb08204197

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.

Declan

-----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?

Thanks,

Jacob Brown
Digital Services Librarian
[log in to unmask]
817-257-5339