Koha Development Services

C & P Bibliography Services will work with you to make sure that the Koha integrated library system will meet your needs perfectly.

One of the great benefits of using an open source system is that if the software does not work the way you want to, you can modify it so that it will. C & P Bibliography Services offers a full range of Koha development services, with particular emphasis on authority control and search-related developments.

Tell us what you want Koha to do

In addition to general Koha support and hosting, C & P Bibliography Services offers contract development to institutions interested in extending the Koha Integrated Library System. Our development foci are authorities, cataloguing, metadata standard compliance, and enhanced content (for example, the incorporation of maps and timelines into the OPAC), though we work on all parts of the system. All code developed by C & P Bibliography Services is released to the community under an open source license, and we work closely with the Release Manager, Release Maintainers, QA team, and other members of the community to ensure incorporation of our work into the Koha codebase.

In many cases, developments begin when we notice a “rough spot” in a customer's workflow, and identify a possible solution. If we notice something that could work just a little bit better for you, we will point it out to you. If you agree with our analysis—or if you notice at any time that Koha is lacking a feature you would like—let us know and we will prepare a rough estimate of the cost to develop that feature. If you are interested in pursuing the development, we will write a more detailed proposal, and—if necessary—work with you to find cosponsors for larger developments that may not be in your budget. Once a project has been fully funded, we will schedule the development and begin work on it, making sure to keep interested customers involved every step of the way.

Why use C & P for development?

In 2012, C & P Bibliography Services developed improved authority matching algorithms for Koha and dramatically expanded Koha’s support for authority linking, adding (among other features) a “Did you mean?” feature that draws on authority data and suport for hierarchical authority records. Despite the complexity of this feature, C & P was able to work with the community to get the code integrated into Koha two weeks after the completion of the development, much quicker than is the case for many large features submitted to the Koha project. C & P’s community-oriented approach is also visible in the role it has played in the development of other large features. In December 2011, C & P collaborated with Anant Corporation to develop a local cover image feature so that libraries could upload photographs of their material directly into their Koha catalogs, a feature not previously available in Koha, as well as donating dozens of hours to the community to work on the integration of an improved analytical record cataloging interface into Koha 3.6 after the feature was abandoned by the original developer before the code was brought up to the community’s standards.

The founder of C & P Bibliography Services, Jared Camins-Esakov, is an active developer in the Koha community, regularly participating in conversations both on the Koha mailing lists and on the Koha IRC channel. As a professionally-qualified librarian and experienced cataloger, Jared is often called upon to answer questions about library standards and cataloging, particularly in special library environments where authorities and analytics play a major role. Jared has personally contributed more than 1,000 patches to the Koha project, and helped with the integration of hundreds of other patches into Koha. Jared was the Release Manager for the Koha 3.12 release and previously served as Release Maintainer for Koha 3.6.

Koha Development Practices

Koha development is often confusing to new (and even not-so-new) Koha libraries. Although it can influence every aspect of the library—as in the case of an integrated library system like Koha—a software project operates quite differently than does a reference desk, technical services department, or bibliographer. Many librarians are used to the traditional, proprietary software development model: every so often (often just once per year), the vendor calls up and says “here is the new version of your software, and this is what it does,” often without regard for what their customers want from the software. In an open source project, anyone who is interested in the software can influence its direction by contributing code, opinions, and/or money to ongoing development. In order to ensure that Koha meets your needs as best as possible both now and in the future, it helps to understand in some detail the development process, and—especially—the problems that can arise during it.

As a large international open source project, the Koha project’s development practices differ somewhat from “classic” software development models. In particular, although there is a Release Manager who makes the final determination about whether a given feature will be added to the Koha codebase, the community is driven by consensus, and building consensus behind the design and implementation of new features is a key component of any development project for Koha. In order for a new feature to be integrated into Koha, all the following steps must be taken:

  1. →The code for the feature must be developed.
  2. →An independent developer must test the feature and “sign off” that it works as advertised, and does not break existing functionality in the system.
  3. →The Quality Assurance Manager or an Assistant Quality Assurance Manager must review the code for possible future problems and compliance with the Koha coding guidelines.
  4. →The Release Manager must review the code and test the feature before “pushing” the feature into the “Master” trunk, for inclusion in the next major version of Koha.

At any point in this process, objections from other Koha developers may hold up or entirely halt the progression of the code towards inclusion in the Koha codebase. However, by working closely with the community, developers can proactively identify and resolve potential objections, thereby smoothing the feature’s path to inclusion in the Koha codebase. Although there can be no guarantee that a particular piece of code will be accepted for inclusion in Koha, there are certain best practices that developers can follow to give their code the best possible chance:

  • Maximize transparency to the community by encouraging community feedback throughout the development process on both the community bug tracking system and the Koha wiki.
  • Separate large features into smaller sub-features that can easily be tested independently.
  • Maintain a reputation for doing high quality work, and working toward the good of the Koha community as a whole rather than partisan interests.
  • Follow the coding guidelines established by the community.
  • Ensure all code is licensed under the GNU General Public License Version 3.0 or greater (or, in some cases, the GNU Affero General Public License Version 3.0 or greater).

As a matter of policy, C & P Bibliography Services follows all these best practices, and maintains strong ties with the community, as discussed in the previous section.

Contact us about our Koha development services

Bookmark and Share