Late in 2001, the Nelsonville Public Library became interested in exploring the possibility of doing away with our commercial integrated library system (ILS) and replacing it with open source software. While I am sure cost (or rather, the lack of cost) was part of the allure of open source, if I recall correctly Joshua F., the library's systems administrator, was aware of open source software, was new to libraries, felt that librarians should be able to easily sympathize with the philosophy of open source, and was shocked at how much libraries were willing to pay for their commercial -- and very specialized -- software.

At some point Joshua convinced me to look into Koha, an open source ILS, and I eventually convened a committee of library staff to investigate. This "Koha Team" included me (Library Director), the Assistant Director Lauren M., Joshua, Owen L. the library's webmaster, and Ken R., our principal liaison with the vendor of our commercial ILS. This committee started meeting in early January 2002 and held occasional meetings throughout the next couple of years. The bulk of our "meetings," however, were conducted by e-mail.

I began saving selected e-mail messages in February 2002, thinking that they would someday provide a good "history" of the Koha implementation process. Now, as the library prepares to move to Koha version 2.2, it seems that the time has come to close off this history and share it with anyone who might be interested.

These messages are selected messages, so transitions between messages will not always be smooth. And since I collected them, they do not include messages which I did not receive. Still, I think they pretty accurately convey the problems, the solutions, and the general mood of the Koha Team as we worked through this process.

In the interest of protecting people's privacy, I have edited all messages to take out e-mail addresses and have not used anyone's surname (other than my own). I have also removed the > sign typically used to denote text copied from an earlier message, and instead use italics, so the text can flow without concerns about line breaks.

sh

Okay, I'll bite...what other means of identification could we use besides a library card #? I could see a change in card format (perhaps to a magnetic stripe and/or smart card, which would allow us to store data on the card itself), but not in the need to have a membership number.

I don't see us ever using a person's Social Security Number,although many institutions already do so. Perhaps logins and PIN's are an option, but that presupposes self-checkout and/or some form of patron interaction with the checkout process.

Ken

Congratulations to Joshua and Owen on the quick progress in setting up Koha, and also for getting Charles V involved in the data transfer. Now we need to meet before you two meet with Charles on the 19th to discuss some broader issues that may affect our data structure. For example: will we use library cards in the future? If not, what will we use as an ID number? How do we need to structure that data column?

We also need to think about what Spydus data, particularly patron data, we want to keep in the transition. In other words, we need to give some serious thought to our data design.

I'd like to meet next Friday, February 15, at 2:00 p.m. at the Athens Library. Please let me know if you cannot make that meeting time and place. Thanks!

Stephen

***

Hi all,

The sample data is loaded! Thanks Owen for your SQL expertise. I need to bring the circ interface up and we will be ready for testing, etc.

To test the search features with the sample data go to: http://13x.18x.10x.25x

Let me know how it works.

Joshua

***

OK, let's meet on the 29th. If it's going to be at The Plains, then we'll need a computer to get to our koha page. What time? (I have a meeting in Athens at 2:00.)

I've been working on installing koha on my laptop, usually a couple of steps behind Joshua, and Joshua and I have both had problems installing the cdk libraries and perl module that koha requires for telneting to the circulation interface. (Our problems have been different, but I think that's because we downloaded the cdk libraries from two different sites.) Joshua was not happy with the web interface, I don't remember why. Chris C's reply seems to indicate that the web interface is still the better choice, however.

Stephen

***

I went over it pretty fast, so here it is again:

http://13x.18x.10x.25x/secret/tech/dev/notes.cfm

There you'll find the Koha notes we have so far, as compiled by Stephen. I made sure there was a way to add a new note, so if anyone has any documentation they'd like to contribute, please do. This is pretty quick-n-dirty, so if anyone has any problems or ideas about a better way to organize things, please let me know!

-- Owen

***

If you're a little tired of looking for errors in scripts, how about a philosophical question -- how many different kohas should there be?

I've noticed that there are some significant differences in what libraries from different areas of the world expect their software to do. For instance, while ten-digit barcodes seem to work well in the South Pacific, in the US (and Canada?) the fourteen-digit barcode for both book ID and 'member' ID seems to be becoming a de facto standard. And then there's the whole MARC record discussion -- just whose MARC format are we discussing? There's Paul's MARC standard in France, there's USMARC, and I get the feeling MARC may not really be all that important Down Under. And while tracking and storing information about ethnicity is necessary in New Zealand, most libraries in the States would find that idea disturbing.

It almost seems as if there are unwritten standards controlling the basic features of library automation systems in different countries. If you think about it, this makes sense. Libraries act like government entities (indeed, they often are), so its not surprising that they try to do things the same way whenever possible, to allow them to interact more easily. But they seldom have any need to interact with libraries outside their own country or area of the world, so regional differences have developed.

Let's use our library (Nelsonville Public Library, Nelsonville, Ohio, USA) to illustrate my point. We have been investigating the possibility of using koha to replace our current Sanderson system. In listing the things we would need to change to make koha work for us, we so far have identified:

While these modifications are necessary to make koha a viable alternative for our library, they would be useless for Paul P's library (or Roger B's library, or Steve T's library, etc., etc.) So let's put my original question a little differently -- is one version of koha enough? Maybe there should be groups in different areas of the world working to develop regional versions of koha. Or has that happened already and we just aren't hearing anything about it?

Stephen Hedges

Director, Nelsonville Public Library

***

Dear Stephen,

I run both a medium size library and and a library system of nine rural libraries in northwest PA. We are located in Crawford County PA which borders the Ohio State line. For the past two and half years we have been incorporating more and more of our information systems into open source platforms. For example we use open source for e-mail servers, web hosting, firewalls, proxy servers, and filtering.

We have been investigating using some sort of Open Source software to migrate from our current circ. system. We have investigated two programs, Koha and OpenBook. Unfortunatelly it looks like Open Book is no more so that leaves Koha.

We have looked at the Koha Program and believe that the changes in the program you outlined in your e-mail are similar to the changes we also wish to make. I also believe that your idea of creating different regional versions of Koha makes a lot of sense.

At this time I wish to state that the *** Public Library would be willing to help out in anyway we can in developing a midwest version of Koha.

We look foward from hearing from you.

Sincerely,

JJB

***

Hello again,

How goes the Koha project? I'm sure you've noticed Koha 1.2.0 was released a little over a week ago. Although there are a few bugs to work out, the new system (if you havn't tried it) seems to be a little bit smoother than its 1.0 counterpart. I've been able to get into contact with a few of the programmers working on the Koha source, and they seem to be very open to any new ideas that people come up with. I've personally been working on Koha for a small organization in Chicago who wishes to keep track of their small (very small) book collection, and they've been very helpful when it comes to figuring out problems. I'm sure they would be more than willing to help bring Koha to this area.

Was there any aspect of your project that I would be able to help you out with? There are parts of the interface I'm working on that I would be more than willing to contribute to your project (a lighter GUI, designed for smaller systems such as handheld and pocket PC, as well as some barcode check digit issues).

I look forward to hearing from your about your progress.

--CJ

***

Hey, I've just done a MARC import to our Koha machine, and it's slick! Ken and Owen, you can get to Koha by going to http://6x.21x.7x.7x:8080, use the same login as for the staff webpage. Under acquisitions, upload MARC records, you'll see a list called "marclist" that I downloaded directly from one of my iPage orders. I went ahead and added one item, "Black River" by G.M. Ford. Try it!

This could make cataloging very easy. I could download MARC lists as I place orders, and the catalogers could pull up the items from those lists as they arrive, add barcodes, and load them into the system. Very nice!! I think I like it better than the bulk MARC import that Paul P is working on.

Stephen

***

Koha, The Next Step(draft)

Well, Koha has been up and running for a few days now. During that time I have given thought to what our next step should be. I think there are two main areas that we need to pursue, Database Concerns, and Module Concerns. I will define them as follows (please add to this or redefine as you see fit):

When I think of our implementation of Koha, I am not merely thinking of it as a replacement for Spydus. It has so much more potential than that.

Any ideas on when our next meeting will be?

***

Owen's traffic on the koha list sent me back to look at our export options on Spydus. We can export MARC records, of course, and probably use the bulkmarcimport.pl to load them without much problem. (Unless we want to wait until there's full MARC support in the koha database.) But for patron records, the only option I see is a listing of all patrons. We could, of course, capture the listing in a file as it scrolls by on the terminal, and maybe even load it into Excel or Access for downloading to koha. Just an option to pursue if we can't come up with anything better. (Owen and Lauren, didn't Charles say he would move the Unidata data to Access, then to MySQL? Or is my memory faulty?)

Stephen

***

We can export MARC records, of course, and probably use the bulkmarcimport.pl to load them without much problem.

But that just exports the MARC records, right? No item records, no circ records, etc?

