-->
Gavia Libraria

Could your software be taught in a library school?

The Loon has a new work project: namely, what she once saw called a “datacenter under desk” (tongue-in-cheek acronym entirely intentional). It’s a tolerably beefy computer with virtualization software and a few static IP addresses allocated to it behind a VPN-access-only firewall. (Ninety percent of what the Loon knows about server security is that the Loon should never be trusted with server security. Ergo, the machine lives behind firewalls managed by people who actually know what they’re doing.)

The Loon’s goal for this machine is that it be a sandbox for open-source server-based software relevant to her own classes and her colleagues’. No production services, no serious development work, just being able to say yes to “hey, heard about this new thing, can we throw it up somewhere and kick the tires?” as well as “this is one of the standard software platforms in this area; students should have a chance to work with it.”

If we care to be polite, we might say that the Loon’s knowledge of systems administration is wholly self-taught. If we don’t, we can throw around such terms as “script kiddie” and “drastically incompetent.” This isn’t a Loonish variant on impostor syndrome; it’s simply truth inflected with deep respect for systems administrators. The Loon is a William Morris gadfly, not an obsessed Lord Byron. Breadth, not depth, is her stock in trade. Worse yet, she hasn’t had to do much of any sysadminning in nearly a decade. So not only does she know barely the barest bones of the sysadmin trade, she hasn’t time to dive much further into it, being busy keeping up with a truly absurd number of other absorbing topics and pursuits.

(And teaching an overload course, and taking on considerable extra service work. This has been a nasty semester for workload and mental strain. The blogging hiatus is now explained, the Loon trusts.)

Currently the Loon is learning how virtualization works while getting various software packages installed and then snapshotted so that they can be loaded when they are needed. The results have been mixed. Some packages—Omeka, WordPress, even Drupal and (rather to the Loon’s surprise) Archivematica—went in with only minor bobbles if any. (Verbum sapientibus, however: Archivematica needs its own VM, as it does not play nicely with… anything else in the universe. In its defense, its documentation says precisely this.)

Others… well, the Loon chooses to believe that developers want adopters even among the tyro-sysadmin population (which, lest we forget, fuels a great many smaller libraries and archives! this is not solely an LIS-education problem), so she will break her usual rule and name names. Other software packages have not been so straightforward to get running, and the reasons for that cluster.

  • Where are the installation instructions, DSpace and Hydra? In the former case, they are three clicks away from the home page (which is at least one too many) and not clearly pointed to from the “Quickstart Guide;” in the latter, they are not reachable in any straightforward fashion from the home page as best the Loon can tell.
  • If you must maroon the tyro sysadmin in dependency hell, at least tell her how to install and configure the damned dependencies. DSpace, this means (among other things) offering full paths to configuration files such as postgresql.conf, not leaving tyros to read the man page for the find command. Let us pass over Tomcat configuration in rueful silence; suffice to say the Loon has made four runs at getting DSpace going, still hasn’t gotten it right, and suspects the yak requiring a barber’s attention lies somewhere in the reeking bowels of the Apache/Tomcat/maven/ant complex.
  • Speaking of dependency hell, it is a terrible thing. DSpace, why in creation do you need not one but two software-build packages (that do not, worse still, work properly when installed via apt-get/aptitude)? Hydra, you cannot possibly be serious about needing to write Ruby code just to install the software—the Loon got to that spot in Dive Into Hydra after about ninety minutes’ work (multitasking, admittedly), and promptly consigned the VM to silicon oblivion, swearing fulminously. She has not yet decided whether it is worthwhile to try again. Minimum time and effort to working installation matters. It matters a lot.
  • Do not assume that tyro sysadmins understand git. Or vagrant. Or Docker. Or any of the million-and-one package managers and build orchestrators that developers have spun up to try to hide how grossly convoluted their software-installation processes still are. The Loon could have saved a full hour’s DSpace installation-failure time if she’d only known that vagrant does not play nicely with VMWare. (And if your immediate reaction is “Why are you using VMWare, you crazed Loon you?” you are part of the problem.)
  • A brand-new installation needs to do something useful, ideally the major task the software exists to do, straight out of the box, Islandora and Hydra. (DSpace passes this particular test fairly well, though its insistence on community/collection creation prior to item deposit does damage it slightly.) Put another way: if you have to hold an entire face-to-face camp before someone can use your software, your software is insufficiently usable, full stop. (Bonus yodel: Islandora, what on earth is that desperately confusing morass you call an administrative UI, and why has anyone anywhere let you get away with it? For shame. Hire a proper usability firm at once—you are many developer-years away from being able to consider actual UX—and hold your developers’ feet over the fire until they implement every last recommendation.)
  • Search engines are terrible troubleshooters, Koha. Do point to listserv archives or support forums from installation and troubleshooting instructions. (The Loon has the Koha administrative interface working, but the user-facing one is still coming up blank. She suspects an Apache configuration problem; see above about dependencies.) Tyros will need help; kindly do not make us guess where to get it. Also keep in mind that many tyros do not do IRC. (The Loon’s Boring Alter Ego does, but in this way she is not a typical tyro.)
  • If you can avoid requiring fully-qualified domain names, please do. The Loon may well acquire ulcers at the red tape necessary to squeeze subdomains out of the IT bureaucracy where she works. Put another way: web interfaces to your software need to work from a static IP address, and installation instructions need to make clear how that can be arranged.
  • Find a tyro sysadmin. Usability-test your installation instructions on her. Fix the problems you discover. Repeat.
  • Find a tyro information professional of the sort who might wind up not so much installing your software, but administering its back-end processes. Usability-test the admin interface on her. Fix the problems you discover, for pity’s sake; do not try to document around them, fix them. Repeat. It’s 2014; why does the Loon even need to say this?

