To plug, or not to plug? Why we develop Koha plugins

by Nick Clemens on Jan 19, 2021

Today I want to explore the pros and cons of plugins, and highlight how they can be a wonderful tool for Koha.

Pros:

• Rapid development - as developers we can update plugin code, deploy it to sites, and test it live in production in a very short time frame.
• Customizable - plugins can be targeted to a library's specific needs. Some workflows that rely on outside vendors, or internal software integration aren't needed in the Koha community at large, but are needed in specific institutions.
• Expandable - Throughout Koha there are various 'plugin hooks' or pieces of code which check for plugins with an ability to be activated at certain points in Koha workflows. These plugin hooks, as above, allow for customization of workflows, or integrations where we expect each vendor to have different needs and may want to offer a choice of workflows.

Cons:

• Maintenance - As they live outside the Koha there is no guarantee a plugin will continue to work with new versions. The maintenance falls back onto the original developer, the user, or the support company.
• Scope - As plugins are developed to tackle specific problems, they can have a narrow focus, and may not be as flexible as a fully fleshed Koha development. While this is good for their intended user, they often require additional work to support broader workflows.
• Reliability - Anyone can write a Koha plugin, and they don't have to guarantee to maintain it. The key is knowing where your plugins come from, who maintains them, and who can offer support.

The above are largely two sides of the same coin, or different facets of the same cube. When deciding on plugins as a method for development, we try to consider how to make the most of the pros and avoid the cons.

Largely, ByWater's koha plugins are vendor integration plugins. We have a variety of EDI plugins for specific US vendors, PayPal and other payment plugins, Hoopla/Cloud library integration, and a few other vendor specific plugins. These were all planned as plugins so that changes made by the vendors can be quickly integrated and to avoid adding code to Koha that isn't widely used.

Some of our other plugins are growths of JS and OPAC customizations that became common enough to warrant work toward standardizing the process. Coverflow, Galadriel, and the label maker all allow ByWater to deploy local customizaitions, with a friendlier interface.

Lastly, we do have a few prototyping plugins for areas where a solution was needed, but the workflows aren't yet standardized. The curbside plugin, item recalls, and the patron emailer all allow us to provide functionality to libraries, while simultaneously getting info on what is needed.

I should mention too, plugins are fun! They allow developers to play with ideas to see how they shape up and how the evolve. Reports plus was written because I wanted to see what was needed to allow reports to take lists. As people used it and commented, I changed my ideas and ultimately submitted them on Bug 27380. If you are interested in playing too, check out the Koha 2020 advent which covers building a plugin that expands and utilizes the Koha REST API

ByWater is committed to improving Koha and submitting our code to the community. When plugins are the best method of contributing we develop them, with an eye towards larger integration and usefulness.