Re: building the "next generation" library catalog

Both Eric's email and Jonathan's response
contrasts "commercial" with "open
source."  Happily, this is not really
necessary--or for that matter, even logical.
Commercial refers to a type of company.  A
commercial product or service is one that is
produced by a for-profit company.  Open source
refers to the type of license by which software
is distributed, and has nothing to do with
whether the software is distributed by a
commercial company, an individual, a non-profit company, etc.

I am not just splitting hairs by pointing this
out.  Much of the discussion of open source
software for libraries has hidden assumptions
that are not examined and that are not true.

There are commercial companies that develop
software and distributed it under an open source
license.  Those companies also offer ongoing
support, as well as installation services,
customization services, and sponsored development.

In reality there is no need to choose between
having a commercial company to rely on and being
able to utilize open source software, with all of
its attendant advantages.  You can have the best
of both worlds by working with commercial
companies that distribute and support open source library software.

David

At 03:50 PM 09/01/2006, Jonathan Rochkind wrote:
>The point of 'communication', as well as possibly computer hardward and
>software (to the extent you mention sharing code between libraries) are
>about NOT building it just for yourself, but coordinated efforts between
>libraries.
>
>That's the real difference---the environment that makes distributed open
>source projects possible. I think that an actual distributed open source
>project with buy-in from, say, at least three institutions (and
>hopefully more later) has a lot more chance of being succesful than
>something you really are developing just for yourself.  If you really
>are just doing it for yourself (and maybe not even making the code
>shareable at all!)---I'm not sure there really are enough environmental
>changes to make this a winning proposition.
>
>The problem, of course, is that you can't be sure something you are
>developing yourself will result in a true open source community being
>developed around it. It's a risk. But, honestly, I think it IS a risk,
>and I wouldnt' want decision-makers thinking otherwise. Buying
>commercial software is a risk too, of course, in many ways. The
>analagous risk would be buying the first version of a software product
>from a new company--who knows if they'll stay around? On the other hand,
>just quite as you reduce your risk (at least that kind of risk) by
>buying from an established and respected company, you reduce your risk
>by using more 'established' open source software instead of starting
>your own from scratch. It's important for libraries to take the risk of
>starting stuff from scratch too---the environment we're in, significant
>innovation is needed (another risk of staying with established
>commercial vendors is getting not enough innovation). But it is indeed a
>risk.
>
>And, again, I think the changed environment is mostly about the
>environment that makes distributed open source possible. If your
>in-house project isn't or doesnt' become a succesful distributed open
>source project---I think it's just as likely to run into the same
>problems in-house software always has.
>
>Jonathan
>
>Eric Lease Morgan wrote:
>>How will we, the library profession, build the "next generation"
>>library catalog, and to what degree will the process include vendor
>>support and open source software?
>>
>>I must admit that there are few things that do not succeed over time
>>without some sort of commercial interest. Think OCLC. JSTOR. Even
>>NOTIS. The only exception to the rule seems to be when government
>>subsidizes the process.
>>
>>Be that as it may, I will still advocate a large dose of grass roots
>>efforts lead by the library community exploiting open source software
>>over something created by a commercial institution. At least for now.
>>Moreover, when your fellow librarians say things like, "We tried
>>those 'homegrown' systems a long time ago, and where are they now? We
>>need vendor-supported software", I can give you a number of reasons
>>why this is not necessarily the case in today's environment:
>>
>>   1. Computer hardware & software - Twenty or more years ago, when
>>the library profession was supporting "homegrown" systems, the
>>hardware used was vendor-specific. Maybe you had a Prime. A Unisys.
>>An IBM 360. A DEC Watchamacallit. A Sun Something. Etc. These
>>computers had less RAM, less disk space, and less processing power
>>than the computer you have on your desktop right now. Each of these
>>computers had their own operating system and set of programming
>>languages used to create applications. The applications created for
>>these systems was not sharable between computers, and consequently is
>>was difficult, if not impossible, to share code between libraries.
>>Now-a-days the applications will be written for Unix/Linux or Java --
>>platforms that are not computer hardware specific. (If someone
>>creates a Microsoft-based "next generation" library catalog, run the
>>other way, very fast.) The code written for one computer will run on
>>the next computer (no puns intended) without much modification, and
>>this will enable the library community to collaborate to a greater
>>degree.
>>
>>   2. Relational databases - Relational databases and the technology
>>used to implement them was embryonic when libraries were supporting
>>their "homegrown" systems. There were few, if any, well-supported
>>best practices for managing large sets of information. And even when
>>you did you sat around worrying whether or not you should allocate
>>two bytes of disk space to denote the name of a state or twelve.
>>These problems are far less challenging now with the cost of disk
>>space and the availability of any number of relational database
>>applications. The problems of storing the data is much less limiting
>>than it was twenty years ago.
>>
>>   3. Indexing technology - Databases are great for storing and
>>manipulating information. Ironically, they are poor on searching. To
>>search a database you must know the underlying structure of the data.
>>Indexes remove this problem. They invert the content of the database
>>creating lists of words and pointers to records. No knowledge of the
>>database's structure is necessary. Couple this with statistical
>>analysis and indexing technology begins to appear "smart" -- think
>>relevance ranking. Indexing technology has matured to a very large
>>degree in the past twenty years, and there are a large number of
>>freely available indexers. How many indexers were available twenty
>>years ago? One, maybe. BRS.
>>
>>   4. Skills - Computers twenty or more years ago were expensive,
>>very expensive. Much fewer people had access to computers and a
>>proportional number of fewer people had computer expertise. Now-a-
>>days hackers abound. [1] If they didn't we wouldn't have the email,
>>Web servers, MySQL, Perl, PHP, Linux, or just about anything related
>>to the Internet. Put another way, there are many many more people now-
>>a-days who know how to make computers do the things they do. There
>>are computer programmers around, they just don't work in libraries to
>>a large degree. "Libraries are about books. Right?"
>>
>>   5. Communication - Communication via the telephone is dirt cheap.
>>You can make long distance telephone calls for pennies. From my
>>workplace here in Indiana I can talk on the telephone with people in
>>the United Kingdom for .02¢/minute. At those rates it is silly not to
>>pick up the telephone. The biggest thing the Internet does is
>>facilitate communication. People-to-people communication. People-to-
>>computer communication. Computer-to-computer communication. Twenty
>>years ago the story was much different. You were lucky to have a 2400
>>baud modem and you dared not make a long-distance telephone call.
>>Because of our increasingly seamless ability to communicate across
>>long distances, it will be easier for libraries to coordinate their
>>effort and create something from the community.
>>
>>In short, don't let people write you off when you say, "We can built
>>it ourselves." Explain to them how the computer environment is
>>substantially different from previous times. Enumerate the things
>>outlined above. Yes, the human challenges still exist. Building
>>consensus. Setting priorities. Keeping things on schedule. Creating
>>communities. Bringing people physically together. Allocating time,
>>space, people, and money. But are those the things you want to pay a
>>vendor for? The other things are "as free as a free kitten."
>>
>>Food for thought on a Friday afternoon.
>>
>>[1] Hackers in this context are contrasted with "crackers". Hackers
>>are the good guys. They look at source code and figure out ways to
>>improve it or modify it for their own purposes. Crackers, on the
>>other hand, are malicious. They look for ways to exploit software for
>>immoral purposes.
>>
>>--
>>Eric Lease Morgan
>>University Libraries of Notre Dame
>
>--
>Jonathan Rochkind, MLIS
>Sr. Programmer/Analyst
>The Sheridan Libraries
>Johns Hopkins University
>410.516.8886
>rochkind <at> jhu.edu
>

David Dorman
US Marketing Manager, Index Data
52 Whitman Ave.
West Hartford, Connecticut  06107
dorman <at> indexdata.com
860-389-1568 or toll free 866-489-1568
fax: 860-561-5613

INDEX DATA Means Business
for Open Source and Open Standards
- - - - - - - - - - - - - - -
www.indexdata.com