(Owen and Lauren, didn't Charles say he would move the Unidata data to Access, then to MySQL? Or is my memory faulty?)

I remember Charles praised Excel (maybe Access too?) for its data-importing capabilities, so I think you may be right. Trying to picture the process in my head, I'm thinking that's the thing to do, because it would be an easy way to correct problems with the data before we put it into MySQL. For instance, it drives me crazy that half the patrons in the database have a phone number like this: 6145924272. Would could do a search and replace in Excel/Access to correct formatting issues like that before putting the data into MySQL. It could be done either place, Microsoft's interface is friendlier.

-- Owen

***

Stephen Hedges a ecrit:

Paul -

I've been looking at the "ToDoMARC" list on the SAAS website and wondering about "create parameter table for different MARC formats and different languages." Do you need MySQL tables set up to hold the fields of the different MARC formats? Do you still need someone to do that in English? There are three of us here at the library who could probably put our heads together and do this.

Thanks a lot for your proposal.

i've volunteers for UNIMARC in french, i already have USMARC in english, if you want to do another parameters file, you're welcomed. I've requested an ASCII file, because i plan to build a small script during installation of koha that permits chosing the MARC you want, and download it.

If you prefer to populate mySQL directly, you can, but please sent me ASCII exported files (CSV).

thanks

-- Paul

***

On Fri, 23 Aug 2002, Stephen Hedges wrote:

Thanks for your help, Pat. We'll start working on the RFP's, and we'll try to do it without too much input from you (since you might want to put in a bid yourself).

Sounds good. I'm really only interested in the z39.50 and NCIP/SIP2 pieces, so if you'd like advice/help on the MARC RFP, I'd be happy to help there (while avoiding any conflict of interest). When you're ready to send out the RFPs, please send them to kohabiz@. I'll probably put them online in an archive as well so that people not yet on the mailing list can get to them through a permalink.

As for using the Nelsonville Library in Koha promotion, that's fine with us.

Thank you. I'll start up on an article right away then. I'll send along a second email with some questions. Please feel free to send it along to other staff who might be interested, the more input the better.

In fact, we are going to be giving a presentation on open source in general (and probably Koha specifically) at this fall's Ohio Library Council Annual Conference in Columbus. We don't believe in being shy librarians! And of course, our presentation handout will list sources of information about open source for libraries, including the Koha list archives.

That's great! Let me know if there's anything that I can do to help. When is the conference? It would be nice to be able to coordinate some kind of Koha activity for it -- I don't know that we could get anyone there, but you never know.

Pat

***

Stephen, thanks again for taking some time to help with Koha. I think that having some bigger libraries here in the States using Koha is a big step for us and will really help push Koha to the next level.

As I'd explained, I'm planning on putting together some materials to help market Koha more effectively and wanted to get a little more information from you first. If you and/or your staff could help by answering these questions, I'd very much appreciate it.

If you have any other thoughts, insights, concerns, or questions I'd be happy to hear them as well.

Thanks,

pate

***

Pat, you ask some very good questions! To answer one question from a different e-mail, the OLC Annual Conference is October 23-25, and our session is the last one on Friday afternoon. :-( We'll see who's truly interested in Open Source!

1) When did you first consider using Koha?

We started lurking on the Koha list about a year ago, though now I don't remember how Koha first came to our attention. In January of this year, I'd seen enough to pull together a "tech team" consisting of me, the assistant director, our webmaster, our systems administrator, and our circulation software supervisor. We decided to embark on an experiment: Could we switch all of our automation software, from operating systems to webtools, to Open Source by the end of this year? We decided that there was no "success" or "failure" involved, just a simple research question with a "yes" or "no" answer. No matter the outcome, we would have gathered a lot of information, and we made plans from the very beginning to share this information with the library community.

2) What was the initial draw of Koha?

Freedom. We want to use the Internet to offer some cutting edge information services to our library patrons, but we realized that this would require us to have control of our automation and database software. We needed the freedom to change things, to change the code if necessary, because the types of things we want to do are not going to appear in commercial library software for years. (Commercial library software vendors are more interested in the bottom line than the cutting edge.)

3) What drawbacks did you see with Koha?

The same drawbacks that plague many of the smaller Open Source projects, I suspect. First is the irregular pace of development. Since Koha code development is a "spare time" activity for most of the programmers, the pace of Koha's growth is hard to predict. We found ourselves waiting for crucial modules to be developed, sometimes wondering if they ever would be developed, often suspecting that the answer to our original research question would be "no" - we couldn't switch to a completely Open Source system.

The second is the problem of "splintering." If we took the developing Koha code and finished it to fit our needs, hardcoding the features we needed and leaving out things we didn't need, we would have in effect created a new version of Koha that had departed from the main development tree. That would mean that we could not take advantage of future upgrades to the main tree.

On the other hand, if we mustered our patience and waited, would Koha ever have enough of the features we needed to be a viable automation system for our library? This is a significant problem: How do the programmers know what the majority of libraries will need, and how do libraries know if Koha will eventually have all the elements that are considered crucial?

4) You've made a decision to contribute to the development of Koha. When HLT first commissioned Koha, they decided to make it Open Source hoping that other libraries would step in and support development of new features as well. What are your thoughts on this model?

We've come to realize that this may be the only viable model, and perhaps the answer to the question I just posed. It's important that libraries do not look on Open Source as free software that they just download, press a button, and all their problems will magically be solved. Open Source requires just as much commitment as commercial software - you still only get what you pay for.

Libraries should approach Open Source with the notion that they will commit a lot of staff time to understanding the code and how the software does its job. They should also be ready to commit financial resources as well, just as if they were still paying annual license fees for commercial software. The difference is, with commercial software a big portion of the license fee goes to research and development over which the library has no control, while with Open Source that same money can fund the development of the software modules that the library really wants.

HLT has paid their money and received a product that works fine for their needs. Now other libraries can pay a little more money and receive enhancements to that product that will make it fit their needs - without having to pay for the development of an entire software package. HLT got what it wanted, we plan to get what we want, other libraries can pay and get what they want. The libraries are paying a one-time expense that's probably less than their annual license fees, so they win. The programmers get a very clear idea of what libraries want (money talks!), so they win.

It's a great model for success!

5) What kind of external support are you using, or do you foresee using as you convert onto Koha?

Very little.

We originally thought we would use a database consultant to assist in moving our data from our current system to Koha. (This is a task that's typically handled by the "new" software vendor when libraries switch from one commercial product to another.) We've recently realized, however, that the mechanics of the data transfer are not as difficult as identifying which data we want to keep and which is superfluous. For that reason, we'll probably do the data transfer ourselves.

Otherwise, the tech team is working to learn the tools we will need to maintain the software: perl, linux, mySQL, php, etc. We regard this learning process as part of our investment in Koha. And remember, our original motivation in looking at Koha was the ability to offer some cutting edge services, so we'll need to have a thorough understanding of the software for more than just maintenance purposes.

6) What are the major milestones in the conversion process?

A big one was the release of Koha 1.2.0 in July. For the first time, we saw a product that looked like a viable alternative to our current software. In late August, we held a day-long meeting of the tech team to review everything that we had seen and learned so far in our research project, and we decided that Koha lacked only three absolutely critical things for our needs: full MARC support, a Z39.50 server module, and a SIP2 or NCIP module. To fill those needs, we decided to commit some financial resources to Koha development.

Our future plan is to move some of our data into the current version of Koha to see what changes we will need to make in the Koha tables. (And we would then suggest to the Koha developers that these types of changes should be built into some sort of configuration utility or template, rather than being hardcoded.) Once we have a little of our data transferred and working, we will transfer the rest and plan to run Koha in tandem with our old circulation system. This will not only allow staff to get familiar with the new system (Koha), it will also give them an opportunity to request changes to screens, customized functions, etc. Once we find that Koha has become the system of choice for the staff, we will shut down the old automation system.

7) When will your patrons be able to see Koha in action?

We expect that Koha will take over from the old system sometime during the summer of 2003.

8) What do you think you're going to see in terms of an ROI on your investment in Koha development?

I expect that an initial investment of about $10,000 will save us about $10,000 every year, beginning in 2003. We might also seek some technology grant money to extend our initial investment.

I think our real ROI will not be financial, however. Within the next few years, we fully expect that our website will offer some of the best online library services available anywhere in the world. That's the value we expect to get from investing in Koha.

Stephen

***

Well, Pat, you said:

if you'd like advice/help on the MARC RFP, I'd be happy to help there

OK, here's my first draft. Since I've never written an RFP for "custom" software before, this may be really out-to-lunch. Please let me know what you think, and I'll run it by some folks here, and _maybe_ we'll have something that's ready to post in a few days.

Stephen

REQUEST For PROPOSAL -- MARC 21 record support for Koha application (koha.org)

The Nelsonville Public Library invites all interested parties to submit proposals in response to the following request. Proposals may be submitted in any format, but should carefully answer all questions in the request. Proposals should be sent to Stephen Hedges, Director, Nelsonville Public Library, e-mail nelpl@athenscounty.lib.oh.us, fax 740-753-3543, mail 95 W. Washington Street, Nelsonville, Ohio 45764. Proposals are due no later than 8:00 A.M. Eastern Daylight Time, September 30, 2002. Any responses made in proposals from interested parties may be incorporated as part of a final agreement.

BACKGROUND

The Nelsonville Public Library is a public library system consisting of seven libraries serving the residents of Athens County, Ohio, USA, with 36,000 active borrowers and over 250,000 items in the collections. The library has made plans to switch from its current library automation system to Koha, but only if Koha has certain required capabilities. Among these is the ability to store and retrieve item records in MARC 21 format at the (Full) National Record Level.

