Cool or Useful? A guide to incorporating hobby projects into library work
Sometimes I have trouble creating a clear line between geeky hobby projects I do on my own time and professional tasks for MPOW (my place of work.) This time, the geeky-thing-I-think-is-cool is a LibraryBox. LibraryBox is a hardware hack created by Jason Griffey. What I’m currently trying to work out is, is this project a viable solution to a practical work-place problem? Of course, I have to watch out for Maslov’s Law of the Instrument which can be paraphrased: “To a person with a hammer, every problem looks like a nail.” These days I’m seeing a lot of LibraryBox-shaped nails. I’m eager to find potential applications for my new
toy tool. My project in today’s post is to describe the LibraryBox project and describe a method of determining whether or not it has a work-related application.
What is a LibraryBox?
A LibraryBox is a very portable pocket-sized device that serves up digital content to wifi devices. It is designed to provide free ebooks to readers with wifi devices but without access to reliable Internet or power. The best introduction to LibraryBox may be found on the LibraryBox site. Jason Griffey has done an excellent job with the site’s design and has written comprehensive instructions for building and deploying LibraryBoxen. The site describes the project as: “an open source, portable digital file distribution tool based on inexpensive hardware that enables delivery of educational, healthcare, and other vital information to individuals off the grid.”
The LibraryBox project was designed to solve a very specific kind of problem. It is useful in scenarios involving all of the following conditions:
- Either no access or sporadic access to Internet and electrical utilities
- a need to distribute digital content
- users that have wifi enabled devices
In order to meet these objectives, the LibraryBox
- uses inexpensive parts and hardware.
- runs off of batteries and is highly portable.
- uses open source software. (The code is both kinds of free; both libre and gratis.)
Building the LibraryBox was fun and easy. I bought the necessary parts: a mobile router, a large usb flash drive, plus an optional battery. (I’m using a Sony Cycle Energy CP-EL I found on sale at the grocery store for $13). Then I went through the instructions. The process is easy and straightforward. A friend of mine completed them while his baby daughter was down for a nap. I took a little longer because I didn’t read the instructions through before starting and did some steps out of order. If you more diligent with following directions than I am, Jason’s instructions will get you from start to finish easily and without a hitch. Once I had my LibraryBox up and running, I filled the flash drive with some free and creative commons licensed content. I tested it out and was happy to see that I could use it to download ebooks onto my phone, laptop, and tablet. Once I demonstrated that it worked, I began to look for practical applications where it could be more than just cool, I wanted my hobby project to be useful. To keep myself honest and keep my project enthusiasm in check, I’m using a series of questions to help determine whether I’m being blinded by the new shiny thing or whether it is, in fact, an appropriate tool for the job at hand. These questions help with the tool/toy distinction, especially when I’m under the spell of the law of the instrument.
- Does this tool or technology offer a solution to an existing problem?
- If the answer to #1 is yes, does it solve the problem better (more efficiently, cheaply, etc.) than alternate solutions?
- Does this tool or technology introduce unintended consequences or side-effects that are worse than the original problem?
Applying the Questions:
There are two ready applications for a LibraryBox at MPOW. Neither directly involve the library, both involve faculty projects in our Creative Media and Digital Culture (CMDC) program. Both are interesting projects and both project leads have indicated interest in using a LibraryBox to solve a problem. The first case involves using a LibraryBox to allow visitors to a remote historical site the ability to download and install a mobile app. My colleague Brett Oppegaard is leading development of a mobile app to provide visitors to a historic site access to interpretive materials. The location is somewhat remote and mobile broadband coverage is spotty at best and varies depending on the cell provider. My thought was to provide visitors to the site a reliable method of installing and using the app. Applying the three questions from above to this project, I learned that the answers to the first two questions are an unqualified yes. It solves a real problem by allowing users to download a digital file without an active net connection. It does so better than alternate solutions, especially due to its ability to run off of battery power. (There are no utilities at the site.) However, the third question reveals some real difficulties. I was able to successfully download and install the app from its .apk file using the LibraryBox. However, the steps required to achieve this are too convoluted for non-technical end users to follow easily. In addition, the current version of the app requires an active Internet connection in order to successfully install, rendering the LibraryBox workaround moot. These issues may be able to be resolved with some hacking, but right now the LibraryBox isn’t a working solution to this project’s needs. We’ll keep it in mind as the project develops and try new approaches.
Fortunately, as I was demonstrating the LibraryBox to the CMDC faculty, another colleague asked me about using it to solve a problem he is facing. John Barber has been working on preserving The Brautigan Library and re-opening it to submissions. The Brautigan Library is a collection of unpublished manuscripts organized in the spirit of the fictional library described in Richard Brautigan’s novel The Abortion. The Brautigan Library manuscripts currently are housed at the Clark County Historical Museum and we tested the LibraryBox there as a source for providing mobile access to finding aids. This worked, but there were speed and usability issues. As we tested, however, John developed a larger plan involving a dedicated tablet kiosk, a web-app template, and a local web server connected to a router in the building. While we did not choose to use LibraryBox to support this exhibit, it did spark useful conversation that is leading us in promising directions.
After learning that the LibraryBox isn’t a turn-key solution for either project, I still have some productive work to do. The first step is to install a light-weight web server (lighttpd) on the hardware currently running LibraryBox. (Fortunately, someone has already done this and left directions.) It’s possible, but unlikely, that will meet our needs. After that we’re going to test our plans using more powerful hardware in a similar setup. I’ve acquired a Raspberry Pi to test as a web server for the project and may also try running a web server on a more powerful router than the TL-MR3020 LibraryBox is based on. (Some open-WRT capable routers have as much as 128mb of RAM, which may be enough.) There is also work to do on the Ft. Vancouver project. The next steps there involve working on-site with the design team to more clearly articulate the problem(s) we are trying to solve.
In both cases my hobbyist tinkering is leading to practical and productive work projects. In both cases the LibraryBox has served as an excellent kluge (jury-rigged temporary solution) and has helped us see a clearer path to a permanent solution. These solutions will probably not resemble my early amateur efforts, but by exercising a little discipline to make certain my
toys tools are being employed productively, I’m confident that my hobby tinkering has a place in a professional workplace. At very least, my leisure time spent experimenting is benefiting my professional work. I also think that the kind of questions used here have application when considering other library toys fads innovations.
Add one part stress test of the Digital Public Library of America’s API, one part conceptual exploration of how DPLA might work, and one part interdisciplinary collaboration contact high, and what do you get? The DPLA Appfest on November 8 in Chattanooga, TN. This day-and-a-half event brought together developers, designers, and librarians from across the US and Canada to build apps on the DPLA platform. (For more on DPLA vision and scope, see previous TechConnect coverage.)
Our venue was the 4th floor of the Chattanooga Public Library. This giant, bare-floored, nearly empty space was once an oubliette for discarded things — for thirty years, a storage space. Now, mostly cleaned out, it’s a blank canvas. New Assistant Director Nate Hill has been filling it with collaboration and invention: a startup pitch day, meeting space for the local Linux users group, and Appfest.
The first night of the event was reserved for getting-to-know-you events and laying the groundwork for the next day’s hacking. With several dozen attendees from a variety of backgrounds, some of us were already good friends, some familiar with one another’s work online, and some total strangers; the relaxed, informal session built rapport for the upcoming teamwork. Tables, sofas, snacks, and beer encouraged mingling.
We also started the intellectual juices flowing with project pitches, an overview of the DPLA API, and an intro to GitHub. Participants had been encouraged in advance to brainstorm project topics and post them on the wiki. People pitched their projects more formally in person, outlining both the general idea and the skills that would be helpful, so we could start envisioning where we’d fit in. Jeffrey Licht from the DPLA Technical Development Team introduced us all to the DPLA API, to give us a sense of the metadata queries we’d be able to base projects on. At Nate Hill’s request, I also did a brief intro to the concepts behind GitHub, one of the key tools we’d be using to work together (seen earlier on TechConnect).
Friday morning, we got to the library early, took advantage of its impressive breakfast spread and lots of coffee, and plunged immediately into hackery. One huge piece of butcher paper on the wall was our sign-up sheet as whiteboards — one for team members to sign up for projects, and the rest quickly covered with wireframes, database models, and scribbled questions on use cases. The mood in the room was energetic, intellectually engaged, and intense.
The energy extended outside of the room, too. An IRC backchannel (#dpla-api on Freenode), shared Google docs, a sandbox server that John Blyberg set up (thanks!) with an impressive range of language and tool support, the #dpla Twitter hashtag, and GitHub collaboration allowed for virtual participation.
The intense, head-down hackery was briefly interrupted by barbecue, cupcakes, and beer (a keg at the library, by the way? Genius). Truly, though, it’s all a blur until 4:30, when the teams demonstrated their apps.
The Apps We Built
There were eleven products at day’s end:
- a workflow for integrating DPLA content with existing Drupal modules;
- a new Drupal module;
- Follow that Cab!, an IFTTT-inspired system allowing users to design a query and be automatically notified of new results (design, code)
- A Ruby library and command line tool for interfacing with DPLA
- Catalog the Whole Earth, a site for letting users submit pictures and metadata of anything;
- a design for Cuttr, a crowdsourced question-and-answer site where users can get their questions answered using DPLA materials, rate answers, and earn karma;
- A PHP class and web interface for DPLA integration;
- A site using DPLA geographical metadata and browser geolocation to show you DPLA collection items sourced near you;
- A browsable map for exploring DPLA items near you (beta, code);
- BiblioGrapher, a tetris-like visualization of DPLA metadata
- DPLA Plus, an engine using probabilistic record linkages to deduplicate and recommend content (documentation, code).
While the DPLA Plus proposer referred to his algorithm-heavy idea during pitches as “super-unsexy”, the judges clearly disagreed, as this impressive bit of engineering took home the prize for best app.
The Culture We Built
Appfest was a very different vibe from DPLA’s hackathon in Cambridge last April (which I also attended). It featured a dramatically larger space, a longer and more structured schedule, more participants, and a much wider range of skills. While Cambridge had almost exclusively software developers, Appfest drew developers, designers, UX experts, metadata wonks, and librarians. This meant it took longer for teams to coalesce, and we needed to be much more intentional about the process. Instead of April’s half-hour for project pitches, we spread that process over the weeks leading up to Appfest (on the wiki), Thursday’s pitch session, and Friday morning’s signups.
With such different skills, we also were familiar with different tools and used different vocabulary; we needed to work hard at making sure we could all communicate and everyone had a useful role in the projects. Again, the longer timeframe helped; an informal dinner at the library Thursday evening and assorted bar trips Thursday night gave us all a chance to get comfortable with one another socially. (So, admittedly, did the keg.) A mutual commitment to inclusiveness helped us all remember to communicate, to break down projects into steps that gave everyone something to do, and to appreciate one another’s contributions. Finally, organizers circulated around the room and kept an eye on people’s mood, intervening when we needed help finding a team that needed our skills, or just a pep talk.
And with all that work put in to building culture? The results were amazing. The April results were generally developer-oriented; as you can see from the list above, the Appfest products ranged from back-end tools for developers to participatory, end-user-oriented web sites. They were also, in most cases, functional or nearly so, and often gorgeous.
#DPLA Appfest is honestly the most productive hackathon I’ve ever been to. More groups shipping near complete things than I’ve ever seen
— Dave Riordan (@riordan) November 9, 2012
There are some implications here for both DPLA and libraries in general. The range of apps, inspired in part by earlier work on DPLA use cases, helped to illustrate the potential impact that DPLA could have. They also illustrated both the potential and the limitations of DPLA metadata. The metadata is ingested from a variety of content hubs and overlaid with a common DPLA schema. This allows for straightforward queries against the DPLA API — you can always count on those common schema elements.
However, as anyone who’s ever met a crosswalk in a library school metadata class knows, automated ingestion doesn’t always work. The underlying metadata schemata don’t always map perfectly to DPLA’s, and therefore the contents of the fields aren’t wholly standardized and don’t always provide what developers might be looking for (e.g. thumbnail images to illustrate query results). This, of course, is why DPLA has these hackathons — both to illustrate potential and to stress-test its back end, find out what works and what doesn’t and why. Want to help? Go for it. There’s a host of ways to get involved at the DPLA web site.
And for other libraries? I keep coming back to two things: Dave Riordan’s tweet, above, and the digital humanities community’s One Week | One Tool project. This was, essentially, a week-long 2010 summer camp in which a small, diverse team of digital humanists built an electronic publishing plugin for WordPress, from scratch, after a public discussion of their community’s needs. In other words: we can do this thing. Working, useful tools can be built in a shockingly short time, if we have open conversations about what would be useful and assemble skilled, diverse teams.
Let’s do more of that.
* The ≈ symbol indicates that the two items are similar, but not equal, to each other.
Hacker is a disputed term. The word hacker is so often mis-applied to describe law breaking, information theft, privacy violation, and other black-hat activities that the mistake has become permanently installed in our lexicon. I am not using hacker in this sense of the word. To be clear: when I use the word hacker and when I write about hacker values, I am not referring to computer criminals and their sketchy value systems. Instead, I am using hacker in its original meaning: a person who makes clever use of technology and information to solve practical problems.
With the current popularity of hackerspaces and makerspaces in libraries, library hack-a-thons, and hacking projects for librarians; it is clear that library culture is warming to the hacker ethic. This is a highly positive trend and one that I encourage more librarians to participate in. The reason I am so excited to see libraries encourage adoption of the hacker ethic is that hackers share several core values with libraries. Working together we can serve our communities more effectively. This may appear to be counter-intuitive, especially due to a very common public misconception that hacker is just another word for computer-criminal. In this post I want to correct this error, explain the values behind the hacker movement, and show how librarians and hackers share core values. It is my hope that this opens the door for more librarians to get started in productive and positive library hackery.
First, a working definition: hackers are people who empower themselves with information in order to modify their environment and make the world a better place. That’s it. Hacking doesn’t require intruding into computer security settings. There’s no imperative that hackers have to work with code, computers, or technology–although many do. Besides the traditional computer software hacker, there are many kinds of crafters, tinkerers, and makers that share core the hacker values. These makers all share knowledge about their world and engage in hands-on modification of it in order to make it a better place.
For a richer and more detailed look into the hacker ethic than provided by my simplified definition I recommend three books. First try Corey Doctorow’s young adult novel, Little Brother 1. This novel highlights the hacker values of self-empowerment with information, hands-on hacking, and acting for the public good. Little Brother is not only an award-winning story, but it also comes with a bibliography that is one of the best introductions to hacking available. Next, check out Steven Levy’s classic book Hackers: Heroes of the Computer Revolution 2. Levy details the history of hackers in the early 1980s and explains the values that drove the movement. Third, try Chris Anderson’s Makers: The New Industrial Revolution 3. Anderson tells the story of the contemporary maker movement and the way it is combining the values of the traditional do-it-yourself (DIY) movement with the values of the computer hacker community to spark a vibrant and powerful creative movement across the world.
In the preface to Hackers: Heroes of the Computer revolution, Levy observed a common philosophy that the hackers shared:
It was a philosophy of sharing, openness, decentralization, and getting your hands on machines at any cost to improve the machines and improve the world.
The Wikipedia entry on the hacker programming subculture builds on Levy’s observations and revises the list of core hacker values as:
- Engaging in the Hands-on Imperative.
These values are also restated and expanded on in another Wikipedia article on Hacker Ethics. Each of these articulations of hacker values differs subtly, yet while they differ they reinforce the central idea that there are core hacker values and that the conception of hacker as computer criminal is misinformed and inaccurate. (While there clearly are computer criminals, the error lies in labeling these people as hackers. These criminals violate hacker values as much as they violate personal privacy and the law.)
Once we understand that hacking is rooted in the core values of sharing, openness, collaboration, and hands-on activity; we can begin to see that hackers and librarians share several core values and that there is a rich environment for developing synergies and collaborative projects between the two groups. If we can identify and isolate the core values that librarians share with hackers, we will be well on our way to identifying areas for productive collaboration and cross-pollination of ideas between our cultures.
If we are going to compare hacker values with library values, an excellent starting point is the American Library Association’s Library Bill of Rights. I recently had the pleasure of attending a keynote presentation by Char Booth who made this point most persuasively. She spoke eloquently and developed a nuanced argument on the topic of the narratives we use to describe our libraries. She encouraged us to look beyond the tired narratives of library-as-container-of-information or library-as-content-repository and instead create new narratives that describe the enduring concept of the library. This concept of library captures the values and services libraries provide without being inextricably linked to the information containers and technologies that libraries have historically used.
As she developed this argument, Char encouraged us to look to library history and extract the core values that will continue to apply as our collections and services adapt and change. As an example, she displayed the 1948 Library Bill of Rights and extracted out of each paragraph a core value. Her lesson: these are still our core values, even if the way we serve our patrons has radically changed.
Char distilled the Library Bill of Rights into five core values: access, freedom, advocacy, inquiry, and openness. If we compare these values with the hacker values from above: sharing, openness, collaboration, and the hands-on-imperative, we’ll see that at least in terms of access to information, public openness, freedom, sharing, and collaboration libraries and hackers are on the same page. There are many things that hackers and libraries can do together that further these shared values and goals.
It should be noted that hackers have a traditionally anti-authoritarian bent and unlike libraries, their value of open access to information often trumps their civic duty to respect license agreements and copyright law. Without trivializing this difference, there are many projects that libraries and hackers can do together that honor our shared values and do not violate the core principles of either partner. After all, libraries have a lot of experience doing business with partners who do not share or honor the core library values of freedom, openness, and access to information. If we can maintain productive relationships with certain parties that reject values close to the heart of libraries and librarians, it stands to reason that we can also pursue and maintain relationships with other groups that respect these core values, even as we differ in others.
At the end of the day, library values and hacker values are more alike than different. Especially in the areas of library work that involve advocacy for freedom, openness, and access to information we have allies and potential partners who share core values with us.
If my argument about library values and hacker values has been at all persuasive, it raises the question: what do hacker/library partnerships look like? Some of the answers to this have been hinted at above. They look like Jason Griffey’s LibraryBox project. This wonderful project involves hacking on multiple levels. On one level, it provides the information needed for libraries to modify (hack) a portable wifi router into a public distribution hub for public domain, open access, and creative-commons licensed books and media. LibraryBoxes can bring digital media to locations that are off the net. On another level, it is a hack of an existing hacker project PirateBox. PirateBox is a private portable network designed to provide untraceable local file-sharing. Griffey hacked the hack in order to create a project more in-line with library values and mission.
These partnerships can also look like the Washington DC public library’s Accessibility Hack-a-Thon, an ongoing project that brings together, civic, library, and hacker groups to collaborate on hacking projects that advance the public good in their city. Another great example of bringing hacker ethics into the library can be found in TechConnect’s own Bohyun Kim’s posts on AJAX and APIs. Using APIs to customize web services is a perfect example of a library hack: it leverages our understanding of technology and empowers us to customize and perfect our environment. With an injection of hacker values into library services, we no longer have to remain at the mercy of the default setting. We can empower ourselves to hack our way to better tools, a better library, and a better world.
An excellent example of hackery from outside the library community is Audrey Watters’ Hack Education and Hack [Higher] Education blogs. Just as computer hackers use their inside information of computer systems to remake the environment, Audrey users her inside knowledge of education systems to make positive changes to the system.
- Doctorow, Cory. 2008. Little brother. New York: Tom Doherty Associates. http://craphound.com/littlebrother/download/ ↩
- Levy, Steven. 2010. Hackers Heroes of the Computer Revolution. Cambridge: O’Reilly Media, Incorporated. http://shop.oreilly.com/product/0636920010227.do ↩
- Anderson, Chris. 2012. Makers the new industrial revolution. New York: Crown Business. http://worldcat.org/oclc/812195098 ↩