Management of Code Changes

Last updated September 27, 2014.

We knew going into Koha that we would be altering the program to meet our own unique needs, which is one of the major benefits of using OSS. The system we set up was similar to how the Koha community managed its code base and releases. We installed a version of Koha on a test server. When we made changes to Koha, we would commit it locally to git, a source code revision management utility which would track our changes to the codebase, essentially making our own “fork” of Koha. Since we were altering the program a great deal, we would test our changes to Koha through a three tier process: proof of concept, beta testing, and production. Proof of concept was to test how it worked and to see if any further changes were needed. Beta was to make sure it worked as advertised in a production setting and didn't break anything else, and finally production was releasing the code for the front line staff to use.

With a developer on staff, making changes, though not inconsequential, was something that could be done on a regular routine. Once the staff saw that changes could be made rather quickly, the IT department became deluged with requests for changes and additions. Wishing to create goodwill towards Koha, the IT staff worked hard to incorporate the staff's suggestions. One or two changes are manageable, but when you create multiple changes in software, one right after the other, it can create chaos. Additionally, some changes may have unexpected consequences. Some staff members would also make direct requests for changes to our developer rather than bringing the change request up at meetings, adding to the potential for confusion. After a couple weeks of rampant chaos, we finally regained order by implementing a formal change request process using the Mantis bug tracker.

For the first few years not many of our changes were incorporated into the mainline Koha program. The reason was that when we did submit changes we could not get other libraries or companies to sign off on our revisions. It would take a number of years for our developer to gain enough experience and horse trading (you sign off on my changes and I will sign off on yours) in order to get changes into Koha. Not getting the changes incorporated into mainline Koha would cause us additional problems down the road.

Koha’s development community is extremely active, so after we initially migrated to Koha in 2007/2008, we wanted to install the latest improved version of Koha. Unfortunately, we found that we had altered Koha so much that we had made it difficult to upgrade. We realized that our strategy had a serious flaw in that it made upgrading to new versions of Koha difficult because we had to reintegrate all of our custom code, and then extensively test the changes, all of which took up to a year. After going through a very difficult upgrade path in 2010, we made the decision to abandon our custom templates in favor of using the default Koha templates with a few minor modifications.

Just switching over our templates was not enough. We still wanted to use our custom changes, but eliminate the need for rewriting the code with every update. So we developed a few strategies. First, for major changes in Koha, we submitted them to the community. We have made a great deal of progress in incorporating our changes into Koha’s main codebase. These include: the MARC Modification templates, Rotating Collections, Clubs and Services, and the Plugins system. All of our submissions have been incorporated so far except the Club and Services module, which is now waiting for approval. Secondly, for changes that are deeply integrated into the main codebase, our programmer created the Plugins system. This allows us and all other Koha libraries to create custom modules for Koha that can be easily installed on a standard Koha installation without disrupting or altering its functionality. We have created many plugins, such as custom reports, spine label printers, and a tool for generating MARC records and barcodes for a year’s worth of magazine subscriptions at a time. Additionally, wherever possible changes are designed to be easily enabled or disabled with a system preference, which helps with getting our major changes integrated into mainline Koha, since libraries that don't want a new feature can simply disable it.

One major change, over the past two years, is that our programmer has been working as a full-time Koha developer for Bywater Solutions while still working part-time on Koha and other projects for CCFLS. While we did lose some of his time with the change, we did gain better access for incorporating CCFLS’s changes into Koha. When Kyle worked for us exclusively, it was very difficult to have other developers review, test and incorporate the changes into Koha. With him working as a developer for a major vendor in the community, getting our changes integrated into Koha has become easier. With all of our major custom changes now in or scheduled to be in the Koha ILS, we are planning to upgrade to the current version of Koha in September 2014. This will also allow us to upgrade Koha on a regular annual schedule so we will be able to roll out the latest ILS features as soon as they become available.