Lessons Learned

tracker

Last updated September 27, 2014.

It probably goes without saying that any system migration is a difficult and time-consuming process for all library staff. It is even more so when the new system is still in active development, which of course complicates matters. We would certainly advise any library to wait for a completed product before attempting a migration unless: (1) you feel confident that your staff can handle the situation of being beta testers at the same time; AND (2) there are compelling reasons – financial, functional, or other – to move off your present system ASAP. Both of these applied to the University of Chicago.

Commitment to developing a community-sourced project such as Kuali OLE requires a library to take a hard look at its staffing levels and the available skill sets. The ability to draft functional requirements, write test scripts and perform Quality Assurance/Quality Control (QA/QC) work, and write coherent documentation are necessary for any software development project and are not necessarily widespread among library staff. There is sometimes also a perception that this work must come “after” other duties – which it cannot if development schedules are to be met. Libraries used to complaining about the inadequacies of their vendors need to realize that with community-source developed products, what was formerly “them” is now “us”, and whatever inadequacies exist can only be traced back to our own doorsteps. In other words, a commitment to develop software cannot be taken lightly. At least as Kuali OLE is financed, these efforts depend on library staff, not paid employees as is the case with commercial vendors.

We anticipated that running open source would require more technical resources; we hired two additional programmers, and we believe that this turned out to be a wise move on our part. We could not possibly have gotten as far as we have with either our VuFind or Kuali OLE implementation without these additional resources. Even if we had decided to run open source without being a development partner, we would still have needed at least one more programmer.

Because of the active development, it turned out to be impractical to contract out for data conversion and training. If we had waited for software development to be complete it probably would have been cost effective to contract out some of that work. Also, the timing of internal work for the project was approximately a full year. There were many iterations of data conversions and installation and setup because we were not working with the final, stable version of the software. Implementation probably could have taken half the time if not for this situation. On the other hand, it was necessary to forge ahead with figuring out setup issues and working on data cleanup and conversion issues in order to meet the desired schedule.

Work with the Kuali project has been useful in forging alliances with our university computing groups. The Library has benefited by association with an open source project that is contributing to other areas of academic computing, particularly in the area of identity management.