Most libraries (including every one I've worked at) create a list of
required, preferred, and optional requirements. The basic idea is you make
a grid and check off which of those requirements is supported and move
forward from there.
However, the devil is in the details and the meaning of the word "support"
is so slippery as to be virtually meaningless in both the open source and
proprietary spheres. Even in a perfect world where all software bugs have
gone extinct, support for standards, functions, technologies, and processes
is inevitably based on assumptions of needs which in turn presume things
like workflows, data, etc. -- so it is common to find yourself where a
product can legitimately claim to support exactly what you need and be
totally useless even before you consider whether the product is a good fit
for your environment. Conversely, the mechanisms through which a product
behaves may be able to easily achieve what you need even though it
theoretically doesn't support it at all.
The most important thing is to understand what you need and the mechanisms
by which various products can meet those needs. I personally feel there is
no substitute for talking directly to people with intimate understanding of
your needs who can provide a balanced picture of how a product might meet
On Wed, Jun 7, 2017 at 8:34 AM, Paige Walker <[log in to unmask]>
> Dear collective wisdom,
> The Digital Library Program at Boston College is investigating new special
> collections repositories as we plan to replace our current one (Digitool)
> in the next year. The last time we surveyed the field, we were looking
> primarily at proprietary platforms, which was reflected in our functional
> To those who have considered open-source models, I’m wondering how this was
> reflected in your functional requirements?
> Thanks in advance,
> PS: Sorry for cross-posting!
> Paige Walker
> Digital Collections & Preservation Librarian
> Boston College
> [log in to unmask]