Accordingly, the Library is seeking proposals from parties who are capable of modifying the current Koha code to provide this capability. Proposals will be evaluated by a committee of five Library staff members, and a contract will be negotiated with the submitter of the successful proposal.

SELECTION CRITERA

Proposals will be evaluated on the basis of cost, qualifications of the programmer(s), time to delivery, ease of integration of the proposed code into the current Koha software, and ease of upgrading the delivered software to incorporate future changes to the MARC formats.

REQUIRED INFORMATION

***

Here's my first cut at a longer article about NPL and Koha. I'm planning on submitting it to a couple of news outlets ... I'd happily take suggestions on possible targets as well as criticism about the writing or content.

thanks,

--pate

----------------------------------------------------------------

Library invests in Free Software.

Nelsonville Public Library (NPL) serves the residents of Athens County Ohio. Like most libraries, they have to weigh the money they spend on Information Technology very carefully since every dollar spent on computers and software is a dollar they can not spend on books. It might seem odd then, that they have decided to spend money on free software.

They look at it as a wise investment though. "I expect that an initial investment of $10,000 will save us about $10,000 every year, beginning in 2003." says Stephen Hedges. "I think our real Return on Investment (ROI) will not be financial, however. Within the next few years, we fully expect that our website will offer some of the best online library services available anywhere in the world. That's the value we expect to get from investing in Koha."

NPL's plan is to initially copy some of their data onto a Koha system to use for testing. Then as the librarians gradually become more accustomed to the new software they will move their live system to Koha as well. They expect to complete their conversion in the summer of 2003.

What does their investment mean though, and how did they come to feel the way that they do? To answer these questions, we'll need to look at some history.

Traditionally, libraries turn to big software vendors and proprietary software to run their libraries. In 1999, a rural library system in New Zealand, the Horowhenua Library Trust (HLT), was at a crossroads. They needed to upgrade their library software, but didn't want to be stuck with the high price tag that they knew would be a part of the package. They made the bold decision to work with Katipo Communications of Wellington, New Zealand. Katipo suggested that they develop a new system based on open standards (like using a web browser for the client software), and Open Source software (like Linux, MySQL, and Perl).

Katipo recommended that the new application be Open Source as well. This accomplished three things: it protected HLT from anything happening to Katipo, the software would always be there and anyone could work on it; it freed Katipo from becoming a software marketing company, allowing them to concentrate on web development; and it allowed other libraries to work with the software, installing it for little or no cost and extending it to fit their own needs. Fittingly, this new sofware would be called 'Koha', a Maori word meaning 'gift'.

Koha was released in 2000, and was quickly picked up by several other libaries. Among the most active were the libraries of the Coast Mountains School District in British Columbia, Cananda. Steve Tonnesen, a Network Technician working for the district, found Koha as he was searching for an inexpensive method for upgrading the library software at one of the schools in his district.

He quickly moved past just installing the system and began writing new functionality into the software. He added MARC import tools, a client for Z39.50, and multiple improvements to the system. Because the software was licensed under the GNU General Public License (GPL), he was not only free to make these changes but also to release them to the rest of the world, which he did.

Other libaries and developers have picked up Koha for their own use. As each one has done so, they've started to make improvements. Almost all of these improvements have worked their way back into the main Koha system. The initial gift that made Koha has been passed along and has grown with each new stop on its path.

Stephen Hedges says, "HLT has paid their money and received a product that works fine for their needs. Now other libraries can pay a little more money and receive enhancements to that product that will make it fit their needs - without having to pay for the development of an entire software package. HLT got what it wanted, we plan to get what we want, other libraries can pay and get what they want. ... It's a great model for success!"

NPL started looking into Koha about a year ago, and although things sometimes looked a bit bumpy, they put together a formal team to explore using Koha and other Open Source tools in January of this year. By August, they had decided to migrate their library system to Koha.

Key to making this migration work were three specific modules. One was under active development, the other two were not. NPL decided that they could put their money where their mouth was and help fund development on these three modules. According to Hedges, this seemed natural. "Open Source requires just as much commitment as commercial software. Libraries should be ready to commit financial resources. The difference is, with commercial software a big portion of the money goes to research and development over which the library has no control, while with Open Source that same money can fund the development of software modules the library really wants."

This has some profound implications for the Koha project as well. While much of the work is being done by developers on their free time, this funding will allow some of them to expand their work on Koha. As libraries step forward to fund work, the work that they are most interested in seeing will be the work that gets the most attention. This really is a case where the consumer can vote with their checkbook.

For more information about the Koha project, please see its website at <www.koha.org>; or send email to <<info@koha.org>>.

***

I just read the announcement on oss4lib that Nelsonville will be converting to Koha. I think that's very exciting, and I wanted to congratulate you on taking this direction. And, of course, I'm interested in seeing how Koha might be able to work with MORE.

Wishing you success,

DY

***

Mr. Hedges:

My name is Brian P, and I manage and write for several Linux and Open Source Web sites. I read with interest a recent release regarding your library's decision to move to the Koha library system, and I was wondering if you or a member of your staff would care to be interviewed for an article about this subject.

As a former library clerk myself, I have more than a little curiousity as to how this decision came about and how it will be implemented.

If you are indeed interested, please feel free to reply to this e-mail and we can set up a time for a phone interview.

Thank you,

Brian P

***

Pat,

The library board gave official approval to release the MARC RFP last night -- I've included the version they approved at the end of this message, and would appreciate it if you would distribute it however you see fit. It is rather formal and intimidating, but library boards (attorneys, educators, etc.) tend to think that way, especially since they are entrusted with stewardship of the public's money. In reality, I see the project as being a much looser process -- let's get it done any way that works. I'm happy to answer any questions I can, join in any discusssions where I'm wanted, etc. Once I have some idea of the type of money we're talking about, I'll probably start soliciting other libraries to help, and apply for a matching grant from the Feds.

Thanks for all your help, Pat!

Stephen

***

Nelsonville Public Library recently made the decision to become actively involved in the development of Koha, an open source library automation system.

The news has been bouncing around in Linux e-zines and generating some interest in the open source community, so some of you may be interested in more information, too. You can go to our homepage, http://www.athenscounty.lib.oh.us, and follow the "Koha" link to learn more.

If you're not familiar with open source systems for libraries, please check out http://www.oss4lib.org.

Remember, NPL will also be doing a Friday afternoon session about our ongoing open source project at the OLC Annual Conference.

Stephen Hedges

***

Good, I'm glad you liked it!

Please let me know when Koha is about finished--I'm also a private pilot, and the chance to fly out and do a live story would be great.

Thanks again,

Brian

On Sat, 2002-08-31 at 13:52, Stephen Hedges wrote:

Brian, I just finished reading the Linux Planet article about Koha -- great work!

Stephen Hedges

***

Stephen,

I've been talking to Glenn about a Linux Show in Toledo, Ohio on Oct 30-31. I think this might be a nice cross-over opportunity. If you guys would be interested in making your presentation about OSS in libraries to a second audience, Glenn can probably find a spot for you on their schedule. They'd also be willing to donate a booth to Koha (or maybe OSS for Libraries) if we can scrape together a couple of bodies to staff the booth.

Glenn has offered free show passes to a presenter and a couple of booth staffers. I think they'd love to see interested librarians at the show to see other Open Source solution providers. More information on the show can be found at: http://lwn.net/Articles/8961/

Why don't we kick this around a bit and see what we can come up with.

-pate

***

I added stuff to our Koha page, following suggestions from both of you. Let me know if there's any changes you'd like to suggest.

Also: You may have seen that someone beat me to the punch in volunteering for the HTML/CSS help, only to be told that there was nothing to be done right now. Sounds like they're still working on a templating system, and until then any HTML work would be redundant. Bummer.

-- Owen

***

Pat and Chris -

The Ohio Library Council Annual Conference runs from October 23 through October 25. The slot for our presentation on open source is on Friday at 2:00, the very last time slot. Just so you have no illusions, we are expecting only a handful of people to show up for the presentation, since most folks will probably leave at noon, having had their fill of conference. And there are no exhibitors at this conference (they do that separately in May), just presentations. We'd love to have you on board for the presentation, Chris, and we'd also love to have the chance to spend time meeting with you while we're all in Columbus, or spending time with you in Nelsonville, whatever. I'm not sure what you'd like to accomplish on this trip, but we'll do whatever we can to make that happen.

Now, for my purposes, the value of the Think-Linux show will be rubbing shoulders with a bunch of other open source folks, so that's why I've been thinking in terms of helping to man a booth. However, I'd also be willing to help with a presentation, if you folks want to do that. Just let me know.

Stephen

It certainly fits into the times ... the two shows are Oct 23-24 (right Stephen?) and Oct 30 and 31.

Shall the three of us put on our writing caps to come up with a presentation for Think-Linux?

-pate

On Mon, 9 Sep 2002, Chris wrote:

Hi Pat

I can get a return flight to columbus ohio for the grand total on 93$nz :) (taxes) the rest are covered with my miles

