 |
 |
Hi Paige We recently went through a process to replace our repository software (III/VTLS Vital) and although we did not explicitly state that the replacement had to be open source, it was one of the criteria in the RFI that we distributed. And as others said above, the existence of a large and active community of users around the solution that we ended up choosing (Islandora) played a large role in our decision. We drew inspiration from this for our own list of functional requirements: http://www.unesco.org/new/fileadmin/MULTIMEDIA/HQ/CI/CI/pdf/news/institutional_repository_software.pdf Thomas On Tue, Jun 13, 2017 at 12:44 PM, Phillips, Jean <[log in to unmask]> wrote: > Paige, > > > I don't know if I've ever required that a platform be open source in the > functional specs. In my experience the successful open source systems have > been chosen based on flexibility, ability to locally customize and > opportunity for development. > > > My 2 cents. > > > Jean > > > Jean Phillips > Associate Dean of Libraries for Technology & Digital Scholarship > Florida State University, Strozier Library > Email: [log in to unmask]<mailto:[log in to unmask]> > ________________________________ > From: Code for Libraries <[log in to unmask]> on behalf of Erin > Tripp <[log in to unmask]> > Sent: Friday, June 9, 2017 8:41:59 AM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Functional requirements for open-source > repositories > > Hi Paige, > > I've responded to RFPs in the past that indicate an open source preference > as a business requirement. The functional requirements don't usually > specify platform or license, but focus on a detailed account of a user > undertaking an action and the desired result. Boston College has an > Islandora institutional repository (http://dlib.bc.edu/) that's been > operational for a few years. The team running that project would have a > great deal of experience, especially with migration from DigiTool. > > DuraSpace fosters the DSpace and Fedora platforms (Fedora as a backend for > Islandora/Hydra/Hyku). If you'd like to discuss what options are out there, > I'd be happy to help. We're contacted regularly by folks who would like to > know what's out there. We do out best to point people in the direction of > helpful resources and contacts. > > Erin Tripp > Business Development Manager > [log in to unmask] > Duraspace > > On Wed, Jun 7, 2017 at 2:28 PM, Christopher Davis <[log in to unmask]> > wrote: > > > Paige, > > > > Kyle's reply to your message reminds me if an important truth which I > > learned a few years ago- no software app or system (open source or > > proprietary) will succeed in this world without an open and active > support > > community made up of users and developers. How many people actually pay > > Microsoft for technical support these days? Instead, when one has a > > problem, they search or ask a forum of users and developers for a > solution. > > > > If software does not offer such a community to my project (even if it > > offers every feature under the sun and is bug free), then I do not > consider > > it. Thanks to Terry Reese's advice, I will always look at the > > interoperability of software and protocols as well (I think that healthy > > support communities and interoperability almost always come hand-in-hand > > though). > > > > FWIW, > > Christopher Davis > > Uintah County Library > > > > On June 7, 2017 10:46:54 AM MDT, Kyle Banerjee <[log in to unmask]> > > wrote: > > >Hi Paige, > > > > > >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 > > >your needs. > > > > > >kyle > > > > > > > > > > > >On Wed, Jun 7, 2017 at 8:34 AM, Paige Walker > > ><[log in to unmask]> > > >wrote: > > > > > >> 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 > > >> requirements. > > >> > > >> To those who have considered open-source models, I’m wondering how > > >this was > > >> reflected in your functional requirements? > > >> > > >> Thanks in advance, > > >> Paige > > >> > > >> PS: Sorry for cross-posting! > > >> > > >> > > >> ------------------ > > >> > > >> Paige Walker > > >> Digital Collections & Preservation Librarian > > >> Boston College > > >> 617-552-3306 > > >> [log in to unmask] > > >> > > >