We Love Open Source Software. No, You Can’t Have Our Code — Access 2008

Dale Askey
Kansas State University

Libraries are not particularly good at making their own code open source and sharing. This is especially true of the small, lightweight applications that we build to make ILS systems “work right” or to solve small problems. These are frequently small (a few hundred lines of code). Why not? Several reasons…
Perfectionism — the code’s not ready yet, there are bugs, not commented well, it’s inefficient. Even though it gets the job done — which is really what counts, many developers are hesitant to share their code with others.
Dependency — we don’t want to be supporting you; we can barely support ourselves. Putting it in a repository, with documentation — a good idea. Puts a bit of distance between developer (library) and user. Rutgers is planning to launch a library open source platform — but it hasn’t happened yet (announced in April 2008).
Quirkiness — What we do is so unique there’s no point to releasing it; our problems are ours alone. This is false; while the exact problem may be different, but the general problem very often is shared. But — if you don’t share the code, you end up with the full support and updating burden. There’s nobody else who can help you find and fix bugs, add new features.
Redundancy — Perfectly good software already exists that works for most people, so why should we offer our own? Good enough — the available solution — is often seen as better than doing it oneself.
Competitiveness — Our code is better than someone else’s, so we want pride of ownership and don’t want to share it. We build our own to be the best, not to share the technology. Institutional Repositories are a case in point — institutions develop/implement their own but all too rarely share their successes to save others time.
Misunderstanding — Administrators do not understand nature of OSS tools — they understand and know how to deal with vendors. Functionality can be built on a good foundation — the open source tool — and customized. This is the antithesis of what vendors offer. Open source puts responsibility for getting it right in institution’s hands, not in a vendor relationship.

What Can We Do?

Figure out a way to share software among libraries. There are methods for “big stuff” (Koha, Evergreen, etc.). But what about small stuff? Several initiatives, but none global Google code is one, but it doesn’t meet everyone’s need and isn’t accessible to non-technical librarians. A library-specific repository might be useful.
Put a license on our code and let it go when asked to share it. Even for the small snippets.
Commit to the necessary human investment to build and maintain open source software for our own good.
Reward staff for contributing to open source communities. This should be viewed as a form of professional development/contribution.
Re-prioritize internally to make open source contributions happen.
Favorite soundbite from Dale’s talk: “Minesweeper is like digital heroin.”