If all of the above seems like too much work, there is another option: offer a sandbox. Archivematica and Islandora do this, though Archivematica’s is considerably more successful because its administrative UI does not act like a Hieronymus Bosch painting. If you cannot imagine making a sandbox because your software requires too much modding before it is actually useful to anyone, that is a bug the Loon doubts you will regret fixing. Doodle up some Alan Cooper personas (the Loon will happily model for one) and make a sandbox they’d see value in.

A good many library schools rely on commercial digital-library and ILS software and software-as-a-service for demo and training purposes. This is not due to any onus against open source. It’s because commercial software companies are not fools; the competitive advantage of having library schools train LIS students on their specific software is dead obvious, so they make it easy for us. Hosted installation? Why, certainly; would you like it branded with your school name and colors? (This actually happened to the Loon.) Free support? But of course. Training materials, sample objects to work with, suggested assignments? Here you go; enjoy them, and do let us know if you’d like one of our trainers to guest-lecture in your class.

If open source wants to compete with that, at bare rock-bottom minimum it had better make software the Loon, busy distracted incompetent 0.1-FTE tyro sysadmin that she is, can damned well install. So endeth this exasperated yodel.

Edited to add: DSpace developer (and longtime usability advocate) Tim Donohue tweeted to inform the Loon that DSpace does have a sandbox installation available. The Loon feels considerable relief to know this…

4 thoughts on “Could your software be taught in a library school?

  1. Candy Schwartz

    We have one of these, made under a grant for the archives program. It’s called the Digital Curriculum Lab, and it has lots of open source IR/DL systems and various sets of objects loaded by players in the sandbox. There’s a student fellowship position that serves as sysadmin – which is a good resume-building opp. I think it also has cases and scenarios for archival use. It does not have things like Drupal, alas. It’s great for the students to have a safe place to experiment – good for you for taking this on.

    1. Library Loon Post author

      There is something of a chick-and-egg problem with the student fellowship: the Loon will have to prove that the sandbox server is pedagogically useful (ideally to more than just the Loon herself) before the Loon can even broach the topic of paying someone to administer it. Such is life.

      The Loon doesn’t mind the work. She just wishes it were less frustrating and time-devouring.

  2. Kristin Briney

    It’s interesting to note the programs that installed easily (Omeka, WordPress, Drupal, and Archivematica) versus the ones that did not. There seems to be a majority of library-centric programs on the wrong side of that line. For all librarians talk about everyone needing programming skills (probably not), we need at least some people who are whizzes at UX and development for our open source projects.

    Also, this sounds like a special circle of hell –> “the Loon … suspects the yak requiring a barber’s attention lies somewhere in the reeking bowels of the Apache/Tomcat/maven/ant complex.”

  3. Tom Cramer

    Thanks for the testing and feedback on Hydra, Loon! Hydra is still a framework more than a turnkey application–something we talk about at great length within the project–and that is (slowly, deliberately) improving. You’ve given us some chunky suggestions for streamlining the tire-kicking and install process. If you happen to know LIS students who’d like to sharpen their OSS skills (if not their programming abilities) by doing further smoke testing of any Hydra docs or tutorials, we’d welcome (and respond to, and even send a sweet t-shirt for…) it.