Id leave nz oct 21, and arrive in columbus the same day (crazy timezones) Then leave from columbus on nov 8 and lose a day or 2 on the way back.

Does this fit with the times for both events? I can perhaps shuffle the flights around a bit (united isnt exactly full at the moment)

If this sounds doable ill look into accomodation and transport around ohio, and then confirm the tickets.

Chris

***

Hi there,

Im still considering whether Ill head over or not. I think the things id like to get out of the trip is to meet the guys from NPL. Listen to some of the talks at the conference. If we could organise some demo-cds to hand out at the conference, that would be great.

Im thinking that the think-linux show will just be a bonus type thing. I dont think the audience there is going to be ideal. But as Stephen said its always great to rub shoulders with other open source minded people.

Now on top of these 2 things, we have a potential client in libertyville IL, which is not far at all from chicago O'hare airport which i have to fly through. So I thought I may be able to pop in on them as well.

So 3 reasons for going, plus the general tourist reasons. Going to see the bluejackets play. The browns are all sold out so maybe going to see some college football .. i hear the buckeyes are good? And isnt Ohio where the original seaworld is? Plus I want to perhaps take a look at the rock and roll hall of fame.

Reasons against, saving my miles for an occassion when we can get more of the koha developers together. This would be a compelling reason ... if I wasnt so scared united was going to file chapter-11 and pull all my miles anyway.

So now im leaning towards going again. So tonight Ill look into accomdation and if it doesnt blow my budget, I think ill confirm my tickets.

Sorry to be so wishy-washy, I have to decide one way or another pretty soon as they wont hold my tickets for much longer.

Chris

***

To the Koha community

Welcome,

Koha seems to be showing up in a lot more places these days. I've heard from people in the US, Ireland, Germany, India, and Panama about their desire to start using it. We've recently shown up on the South African Government's Open Source Software website. I've even seen a Koha installation in Japan. This is really cool! What's even better is that we're poised to do even more.

If you've got a question, comment, or a success story, please feel free to drop me a line.

In breaking news, Steve T has worked a bit more Koha magic. This week he's released a demo CD for Koha. This CD will allow a user to run a sample Koha installation on any Win32 systems that will boot from a CD. What a great way to spread the word. An ISO image (suitable for burning CDs) is available at: <http://sourceforge.net/project/showfiles.php?group_id=16466>;.

Koha has been invited to participate in the Think-Linux show in Columbus, Ohio (in the US). We're not sure yet whether this is logisticly possible for us. If you're interested in making our appearance at this show a reality, or in seeing Koha at a local conference, User Group meeting, or similar event, please let me know.

While the pace of Koha acceptance and development seem to be picking up, we're still a very friendly place for newcomers. If you're new to Koha, please stop by the mailing list and introduce yourself.

happy hacking,

Pat E

***

Hi Guys

Well Ive decided I will head over to Ohio to meet the NLP people and go to the 2 conferences/shows. Im hoping to have a bit of a holiday as well, as im feeling the need :-) (Ive managed an overseas trip each year since ive left uni, this year was looking to be my first without one).

I think ill take stephens suggestion and stay and a motel 6 or red roof inn or the like. But im not too keen on hiring a car and driving on the wrong^H^H^H^H^H other side of the road. :-) So im hoping I can bride one of the NLP librarians to show me around columbus a bit, with the promise to return the favour if they visit nz :) And I think ill make use of the public transport system for the rest of the time.

So i'll talk to rach and pat about getting some brochures to hand out about koha. And we can perhaps burn some koha cds to hand out.

Then ill work with pate et al (if they have time) to figure out what we want to do at the thinklinux show.

Chris

***

On Thu, Sep 19, 2002 at 03:27:45PM -0700, Stephen Hedges said:

You've got a deal, assuming you mean "bribe" ;-| We're all looking forward to meeting you, so I'm glad you've decided to make the trip.

Excellent and oops yes, i meant bribe :)

I have some news to share about the RFP process. We still have not received any formal proposals, but I believe we will get a "pre-proposal" from evolServ Technologies in Dayton, Ohio. I met with Don C, their pres., and Keith C, their account manager yesterday afternoon. (Don seems to get around on the Internet under the name "thelinuxguy.") To summarize, they seem very interested in the project, two of their developers have been investigating the Koha RCs on Sourceforge, but they're not quite sure how much time it will take them to decipher the myteries of MARC. So their plan is to submit a pre-proposal, with the intention of getting feedback from NPL and any of the current Koha team who want to chime in. I assured them that the process is flexible enough to handle that kind of activity.

Cool. Im fairly sure Paul, (the koha MARC guru) was going to respond to the RFP, perhaps Pat and I will chase him up. He may need some help writing the response as english is not his first language. But he has gotten Koha to the point of lossless importing from MARC. And is currently working on export and display routines. So it would be great to involve him in some way.

They may be at the Think-Linux show, too. Don says he has known Glenn J since the '80's, but they haven't yet decided if they'll go.

Cool. It'd be good to meet them.

Oh, as an aside, I was most impressed with the COTA website, specifically the plan an itinerary facility. You type in your departure address and ur destination one, and the time. And they email which buses to catch from where. Quite neat, a system that many other cities could/should copy.

Chris

***

Owen, here's another link for our Koha page.

S.H.

Thanks Stephen,

I am running a story on you implementation in this month's (September) Biblio Tech Review - out Friday morning. http://www.biblio-tech.com//btr11/S_PD.cfm

Peter E

***

On Fri, 20 Sep 2002, Stephen Hedges wrote:

