This was initially meant to be about the “Supporting Open Source in Libraries” breakout session at Code4Lib 2011, but after listening to the Lullabot podcast about the concept of a Drupal app store I had all kinds of deep and important thoughts about open source software in general. Then I neglected to write any of them down, so this will probably not be as exciting as it could be.
Nevertheless, I told some people on Twitter I would write it, and so here I go.
The point of the breakout session was for people from LYRASIS to get ideas about what types of information would help support libraries in adopting OSS. The discussion revolved around several issues (there was a lot of chat about whether outsourcing data storage and servers is cheaper or not, which I basically tuned out). First, what skills are required for library staff to effectively implement OSS, and second, how to get support for OSS without being stuck with yet another monopoly. That second point had a related angle of how to find support vendors/how to find OSS products that have been vetted in some manner, which I will return to later.
What technology skills librarians need to have was a touchy issue for many librarians at Code4Lib, even those of us who work with technology on a daily basis. That is, many of us feel that we don’t know enough and don’t have time to learn as much as we would like. This may or may not be true. In any event, I see a few scenarios from my own and others’ experiences. Many people at the breakout session mentioned tense relationships with central university or city IT, leading them to have to outsource hosting and support both, or else build a library IT team that could handle everything. I am extremely lucky to have an excellent relationship with my university’s central IT, and a server that the library owns but IT administers. We are also given as much space as we need on other servers. Of course, they have to administer all the applications for all the university departments, and so when I need things done on my schedule or to my weird specifications, I have to do it myself–this is where issues with OSS can arise. For instance, after much thought and discussion before I started working here, the software picked for the institutional repository was DSpace. Due to one such tense IT relationship scenario, we took it over from the institution that was hosting the IR. Again, it’s our server, and IT had no problem installing it and doing basic server admin stuff. They would not, nor would we expect them to, mess around with configuring DSpace. As my time is devoted to many different things, I don’t feel I’m giving DSpace all the love and care a free kitten needs. This seems to be a big issue for many libraries. Without the cash on hand for a commercial product or a new staff member who is devoted to the OSS project, it can seem a bit neglected. On the other hand, maybe it’s better to have a mostly ok solution than nothing at all.
Now let’s say that you do choose to outsource support for your OSS project. This is not something I have much experience with, so I am using what other people said at the session. The problem is that with many products, one company has become the de facto solution, whether because they are the best or because they are the only ones in the market. In this case you have merely transferred your money from one company to another, and are still stuck in a monopoly situation. Lots of people pointed out that you have all the advantages of OSS, and are just choosing how to spend the same amount of money. Still, I can see how this is a concern. My perception was that most people felt the ideal situation was to be able to hire an in-house developer, but this is really impractical for most situations. Perhaps an even better situation is for more librarian-developers to enter the market and increase competition, but this is again not an immediately practical solution.
Like I said, a few days later I listened to the Lullabot podcast about the theory of a Drupal app store, and then it hit me–a library app store!
To back up a moment, the Drupal app store was an idea floated on Twitter that apparently went a little nuts. I don’t follow Drupal stuff on Twitter or really anywhere on the social web as much as I should, so I’d not heard of this before. Basically, the idea is that you have modules or other features available for purchase, much as exists for WordPress or other CMSs. This is to many people completely antithetical to the spirit of Drupal. The way it works now is that plenty of developers and straight-up corporate America type companies do a lot of work on modules, but then contribute most of it back. If you want specialized solutions, you hire a third-party Drupal developer to do the work for you, and then the maintenance of that is up to you (or not, as the case may be). There are some GPL considerations, but I’ve discovered that if I spend too long thinking about licenses I feel like I’m being sucked into a vortex. The app store idea turns this around–an individual developer or company creates a module, and you pay to use it. For someone like Earl Miles who created Views, this could look like a get rich quick scheme, but there are many many issues created by this that I won’t get into.
One of the major pros to a model like this is something that I’d never really considered before. It does seem right to support developers monetarily if you can’t do any coding yourself. But entities like the US government or a major corporation aren’t going to donate money to a random person, nor will they trade favors/beer/etc. They would be able to pay an invoice, however. This makes the idea of an app store look really appealing to gain wider acceptance. It also occured to me that something like this for libraries could be really helpful. I am not quite sure now how libraries who don’t know what they are looking for find solutions currently–do they wander the halls at ALA? Ask colleagues? Study the literature? I suppose these are all things I’ve done myself, so I know that at least some librarians do them. Anyway, it was very easy for me to pick LibraryH3lp as a cost-effective solution for virtual reference because there was lots of information available. I believe the same is true for how DSpace was picked, though I guarantee that the conversations I had when planning the implementation were not as cheery as the ones that must have occured to select it! I know there are many wikis, etc. that share info about OSS for libraries, not the least of which is oss4lib. But a lot of these assume a level of knowledge that is probably beyond many people. I am imagining something as easy as the Apple app store, though that is probably too simple.
In any event, the point was made in both fora that to be useful it must be well-vetted with a good system for unhappiness in place. There are lots of sites offering free software, themes, plug-ins, etc. that are very bad, or so I understand. I am super paranoid, and so haven’t run into this personally. If you download a malware theme for WordPress from a random site, who is going to care? But if you buy a bad app from the Apple app store, you get a refund and have someone to complain to. Let’s say someone (a consortium of libraries, preferably) set up an app store where the providers were vetted in some manner, as well as the products, and if the product turned out not to be right, there would be some method for getting a refund. Of course, some would be offered free as well! You would still do the due diligence of reading product reviews, discussing with colleagues, and speaking with the vendor if neccessary, but would have some peace of mind knowing that a third party would help you out. What scale of product could you offer in this type of venue? Probably not an entire ILS migration, but plenty of smaller things–statistics and ERM are two that pop into my mind.
If such a thing exists already, someone please point it out to me. What do you think? What kinds of problems do you have that this could help with, either as a vendor or a library?