[UPDATE: July 9, 2:00pm Matthias Strubel, lead developer for the PirateBox project, has agreed to be the developer for LibraryBox 2.0, Jason Griffey posted today on the CODE4LIB listserv. Appended below is a Q&A in which Griffey talks with Jonathan Rochkind, Digital Services Software Engineer for the Sheridan Libraries at Johns Hopkins, about how the project’s goals are evolving, thanks to the success of his Kickstarter campaign. Griffey also clarifies how the project differs from PirateBox. The Q&A has been reprinted in full with permission from Griffey and Rochkind].
Jason Griffey, head of library IT for the University of Tennessee at Chattanooga, has launched a Kickstarter campaign to help fund expansions and upgrades for his open-source LibraryBox project. LibraryBoxen are self-contained, battery-powered, pocket-sized routers that enable wireless distribution of ebooks, images, and other digital content without an Internet connection.
Making a LibraryBox is a relatively simple do-it-yourself project that can cost less than $50 using an inexpensive portable router, a USB flash drive, a USB charger, and free, open-source code. Griffey’s website includes step-by-step instructions for people interested in creating their own. However, doing so requires procedures that many users may not be comfortable with, such as replacing a wireless router’s firmware with Open-WRT, using telnet, and working from a command line prompt to edit the router’s network configuration and then install software.
Two of Griffey’s primary goals for the 2.0 version of the project are simplifying the install process as much as possible, and exploring how LibraryBoxen might work with new hardware, such as solar panels for semi-permanent outdoor installations. Funding raised by Kickstarter pledges will be used for test hardware and hiring a developer to simplify the install process and enhance the interface, making it easier for users to navigate, and easier for owners to make minor customizations.
As LJ described in a July, 2012 profile of the project, libraries are already using these portable devices to distribute out-of-copyright and Creative Commons licensed ebooks at local coffee shops and farmers markets. Likewise, one teacher in China told Griffey that s/he had made a LibraryBox to simplify the distribution of classroom materials in an area where Internet traffic is heavily monitored and censored.
He added that he has gotten “an enormous number of requests” for a design that incorporates solar power and a waterproof container. “Especially from little free libraries. A lot of those have been interested,” Griffey said. “I need to see what I can recommend that actually works.”
As for simplifying the installation, Griffey said that he gets lots of feedback from people who followed his instructions and created their own LibraryBox without encountering any serious problems. A community of users has also coalesced around the project, offering online help to anyone who gets stuck. But, as he points out, “I would love to have some statistics about how many people visited the [LibraryBox] page, got excited about the project, looked at the instructions and said ‘nope!’”
With the current LibraryBox 1.5, Griffey said he tried to make the instructions “absolutely as recipe-like as I could possibly make them, and yet there are still ways that they could be better. One of the goals for the 2.0 is to remove as much of that complexity as humanly possible…. In my ideal setup, it would be something like, you download the software, you put it on the USB stick, you log into the box, press a button and magic happens.”
This is not as easy as it sounds, and further complicating the issue, Griffey does not want version 2.0 to be tied to a specific piece of hardware. Currently, he recommends TP Link’s MR3020 for it’s portability and low price, and a single type of hardware is both easier to write code for and support. But theoretically, the code can run on any Open-WRT compatible router, and as Griffey points out, there’s no guarantee that the MR3020 will be manufactured in perpetuity.
“I live in constant fear that TP Link is going to discontinue that router. Tying the project—which is much bigger than any single piece of hardware—to a piece of hardware, is short sighted and not something that I want to do.”
The LibraryBox Kickstarter campaign almost immediately exceeded its modest fundraising goal of $3,000 after launch on Friday, but Griffey has several “stretch goals” that he plans to work on if the project raises more.
For example, if the campaign raises $4,000, the extra $1,000 will be spent hiring a developer to figure out a way for a LibraryBox to track download statistics without logging any user information.
“One of the biggest requests has been for [usage] statistics,” he said. “It’s important for the project that there not be logs of access. It’s anonymous and off the grid. Doing statistics without logging in some way is going to be tricky…. That’s something I really want done, but don’t have the capacity to do myself…. If it raises $5,000, $6,000, $8,000, other new goals will be added.”
Jonathan Rochkind: I still don’t understand how this project differs from PirateBox. What features are you adding in your fork? What has been added to your fork over PirateBox in the current release, and what do you plan to add that differs from PirateBox in the 2.0 release you are funding? And why are you adding these features in a fork, instead of contributing them back to PirateBox?
Jason Griffey: LibraryBox began as a fork of PirateBox that attempted to make it generally more comfortable for use in academic settings. Anonymous upload is…troublesome at best…so that was the first thing I stripped out. I also built in the ability to alter the SSID easily, customize the logos without having to be familiar with the command line, and just generally try and make the sorts of questions that librarians and teachers might ask a bit more obviously answerable. It was a _very basic_ fork. But it was something that seemed to have legs despite.
The existing install of LibraryBox (1.5) is based on the .3.2 release of PirateBox, and as such is missing some of the newer abilities that PirateBox .5.x has. Part of the 2.0 is simply bringing the two into sync.
I am adding them in a fork because it’s a different project with different goals. The features of LibraryBox 2.0 that are applicable to the upcoming release of PirateBox 1.0 will be contributed back.
Rochkind: Or are there no new features, it’s feature-identical, but just with a different name and different branding? In which case, what is the kickstarter actually paying for?
Griffey: See above. In addition, the Kickstarter funding is allowing us to leapfrog the current PirateBox install in a lot of ways that haven’t been possible until now, such as unmediated installation (well, basically unmediated). I haven’t announced it yet (coming in the next Kickstarter update) but the lead developer of PirateBox has agreed to do the work on LibraryBox 2.0, so much and more of it will be used in PirateBox as well. We’re also going to be adding MUCH easier web customization vis a vis relocation of the web directory to the USB stick (not currently available in PirateBox) and we’re testing PHP on the boxen to allow for a richer web experience. None of this is currently available without customization of a Piratebox install which is again beyond the abilities of most librarians.
Rochkind: I’m also very confused about how you are budgeting, how you are determining how much money raised will fund how many new features of what sort.
Griffey: I can see that! Kickstarter is a marketing medium, not a project management tool. :-) So the language used in the campaign isn’t designed to be project management based. That comes after.
Rochkind: You say in the kickstarter, that the money raised will “help me find and pay them to make LibraryBox more awesome” — but then you also say that “Anything raised here on Kickstarter will also be used to purchase hardware” — this seems to be contradictory. Will the money be used to pay developers, or will it be used to purchase hardware?
Griffey: Ummm…Both? My initial plans for how to budget got shot out of the water in the first 12 hours of the campaign…I had originally planned, when I thought I would raise somewhere between 3-5 thousand, to use the money for bounties on given features. And I had a couple of stretch goals, for like the 4000 and 4500 marks. Needless to say, that was pretty meaningless pretty fast.
That said, now that I have the money to pay the appropriate person to do the work (Matthias Strubel, lead developer on Piratebox) I am doing so. At the same time I will be purchasing hardware for testing purposes (part of the need is to ensure that the unmediated install works on a variety of hardware) as well as buying some solar panels to test load and runtime under various conditions. There’s been a lot of interest in unattended LibraryBoxen, so I’m going to try and test enough things that I can recommend a set of things that work reliably and well.
Rochkind: If it was being used to purchase hardware, than it wouldn’t be obvious that more money raised could lead to more feature development — since you don’t need more hardware for more feature development. But you repeat later that the more money raised, the more features will be delivered: “If we raise a ton of money, the v2.0 will have a ton a features!” — so I’m thinking your earlier assertion that the money will be used for hardware was in error (and you should correct it to avoid being dishonest and/or self-contradictory) — you do plan to use the money to pay developers?
Griffey: Technically, developer at this point. Although I suppose if Matthias gets hit by a bus, developers will still be applicable.
While in many cases it is true that you don’t need more hardware for feature development, you certainly _do_ if the feature you are developing is hardware specific in some way…say, if you wanted to test having two wireless networks running simultaneously on a single box, it would help to write to and test on a box that has that hardware capability. It’s also necessary to have hardware to test new installs on, troubleshoot, develop documentation, etc.
If you knew me, you would have an idea of how amusing the idea of me being dishonest or self-contradictory is. :-)
Rochkind: But then the question is, what methods have you used to estimate how much it will cost to pay developers for each of the new features or improvements you plan, how do you know the amount of money you are raising is sufficient for the development you are telling people you’ll do with it — including the ‘stretch features’ you already have in mind but have not revealed yet (you say will be revealed ‘as soon as the project is funded’).
Griffey: Here’s an area where I am learning as I go! Given that my plan had been bounty-driven, I am now faced with the complication of more flexible development costs but also with the boon that it’s a single developer who is also the lead on the very thing I’m forking. So it’s a lot less complicated than I could be, thankfully.
As I said above, when I wrote the text for the Kickstarter, I certainly didn’t think I’d be where I am now. The original stretch goals read like a joke now. So: back to the drawing board for more audacious goals (developed with Matthias, so that it’s clear what both the cost and the timeline is). Those are coming ASAP.
Rochkind: Also, do you plan to use any of the money to pay yourself for your time, in addition to paying other developers, and buying hardware?
Griffey: Originally? No. But originally I had a bit less money in mind. I am still considering myself the last in line for $, and will manage the money in order to provide what’s promised before anything else is done with it. After that, I’ll see what I have left….but I’m betting it won’t be much. Let’s just say that the difference between $3K and $20K is significant when it comes to financial planning and I didn’t think I was going to need things like an LLC that now it appears I desperately need. So development is only one part of what is now a very complicated problem set.
Rochkind: I think these are questions that need to be answered for code4libbers — or really anyone that has enough understanding of software development to know what to ask — to be interested in giving you money. Frankly, I have some serious reservations about contributing to your project, and would share these reservations with anyone else you asked. It is not clear to me that you have a clear plan for what you’re actually going to do; that you have adequately done homework to make sure you can do what you want to do for the amount of money you expect; and you have not provided the argument for why what you want to do (a fork of PirateBox) is actually a useful thing to want to do in the first place.
Griffey: Hope that helps assuage some reservations. I totally understand if it didn’t, though…I am assuredly _not_ a developer in any meaningful sense of the word. I am, at best, a product guy who bumbles his way through things that people think are interesting.
I have not tried to justify LibraryBox vs PirateBox as I see them as two very, very different things. PirateBox was started as an art project, a way of thumbing ones nose at copyright status in the US. Before I forked the project I spoke with David Darts (the inventor of PirateBox) to get his advice, and throughout the development of LibraryBox both he and Matthias have been awesomely supportive. I think both of them see it as an extension of the ideas behind Piratebox…it is certainly the first public project that I’ve seen that attempted to turn PirateBox into a more appealing project for librarians and educators. While development is a _big deal_ in this project, I’d like to think that the rest of the implementation is just as important, and that has been done pretty well, I think.
The Kickstarter campaign wasn’t about having a clear, delineated development plan. It was about selling the idea and possibility of the project so that I could then have a clear delineated development plan. Which is what myself and Matthias are working on now.
About Matt Enis