Recently I was thinking about institutional engagement with free and open source software (FOSS). I had been asked to open a day-long workshop on the relevance of a FOSS integrated library system (ILS) for academic libraries. The more I thought about it, the more I realized that libraries have a vast array of FOSS they are busy deploying. Everything from Apache web servers, to Drupal content management systems (CMS), to institutional repository (IR) packages. Yet as much I would like for us each to have an infinite amount of time and energy to spare on our passions, I am reconciled to the fact that we need to make choices. Hard choices. Choices about our level of engagement with the software we deploy.

A choice matrix is often elaborated in terms of a "square of priorities". This will be familiar to you if you have ever had cause to work on time management issues. One axis shows the level of importance increasing, and the other axis shows the level of urgency increasing. This quickly resolves into 4 key areas against which your tasks may be plotted: those which are not urgent and also not important; those which are urgent but not important; those which are important but not urgent; and those which are both important and urgent. Plotting your current task list helps reveal whether you are spending too much time in the wrong box and may prompt a revision for the future.

I think a very similar story can be told about the "square of engagement". Libraries use a large number of FOSS applications. But do they need to engage with the ongoing development and user communities for each of these? Would that be a wise use of their time and energy?

The answer is obvious once you start plotting where each FOSS application in use in the library would sit on the square of engagement. Do systems librarians need to spend time and energy working on the ongoing development of the Apache web server? It is clearly used constantly in any library that has an OPAC or even just a website. But it probably does not call for a large amount of librarian engagement. What about a CMS such as Drupal? Many libraries shape their whole online presence around the capabilities of their CMS. So they need to stay on top of those capabilities in order to know what options they have available. They may have someone monitoring the Drupal user discussion list. But they may not be getting in to the code. Your CMS therefore may be slightly up the scale of engagement but still well below the mid-point on that scale.

There are also FOSS applications that individual libraries with systems development personnel will engage with at a very high level, not least because they may be the lead developers of this software. Here the level of engagement outstrips the use within that library, either because this is solely a development project and not in official supported use in the library, or because the use of this application by others is so large that the project has effectively become independent of the overall priority matrix of the library.

But which FOSS packages then do call for serious and sustained engagement by libraries? And should I feel uneasy if my library is not engaged fully with these, or cannot be? The latter question is very important, but let's come back to it at the end.

Clearly libraries will want to expend their limited time and energy engaging seriously with FOSS applications that are central to their mission. Engagement here does not mean that they are or will become key developers of the software. But it does entail a level of involvement that goes significantly beyond mere use. It suggests that staff will be encouraged to actually participate on the user email discussion lists. Not merely to ask questions for themselves, but also to answer the questions that other librarians struggling with the software have posed. It suggests a level of awareness of the ongoing development roadmap for the software, and the potential, certainly, to express preferences for what you would most like to see happen there. At some point it may even include submission of "bug" notices to the development team, and ideally the offer of code "patches" to address such bugs. And through all of this you will be thinking that this sounds just like robust participation in a whole complex support network for this software. It is.

The ILS is still today the cornerstone of a library. It seems only right that an institution should acknowledge this by sanctioning as much engagement with the project as can be sustained.

But what if my library doesn't have a large pool of talented software developers? What if my resources are as limited as can be? How can I ever truly engage with such software? And am I failing by not doing so?

I noted somewhere near the beginning of this reflection the sad truth that we are blessed with only a finite amount of time and energy to commit to our passions. The quantity may vary. And this may determine much. For example, it may very well be that your only viable option is to accept a "hosted" ILS solution. Not much room for engagement there, right? Not really that much different than your engagement level with your Apache web server, right? Wrong. Because your engagement marks out where your passion lies. And if it lies with your ILS, then even in the case where you have no real technical involvement with the software, you will still have opportunities to demonstrate your passion, your commitment, and your desires.

I think this is most important thing I have learned in thinking through the square of engagement. It is the realisation that engagement is an expression of commitment and not a quantity of commitment. With that observation, I think the square of engagement can be used effectively by any library thinking through its involvement with various FOSS applications. And just as the square of priorities can be a tool for reforming our work practices, so too can the square of engagement be a tool for reforming how, as institutions, we evaluate the relevance of a FOSS solution for our libraries.