Thread: Re: [oss4lib-discuss] interesting link
Brought to you by:
dchud
From: Smith,Devon <sm...@oc...> - 2002-11-13 16:27:40
|
> again, this seems like a really good place for support companies to play. > (and, thus, a good reason for people on both sides of the road to think > about what it will take to sell those companies to libraries.) Just over a year ago I suggested that OCLC start providing support for open source software to libraries. Unfortunately, it didn't go anywhere. I still think it makes a lot of sense for OCLC to provide this kind of service. - It fits in well with our vision and mission statements. - We have existing relationships with many libraries. - We have the technical capability. I'd be interested in hearing what others on this list think. Is OCLC an appropriate place for this support to come from? Are there things I'm not aware of that make it a bad idea? /dev -- Devon Smith <sm...@oc...> Software Engineer, Office of Research OCLC Online Computer Library Center, Inc http://www.oclc.org/research/ |
From: Karen C. <kar...@uc...> - 2002-11-13 17:02:12
|
At 11:27 AM 11/13/2002 -0500, Smith,Devon wrote: >I'd be interested in hearing what others on this list think. Is OCLC an >appropriate place for this support to come from? Are there things I'm not >aware of that make it a bad idea? One obvious one would be that it isn't (at least yet) a viable business model. Support services are costly in terms of the staff time required. Someone with business savvy would have to show a convincing spread sheet of costs vs. income. How much do we think libraries would be willing to pay for such a service? ---------------------------------------------- Karen Coyle kar...@uc... University of California Digital Library http://www.kcoyle.net 510/987-0567 ---------------------------------------------- |
From: David D. <dd...@lt...> - 2002-11-13 17:31:33
|
Viable business models can be created rather than discovered. And they do not have to concentrate costs and income within one coordinating institution: they can be apportioned across an entire community of participating institutions. I would contend that it is not too early for OCLC to begin to develop an experimental business model that aims to do just that, while also working toward a sustainable income/expense relationship for its own efforts as a coordinating institution. David. >At 11:27 AM 11/13/2002 -0500, Smith,Devon wrote: >>I'd be interested in hearing what others on this list think. Is OCLC an >>appropriate place for this support to come from? Are there things I'm not >>aware of that make it a bad idea? > >One obvious one would be that it isn't (at least yet) a viable >business model. Support services are costly in terms of the staff >time required. Someone with business savvy would have to show a >convincing spread sheet of costs vs. income. How much do we think >libraries would be willing to pay for such a service? >---------------------------------------------- >Karen Coyle kar...@uc... > University of California Digital Library > http://www.kcoyle.net 510/987-0567 >---------------------------------------------- > > > >------------------------------------------------------- >This sf.net email is sponsored by: Are you worried about your web >server security? Click here for a FREE Thawte Apache SSL Guide and >answer your Apache SSL security needs: >http://www.gothawte.com/rd523.html >_______________________________________________ > >oss...@li... > >https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss >see also http://www.oss4lib.org/ -- David Dorman Lincoln Trail Libraries System 1704 West Interstate Drive Champaign, IL 61822-1068 Phone: 217-352-0047 ext. 209 Fax: 217-352-7153 E-mail: dd...@lt... Web Site: http://www.ltls.org |
From: Smith,Devon <sm...@oc...> - 2002-11-13 18:19:32
|
> It does make sense for OCLC to develop services to support OSS use in > libraries. What is needed is support from top management and a sound > business plan. The latter, I suspect, would influence the former. > Have you or anyone at OCLC tried to develop a viable business plan > for providing OSS support for libraries? I don't know of any attempts to develop a business plan and I doubt my ability to develop one. I've never had much business sense. > Here is one off-the-cuff idea: an initiative to set up a OSS Pilot > Project to model a subscribing group of OSS participating libraries, > each of which would agree to pool a defined amount resources: either > a direct contribution of staff time or an annual payment of money to > OCLC. Such a pilot project could gain OCLC valuable experience and > point the way to a sustainable cooperative OSS effort. Right. A cooperative model is essentially what I suggested. It seems to fit very well with how open source software is developed and with OCLC's existing business. Extending the model to open source support is a natural progression. > OCLC has a participatory model that I think could be effectively > adapted to support OSS in libraries, to the benefit of both OCLC, its > members, and the library community at large. That's what I thought. After my proposal was passed by, I assumed that I just wasn't in touch with what libraries wanted/needed. Over the past year however, I've read things here and there that have reinforced the idea that OCLC's leadership in this area would be beneficial for all. > David /dev -- Devon Smith <sm...@oc...> Software Engineer, Office of Research OCLC Online Computer Library Center, Inc http://www.oclc.org/research/ |
From: Smith,Devon <sm...@oc...> - 2002-11-13 18:33:27
|
I looked around a little and didn't find any lists for this kind of thing. How does one join the callimachus list? There weren't any instructions on the site. /dev -- Devon Smith <sm...@oc...> Software Engineer, Office of Research OCLC Online Computer Library Center, Inc http://www.oclc.org/research/ -----Original Message----- From: Nicholas S. Rosasco [mailto:ns...@et...] Sent: Wednesday, November 13, 2002 1:10 PM To: Smith,Devon Subject: RE: [oss4lib-discuss] interesting link This is an intriguing set of thoughts.... I was wondering if there was some sort of mail list/forum over at OCLC for this kind of thing? I'd be happy to join... I handle administrivia for the Callimachus Group (currently a little quiet) which is definitely interested in this sort of thing also (www.callimachus.org), if you'd like to join their mail list as well. Intrigued, Nick Rosasco Koha/Documentation Guru, Callimachus Group -----Original Message----- From: oss...@li... [mailto:oss...@li...]On Behalf Of Smith,Devon Sent: Wednesday, November 13, 2002 11:28 AM To: 'oss...@li...' Subject: Re: [oss4lib-discuss] interesting link > again, this seems like a really good place for support companies to play. > (and, thus, a good reason for people on both sides of the road to think > about what it will take to sell those companies to libraries.) Just over a year ago I suggested that OCLC start providing support for open source software to libraries. Unfortunately, it didn't go anywhere. I still think it makes a lot of sense for OCLC to provide this kind of service. - It fits in well with our vision and mission statements. - We have existing relationships with many libraries. - We have the technical capability. I'd be interested in hearing what others on this list think. Is OCLC an appropriate place for this support to come from? Are there things I'm not aware of that make it a bad idea? /dev -- Devon Smith <sm...@oc...> Software Engineer, Office of Research OCLC Online Computer Library Center, Inc http://www.oclc.org/research/ ------------------------------------------------------- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html _______________________________________________ oss...@li... https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss see also http://www.oss4lib.org/ |
From: Pat E. <pa...@ey...> - 2002-11-13 18:42:25
|
On Wed, 13 Nov 2002, Smith,Devon wrote: > > I looked around a little and didn't find any lists for this > kind of thing. How does one join the callimachus list? you can send mail to dis...@ca... > There weren't any instructions on the site. hmmm, I thought there were ... this needs to be fixed. -pate > > /dev > > -- > Devon Smith <sm...@oc...> > Software Engineer, Office of Research > OCLC Online Computer Library Center, Inc > http://www.oclc.org/research/ > > -----Original Message----- > From: Nicholas S. Rosasco [mailto:ns...@et...] > Sent: Wednesday, November 13, 2002 1:10 PM > To: Smith,Devon > Subject: RE: [oss4lib-discuss] interesting link > > This is an intriguing set of thoughts.... > I was wondering if there was some sort of mail list/forum over at OCLC for > this kind of thing? I'd be happy to join... > > I handle administrivia for the Callimachus Group (currently a little quiet) > which is definitely interested in this sort of thing also > (www.callimachus.org), if you'd like to join their mail list as well. > > Intrigued, > Nick Rosasco > Koha/Documentation Guru, > Callimachus Group > > -----Original Message----- > From: oss...@li... > [mailto:oss...@li...]On Behalf Of > Smith,Devon > Sent: Wednesday, November 13, 2002 11:28 AM > To: 'oss...@li...' > Subject: Re: [oss4lib-discuss] interesting link > > > > > again, this seems like a really good place for support companies to play. > > (and, thus, a good reason for people on both sides of the road to think > > about what it will take to sell those companies to libraries.) > > Just over a year ago I suggested that OCLC start providing support for open > source software to libraries. Unfortunately, it didn't go anywhere. > > I still think it makes a lot of sense for OCLC to provide this kind of > service. > - It fits in well with our vision and mission statements. > - We have existing relationships with many libraries. > - We have the technical capability. > > I'd be interested in hearing what others on this list think. Is OCLC an > appropriate place for this support to come from? Are there things I'm not > aware of that make it a bad idea? > > /dev > -- > Devon Smith <sm...@oc...> > Software Engineer, Office of Research > OCLC Online Computer Library Center, Inc > http://www.oclc.org/research/ > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > > oss...@li... > > https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > see also http://www.oss4lib.org/ > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > > oss...@li... > > https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > see also http://www.oss4lib.org/ > |
From: Dave B. <Dav...@uc...> - 2002-11-13 19:31:41
|
This discussion has taken some very interesting turns. I'm most concerned about an internal audit of a public agency resulting in the possibility of discontinued use of open source software. There is so much wrong with that picture I can't begin... One cannot rule out the possibility that OCLC will do something, but any conservative organization which has to be concerned with self-preservation can't be expected to leap into anything new. I've made similar, though informal, suggestions for other, library-related groups and the reaction I get tells me most of the people in groups which govern these organizations still don't get it. Then again, that is still true of lots of libraries in general. I don't want to speak for OCLC, and Devon is in a much better position to do so anyway, but I would suggest that it has already taken a big step in the direction of open source (from OCLC's perspective) by releasing SiteSearch source code and developing and releasing Pears and other packages. I realize that's not what is pertinent to this discussion, but it takes time for all to see the big picture. I agree in the long run it would make sense for OCLC to move in this direction. But the fact that large organizations don't necessarily move quickly doesn't mean they don't move at all. Perhaps the timing of Devon's suggestion has not been quite right. Devon, I hope you don't allow yourself to be too frustrated by bureacratic slowness, and will continue to remind people within OCLC of your suggestion on occasion. From my conversations, I know you're not the only person at OCLC who perceives these issues. Dave +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dave Bretthauer Network Services Librarian University of Connecticut Libraries 369 Fairfield Rd, U1005SY Storrs, CT 06269-1005 Voice: (860) 486-6494 Fax: (860) 486-2184 http://www.lib.uconn.edu/~dbretthauer > -----Original Message----- > From: Smith,Devon [mailto:sm...@oc...] > Sent: Wednesday, November 13, 2002 1:19 PM > To: 'oss...@li...' > Subject: RE: [oss4lib-discuss] interesting link > > > > > It does make sense for OCLC to develop services to support > OSS use in > > libraries. What is needed is support from top management > and a sound > > business plan. The latter, I suspect, would influence the former. > > Have you or anyone at OCLC tried to develop a viable business plan > > for providing OSS support for libraries? > > I don't know of any attempts to develop a business plan and I > doubt my > ability to develop one. I've never had much business sense. > > > Here is one off-the-cuff idea: an initiative to set up a OSS Pilot > > Project to model a subscribing group of OSS participating > libraries, > > each of which would agree to pool a defined amount > resources: either > > a direct contribution of staff time or an annual payment of > money to > > OCLC. Such a pilot project could gain OCLC valuable experience and > > point the way to a sustainable cooperative OSS effort. > > Right. A cooperative model is essentially what I suggested. It seems > to fit very well with how open source software is developed and with > OCLC's existing business. Extending the model to open source support > is a natural progression. > > > OCLC has a participatory model that I think could be effectively > > adapted to support OSS in libraries, to the benefit of both > OCLC, its > > members, and the library community at large. > > That's what I thought. After my proposal was passed by, I assumed that > I just wasn't in touch with what libraries wanted/needed. > Over the past > year however, I've read things here and there that have reinforced the > idea that OCLC's leadership in this area would be beneficial for all. > > > David > > /dev > -- > Devon Smith <sm...@oc...> > Software Engineer, Office of Research > OCLC Online Computer Library Center, Inc > http://www.oclc.org/research/ > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > > oss...@li... > > https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > see also http://www.oss4lib.org/ > |
From: Oberg, S. <STOBERG@TAYLORU.EDU> - 2003-05-05 23:18:40
|
QXMgbXVjaCBhcyBJIGFwcGxhdWQgdGhlIGVmZm9ydHMgSSd2ZSBzZWVuIHRodXMgZmFyIHRvIGJ1 aWxkIGFuIG9wZW4gc291cmNlLCBmdWxsLWZlYXR1cmVkIElMUywgSSBoYXZlbid0IHNlZW4gYW55 dGhpbmcgeWV0IHRoYXQgY29tZXMgYW55d2hlcmUgY2xvc2UgdG8gbWVldGluZyB0aGUgZW50aXJl IHJhbmdlIG9mIGJhc2ljIGZ1bmN0aW9uYWxpdHkgb2YgYW4gYWNhZGVtaWMgbGlicmFyeS4gIE5v dGljZSB0aGF0IEkgc3RhdGVkIHRoYXQgSSBoYXZlbid0IHNlZW4gYW55dGhpbmcgKnlldCouICBJ biBhbiBhZG1pdHRlZGx5IGN1cnNvcnksIHZlcnkgbGltaXRlZCByZXZpZXcgb2Ygc29tZSBvcGVu IHNvdXJjZSBwcm9qZWN0cyBmb3IgYW4gYXJ0aWNsZSBJIHJlY2VudGx5IGF1dGhvcmVkIGZyb20g YSBzZXJpYWxpc3QncyBwZXJzcGVjdGl2ZSBmb3IgX1NlcmlhbHMgUmV2aWV3XywgSSBwb2ludGVk IG91dCBlc3BlY2lhbGx5IHRoZSBsYWNrIG9mIGJhc2ljIHNlcmlhbHMgZnVuY3Rpb25hbGl0eS4g IEknZCByZWFsbHkgbGlrZSB0byBrbm93IGlmIGFueSBvcGVuIHNvdXJjZSBzeXN0ZW0gaGFzIHJv YnVzdCBjaGVjay1pbiwgY2xhaW1pbmcsIGV2ZW4gYmFzaWMgc2VyaWFscyBjYXRhbG9naW5nLCBm dW5jdGlvbmFsaXR5Lg0KIA0KTWF5YmUgd2hhdCB5b3UgbWVhbnQgd2FzIHRoYXQgZ2l2ZW4gdGhl IGtpbmQgb2YgbW9uZXkgdG8gaW52ZXN0IHRoYXQgVW5pdi4gb2YgU2Fza2F0Y2hld2FuIGRlbGlu ZWF0ZWQgaW4gdGhhdCBkb2N1bWVudCwgS29oYSBvciBzb21lIG90aGVyIG9wZW4gc291cmNlIElM UyBjb3VsZCByZWFkaWx5IGRldmVsb3AgdGhpcyBmdW5jdGlvbmFsaXR5Lg0KIA0KSSdtIG5ldyB0 byB0aGlzIGFyZWEgYW5kIHNvIGFtIGdsYWQgdG8gYmUgY29ycmVjdGVkIGlmIEknbSBtYWtpbmcg d3Jvbmcgc3RhdGVtZW50cyBvciBhc3N1bXB0aW9ucywgYnV0IEkganVzdCBoYXZlbid0IHNlZW4g YW55dGhpbmcgdG8gY29tZSBjbG9zZSB0byBJSUkncyBNaWxsZW5pdW0gb3IgYW55IG9mIGl0cyBj b21wZXRpdG9ycycgYmFzaWMgZnVuY3Rpb25hbGl0eSBhdCB0aGlzIHN0YWdlLg0KIA0KU3RldmUN CiANCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fiANClN0ZXZlIE9iZXJnIA0KRWxlY3Ryb25pYyBSZXNvdXJjZXMgTGlicmFyaWFuICYgQXNzaXN0 YW50IFByb2Zlc3NvciANCmh0dHA6Ly93d3cudGF5bG9ydS5lZHUvbGlicmFyeS8gDQoNCkVkaXRv ciwgQml0cyAmIEJ5dGVzIENvbHVtbiwgX1NlcmlhbHMgUmV2aWV3XyANCmh0dHA6Ly9zY2llbmNl ZGlyZWN0LmNvbS9zY2llbmNlL2pvdXJuYWwvMDA5ODc5MTMgDQoNCiANCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBQYXQgRXlsZXIgW21haWx0bzpwYXRlQGV5bGVyZmFtaWx5 Lm9yZ10gDQpTZW50OiBNb24gNS81LzIwMDMgNTo1MyBQTSANClRvOiBvc3M0bGliLWRpc2N1c3NA bGlzdHMuc291cmNlZm9yZ2UubmV0IA0KQ2M6IA0KU3ViamVjdDogW29zczRsaWItZGlzY3Vzc10g aW50ZXJlc3RpbmcgbGluaw0KDQoNCg0KCUxldHMgc3RhcnQgd2l0aCB0aGUgbGluayBpdHNlbGY6 DQoJICAgbGlicmFyeS51c2Fzay5jYS9pdHMvTWlsbGVubml1bVByb3Bvc2FsLnBkZg0KCQ0KCU5v dyB0aGVuLCB3aHkgZGlkIEkgcG9zdCB0aGlzIGhlcmU/ICBJIGp1c3QgY2FuJ3QgaW1hZ2luZSB0 aGF0IHdpdGgNCgl+JDkwMCwwMDAgdG8gaW52ZXN0IGFuZCBhbiBhZGRpdGlvbmFsIH4kNTAsMDAw L3llYXIgaW4gbWFpbnRlbmFuY2UgZmVlcw0KCShldmVuIGlmIHRoZXNlIGFyZSBpbiAkQ0EpIEF2 YW50aSwgS29oYSwgTGVhcm5pbmdBY2Nlc3NJTFMsIG9yIHNvbWUgb3RoZXINCglmcmVlIElMUyBj b3VsZG4ndCBtZWV0IG9yIGV4Y2VlZCB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IHRoZSBVbmkgb2YN CglTYXNrYXRjaGV3YW4gbmVlZHMuDQoJDQoJSSBhbG1vc3Qgd29uZGVyIGlmIHdyaXRpbmcgYW4g b3BlbiByZWJ1dHRhbCB0byB0aGlzIGRvY3VtZW50IHdvdWxkIGJlIGENCgl3b3J0aHdoaWxlIHRh c2sgZm9yIHNvbWVvbmUgdG8gdGFrZSBvbi4gIElmIHNvLCB3aGVyZSBjb3VsZC9zaG91bGQgaXQg YmUNCglzZW50Pw0KCQ0KCUFueSB0aG91Z2h0cz8gIEFueW9uZSBub3QgaW52b2x2ZWQgaW4gb25l IG9mIHRoZSBhYm92ZW1lbnRpb25lZCBwcm9qZWN0cw0KCWludGVyZXN0ZWQgaW4gd3JpdGluZyBh IGdlbmVyaWMgcmVidXR0YWw/DQoJDQoJLXBhdGUNCgkNCglQYXQgRXlsZXINCglLYWl0aWFraS9t YW5hZ2VyICAgICAgICAgICAgICAgbWlncmFudCBMaW51eCBzeXMgYWRtaW4NCgl0aGUgS29oYSBw cm9qZWN0ICAgICAgICAgICAgICAgcnVieSwgc2hlbGwsIGFuZCBwZXJsIGdlZWsNCglodHRwOi8v d3d3LmtvaGEub3JnICAgICAgICAgICAgaHR0cDovL3BhdGUuZXlsZXJmYW1pbHkub3JnDQoJDQoJ DQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KCVRoaXMgc2YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCglXZWxj b21lIHRvIGdlZWsgaGVhdmVuLg0KCWh0dHA6Ly90aGlua2dlZWsuY29tL3NmDQoJX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkNCgkNCglvc3M0bGliLWRp c2N1c3NAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJDQoJDQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vm b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vb3NzNGxpYi1kaXNjdXNzDQoJc2VlIGFsc28gaHR0cDov L29zczRsaWIub3JnLw0KCQ0KDQo= |
From: Pat E. <pa...@ey...> - 2003-05-05 23:31:07
|
On Mon, 5 May 2003, Oberg, Steve wrote: > As much as I applaud the efforts I've seen thus far to build an open > source, full-featured ILS, I haven't seen anything yet that comes > anywhere close to meeting the entire range of basic functionality of an > academic library. Notice that I stated that I haven't seen anything > *yet*. In an admittedly cursory, very limited review of some open > source projects for an article I recently authored from a serialist's > perspective for _Serials Review_, I pointed out especially the lack of > basic serials functionality. I'd really like to know if any open source > system has robust check-in, claiming, even basic serials cataloging, > functionality. > is there a link to this article somewhere? Could you provide reasonable overview of what you saw, and what you think is needed? > Maybe what you meant was that given the kind of money to invest that > Univ. of Saskatchewan delineated in that document, Koha or some other > open source ILS could readily develop this functionality. > This was my point exactly. $900,000 would buy a *lot* of development. There are additional benefits that could be derived from investing in OSS as well: * the money could be provided as seed money or as an endowment to fund a local group to do the work -- this would benefit the local economy, improve the local tax base, and generate goodwill for the library * the U of Saskatchewan could steer the development to provide exactly the features they wanted, without having to convince a marketing department that it was a good idea * the U of Saskatchewan could turn around and redistribute their new ILS other libraries in the region as desired. > I'm new to this area and so am glad to be corrected if I'm making wrong > statements or assumptions, but I just haven't seen anything to come > close to III's Millenium or any of its competitors' basic functionality > at this stage. I agree that we're not there yet, but I don't think it's an impossible goal. I also think that 10 libraries each investing half of the money described above could create to or three excellent, free ILSs -- to me, this is a *much* better investment than licensing an ILS. thanks, -pate > > Steve > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Steve Oberg > Electronic Resources Librarian & Assistant Professor > http://www.tayloru.edu/library/ > > Editor, Bits & Bytes Column, _Serials Review_ > http://sciencedirect.com/science/journal/00987913 > > > > -----Original Message----- > From: Pat Eyler [mailto:pa...@ey...] > Sent: Mon 5/5/2003 5:53 PM > To: oss...@li... > Cc: > Subject: [oss4lib-discuss] interesting link > > > > =09Lets start with the link itself: > =09 library.usask.ca/its/MillenniumProposal.pdf > > =09Now then, why did I post this here? I just can't imagine that with > =09~$900,000 to invest and an additional ~$50,000/year in maintenance fee= s > =09(even if these are in $CA) Avanti, Koha, LearningAccessILS, or some ot= her > =09free ILS couldn't meet or exceed the functionality that the Uni of > =09Saskatchewan needs. > > =09I almost wonder if writing an open rebuttal to this document would be = a > =09worthwhile task for someone to take on. If so, where could/should it = be > =09sent? > > =09Any thoughts? Anyone not involved in one of the abovementioned projec= ts > =09interested in writing a generic rebuttal? > > =09-pate > > =09Pat Eyler > =09Kaitiaki/manager migrant Linux sys admin > =09the Koha project ruby, shell, and perl geek > =09http://www.koha.org http://pate.eylerfamily.org > > > > =09------------------------------------------------------- > =09This sf.net email is sponsored by:ThinkGeek > =09Welcome to geek heaven. > =09http://thinkgeek.com/sf > =09_______________________________________________ > > > =09o...@li... > > > =09https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > =09see also http://oss4lib.org/ > > > N=18=AC=B1=F9=DE=B5=E9=9A=8AX=AC=B2=9A'=B2=8A=DEu=BC=BEN=18=A7=90g=9E=91g= =A5r=89=9E=B6=88=1EzH^j=F7=A7=86=DBi=FB=FF=ED=86)=E4=81=E7=A4r=89=BF=B1=FA,= =B3=89bm=D8=ACr=EB,=96+-=B2=CA.=AD=C7=9F=A2=B8=1E=9D=EBa=B6=DAl=FB=FF=E5=8A= =CBl=B2=8B=ABq=E7=E8=AE=07=A7z=DF=E5=8A=CBl=FEX=AC=B6)=DF=A3=FA,=B3=89bm=D8= =ACr=EB,=B1=E7=9A=96=CA!=B6=DA~=FF=FA,=B3=89bn=8A=E0 |
From: Eric L. M. <em...@nd...> - 2003-05-06 13:19:54
|
On 5/5/03 6:31 PM, Pat Eyler <pa...@ey...> wrote: > This was my point exactly. $900,000 would buy a *lot* of development. There > are additional benefits that could be derived from investing in OSS as well: > > * the money could be provided as seed money or as an endowment to fund > a local group to do the work -- this would benefit the local economy, > improve the local tax base, and generate goodwill for the library > > * the U of Saskatchewan could steer the development to provide exactly > the features they wanted, without having to convince a marketing > department that it was a good idea > > * the U of Saskatchewan could turn around and redistribute their new ILS > other libraries in the region as desired. I think these are interesting points. Yes, 900K is a lot of money, and I think it would be possible to create an ILS that does the functionality desired, if some of us were willing to dump our day jobs. Often times I see us spend our money and get little return. Money spent to develop open source software goes back into the community through shared experience, shared code, and the proliferation of best practices and open standards. -- Eric Lease Morgan University Libraries of Notre Dame (574) 631-8604 |
From: David D. <dd...@lt...> - 2003-05-06 14:58:26
|
Let's not be too quick to fault the University of Saskatchewan and to propose a solution which may not meet its library's needs. It's asking a lot of an institution to spend $900,000 to build a solution that will take an indefinite amount of time to develop when functioning solutions already exist and can be purchased and implemented within months. We all know that OSS represents a more effective and efficient development model for libraries than proprietary software, but lets also remember that the commercial model also represents a significant advance over the inhouse development model. The trick is to combine the two approaches in a way that will enable an OSS library management system (LMS) to compete in the library market in the way that other OSS is being successfully marketed in the broader computer industry and in a few niche markets in the library field. A viable OSS LMS will not be built overnight. It has taken 25 years for proprietary LMS software developers to get as far as they have, and while an OSS development process may be faster, it is not a magic bullet. Pieces of OSS--MARCJ4 for example--are already being used by LMS vendors. This is a trend that will accelerate. I suspect that we will see an increasingly mixed market of OSS and proprietary software in libraries. Doing worthwhile thing well takes time. An OSS LMS is inevitable, but, I suspect it will take something like the following elements to dramatically speed up the development of one that can play with the big dogs: 1. a foundation willing to commit a several hundred thousand dollars to a development effort 2. a library or library system with savvy system staff, a functioning LMS they are in no rush to replace, and a willingness to commit staff time to testing out a new system 3. an OSS LMS that has proven itself to be well designed that can serve as the core software for the project 4. a commitment of at least a half dozen programmers around the world who are willing and able to participate in an OSS develoment effort. >On 5/5/03 6:31 PM, Pat Eyler <pa...@ey...> wrote: > >> This was my point exactly. $900,000 would buy a *lot* of development. There >> are additional benefits that could be derived from investing in OSS as well: >> >> * the money could be provided as seed money or as an endowment to fund >> a local group to do the work -- this would benefit the local economy, >> improve the local tax base, and generate goodwill for the library >> >> * the U of Saskatchewan could steer the development to provide exactly >> the features they wanted, without having to convince a marketing >> department that it was a good idea >> >> * the U of Saskatchewan could turn around and redistribute their new ILS >> other libraries in the region as desired. > >I think these are interesting points. Yes, 900K is a lot of money, and I >think it would be possible to create an ILS that does the functionality >desired, if some of us were willing to dump our day jobs. > >Often times I see us spend our money and get little return. Money spent to >develop open source software goes back into the community through shared >experience, shared code, and the proliferation of best practices and open >standards. > >-- >Eric Lease Morgan >University Libraries of Notre Dame > >(574) 631-8604 > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ > > >oss...@li... > > >https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss >see also http://oss4lib.org/ -- David Dorman Lincoln Trail Libraries System 1704 West Interstate Drive Champaign, IL 61822-1068 Phone: 217-352-0047 ext. 209 Fax: 217-352-7153 E-mail: dd...@lt... Web Site: http://www.ltls.org |
From: Pat E. <pa...@ey...> - 2003-05-06 17:00:29
|
On Tue, 6 May 2003, David Dorman wrote: > Let's not be too quick to fault the University of Saskatchewan and to > propose a solution which may not meet its library's needs. I certainly don't fault them, and didn't plan on proposing a Koha solution to them (or any other oss solution for that matter). I was more interested in laying out something of a call to action in the form of a rebuttal. I'd really like to have some widely available text that talks to the many benefits that investment will bring. That's really the key (to me), and it seems that many libraries (or library boards) don't seem to get it. Choosing a proprietary solution is like renting a house and choosing an oss solution is like buying a house. Sometimes renting is the only viable solution at the time you need a house. You'll still be stuck living in someone elses house, not being able to make the changes you'd really like, and having fewer financial (tax breaks, etc.) and social benefits (a lasting connection to neighbors, etc.). Many (most?) people who are renting percieve the benefits of owning their own home and put aside a little money to help make that possible. I think that being able to point to a document that made this comparison very obvious would be a great benefit to the oss4lib community. -pate > It's > asking a lot of an institution to spend $900,000 to build a solution > that will take an indefinite amount of time to develop when > functioning solutions already exist and can be purchased and > implemented within months. We all know that OSS represents a more > effective and efficient development model for libraries than > proprietary software, but lets also remember that the commercial > model also represents a significant advance over the inhouse > development model. The trick is to combine the two approaches in a > way that will enable an OSS library management system (LMS) to > compete in the library market in the way that other OSS is being > successfully marketed in the broader computer industry and in a few > niche markets in the library field. > > A viable OSS LMS will not be built overnight. It has taken 25 years > for proprietary LMS software developers to get as far as they have, > and while an OSS development process may be faster, it is not a magic > bullet. Pieces of OSS--MARCJ4 for example--are already being used by > LMS vendors. This is a trend that will accelerate. I suspect that > we will see an increasingly mixed market of OSS and proprietary > software in libraries. > > Doing worthwhile thing well takes time. An OSS LMS is inevitable, > but, I suspect it will take something like the following elements to > dramatically speed up the development of one that can play with the > big dogs: > > 1. a foundation willing to commit a several hundred thousand > dollars to a development effort > 2. a library or library system with savvy system staff, a > functioning LMS they are in no > rush to replace, and a willingness to commit staff time to > testing out a new system > 3. an OSS LMS that has proven itself to be well designed that > can serve as the core software > for the project > 4. a commitment of at least a half dozen programmers around the > world who are willing and > able to participate in an OSS develoment effort. > > > >On 5/5/03 6:31 PM, Pat Eyler <pa...@ey...> wrote: > > > >> This was my point exactly. $900,000 would buy a *lot* of development. There > >> are additional benefits that could be derived from investing in OSS as well: > >> > >> * the money could be provided as seed money or as an endowment to fund > >> a local group to do the work -- this would benefit the local economy, > >> improve the local tax base, and generate goodwill for the library > >> > >> * the U of Saskatchewan could steer the development to provide exactly > >> the features they wanted, without having to convince a marketing > >> department that it was a good idea > >> > >> * the U of Saskatchewan could turn around and redistribute their new ILS > >> other libraries in the region as desired. > > > >I think these are interesting points. Yes, 900K is a lot of money, and I > >think it would be possible to create an ILS that does the functionality > >desired, if some of us were willing to dump our day jobs. > > > >Often times I see us spend our money and get little return. Money spent to > >develop open source software goes back into the community through shared > >experience, shared code, and the proliferation of best practices and open > >standards. > > > >-- > >Eric Lease Morgan > >University Libraries of Notre Dame > > > >(574) 631-8604 > > > > > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by:ThinkGeek > >Welcome to geek heaven. > >http://thinkgeek.com/sf > >_______________________________________________ > > > > > >oss...@li... > > > > > >https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > >see also http://oss4lib.org/ > > > -- > David Dorman > Lincoln Trail Libraries System > 1704 West Interstate Drive > Champaign, IL 61822-1068 > Phone: 217-352-0047 ext. 209 > Fax: 217-352-7153 > E-mail: dd...@lt... > Web Site: http://www.ltls.org > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > > > oss...@li... > > > https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > see also http://oss4lib.org/ > |
From: <ar...@se...> - 2003-05-06 15:46:39
|
As long as a large-scale ILS remains a monolithic application involving thousands or millions of lines of code, then I suspect it will be an uphill battle to get library decision makers to invest in OSS. At the very least, there will be a fear that the code base will be too large to sustain itself even with the amount of communal maintenance and nurturing that libraries could collectively contribute. A worldwide community of developers can be galvanized to tackle an operating system or an office suite, but the numbers dwindle pretty fast when you start talking about MARC editors and Serials Control. In other words, we are still a pretty small bunch when it comes to this kind of system. The question I have is whether monolithic applications have to be the only answer for every kind of enterprise system. I have rambled about this at /usr/lib/info concerning ERP, but the ILS vendors are way behind in component-based computing and utilizing mainstream software. I find it extremely interesting that Sun's latest paper on Digital Libraries points out that the commercial ILS solutions are lagging on this front. Sun is very good at promoting commercial ILS options because, for the most part, they seem to prefer Sun hardware, but other somewhat comparable systems, like in the banking and insurance industries, are knee-deep into component-computing. The fact that Sun would even recognize that commercial ILS vendors need to get into this environment speaks volumes to me. Not that I don't doubt that a million-line OSS ILS could be built for the million dollars they cost on the marketplace, I just question whether a self-authored million line system of any kind makes sense any more. This, in fact, is where I see the most hope for OSS for large library systems, because I don't think the ILS vendors' business models are ready for using mainstream components and it's conceivable that OSS approaches could leapfrog over them. Remember, it wasn't that long ago that universities at least, did build million line systems through consortium-based software, and there was a great turning to the marketplace in the 80s when it was realized that they couldn't easily keep them running. Let's take the module that has come up here and that ILS programmers probably fear the most, Serials Control. Any one who has slogged through programming a Serials Control module will probably tell you it takes very intricate business logic and all sorts of weird time-specific pattern matching algorithms to handle predictions on when issues should arrive. There are mature OSS component container systems like JBOSS that provide a framework for plugging in general purpose building blocks which might be able to do most of the heavy lifting. If you used JBOSS with OFBiz (an OSS component for handling business logic) and an OSS calendar server (for handling predictions), how close would you get to a viable Serials Control system? My sense is that the target would become much more achievable because a lot of that million lines of code that runs underneath it all has suddenly been contributed by other programmers who wouldn't, and don't need to, have a clue what a MARC record is about. Make no mistake, it would still be a lot of work, and as Eric points out, we all have our day jobs, but what I find the most interesting about the University of Saskatchewan document is not the cost of the upgrade, but their compelling description of what an ILS in 2003 needs to be able to accomplish. Even the library vendors are finding it hard to maintain the ILS as both a purchasing and inventory control system while at the same time trying to keep up with what the users expect and want when they interact with systems on the web. Eric Raymond talks about the benefits of "constructive laziness", maybe the trick is find similarities in other applications and use component models to employ them for library systems. I suspect we would still need to dump some day jobs to make this happen, but the needs of the user community may be what it takes to push some organizations to invest in this. Or, like the use of relational database behind commercial ILS systems, the vendor community will eventually get there by themselves. Our advantage is that we can use some great OSS building blocks because the licensing doesn't hurt our bottom line. The trick is probably to find a way to leverage this advantage. art |
From: Karen C. <kar...@uc...> - 2003-05-06 16:18:52
|
Yes, it's time for the Dis-integration of the integrated library system! Talk to any librarian who has recently gone through an RFP process to buy a new system and they'll all tell you that they wish they could have taken the serials control from vendor A, the acquisitions module from vendor B, and the cataloging interface from vendor C. Notice I didn't mention the OPAC? As far as I can tell, and vendors have confirmed this for me, no one picks an ILS based on the OPAC functionality and vendors know that the OPAC is not going to sell their system. The result is that library users get short shrift in terms of features and service. Components of course need interfaces to each other. "Innovative Interfaces" got its start by providing an interface between the library cataloging module and OCLC. It was, literally, a black box. Z39.50 serves as an interface to the catalog (yep, although imperfect) and OPACs can be built that talk to any library catalog with a Z server. What we need are not better ILSs but more and better interfaces. kc At 11:22 AM 5/6/2003 -0400, Rhyno Art wrote: >As long as a large-scale ILS remains a monolithic application involving >thousands or millions of lines of code, then I suspect it will be an uphill >battle to get library decision makers to invest in OSS. At the very least, >there will be a fear that the code base will be too large to sustain itself >even with the amount of communal maintenance and nurturing that libraries >could collectively contribute. A worldwide community of developers can be >galvanized to tackle an operating system or an office suite, but the >numbers dwindle pretty fast when you start talking about MARC editors and >Serials Control. In other words, we are still a pretty small bunch when it >comes to this kind of system. > >The question I have is whether monolithic applications have to be the only >answer for every kind of enterprise system. I have rambled about this at >/usr/lib/info concerning ERP, but the ILS vendors are way behind in >component-based computing and utilizing mainstream software. I find it >extremely interesting that Sun's latest paper on Digital Libraries points >out that the commercial ILS solutions are lagging on this front. Sun is >very good at promoting commercial ILS options because, for the most part, >they seem to prefer Sun hardware, but other somewhat comparable systems, >like in the banking and insurance industries, are knee-deep into >component-computing. The fact that Sun would even recognize that commercial >ILS vendors need to get into this environment speaks volumes to me. > >Not that I don't doubt that a million-line OSS ILS could be built for the >million dollars they cost on the marketplace, I just question whether a >self-authored million line system of any kind makes sense any more. This, >in fact, is where I see the most hope for OSS for large library systems, >because I don't think the ILS vendors' business models are ready for using >mainstream components and it's conceivable that OSS approaches could >leapfrog over them. Remember, it wasn't that long ago that universities at >least, did build million line systems through consortium-based software, >and there was a great turning to the marketplace in the 80s when it was >realized that they couldn't easily keep them running. > >Let's take the module that has come up here and that ILS programmers >probably fear the most, Serials Control. Any one who has slogged through >programming a Serials Control module will probably tell you it takes very >intricate business logic and all sorts of weird time-specific pattern >matching algorithms to handle predictions on when issues should arrive. >There are mature OSS component container systems like JBOSS that provide a >framework for plugging in general purpose building blocks which might be >able to do most of the heavy lifting. If you used JBOSS with OFBiz (an OSS >component for handling business logic) and an OSS calendar server (for >handling predictions), how close would you get to a viable Serials Control >system? My sense is that the target would become much more achievable >because a lot of that million lines of code that runs underneath it all has >suddenly been contributed by other programmers who wouldn't, and don't need >to, have a clue what a MARC record is about. > >Make no mistake, it would still be a lot of work, and as Eric points out, >we all have our day jobs, but what I find the most interesting about the >University of Saskatchewan document is not the cost of the upgrade, but >their compelling description of what an ILS in 2003 needs to be able to >accomplish. Even the library vendors are finding it hard to maintain the >ILS as both a purchasing and inventory control system while at the same >time trying to keep up with what the users expect and want when they >interact with systems on the web. Eric Raymond talks about the benefits >of "constructive laziness", maybe the trick is find similarities in other >applications and use component models to employ them for library systems. I >suspect we would still need to dump some day jobs to make this happen, but >the needs of the user community may be what it takes to push some >organizations to invest in this. > >Or, like the use of relational database behind commercial ILS systems, the >vendor community will eventually get there by themselves. Our advantage is >that we can use some great OSS building blocks because the licensing >doesn't hurt our bottom line. The trick is probably to find a way to >leverage this advantage. > >art > > >------------------------------------------------------- >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >The only event dedicated to issues related to Linux enterprise solutions >www.enterpriselinuxforum.com > >_______________________________________________ > > >oss...@li... > > >https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss >see also http://oss4lib.org/ |
From: Walter L. <le...@hh...> - 2003-05-09 19:16:22
|
Karen Coyle wrote: > [snip]Components of course need interfaces to each other. "Innovative > Interfaces" got its start by providing an interface between the > library cataloging module and OCLC. It was, literally, a black box. > Z39.50 serves as an interface to the catalog (yep, although imperfect) > and OPACs can be built that talk to any library catalog with a Z > server. What we need are not better ILSs but more and better interfaces. Was it not pointed out earlier in this discussion that one of the key problems in Saskatchewan is extracting the data from the III acquisitions system? Apparently management learned something from their early experience (if you can take their data, you can take their customers). Would any organization bet the farm on a collection of objects (however well designed) that required a platform that supported PHP, Python, and Java, where some of the technologies used SOAP, others the java specific messaging tools, and multiple databases becuase this was written to MySQL and that to specific Postgres functionality, all of which were engaged in separate upgrade cycles full of unintended consequences? In re-reading that last sentence, I realize it sounds rhetorical. It wasn't meant to be. Is it more realistic to assume that viable ILS systems will emerge in clusters that makes common assumptions about requirements? Or are we poised to evolve beyond this? Walter Lewis Halton Hills |
From: Peter S. <pet...@ya...> - 2003-05-10 03:21:54
|
--- Walter Lewis <le...@hh...> wrote: > Karen Coyle wrote: > Would any organization bet the farm on a collection > of objects (however > well designed) that required a platform that > supported PHP, Python, and > Java, where some of the technologies used SOAP, > others the java specific > messaging tools, and multiple databases becuase this > was written to > MySQL and that to specific Postgres functionality, > all of which were > engaged in separate upgrade cycles full of > unintended consequences? > This is a good point. It is a strength but also a weakness of the usual approach of the web based open source application: having to blend a soup of disparate and independently evolving technologies to work together to do something useful. This appeals to hackers and techies. But expecting the masses to get Linux, MySQL, Perl, Apache (with the sundry needed Perl and Apache modules compiled in) all working together to support their library system is unrealistic. A library system that's successful and taken seriously beyond the technically savvy would need to be packaged as a more or less vertically integrated system that's very easy to install, runs on just about anything and requires little tweaking to get up and running. Such a system should be simple, robust, and require a minimum number of components for its platform. the more it can do itself (even if the developer has to reinvent some wheels) the better. Peter Schlumpf Avanti Project Manager __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
From: <ar...@se...> - 2003-05-10 20:59:26
|
> Is it more realistic to assume that viable ILS systems will emerge in > clusters that makes common assumptions about requirements? Or are we > poised to evolve beyond this? > I wonder if there are two kinds of dis-integration. One involving library-specific reference models and APIs, and another using somewhat more widely supported "mainstream" technologies. When Melvyl(?) announced a circulation link to another site using Z39.50 in the early 90s, it seemed like plug and play library systems were just around the corner. Maybe the metric needs to be what some programmers call the "O'Reilly factor" where the measure of the viability of a technology is directly proportional to the likelihood that O'Reilly will publish a book about it. There are solutions which take a "quasi-API" approach where you map data models and the underlying database logic, system interface, or whatever, is somewhat swappable. O/R modelers for relational databases and container systems in EJB and application servers, for example. This helps protect you from growing too enamored of database-specific functions, and allows some level of consistency in underlying storage solutions. There are also "classes" of systems, like directory and calendar servers, where enough organizations have needed certain kinds of functionality to spawn widely available API-based solutions. These may have reached a critical mass where either the desired database system will be available in at least one of the options, or the solutions themselves are already present in some other system sanctioned by the organization. I would think management would be less likely to lose sleep over something like an LDAP implementation, for example, because there are so many servers to choose from. In a university environment at least, there are also probably several co-managers that already have one in their department on campus. There are some volatile questions about how to "wire" the dis-integrated pieces together, though "glue" technologies may be slightly easier to fix and negotiate than servers. In thinking about this in glorious ascii, and I apologize in advance to anyone who is tied to a proportional font in their mail system, one impression of a dis-integrated ILS might look something the diagram below. Not all of these are mainstream components, and some are optional, but the advantages of these kind of combinations could be in supporting services that are currently require a lot of additional plumbing in a commercial ILS. For example: * syncing circ information with PDAs * providing PDF formatted lists for searches * using iCalendar for sharing/defining holidays, upcoming events, calendar server functions for mapping patterns for serials check-in, etc. The parenthesis below lists OSS systems for each category, though there are also many commercial options for some of them. Again, these are solutions that are built by developers who would think a MARC record was an ill-formed basic program listing gone berserk. Walter has a great point in identifying the number of disparate technologies a dis-integrated system could entail, and the layout below doesn't really address the possibility that dozens of different application environments could be a huge implication of breaking the ILS up. Still, I think the trade-off is that these individual pieces may be able to do much more than the monolithic system could have handled. So I don't know if I have just muddled the question more but the answers seem well worth pursuing. art --- a dis-integrated ILS in ascii ---------------------- |Permissions/Rights | |Managers | | (Shibboleth) | ---------------------- / / ACQUISITIONS/ CIRC / SERIALS CONTROL ----------------- ----------------- | LDAP/Directory| |General Ledger | | O/R Mapping |----------|Business Logic | | (Hibernate, | / |ERP | | Castor, | / | (OFBiz, | | Tangram, | / | Compiere) | | Pjdo) | / ----------------- ----------------- / | \ / | BIB. MGT & CAT. \ / --------------- ---------------- | O/R Mapping | | Calendar | | (see Circ) | | Server | --------------- | (UW Calendar,| | ------------- | Mozilla) | |------------|Annotation | ---------------- | |Server | | |(Annozilla)| | ------------- | |------------------- / \ |Virtual Ref.| / \ -------------- /OPAC \ | Browser ------------ ... |Publishing| |Framework | |(AxKit, | | Cocoon) | ------------ / | \ Browser PDAs RSS... |
From: Walter L. <le...@hh...> - 2003-05-11 15:06:14
|
Rhyno Art wrote: >I wonder if there are two kinds of dis-integration. One involving >library-specific reference models and APIs, and another using somewhat more >widely supported "mainstream" technologies. > [with lots of good stuff snipped] The hazy vision I have of the broader problem is: a) there is not a single solution: putting foundation (and other) money into a single open source code set underestimates the diversity of the problem sets at each target. (answer: put development resources into 2-4 core sets) b) that some technology decisions tend towards mutually exclusive clusters (database and programming language decisions being key) c) despite this some solutions *are* remarkably useful underneath a wide range of system decisions (exhibit A: yaz) d) and within the clusters there could and should still be choice in the modular fashion you describe I recently got an announcement that VB-ZOOM had been upgraded again. Its dependencies include yaz (written in c and compiled everywhere c is) and the latest MS XML parser. ZOOM is explicitly a set of abstract APIs that has bindings in perl, php, java, tcl and very nearly everything I would ever consider programming in. I suspect Peter is right and that folks are looking for some assurances that a particular set of parts will fly together in close formation. What he's doing with Avanti and what the Koha folks are doing is evidence of that. Implicit in what Art says is that this may well only be required from a marketing perspective (tell nervous people which things work together) and at the backend build your ILS "distribution" from a set of parts you know will play nicely. ... isn't this what a lot of the library vendors do anyway? Some resell telephone notification products; licence Z39.50 engines; and a whole range of other code outside their core competencies. Walter Lewis Halton Hills |
From: David D. <dd...@lt...> - 2003-05-11 16:26:39
|
Art, You have clearly articulated an architectural approach to LMS software development that the library community should be addressing. Standardizing what this thread has termed "Dis-integrating ILSes" is, I think, one of the most important challenges facing the library technology community. It would be a great step forward if NISO, the DLF or some other appropriate organization took up the cause of architectural standardization. Libraries could sure benefit from the effort and I think the vendors are also ready for it. David > > Is it more realistic to assume that viable ILS systems will emerge in >> clusters that makes common assumptions about requirements? Or are we >> poised to evolve beyond this? >> >I wonder if there are two kinds of dis-integration. One involving >library-specific reference models and APIs, and another using somewhat more >widely supported "mainstream" technologies. When Melvyl(?) announced a >circulation link to another site using Z39.50 in the early 90s, it seemed >like plug and play library systems were just around the corner. Maybe the >metric needs to be what some programmers call the "O'Reilly factor" where >the measure of the viability of a technology is directly proportional to >the likelihood that O'Reilly will publish a book about it. > >There are solutions which take a "quasi-API" approach where you map data >models and the underlying database logic, system interface, or whatever, >is somewhat swappable. O/R modelers for relational databases and container >systems in EJB and application servers, for example. This helps protect you >from growing too enamored of database-specific functions, and allows some >level of consistency in underlying storage solutions. > >There are also "classes" of systems, like directory and calendar servers, >where enough organizations have needed certain kinds of functionality to >spawn widely available API-based solutions. These may have reached a >critical mass where either the desired database system will be available in >at least one of the options, or the solutions themselves are already >present in some other system sanctioned by the organization. I would think >management would be less likely to lose sleep over something like an LDAP >implementation, for example, because there are so many servers to choose >from. In a university environment at least, there are also probably several >co-managers that already have one in their department on campus. > >There are some volatile questions about how to "wire" the dis-integrated >pieces together, though "glue" technologies may be slightly easier to fix >and negotiate than servers. In thinking about this in glorious ascii, and I >apologize in advance to anyone who is tied to a proportional font in their >mail system, one impression of a dis-integrated ILS might look something >the diagram below. Not all of these are mainstream components, and some are >optional, but the advantages of these kind of combinations could be in >supporting services that are currently require a lot of additional plumbing >in a commercial ILS. For example: > >* syncing circ information with PDAs >* providing PDF formatted lists for searches >* using iCalendar for sharing/defining holidays, upcoming events, calendar >server functions for mapping patterns for serials check-in, etc. > >The parenthesis below lists OSS systems for each category, though there are >also many commercial options for some of them. Again, these are solutions >that are built by developers who would think a MARC record was an >ill-formed basic program listing gone berserk. Walter has a great point in >identifying the number of disparate technologies a dis-integrated system >could entail, and the layout below doesn't really address the possibility >that dozens of different application environments could be a huge >implication of breaking the ILS up. Still, I think the trade-off is that >these individual pieces may be able to do much more than the monolithic >system could have handled. So I don't know if I have just muddled the >question more but the answers seem well worth pursuing. > >art >--- >a dis-integrated ILS in ascii > > ---------------------- > |Permissions/Rights | > |Managers | > | (Shibboleth) | > ---------------------- > / > / ACQUISITIONS/ >CIRC / SERIALS CONTROL >----------------- ----------------- >| LDAP/Directory| |General Ledger | >| O/R Mapping |----------|Business Logic | >| (Hibernate, | / |ERP | >| Castor, | / | (OFBiz, | >| Tangram, | / | Compiere) | >| Pjdo) | / ----------------- >----------------- / | > \ / | BIB. MGT & CAT. > \ / --------------- > ---------------- | O/R Mapping | > | Calendar | | (see Circ) | > | Server | --------------- > | (UW Calendar,| | ------------- > | Mozilla) | |------------|Annotation | > ---------------- | |Server | > | |(Annozilla)| > | ------------- > | > |------------------- > / \ |Virtual Ref.| > / \ -------------- > /OPAC \ | > Browser ------------ > ... |Publishing| > |Framework | > |(AxKit, | > | Cocoon) | > ------------ > / | \ > Browser PDAs RSS... > > >------------------------------------------------------- >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >The only event dedicated to issues related to Linux enterprise solutions >www.enterpriselinuxforum.com > >_______________________________________________ > > >oss...@li... > > >https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss >see also http://oss4lib.org/ -- David Dorman Lincoln Trail Libraries System 1704 West Interstate Drive Champaign, IL 61822-1068 Phone: 217-352-0047 ext. 209 Fax: 217-352-7153 E-mail: dd...@lt... Web Site: http://www.ltls.org |
From: <ar...@se...> - 2003-05-12 20:00:43
|
> You have clearly articulated an architectural approach to LMS > software development that the library community should be addressing. > Standardizing what this thread has termed "Dis-integrating ILSes" is, > I think, one of the most important challenges facing the library > technology community. It would be a great step forward if NISO, the > DLF or some other appropriate organization took up the cause of > architectural standardization. Libraries could sure benefit from the > effort and I think the vendors are also ready for it. > Gosh, I don't know if my diagram would qualify as a clear architecture, but as someone pointed out to me, I am really sidestepping some big issues by not identifying the lines going between the "dis-integrated" pieces. For the record, let me say publicly that there are at least 4 options for making a dis-integrated ILS talk to each other: * programmatically - hand-coding the connections * REST - passing XML over HTTP * SOAP/XML-RPC - XML for both requests & responses over HTTP * EJB/CORBA - for more "tightly coupled" interactions, the ACQ tools in particular tend to be slated this way A combination of the above would probably make the most sense, but there are both political and technical challenges to be navigated around in the "connector" technologies, and they probably need to be addressed much more clearly than I may have implied. At the recent Ontario Library Association conference, one of the plenary speakers was David Snowden, the Director of the IBM Cynefin Centre for Organisational Complexity in Wales, and one of his topics was addressing "impossible problems" in a practical manner. Snowden is a great speaker, and believes in the use of stories as an advanced form of knowledge repository, so maybe that explains his ability to deliver a tale, but he used a wonderful example of a group of West Point graduates being taken to a school in the Bronx to formulate a plan for managing a playground. After carefully laying out schedules and optimum timings for the kids, the graduates threw up their hands in frustration because it all degenerated into chaos seconds after the kids arrived on the playground. The West Point crowd then watched how the teachers handled the situation. What would happen is that the teachers would let the kids interact and look for patterns to build on in designing a plan, rather than laying it out in abstract. Pattern seeking, Snowden argued, especially on the ground of ongoing processes, makes a lot of sense for both volatile and complex systems. If you looked at the patterns in the ILS, which I think qualifies as a complex system, you would see a lot of directory functions, date/time requirements, transaction issues, and lots of other system needs that many other communities have had to address. There's definitely a lot of uniqueness there as well, but one of the great advantages to an Open Source approach could be a better utilization of existing plumbing. I am not sure that an organization like NISO or the DLF would be a logical facilitator of this but I think your point about the vendors is really interesting. What if the bright minds behind the vendor solutions could concentrate on the unique parts of library systems rather than architecting transaction support and other functions that are already out there? My guess is that changing or upgrading an ILS would be less like adopting a monolithic monster from a small family that doesn't get out much, which seems to be what happens now. Still, there was a time when using a relational database behind an ILS was considered a pretty radical step, I don't think any serious library vendor would now argue that building their own database system is a particularly good idea, at least for a large organization, so maybe we are making some progress after all. The difficulty is that user expectations are so high now that spending too much time perpetuating the ILS' primary function as an inventory control system detracts from what needs to happen to make the public side more compelling. art |