On 28/01/2008, John Little <John.Little_at_duke.edu> wrote:
> NGC:
>
> The Duke University Libraries are preparing a proposal for the Mellon
> Foundation to convene the academic library community to design an open
> source Integrated Library System (ILS). We are not focused on developing an
> actual system at this stage, but rather blue-skying on the elements that
> academic libraries need in such a system and creating a blueprint. Right
> now, we are trying to spread the word about this project and find out if
> others are interested in the idea.
>
> We feel that software companies have not designed Integrated Library Systems
> that meet the needs of academic libraries, and we don't think those
> companies are likely to meet libraries' needs in the future by making
> incremental changes to their products. Consequently, academic libraries are
> devoting significant time and resources to try to overcome the inadequacies
> of the expensive ILS products they have purchased. Frustrated with current
> systems, library users are abandoning the ILS and thereby giving up access
> to the high quality scholarly resources libraries make available.
>
> Our project would define an ILS centered on meeting the needs of modern
> academic libraries and their users in a way that is open, flexible, and
> modifiable as needs change. The design document would provide a template to
> inform open source ILS development efforts, to guide future ILS
> implementations, and to influence current ILS vendor products. We would use
> the grant to fund a series of planning meetings, with broad participation in
> some of those meetings and a smaller, core group of schools developing the
> actual design requirements document.
>
> At this stage, we're seeking feedback on our ideas and finding out who might
> be interested in participating, prior to our formal submission of the
> proposal to the Mellon Foundation in early March. We would greatly
> appreciate your responses to the following questions.
>
> 1) Does designing an open source ILS seem like something worth exploring for
> academic libraries?
>
> 2) Given the information above about the proposed project, is your
> institution interested in:
>
> -- staying informed of our progress?
>
> -- contributing time and effort to the planning process, even if only
> through the first or second workshops?
>
> -- possibly being one of the core schools that participates throughout the
> full planning and writing process
>
> 3) If you have any initial feedback on our ideas, we would love to hear it!
>
> *Please email us at openlib_at_duke.edu.*
>
> Thank you for your interest and considering this opportunity to work with us
> on this project. If your answer is yes to number two above, we will be
> contacting you to further explore participation. Please send your *reply to
> openlib_at_duke.edu.*
Hi John:
This sounds very much like the first step in a traditional
waterfall-oriented approach to systems development. While I applaud
your willingness to approach the implementation as open source
software, and agree that having a rough set of requirements publicly
documented would be useful, I worry that pouring a huge amount of
effort into creating a set of design documents with "a series of
planning meetings" would be far less rewarding than simply taking an
existing open source library system and building out / discovering the
additional academic requirements you have using an agile development
methodology.
We (Laurentian University, McMaster University, and University of
Windsor) plan to take an agile approach with Evergreen (a recent
recipient of a Mellon award). I've been focused on old-fashioned
infrastructure work to support internationalization, to begin with,
but once we have a shared consortial test system running we plan to
try it out with our users (patrons, staff, librarians), find out what
needs fixing and what's missing, address those pieces, and iterate
again in relatively fast cycles.
We know at the "rough requirements" level that above and beyond
Evergreen's current features we want acquisitions, serials, reserves,
and integration with course management systems, for example - but we
also know that spec'ing all of that out in advance is going to be far
less effective than getting something basic working, trying it out,
and figuring out what needs fixing or enhancing. We don't see that
cycle ever stopping, actually. Library systems should be living
systems: that's part of the problem that we've seen with our
proprietary systems (even the ones that aren't having their life
support pulled by the vendor).
If you have to go the full design document route for process or
funding reasons, that's understandable: however, when you pass the
design document stage, please consider an implementation route that
builds upon and extends an existing open source ILS.
--
Dan Scott
Laurentian University
Received on Mon Jan 28 2008 - 19:48:37 EST