Pat and Chris, I'd suggest that Chris fill out the forms (using "Koha.org" as the company name, so we don't get charged?), but we can use the contact information for Nelsonville Public Library for phone number, fax number, cell phone, e-mail (or maybe Chris' would be better), contact name (Stephen Hedges), etc., since I don't imagine the Think-Linux folks would want to call New Zealand if they have questions.

Right will do.

As for the presentation, may I suggest we do a general overview of where Koha is and what it does, then launch into a discussion of the "Koha model" in which libraries pay for development of open source software. From the questions I've been getting about our RFP, this seems to be a radical notion in open source land.

Im thinking it might be cool to organise to have people in #koha chatting, and have that on the screen behind us during the presentation too? And yep, we can look at HLT funding initial koha, philanthropy funding some changes. and now NLP doing the RFP approach.

Its strange that something that seems so logical, is still seen to be so radical. Mind you good ideas are often that way.

I arrive in columbus at 11pm on the 21st, I figure that gives me some time to coordinate with Stephen. So ill work on a draft with rachel and rosalie, and then fire it through for you guys to peruse.

Chris

We have our first RFP for Koha-MARC, and I've attached it to this note. I suddenly think this would make a perfect LSTA mini-grant proposal, with NPL supplying $x,xxx and LSTA supplying the remaining $xx,xxx. Not many grants would have the potential to benefit Ohio libraries like this one would! So, Lauren, would you download the forms, and let's get started!

And no, I'm not yet assuming that this is the RFP we'll accept, but I am assuming that any others we get will be in this same price range.

Stephen

Mr Hedges,

Please, find as attachment my proposal for integration of MARC21 management into koha.

I'm Paul P, french software developer, working on koha since january/february. I'm the release manager of the 1.4 version (the MARC one), and one of the leaders of "the french community" growing around koha. I'm working as a freelance developper, and coding koha on my spare time. I intend to sell services here in France whenever the french version can be released (installation/teaching/hotline...).

If you have questions, you can mail me (if you want to phone, I'm OK, but my spoken english is not as good as my written english)

However, I'm happy to announce you that today the 1.3.0 version of koha shall be released. This version is the 1st step to MARC management. It's an unstable version, only for testers, but it shows that the analysis we made (and that is inclosed in my attachment) was right : this version manages internaly the MARC DB. A big job is still to be done to reach GUI MARC management and debug the stuff already done. If i'm the winner of this RFP, the money you'll fund will permit a full-time development, so software will be released sooner.

Je vous prie d'agréer mes salutations respectueuses.

Paul

***

Here's our second RFP, quite a bit different from the first. Please look it over, I'd like to discuss both when we meet on Wednesday. Thanks!

Stephen

Dear Mr. Hedges,

Please find below our proposal in response to your RFP entitled "MARC 21 record support for Koha" to provide certain enhancements to the Koha Library Managememt system. Our firm, PSL Tech, specializes in information systems based on open source technology (http://www.psltech.com). We have been in business for over seven years and have worked on many complex data management systems. While our direct experience to date with Koha is limited, we have taken time over the last few weeks to review the code and database and familiarized ourselves with the MARC21 standard. Given the difficult nature of this data, we feel our knowledge of data base design, Perl programming, and open source data base systems could be a big asset to the project. We have a strong interest in Koha since and are very interested in doing this work. Below we have set forth our approach to meeting your requirements.

If you have any questions, please feel free to contact me.

Regards,

Stan G

***

Paul, the "Committee" has met and considered your proposal. I should tell you that this group consists of myself, Lauren M (our Assistant Director), Joshua F (Systems Administrator), Owen L (Webmaster), and Ken R, who manages support of our current ILS.

We like your proposal very much and would like to support your work on Koha. The price of $1x,xxx is higher than we are prepared to pay by ourselves, but we have a plan. We intend to apply for a federal grant (Library Services and Technology Act funds) that would pay 75% of the cost, and we are fairly sure we can get this grant.

However, using this grant would force us to delay any payments until after January 1, 2003. That means we would actually be slowing down Koha development while we wait for the funds -- not a good situation.

Would you be willing to wait until January to receive payment? You would, of course, have to take other work in the meantime, which would slow down Koha development, but it looks like it could still be done by February. Or can we separate a small part of the job, something that you _really_ want to work on right now, pay you for that, and then do the rest of the work later. Because this would reduce the amount of grant money we would receive, we would like to keep any amount paid in 2002 as small as possible.

Finally, we would like to have your proposal (text) in a form that could be edited for use as an attachment to our grant proposal. We would like to refine the language, then send it back to you for your approval, then you could send us the revised proposal as a pdf file to include with our application. We think it would make our grant application much stronger.

Thank you, Paul. We hope we can come to some agreement that will allow us to support your work.

Stephen

***

<snip>

I completly agree to to work at full time on koha until MARC works (in my planning, for instance, there is only a 2x3 days of teaching free-software technologies, but it may be delayed until 2003 too - for budgetting reasons - Other opportunities coming probably, but i can delay them). If I'm sure to be paid at the end of the job, then i'm happy and will work on koha. Note it's my interest too, as I plan to sell services here in France on koha : installation, teaching, support... To do this, we need a french version, which MUST be MARC-compatible. So, your and my interests joined here. the sooner the software is MARC-compatible, the sooner i can install it in France.

Finally, we would like to have your proposal (text) in a form that could be edited for use as an attachment to our grant proposal.

No problem. I can send it in TXT, RTF, Word, or OpenOffice format, as you want (the original doc is written by OpenOffice)

Thank you, Paul. We hope we can come to some agreement that will allow us to support your work.

It seems it begins very good ;-)

One last note : i'm very impressed by the differences between french and US "public" administration : we try since 4 months to get some funds here in France for MARC support. We don't succeed for many reasons : "no funds for this" (but funds to buy a proprietary software !), "funds only for fundamental research, not for supporting free software", "12 months to get an answer"... And NPL arrives, ask for a RFP, answer 5 days after my proposal, and need only 3 months to get the funds.

Note : I'm GMT+2, so it's time to go to bed for me. But i'm sure my dreams will be sweet with this good news ;-)

Paul

***

Paul, sorry I didn't get back to you sooner. I had intended to look at my e-mail last night, but then my son needed help with his schoolwork, and that filled the whole evening.

I've only one questions : do you plan to fund 75% or 100% (25% by yourself and 75% by federal grant ?) Just to be sure.

The grant requires a 25% 'match,' so we would be paying 25%, the grant would pay 75%. However, you don't need to worry about this. The library will pay all 100% to you, then get reimbursed 75% by the grant. You won't be waiting for payment from the grant, you'll just get one check from the library, probably about January 15. The easiest way to do this, in fact, would probably not be a check, but a transfer of funds to your bank account. We can work out those details later.

I can send it in TXT, RTF, Word, or OpenOffice format, as you want (the original doc is written by OpenOffice)

OpenOffice is fine, that's what I use.

One last note : i'm very impressed by the differences between french and US "public" administration

We're probably not all that different from France. NPL happens to have people on staff who are very interested in innovation and know how to 'work the system.' I'm sure that combination would have worked just as effectively in France.

I'll keep you informed of any new developments here. We had another proposal from a firm in Dallas, Texas (psltech.com), but we think they would be much better at working on standardized borrower records instead of MARC records. I intend to call them today and propose that we hire them to help us transfer our borrower records to Koha, thus getting them involved in the project . . .

Stephen

***

Stephen Hedges wrote:

Paul, sorry I didn't get back to you sooner. I had intended to look at my e-mail last night, but then my son needed help with his schoolwork, and that filled the whole evening.

No problem. I was in bed anyway, [and was awaken at 3AM by my 2nd son :-\\\ (2 years, the 1st being 7)]

You won't be waiting for payment from the grant, you'll just get one check from the library, probably about January 15. The easiest way to do this, in fact, would probably not be a check, but a transfer of funds to your bank account. We can work out those details later.

The fund transfer is for sure the best solution I think. Let's see this later.

OpenOffice is fine, that's what I use.

Here it is

Paul

***

Stephen,

Now that we've passed the Sep 30 deadline, I thought I'd ask you how things were going with the RFP.

Hi, Pat!

Well, we had two proposals, one from PSLTech (psltech.com), and one from Paul, which I assume you have seen (?). I'll forward the PSLTech proposal to you as a separate e-mail.

Even though PSL was considerably cheaper than Paul, we have reached an agreement with Paul to do the work. We will be applying for a Library Services and Technology Grant through the State Library of Ohio's 'mini-grant' program which would pick up 75% of the cost. We will be paying Paul the full price, and think our chances of getting reimbursed by the LSTA grant are very good.

We still think it would be a good idea to get PSL involved in Koha, so I intend to speak with them today about the possibility of hiring them to transfer our borrower data from our old Pick database to Koha. In the process, we would want them to keep a close eye on NCIP and SIP2 to try to keep our data compatible with those 'standards.' They may prompt some changes to the Koha database structure, and would leave an opportunity for writing NCIP or SIP2 modules/scripts for Koha. In other words, we're thinking ahead to our next RFP, which actually may not take the form of an RFP. I think you were interested in doing some NCIP work, right? At this point, we're very much groping our way forward, but we do think that it would be good to get PSL involved.

The other company that I spoke with, evolServ, called to say that they would not submit a proposal because their costs (mainly time spent in learning MARC) would make their proposal much too expensive. They're still keeping an eye on Koha, because they're seeing the same thing that PSL sees -- this is a big potential market for them in the future. Have you seen the Red Hat slogan, "Would you buy a car with the hood welded shut?" (I love that analogy.) These guys are getting themselves positioned to be the "mechanics" that serve Koha libraries.

That's the news so far. What do you think?

Stephen

***

On Thu, 3 Oct 2002, Stephen Hedges wrote:

Well, we had two proposals, one from PSLTech (psltech.com), and one from Paul, which I assume you have seen (?). I'll forward the PSLTech proposal to you as a separate e-mail.

I did see Paul's. In fact, I was asked to proof-read it for him. (He's occasionally nervous about his english skills.)

Even though PSL was considerably cheaper than Paul, we have reached an agreement with Paul to do the work. We will be applying for a Library Services and Technology Grant through the State Library of Ohio's 'mini-grant' program, which would pick up 75% of the cost. We will be paying Paul the full price, and think our chances of getting reimbursed by the LSTA grant are very good.

That's wonderful. He'll be happy, and I'm sure this will help push Koha along.

We still think it would be a good idea to get PSL involved in Koha, so I intend to speak with them today about the possibility of hiring them to transfer our borrower data from our old Pick database to Koha. In the process, we would want them to keep a close eye on NCIP and SIP2 to try to keep our data compatible with those 'standards.' They may prompt some changes to the Koha database structure, and would leave an opportunity for writing NCIP or SIP2 modules/scripts for Koha. In other words, we're thinking ahead to our next RFP, which actually may not take the form of an RFP. I think you were interested in doing some NCIP work, right? At this point, we're very much groping our way forward, but we do think that it would be good to get PSL involved.

Potentially. I actually touched base with a couple of very good Perl programmers who were invovled in writing early SIP/3M code for a vendor some years ago. They're interested in working on NCIP as well. I'd rather back down and let them do the work, because a) it will get done better and faster and b) I'd like to get them into the Koha community.

Katipo has also expressed some interest in working on NCIP. I think they were offered some 3M equipment and think that the time spent on NCIP would enable them to integrate self service 3M systems into Koha.

I may end up keeping my own work with Koha on more of a consultative level. We shall see.

The other company that I spoke with, evolServ, called to say that they would not submit a proposal because their costs (mainly time spent in learning MARC) would make their proposal much too expensive. They're still keeping an eye on Koha, because they're seeing the same thing that PSL sees -- this is a big potential market for them in the future. Have you seen the Red Hat slogan, "Would you buy a car with the hood welded shut?" (I love that analogy.) These guys are getting themselves positioned to be the "mechanics" that serve Koha libraries.

I think this is a great position for evolServ and PSL to put themselves in. I'd welcome their presence on the kohabiz list or the devel list if they'd care to join up. One place that they might be able to get involved with a minimal investment of resources is a project that I'm starting.

Each of the library associations here in the midwest has put together a strategic plan. My initial goal is to merge the plans and cull out the parts that Koha can address . My next step will be to contact the working groups responsible for these visions to try to build a dialog. Hopefully, we can build the results of this dialog into Koha, put ourselves firmly in the library associations' fields of vision, and show off the real value of Free Software.

I'd be happy to talk to PSL or evolServ about this project, or about Koha in general if they're interested.

That's the news so far. What do you think?

Sounds great! On this end, I know that Steve T, who wrote the Z39.50 client, is working on a server. I think he's hoping to put in a bid on that project.

I guess a logical question at this point is: Since we announced the RFP, do should we also make an announcement about the award?

As always, if there's anything I can do, please let me know.

-pate

