Blog Feed ( rss | atom | rdf )

Blog Comments ( rss | atom | rdf )

Entries in code4lib (3)


Code4Lib Jobs

Just a quick note.  It seems there's still a lot of folks out there who haven't heard of Ed Summers' excellent little tool, http://jobs.code4lib.org.  It's a semi-automated harvesting system that's pulling in a ton of job posting related to libraries.  You can also filter out the @code4lib twitter posts that start with Job:, they're being supplied by this nifty little system.  And like many code4lib projects, it's open source and can be found as shortimer at git.

I know Ed was hoping it might even lead to part-time and contract work where someone might set up a short-term need and a programmer with a lot of library knowledge could fill it.  Say, adapt Evergreen so it interacts with some digital library software that it doesn't currently work with.  I haven't seen many of those yet, but hopefully we'll see those become more common. It would make earning a little extra money consulting far easier. 


Unglue.it launched!

Those following me in my various social circles are probably already sick of hearing about this, but unglue.it launched yesterday.  Unglue.it, started by Eric Hellman (aka @GlueJar) and other folks w/ connections to Code4Lib, is a effort to release copyrighted books to the world.  Working with right-holders in a kickstarter style to raise enough money to license an ebook  a creative commons non-commercial license.  It's a way of "front-loading" profits so the author can be compensated for their work, but the world gets access.

They also have a mechanism for adding books to a "wishlist" that will give them an indication of works that people want and what right-holders they should track down.

This is a brilliant way to deal with some of those really important and hard to find out of print books.  For example, I've wishlisted a very good biography by Greg Rickmann of Philip K. Dick called To the High Tower.  It's a work that I stumbled across that's sought out by a small circle of Philip K Dick fans. 

It's not clear if there's enough demand for another printing, but unglue.it offers a chance that it could be made easily available again while also giving the author further profit he's not going to see of this long-since sold out book otherwise.  I have had the good fortune to read it due to the fact I work at a major library that has a ton of access of books, but I know many a sci-fi fan that doesn't have the resources I do.

I also must admit that I'm interested to see if this model works.  I've thought about trying to do a small hobby side business of making value-added public domain works and perhaps doing something similar to unglue.it with near-orphaned copyright works.  However, tracking down right-holders has proved troublesome enough that it's remained in my large bucket o' ideas I'd like to do someday.  I'm hoping unglue.it takes off enough that it'll create a infrastructure that might make it easier to do projects of this nature.

Here's what I'm pledging to:



Sharing Code

Recently a newcomer to the Code4Lib mailing list, Cliff, posted a question asking for information about sharing code and also possible ethical considerations as some of the shared code might be based off of other's efforts.

I did a short response that focused more on the first part of his query covering some thoughts about code sharing in the Code4Lib community, which I'm cleaning up and posting here.

There seems to have been a push over the past few years in Code4Lib to share more and more code, even with small projects. There are a lot of individuals scattered about in the library world writing code to accomplish similar tasks, small and large.  One common example is the glue between certain academic enterprise systems and our catalogs.  This code, particularly in the past, got developed in little pockets without ever getting shared.  Occasionally code sharing flourishes as a gated community surrounding a particular vendor, but I think these communities suffer by just not being large enough.  There seems to be a conscious push against the tendency of isolated development by releasing often and without regard to size.  GitHub in particular has made it really easy and painless to share smaller chunks of code and offer patches to projects.

I have been bad about releasing and sharing source myself. This has been a hindrance as I find myself creating similar code in different internal projects instead of taking a step back and generalizing the code.  If I did, not only could the code be shared among my projects, it could be shared with the community.

There is also a barrier in our lawyers. I have not put in the energy needed to get the attention of the office that makes decisions on whether or not to release code as open source.  That office also does not make it easy or comfortable to ask questions.  I suspect from what I've heard that one really needs to call or try to visit in person, something I tend to sub-consciously avoid in my typical approaches to communication.

On a community level, it feels like Code4Lib is starting to see tension about releasing small projects and lots of code that manifests in a variety of ways. 

  • There is the perception that there are projects have been abandoned or just don't have the level of  support and community necessary to sustain development.
  • Large scale of adoption of code/projects by people who don't have the technical skills to contribute patches and need help to use the project.
  • Competition among projects that share goals and need to compete with each other for community.  I think choices are good, but choices introduce tension and too many choices can lead to people choosing nothing.  I don't think the library software world has hit that point, but I can see a future not to far away where this is more of a problem. 

There have been a couple of articles over the years on these topics in the code4lib journal that describe it in more detail than the general approach I've taken here that worth reading.

First, an argument on why to just put stuff out there and why so often we seem to fail to by Dale Askey: COLUMN: We Love Open Source Software. No, You Can’t Have Our Code 

On the other hand, see Terry Reese's excellent article in the latest issue presenting an argument why one should be prepared to support the code published: Purposeful Development: Being Ready When Your Project Moves From ‘Hobby’ to Mission Critical

Finally, Michael Doran gave an excellent talk a few years back that really stuck in my head with the very issue I've been reluctant to put more effort into: lawyers and code: The Intellectual Property Disclosure: Open Source in Academia. (Powerpoint slides)

In re-reading the original post, I realized I glossed over the ethical part, which is a shame.  There are some fascinating issues concerning the ethical dimension of sharing code that was based and inspired off of other code. Of course, on one level are the legal issues involved with copyright and derivative works depending on exactly what "based on" entails. 

However, I'm more interested in the learning and sharing aspect of code development. It is extremely useful for me to read code developed by others.  Like critical reading of prose, you can learn a lot by not just trying to figure out what the code does, but thinking about how the code you are reading communicates to the reader.  Does it flow?  Does it jump around?  Are abstractions employed that makes it easier to conceptualize?  It's a fascinating topic and really deserves longer treatment with another post. 

My thanks go out to Peter Murray (aka @DataG) who shared a link to my email.  Also thanks to Becky Yoose (aka @yo_bj) for retweeting. In doing so they made me realize perhaps it would be worth revising and posting the email as a blog post.