Previous by Date |
Index by Date
Threaded Index |
Next by Date |
---|---|---|
Previous by Thread | Next by Thread |
Re: Consortia pricing
The issue of consortial pricing raised by John Campbell is an interesting one. Mr. Campbell raised in the context of JSTOR so, disclaimer first: my library is a charter member of JSTOR. If he doesn't know it already, the main thing I would advise Mr. Campbell to be aware that while many libraries have joined JSTOR and many members (and non-members) are supportive of this digital initiative with an emphasis on the archival as long overdue -- applause, applause -- the biggest complaint I have heard regarding JSTOR is its stance not to deal with library consortia. (This complaint gets "mixed up with" the belief that JSTOR is over-priced; that is, since a library cannot get a discounted price via a consortia, it is too expensive.) Indeed, "complaint" really isn't strong enough; many colleagues I talk to are offended by this position. I have asked JSTOR about this issue directly and the response I got was that they see no economic advantage or efficiency to a consortial arrangement. My interpretation of this remark was, "we can't see what money or services we would save in dealing with a consortia of 10 libraries versus dealing with 10 libraries individually, therefore we have no basis on which to base a consortial pricing with reduced costs." I think this logic is short-sighted and incorrect. Many of those hypothetical 10 libraries might not join at all due to individual pricing, but *all* 10 might join if consortial pricing is permitted and costs are shared. In the end, I think vendors should and would end up getting more money with consortial pricing than without. Of course, in addition to the increased dollars, they will also have the additional burden of support for those 10 libraries (requiring, perhaps, faster connectivity, greater load on servers, etc.) Still, however, this *is* a digital product and the cost of additional digital copies are not as compelling or direct as in the paper space. Note: it is amazing how many consortial arrangements of which libraries can be members! We're a medium-sized academic library in Mass. and I can easily name a dozen consortia or affiliations which might serve as the basis of some vendor digital initiative. It starts with very broad groupings (such as Nelinet, our OCLC provider) and all the way down to very small but very effective local affiliations such as SMCL, consisting of the four academic libraries in this part of the state. I would agree that a consortial arrangement should have some advantage to the vendor in terms of reduced contact points for support issues and billing/payment. I think these are very reasonable requirements and any consortia that does not offer them is not, in my opinion, a reasonable arrangement for the vendor. However, in addition to the economic factors, there is a more fundamental reason why I think JSTOR's position is wrong and is also the reason why libraries are offended by its position. Libraries have a long and valuable history of consortial arrangements resulting in the sharing of materials, support, expertise and costs. I think we're one of the few entities in higher ed that have such meaningful relationships. We deserve credit for that. Moreover, in these days, when we all recognize that not even the largest of libraries can have everything and the increased importance of access and delivery vs. ownership, these relationships are increasingly important. We should encourage and enhance them, not abandon them. Indeed, we should look for ways to creatively apply these relationships in the new digital world. Ultimately, I believe that what's good for libraries are good for the vendors we deal with; that includes consortial relationships. ------------- David Carlson Director of Libraries Bridgewater State College Bridgewater, MA 02325 E: dcarlson@bridgew.edu V: 508/697-1256 Fax: 508/697-1349
http://www.library.yale.edu/liblicense © 1996, 1997 Yale University Library |
Please read our Disclaimer E-mail us with feedback |