***

Stan, thank you for your proposal in response to our RFP for MARC21 support for Koha. We have accepted the proposal from Paul P of France and reached an agreement with him to do this work. Paul has been working on Koha for some time, and it turms out he's already about half finished with the MARC21 support. He was way ahead of everyone else.

I want to propose something to you in return. We're very interested in the database expertise you have available at PSL Tech. At some point, we will need to transfer our borrower records from our old Pick database to the Koha (MySQL) database. We're wondering if you would be interested in the job.

But of course, it's not quite as simple as that. I need to give you some background on library databases and automation software before I can explain.

MARC, as I'm sure you now know, is a rather old standard developed in conjunction with the Library of Congress to allow libraries to easily exchange bibliographic data, by making sure that the data structures are the same in all libraries using MARC (which is now almost all public and academic libraries in the U.S., and many school libraries).

There has never been a corresponding standard for borrower data. Every library automation package has it's own way of storing borrower data, which makes sharing of borrower data difficult to impossible, and also means that someone (usually the new software vendor) must figure out how to convert borrower data from one system to another whenever a library changes systems.

3M ran into a problem with this as they started to market self-checkout hardware for libraries. Their machines had to be able to communicate with a wide variety of library systems and exchange borrower and circulation data efficiently. So they developed a standard interchange protocol (SIP) and software which could be added to existing systems, allowing passing of borrower data between the self-checkout machine and the library's automation system. Version 2 (SIP2) was released early in 1998.

Since then, NISO has become involved in developing an official standard based on SIP2, the NISO Circulation Interchange Protocol (NCIP -- see http://www.niso.org/committees/committee_at.html ) This standard is close to being adopted.

In Ohio, libraries can share resources with other libraries if their automation systems have full MARC records, a Z39.50 server for sharing MARC records, and a SIP2 module (eventually to become NCIP). Nelsonville Public Library (or any other library in Ohio) cannot use Koha until it meets these requirements.

So, back to our proposal. We would like to know if you are interested in the job of converting our borrower records into Koha (since there's no traditional vendor to handle this). But this process also needs to keep the SIP2/NCIP standards in mind, because someone will eventually need to write SIP2/NCIP support into Koha.

Stephen Hedges

***

Excellent letter, thank you for BCCing me on it. I look forward to hearing Stan's response, and hope that he moves forward with supporting you guys.

On a related note. I'm at the head end of starting a project to reach out to library associations with the intent of starting an ongoing dialog about koha and how it needs to grow to meet the various library associations strategic goals. I'm planning on working with the BC, WA, and OR associations (because I'm closest to them), but would hope that other associations, developers, and support companies would be interested in joining the effort. You can see the work in progress at http://www.kohalabs.com

thanks

-pate

***

Stephen,

Thanks for letting us know the proposal status. Sounds like Paul P will do a good job and it will be great to have MARC21 capability in Koha.

We are very interested in working on other aspects of the project, including the one you mentioned. Eugene and I have spent some time over the weekend to review the NCIP standard and feel confident we can convert your borrower data from the existing Pick database to Koha. Koha has limited support for this data now, so it may be advantageous to use auxillary tables that support full NCIP data until Koha can be expanded to utilize this information. To provide access in Koha, we would simply link these auxillary tables to existing Koha tables.

Here are some important questions we have:

Stephen, as we proposed with the MARC21 work, it would be beneficial to have some actual data to look at. Can you export some or all of the SIP2 data from Pick and send it to us? I realize this may be sensitive information so we are willing to sign a non-disclosure agreement to ensure its protection.

All of this will help us develop a scope of work for the project. From there, we can provide a proposal to you. Just so you will know, NPL does not incur any costs from us unless you accept the proposal. Any preliminary effort is just to help us better understand your needs.

Thanks again for considering us,

Stan

***

Maybe I'm interpreting this incorrectly, but it sounds to me like we're talking about something different than they are. Are we even concerned at this point about how our data is going to fit into Koha, since we know that Koha isn't NCIP-compatible yet? Wouldn't the data-transfer we're asking them to to take place *after* that compatibility was in place, and they wouldn't have to worry about 'auxillary tables' or Koha enhancements?

-- Owen

I'm thinking about the best way to answer this, and would appreciate any comments you might have. S.H.

***

Stephen,

Yes, we agree, compatibility comes before data transfer, but having some sample data helps us better design and implement the new features. It is not intended to use as the final transfer of borrower data for production use---just as a tool to aid development and testing.

Thanks again and we look forward to your comments,

Stan

Stephen Hedges wrote:

Stan, I did get your e-mail, it's just been a crazy week. I need to look at your ideas more closely, but one reaction I'v had so far is that we need to be sure that SIP2/NCIP compatibility comes before the borrower data transfer in our hierarchy of tasks. Is that your understanding, too?

Stephen

***

Stephen,

Thanks for the help program. We'll take a look at it. No problem with Windows (we still keep a couple of copies around or try Wine).

Don't worry about the translations, we will figure it out. We'll get the wIntegrate program too.

Look forward to the borrower data. Just send it in what ever form is convenient for you. CVS is good but we can handle most anything.

Thanks,

Stan

Stephen Hedges wrote:

OK, Stan, let's start with this. I've attached a big file called SpydusHelp.exe which is the online help system for our current system. I'm sending it because it includes the file specs for our data files. You'll notice that Spydus' borrower data does not conform to SIP2 or NCIP. I suspect their SIP2 module must act as a translator and communication interface (or maybe I'm completely out to lunch). Unfortunately, the help file requires Windows.

The most convenient interface to our Unidata (Pick) files is a program called wIntegrate, which can be downloaded (trial version) from IBM. Unfortunately it requires -- yeah, you guessed it.

I'll try to get some time tomorrow to extract some borrower data in CSV format and send it off to you. Then we can talk further.

Stephen

***

Good morning stephen,

Most is in the title. I've just released the 1.3.1 version of koha. Notes explain what's new. (http://sourceforge.net/project/shownotes.php?release_id=116166)

I think you should consider installing it and taking a deep look to the parameters table. The default param tables are USMARC21 in english. That's exactly what you need. So, verify that the texts are right (they come from LOC !) and meet your needs.

I'm working on marcimport and manual add/modif of biblios now.

Paul

***

Stephen,

Thanks for the files. We are looking at them now and have already converted them into a temporary database (easier to examine the data). Will keep you informed as to our progress.

We will definitely secure this data on our server. We are planning to provide you a secure ftp address in the future so you don't have to email large files. This will be much better, faster and more secure than email attachments.

Thanks,

Stan

Stephen Hedges wrote:

I've attached two text files: 1) the listing of the BRW file, limited to borrower numbers less than 1000; 2) the list of the BRW.DETAILS (BRWDET) file, same limits.

These two files cross index by borrower number. What you're seeing here is warts and all. For instance, all borrower numbers should be seven digits padded with leading zeros (e.g. 0000009, 0000099, 0000999, etc.). As you can see, we have some that aren't.

Also, I'm relying on your integrity with this data -- names addresses, phone numbers, stuff people generally don't like to broadcast.

Let me know if there's anything else I need to send. Thanks!

Stephen

***

Hello, Paul. You wrote to me last Monday:

I think you should consider installing it and taking a deep look to the parameters table. The default param tables are USMARC21 in english. That's exactly what you need. So, verify that the texts are right (they come from LOC !) and meet your needs.

OK, I have looked at the new tables and scripts in 1.3.1. I am sending my comments to everyone involved with our project, so they can all see what I have sent to you, and I would like you to send any reply to everyone as well (reply to all). My comments are my own, however, and not comments from the group. You may get other comments from those individuals.

First, I am very impressed by the amount of work you have done. I think your comment that fill_usmarc.pl is a "simple" script is much too modest! I noticed that many of the '$dbh->do("update")' lines are still commented out. Does that mean you are still working on this script?

You asked us to verify that the texts are right (from LOC). They look fine to me, and everything looks like it will fit our needs nicely. We currently do not store our item information (barcode, etc.) in the 955 tag, but we should be, and can take care of that detail when we migrate our data.

It looks like you have introduced a new primary key -- 'bibid' -- that was not in the kohadb, is that correct? I also do not understand the relation between marc_tag_table and marc_tag_structure, or between marc_subfield_table and marc_subfield_structure. That is not important, however, as long as it works!

Joshua and Owen and I will be spending most of next week at a conference with Chris Cormack. I mention this because 1) we will probably not have much time to reply to e-mails, and 2) we will probably talk about you a lot!

Thanks, Paul.

Stephen

***

Stephen Hedges wrote:

First, I am very impressed by the amount of work you have done. I think your comment that fill_usmarc.pl is a "simple" script is much too modest! I noticed that many of the '$dbh->do("update")' lines are still commented out. Does that mean you are still working on this script?

2 answers :

Note you'll still need to do your own parameters for links between the old koha-db and the MARC-db, and what you want to manage/ignore in your library. Both operations are done in /admin/ scripts provided in 1.3.1.

You asked us to verify that the texts are right (from LOC). They look fine to me, and everything looks like it will fit our needs nicely. We currently do not store our item information (barcode, etc.) in the 955 tag, but we should be, and can take care of that detail when we migrate our data.

Nice.

It looks like you have introduced a new primary key -- 'bibid' -- that was not in the kohadb, is that correct? I also do not understand the relation between marc_tag_table and marc_tag_structure, or between marc_subfield_table and marc_subfield_structure. That is not important, however, as long as it works!

Joshua and Owen and I will be spending most of next week at a conference with Chris Cormack. I mention this because 1) we will probably not have much time to reply to e-mails, and 2) we will probably talk about you a lot!

