Currently, looking at either Evergreen or Koha ILS systems, both are
being used primarily by public libraries or small academic libraries.
In neither case have I seen a consortial academic environment using
either system--please let me know if I'm in error here.
There's nothing wrong in creating requirements that meet the needs of a
large set of academic libraries; this does not require taking a
'waterfall' approach to software development, rather it can definitely
take on the 'release fast and often' approach as Dan describes. We
need a starting point and John is correct imo that we need to have an
Open Source ILS that meets the needs of both academic and consortial
environments. How else can we do that without creating some basic
requirements?
Deb
John Little wrote:
> 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
>
--
Deb Bergeron <mailto:bergeron_at_macalester.edu> System Admin: User Support
CLIC Consortium <http://clic.edu>
1619 Dayton Avenue, Suite 204A
Saint Paul, MN 55104
O:*651.644.3878* C:*651.487.7609* F:651.644.6258
Received on Tue Jan 29 2008 - 19:04:54 EST