Business Idea #1: Library Development Jobs Shouldn't Be Lame

Cody Powell, a developer in Austin, Texas, has written a nice article about how to determine if a programming job is lame. The Codypo scale has 8 questions on it:

1. Would I be paid below market rates?
   
2. Would I always be on call?
   
3. Am I the IT staff?
   
4. Would I work with a single monitor?
   
5. Will I be maintaining any ancient system, and what's it written in?
   
6. Would my internet usage be filtered or monitored?
   
7. Would I be the only programmer?
   
8. Am I expected to travel every week?

I'm wondering how the typical library does on the codypo programmer-job-lameness scale. If you work in a library, please please enter your result in the survey:




I have observed that most libraries need to employ software developers, but few libraries are good places for software developers to work. This is a bit of a paradox, because libraries have some wonderful problems for software developers to work on. The small number of libraries that have robust development departments- typically large research and corporate libraries - have done some amazing work.

Among the problems that libraries have in employing developers are divergent pay scales, small size, mentor availability, quality of supervision, development infrastructure, and the herding of cats problem. Their jokes are different.

Partly as a response to this, libraries have tended to outsource the bulk of their technology development to their systems vendors. For the most part, this solution has been adequate, but costly. Increasingly though, libraries find their support costs rising, their service declining, and they are left with increasingly complex integration tasks, especially if they are so bold as to use systems from more than one vendor.

One response to dissatisfaction with vendor support has been a shift to open-source and/or cloud-based solutions. The advantage of open-source firms is that they can't afford to provide poor support, because nothing prevents competitors from providing the same support. The advantage with cloud-based systems is that a cloud vendor can provide basic service at a significantly lower cost.

The paradox of relying on open-source and cloud based systems, however, is that it causes libraries to employ more development staff, not fewer. This is because open-source systems present new opportunities to improve, integrate and modernize services, and libraries feel obliged to contribute improvements into the open source ecosystem. In contrast, cloud based systems tend to be provided with minimal local support coupled with API-based integration options. As more and more these solutions become available, the library's need to integrate multiple solutions (both cloud and open-source) increases.

As if libraries had nothing more to worry about, most of them are facing budget cutbacks, and in many cases, required staffing cuts. What if there was a company that could take on their development and software integration burden, provide their development staff with the environment, support and training they deserve, and commit to reducing their total expense? Maybe Gluejar could do that.

This is not a new idea- both IBM and HP/EDS have successfully demonstrated the viability of this business model for providing IT to large businesses (for a report on the market, take a look at this Forrester Wave report (765KB)). It's no coincidence that these companies (particularly IBM) are active in support of Open Source software and cloud-based services.

The library world is no stranger to staff outsourcing- companies such as Library Associates and LSSI have been assuming the management of libraries and library departments for quite a while now. In Japan, even academic libraries will outsource key functions to companies like Kinokuniya. There's been opposition to library staff outsourcing- how can librarians truly focus their attention on the needs of their institution or community if they are employed by a dispersed corporate entity? I think outsourcing librarians is quite different from outsourcing library development staff.

It's possible that the Open-Source Library systems companies like LibLime, Equinox, IndexData, ByWater and BibLibre will evolve towards this model. The current reality, however is that most libraries must deal with many proprietary systems vendors as well, and these are often not predisposed towards working with the Open Source vendors who hope to displace them. To most effectively serve libraries, a company that manages a library's development staff must establish good relations with all types of technology and database vendors as well as information suppliers.

What I don't know is how desperate libraries are to fix the problems I've perceived, or how serious and widespread they are. It's entirely possible that the tight control over development staff is something that libraries are unwilling to give up.

I would be very interested to get feedback on this, either in private, or in the comments.