Did chris come to US, or do you fly to nz ?

Paul

***

Stephen,

Just wanted to give you a brief update as to our progress on developing an NCIP capability for Koha. Eugene has been busy building an initial cut of a full NCIP database. As you know this is quite and extensive standard so it has taken some time to do. The next steps are to analyze and refine this design, then load the sample borrower data you supplied. Once this is complete we can do some testing and look at refinements.

The big questions for us are the things we have not tackled yet: linking this data to the current Koha tables and defining Koha interface changes to support your needs. At some point, I think it would be good to have a conference call to address these and other issues. After we feel comfortable with the scope of the effort, we will prepare a proposal for your review, which I expect will be in the next 2-3 weeks.

Stephen, I will be out of town until late Monday, so I won't be able to reply to any of your email until then. If you need help, you can email Eugene at the address above.

Regards,

Stan

***

Stephen Hedges a ecrit:

Thanks, Paul. We will wait (impatiently!) for your announcement.

The site is running (http://demo.koha-fr.org). Announcement will be made tomorrow in weekly newsletter. You can take a look before anybody else :-)

If you have problem to understand something, don't hesitate to ask (by mail or irc). Note it's 6pm here, so, i will leave my computer soon.

Paul

***

Okay, I've been struck with a thought that I think bears some kicking about. In regions where there are several Koha libraries, it might make sense to start Koha User Groups. If a vendor wanted to host a website and email list, actively recruit attendees, and try to host/organize a meeting quarterly or semi-annually, I think that the resulting user group would really help make Koha a more visible, more viable option for other libraries in the area.

--some questions--

I've got some thoughts about each of these, but I think I'll hold my peace for a bit and see what everyone else thinks.

BTW, I'm planning on trying to jumpstart 2 of these as pilots, one in the Washington, DC area and one in the Ohio-Michigan area. I'll plan on reporting my progress periodically. Kibbitzim welcome.

-pate

***

On Fri, 22 Nov 2002, Stephen Hedges wrote:

> Hmm, I just got an email from a member of the > NCIP committee with regard > to our plans to build an NCIP interface for Koha. > It sounds like you've > made bigger waves than I thought. Good! BTW, I'm beginning to think that P** Tech (the co. in Dallas) is the wrong horse for this race.

I'm sorry to hear that. I'd have like to see them get involved. It didn't look like they wanted to play in that direction though.

Chris told me that Katipo has an offer from 3M to deliver the code for SIP2 that would run on Koha. I wonder if it wouldn't be wise to take their offer, then make modifications to convert the SIP2 to NCIP. I think there's some SIP2 available as open source, too, although I can't find the links right now. (Seems like epixTech may have been distributing it -- but was the source open? I don't know now.)

EpixTech has released an opensource NCIP toolkit, which we may be able to use to create a Perl NCIP library ... it's certainly worth exploring. Perhaps working both directions with Katipo would be a good idea. I do have a couple of very strong Perl guys (with an ILS background) in Portland who are interested in doing the work though, and a vendor in Ann Arbor that is making noises about doing things with Koha, so if we can find a way to run a competetive selection process that would be nice.

I don't suppose the NCIP folks would be interested in working with open source software (Koha) to test their open standard (NCIP)?

I think there's some room to operate there. We just need to be careful not to put the NCIP standards folk in the awkward position of working on Koha, while they work for a proprietary vendor.

> Have you had a chance to play with Pauls new > demo? I realize that it's > unimarc, not marc 21, but I think it will still be > interesting. Yes, I've peeked at it (Paul sent me the URL a little early), and want to spend some time digging deeper this weekend, but what I've seen is very impressive. I think the changes justify the ver. 2.0 label.

I'm glad you think so. I'm pretty excited by the way things are moving. We've also had some progress on reports, and (just this morning) a volunteer to start working on a serials module.

***

I do have a couple of very strong Perl guys (with an ILS background) in Portland who are interested in doing the work though, and a vendor in Ann Arbor that is making noises about doing things with Koha, so if we can find a way to run a competetive selection process that would be nice.

The Linux B**, right? We met them at the Think-Linux show, and they seem to be very interested and very nice.

And yes, I know you're interested in this piece, too. Here's my current status. I'm going to be paying Paul about $1*,*** for the MARC coding (which looks like it's going to include the Z39.50 server, right?). I had planned on getting a grant for some of that, but just learned that if I apply for the grant that's most appropriate (and therefore easiest to get), I would be disqualifying the library from receiving a grant for a different project. Complicated, I know, but the other project involves several community partnerships, so I'm not going to request money from that source for Koha.

I'm looking -- but not yet finding -- other sources of grant funding, but the timing is going to be a problem. I think I'll be paying Paul the entire fee out of the library's pocket. No problem, the work's certainly worth it! But it leaves me strapped for cash for a few months.

So that's why I'm considering alternative ways to get this (NCIP) done without waiting for the money to arrive. Of course, it could take months for any grant money to arrive, also, and I may just have to learn a little patience. Not in my nature!

Stephen

***

Hi Stephen, (hi to other npl, that are cc in this mail too)

First of all, I wish you a happy new year, with a lot of free softwares :-)

Maybe you've seen that koha-1.3.3 has been released a few days ago. It's a very stable release for acquisition, that is used in the Dombes Abbey, here in France since december.

I've included a "plugin" system to improve MARC entering of datas. With this system, you can define "events" and "relations" to limit or check values entered.

For example, the plugin 210c (value_builder directory), when there is an ISBN, auto calculates the editor name if it's entered in the thesaurus table. The plugin 700..., when you choose the right entry in the 700a, auto split name, DOB, and title in 700b,c,d and f... The plugins i've developped are only for unimarc (and french thesaurus/authorities structure), so i encourage you to develop you own plugins. Don't hesitate to ask me if there is something you don't understand.

I've written a documentation about the plugin structure at: http://www.saas.nsw.edu.au/wiki/index.php?page=PlugInDoc

Hope you'll enjoy this new version.

The next release will be 1.9.0, which will be the 1st beta before 2.0RC. In 1.9.0, you should be able to to all what was included in my answer to RFP, with some bugs for the price ;-) The bugs will be corrected between 1.9.0 and 2.0 (1.9.1, 1.9.2... until 2.0 can be launched).

Paul

***

Hi, Larry -

Now that Paul has released the stable version 1.3.3, we are installing it on a server and will soon be starting the process of migrating some of our data to it. I think the MARC data will be no problem, since Paul has done such a nice job of making Koha MARC-compliant. Our patron data may take a while.

We intend to run both Koha and our old system side by side for a while to get Koha in shape for daily use in our libraries. Our deadline for making the complete switch-over is September, when our annual contract with the current vendor falls due.

Stephen

Dear Stephen,

We need to have a new library automation system in place by July 1st of this year, and we have been considering Koha as well as commercial vendors. Can you tell me what sort of timeline your library is on for the replacement of your current system? Since we may require a lead time of three or four months for the installation of a new system, we don't have alot of time in which to make our decision, so we're wondering whether you are planning to have a MARC- compatible Koha system installed within the same timeframe.

Larry C

***

Hey Stephen,

Hope you had a good holiday! I wanted to check in and see how things were going with the NPL's open source/Koha project, and see if things were still on schedule for this summer.

Looking forward to hearing from you. I just found out my old boss is the assistant director of the Greene County Public Library, and I need to contact him and see if he would be interested in your project, too.

Peace,

Brian

***

Stephen Hedges: Nelsonville Public Library

Allow me to introduce myself briefly. I am a librarian, once head of the Boston Theological Institute's Library Program (1967-1971), after that head of the Office for Systems Planning and Research in the Harvard University Library (1973-1978). Then I became the executive director of OHIONET (1978-1988), next the executive director of CoBIT (1988-1992). After that, I left Ohio (lived in Wyoming and North Carolina). Three years ago I joined the staff of the North Carolina Supreme Court Library.

The NCSCL installed SIRSI some years ago, is currently up to date on revisions, but cannot justify the $6,000+ annual fees (for emergency services and little else). We were interested in an open source solution and began searching for possible candidates - none on the horizon that looked good until KOHA.

The KOHA releases have stated that the project will need assistance in the area of documentation. I have spent at least sixteen years of my life either writing or editing documentation, both technical support materials and end-user documentation. The NCSCL, with a staff of six, might be able to take on a significant responsibility here. We could continue to use SIRSI for cataloging and acquisition (we have no need of a circulation module) until KOHA was prepared to replace fully what we have now. I have handled the archive MARC file of SIRSI (now approaching 20,000 titles) and know that it could be readily converted into an import file for any other system. I have had extensive programming experience in older compilers and interpreters, and am working to become proficient in Web languages and open source SQLs. As a law collection our needs are for a system that does not treat very large numbers of titles, but requires lots of detail for materials that are issued-in-parts, serialized and/or periodical. We are also involved in considerable analytic cataloging (parts of monographs or books). We have a wonderful collection of historical materials going back to the end of the eighteenth century, almost all are imprints (very little manuscript, very little realia). We are one of the few libraries of this type that still subscribe to the current statutes and court reports of all fifty states - with very large collections of older compilations or imprints. It is clear that SIRSI will not fill our needs for the long run.

