How Avalon differs from YouTube or a DAMS

(Last week we noticed that the Duke Digital Media Community featured Avalon in a blog post. Though they don't plan to implement Avalon at this time, we were very happy that they took the time to write about how they made this decision. Since our response might help other potential adopters of Avalon, we wanted to post it on our site.)

The Avalon Team is happy to see you take notice of our work! You are quite right that we are not targeting the YouTube-style end-user upload use cases, and Kaltura-killing is not on our to-do list. Nor are we trying to compete with MAM/DAM systems, where the focus is on managing content for internal use by media-generating organizations.

The needs we are squarely focusing on are those of libraries and archives, whose needs are not well met by any of the open source solutions available today. Neither are they well met by more than one or two expensive commercial systems. It has been a major activity of our work to explain to IT organizations why library and archive needs are not addressed by the kinds of media solutions initially adopted by campuses. In what ways are these needs not well met?

• Metadata for the long haul. Although we are planning to rework our content ingest process to provide a better manual workflow, part of the reason all the steps are there is that library content, unlike the latest video from a cell phone, needs to be discoverable and accessible for a long time. Most course lectures and assignments tend to be ephemeral in nature rather than needing to be reliably found and viewed ten years hence. Of course some user-generated content does merit long-term preservation and access, but when it does, the content ends up having metadata requirements similar to any other curated library content.
• Metadata for navigation. Most of the generic streaming media players simply provide a scrubber for navigation, on the assumption that most content is short. This doesn't work well for longer items such as operas, ballets, plays, or feature films. Adding structural metadata for chapters or tracks helps considerably. 
• Flexible access control. Academic libraries and archives provide content under a wide variety of access control schemes. Rights differ across materials. Rationale and risk assessments differ across institutions. 
• Security. Most streaming media systems either have no security or security by obscurity. Avalon is being designed to support delivery of highly sensitive content, whether for reasons of intellectual property protection, cultural sensitivity, human subjects protection, or other privacy concerns.
• Integration. Avalon aims to integrate with pre-exisiting digital object repositories (such as Duraspace's Fedora) and enterprise media servers (such as Adobe's). Although many systems do integrate with institutional authentication and authorization, other integrations, such as with library catalogs for automatic import of descriptive metadata, or support for course reserves, are found only in systems that grow up within library environments.

So these are some of the distinctive needs Avalon aims to address with a freely available open source system. That said, we know Avalon will be used for scenarios beyond those we are intentionally addressing, and Avalon will likely be useful in ways we do not currently imagine. The Duke evaluation raises some good points and also identifies information gaps we can address here.

1. The manual upload sequence of pages is indeed clunky, though we find people are able to be successful with it. We are planning to revise it, with the aim of making simple things simple and hiding optional complexity. But it is also worth mentioning that we expect most Avalon content will not be uploaded manually. We have a batch upload capability we expect to be the primary means of adding content: collection managers will put the master (or mezzanine) files on the server, along with a descriptive spreadsheet. Avalon then automatically ingests and processes the items and can even auto-publish them. Of course, this feature is more helpful for libraries and archives than for an individual submitting an assignment or example.
2. Many institutions, like Duke, are looking for hosted solutions. For that reason, we are being careful to avoid licensing encumbrances (such as GPL) that would deter third-parties from picking up Avalon and offering it as a service. We expect one or more third-party providers to provide application hosting and related services, but it's a little early to start recruiting them.
3. Player embedding is on our list of development priorities for early next year.
4. Regarding Shibboleth, Avalon uses a Ruby gem called OmniAuth for authentication, and therefore supports several dozen authentication strategies with a minimum of implementation and configuration required to set them up. The difference between the default "identity" strategy and full integration with Northwestern's LDAP directory, for example, consists of 8 lines of code and a 10-line configuration file. IU's CAS integration is slightly longer at 23 lines of code and 10 lines of configuration, but only because it has to do a secondary LDAP email lookup after login. There is a third party, well-documented Shibboleth strategy available for OmniAuth, and it looks just as simple to configure as the ones mentioned above, with the addition of one stanza of Apache auth configuration.
5. Thanks for pointing out we missed listing wmv in our supported formats. We’ve now updated that document to be current. We use HTTP live streaming to support iOS devices.
6. We haven't yet tried or prioritized Wowza integration.
7. The Engage player can be slow to start up. For this and other reasons we are investigating switching to mediaelement.js as our player of choice.
8. The test site upload limit is due to disk space on the test server. We have been testing the system with files 50GB and larger, though not, of course, through the web browser. That's what the Avalon dropbox is for.
9. We are currently implementing "collections", which will provide something equivalent for "my media", enabling collection managers to view their own collections (and preventing them from modifying collections for which they do not have editing privileges. Even in the existing system, "collection" is a facet you can filter on.

Finally, we’d like to point out that we have only recently release version 1.0 of Avalon. We have releases scheduled roughly every three months, so we are early in the development process and welcome input and evaluation such as this as Avalon makes progress.

Thanks again for the helpful review!

The Avalon Team