Re: Planning open source Library system at Duke

Hi Dan:

I'm not sure I see this as a waterfall approach.  But in any case, I see no
reason why existing implementers cannot use the fruit: some design documents
from a defined community.  It's also important to recognize, as I think you
do, that collections have changed considerably over the past 10-20 years yet
the workflow/services of the library system have not kept pace to help
process/present a modern "collection".  In other words, even in light of the
very capable existing OSS systems, there is room for innovation.  I think
there are services that have not yet been built in existing open source
systems.  At the same time academic libraries need to try and articulate
[common] needs.

Duke is very pleased with the initial expression of interest among the
community of academic libraries.  Optimistically I'd say we have some
reasonable evidence that there is more than one approach to gathering the
input and articulating the needs of the academic library community.  We hope
to build on that expression of interest and we think we can do this without
unnecessary duplication vis-a-vis existing OSS systems.  That said, I think
down the road, much of this work can lead toward some very helpful
convergence and joint future activities as well.



--John

On Jan 28, 2008 7:50 PM, Dan Scott <denials_at_gmail.com> wrote:

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



--
John.Little_at_Duke.edu
ILS Support Section Head
Duke University Libraries
919.660-5932