But we also want to know what we are getting into. Your library is the only one prominently mentioned as being involved somehow in KOHA. We would simply like to know more.

I have two young children in Columbus (divorced). I visit them once a month - traveling from Raleigh via Wake Forest, Charleston (WV) and Gallipolis, Chillicothe and Centerville to Columbus. I could easily alter this route and come to Nelsonville on one of these trips (I used to stop there years ago at the shoe factory for good boots).

I hope that I have not gotten too far, but have at least covered the ground as to what our interests are.

Ronald E. D

***

Ronald, thank you for the introduction, and glad to meet you! My library background is not as extensive as yours. I actually hold a PhD in the History and Theory of Music (talk about esoteric! -- but I was interested in the subject), but I soon found that I hated teaching at the college level. The library is my second career.

Your e-mail is incredibly well-timed. Koha is quickly approaching its version 2.0 release, which will have the full MARC support Nel.Pub.Lib. contracted for. (And more, actually, since the developers came up with some nifty features we hadn't anticipated.) But I was just thinking this morning that the documentation is now getting way behind as the development progresses. I was beginning to consider stepping in myself to try to write some how-to's, but I'm very, very bad at that type of writing.

So where is Koha right now? Mostly in small special and school libraries that happen to have very strong IT people on staff. And with a lot of other libraries quietly (or not so quietly, in the case of NPL) lurking and waiting until Koha has enough features to make it practical for larger operations. We've specified the features we need -- full MARC support, Z39.50 server module, and a SIP2 or NCIP module -- and the first two of these requirements are in place, for all intents and purposes. Koha version 1.2.3, the latest stable release, is the one currently in production, but has none of these features. Koha 1.3.3 (unstable) has been released for debugging, version 1.9.0 (also unstable) is just around the corner, and version 2.0 (stable) is due out in about a month and will have everything we need except SIP2. So we will be installing 2.0 and moving our data into it as soon as it's ready, and will run our two systems side-by-side until we are sure Koha is handling our needs. Then come September, when our ($12,000) annual support fee is due for our current system, we plan to shut the old system down and move completely to Koha.

I am amazed at the speed at which Koha develops. But I see a major hurdle on the horizon, in that there MUST be good user documentation before all that fine code is going to be usable. There is a documentation project under way, but I haven't heard much about it lately. Either it has been overwhelmed by the pace of development, or it's a very quiet project. There are various documents floating around on the Internet that address one aspect or another of Koha, but no unified manual(s) that I know of.

At any rate, I think you should get in touch with Pat E, the Koha project manager (in Seattle), who would know a lot more about the current state of the documentation and be able to answer any questions I've left hanging. His e- mail is pate@*** and if you want, I can forward him a copy of your e-mail and this e-mail, so we won't have to cover all this ground again. What do you think?

Hope I haven't scared you off, and looking forward to hearing from you again -

Stephen

***

Stephen:

Please forward these exchanges to Pat E and see where we go from there.

We are definitely ready to make some moves. As I noted before, we will need full MARC support: i.e., MARC in and MARC out. I would prefer that the communication format MARC record be stored in the system somewhere. We will definitely do much more than traditional cataloging, i.e., analytic cataloging and indexing of North Carolina legal materials.

As I noted previously, I was in charge of The Library Machine (TLM) for many years. I wrote most of the code (PL/1 and Assembler - ah, the good old days). In the code, I made sure that I wrote (and insisted that others do the same) all the hooks and hangers for both technical and user documentation. For instance, in the Acquisitions Module, where there was code to correct an invoice date that had been incorrectly entered previously, you will find a box that describes how that function works and why it was programmed that way. It was an easy process then to take each of those boxes and write documentation directly out of them. In the end, the material had to be organized differently from the way that the code proceeded (the sequence of programming logic is not necessarily the same as the functional or use-logic). If the KOHA code does NOT include such hooks and hangers, then that should be a future priority - so that, in the end, as the code changes, so can the documentation.

Another irony: I was originally trained in theology and classical languages. When I got to my last year of seminary, I was one of twenty (eventually twelve - of course, twelve) who "dropped through" - we graduated from the seminary but refused to be assigned to parishes. That was when I became a librarian. Later I went to Harvard and did a ThD in ecclesiastical history under George Huntston Williams. I worked on a historiography topic of the mid-sixteenth century. When I finished, George wanted me to take a teaching position at Boston University (among other reasons, to keep me close by - we had become very close friends by then). I told him, No thanks, because I could not afford a fifty percent salary cut. When he found out how much I earned as an assistant to the University Librarian at Harvard, George went to the Dean (Rosovsky, at the time) and complained that the librarians were overpaid! The stinker! Later he cooled off, and so did I. I did do some graduate seminars at Ohio State for a few years, when Harold Grimm was the resident Reformation scholar.

More later.

Ronald E. D

***

The koha 1.9.0 is born a few minuts agos.

His parents, the koha-team, are very proud of this almost-stable children. Please go to see the baby at : http://sourceforge.net/project/shownotes.php?release_id=138050

Paul P

***

Hi Stephen,

You should have seen that koha 1.9.0 has been released a few days ago. The MARC part of this version is stable. We just need to re-integrate z3950 client, fix some bug (not related to the MARC acquisition part of koha). I plan for 2.0 to reorder acquisition/cataloguing as discussed on the mailing list. It's something that was not on your RFP but seems really important, and you have the same wishes as me ! The acquisition is in production in a christian library here in France since december, and the librarian is happy with koha "new look". She asks for some minor improvments, but "true" bugs seems to be solved.

Important note : The MARC21 parameter table is NOT complete : completing it is a librarian job, and nobody did it at the moment. every MARC21 fields/subfields are defined, but their mapping to non-MARC DB and links to tabs still have to be done. Note i've added in the parameters section of koha a "check MARC" that checks the MARC structure and shows problems. If you build a working MARC21 parameters table, please send it to me by mail or commit it directly to cvs (marc_tag_structure and marc_subfield_structure tables).

Some questions to end this mail :

Paul P

Paul -

There are a few MARC tags which seem to be missing from version 1.9.0 (at least I haven't found them :-)

All of these are described, of course, at http://www.loc.gov/marc/bibliographic/ecbdlist.html

I've got two other complaints with 1.9.0 -- ready?

I'm running 1.9.0 on RedHat 8.0 and Apache 1.3.22.

Thanks, Paul!

Stephen

***

Hi Paul (Hi Chris) -

I think I have found a BIG problem in 1.9.0. The links between the old (Chris) Koha database and the new (Paul) Koha-MARC database cannot work.

From the way 1.9.0 is reacting, it seems that it requires a one-to-one link between the old and the new database, and that the link must be unique. However, many of Chris' database fields should link to the same MARC tag. For instance, the date of publication is always MARC tag 260c, even though Chris may have used it as different fields (copyrightdate, volumedate, publication year) in the old Koha database. All of those old fields should link to MARC 260c. (Correct me if I have misunderstood how these old fields are used, Chris.)

There are other things, like holdingbranch, that are never part of a MARC record, but are part of the circulation record that keeps track of where the book is. 1.9.0 shoudn't return any error when this is not mapped to a MARC tag.

Also, Chris, I have some questions about things like biblio.serial (how is that used) and the different classification fields and how they are used. What is the difference between biblioitems.classification, biblioitems.itemtype, biblioitems.dewey, and biblioitems.subclass, for example.

Chris' timestamp field should be mapped to MARC tag 005, which does not appear in the list of MARC tags. (More about this in a separate e-mail, Paul.)

I think the old items table will be the hardest thing to map to Koha-MARC, since so much of it is not MARC data. Would you like me to send you a list of which items fields I think should be mapped, and which should not?

Stephen

***

Stephen Hedges wrote:

I think I have found a BIG problem in 1.9.0. The links between the old (Chris) Koha database and the new (Paul) Koha-MARC database cannot work.

From the way 1.9.0 is reacting, it seems that it requires a one-to-one link between the old and the new database, and that the link must be unique. However, many of Chris' database fields should link to the same MARC tag. For instance, the date of publication is always MARC tag 260c, even though Chris may have used it as different fields (copyrightdate, volumedate, publication year) in the old Koha database. All of those old fields should link to MARC 260c. (Correct me if I have misunderstood how these old fields are used, Chris.)

In UNIMARC, we didn't face this problem.

I would be surprised to learn that koha old-db has more datas than MARC21 ! Anyway, if you are certain that 260c subfield can handle various old-DB subfield, let me know, it should not be hard to manage. The biggest question being to know what to store when you have a publication year AND a @date, AND a volumedate !)

What would be almost impossible is the opposite : store something from old-DB into various MARC subfield (ie : publicationyear in 260c OR 248d OR 115f : how to choose ?)