There are days that I feel like Tom Cruise. No, I have no idea what it is like to be married to Nicole Kidman or Katie Holmes and I don’t have the secrets of Scientology. Let me rephrase: there are days that I feel like Jerry Macguire, the character Tom Cruise played in the movie by the same name. Have you seen it? Very early in the movie there is a scene where Jerry’s life as a top-tier sports agent is crumbling. He is on the phone with what turns out to be his last client — desperately trying to keep his business. The athlete (Cuba Gooding Jr. — I have no idea what it is like to be him either) gets Jerry to scream “Show Me The Money!” into the phone as a precondition for remaining his agent. In that vein, here is what I’m screaming into this PowerBook. (Imagine now that I am dancing around the room and standing on top of desks — not really a stretch for those that have seen my presentation style, I’ll admit.)
What has set off this rant, you might ask? The trigger was Dan Chud’s “Dear Casey” post. But it has been building up for a while. Another prodding came two weeks ago when an OhioLINK staff member commented (paraphrasing) “the only people really interested in open source are those that want to take what others have created.” Other instances include various discussions with people that tend to drift off at the point of “well, I’ll release it when I get a chance to clean it up” or “you know, there are so many institution-specific hard coded things in it”. Look, folks — if you care about the code at all, you may never consider it clean enough to share with others. — and if there are institution-specific pieces in it, what incentive do you really have to generalize it.
I’d like to think I strive to practice what I’m preaching. The OhioLINK DRC code is available for all to see as it is being built. Now admittedly its development appears to come in fits and starts. And there are definitely activities happening that are not registered in the Subversion code repository. But it is there — mistakes, ugliness, refactoring, and hard-coded stuff.
If you want to ascribe to the principles of open source, well then welcome to the party. But that means you have to come to the party with your code and not just your words. Please don’t tease by saying that you’ll release your code but never do, even if you have the best intentions. Open source is as much about giving back — improving your code by submitting patches, helping clean up the ugliness, and refactoring out institutional-specific pieces (because it would be in my interest to do so) — as it is about borrowing from others. Or, in the words of Eric Steven Raymond in his book The Cathedral and the Bazaar: “Release Early, Release Often.”
So my hope is that this inspires you to release your own code. This is not picking on any one individual or institution, but if it helps you may now believe that there is a virtual finger pointed to you if you have had one of these “I’ll release it into open source” conversations with me in the past. Making source code available does take a few additional steps and a little bit of work, but the steps aren’t hard and the work isn’t significant compared to the effort you’ve already put into the code. If you need help, please ask — in the comments here, on the Code4Lib (or similar) mailing list, in private correspondence, wherever. If you need letters explaining the importance of releasing code or acknowledging your contribution to the open source community, let me know. If you need further inspiration to follow the open source path, well, I’ll see what I can do.





4 Comments
Other instances include various discussions with people that tend to drift off at the point of “well, I’ll release it when I get a chance to clean it up” or “you know, there are so many institution-specific hard coded things in it”
Tried using your blockquote tags and couldn’t figure them out (and “quote selected text” was making me nutty as well). But wanted to say that in a Former Place Of Work, I lived this life. Open source that isn’t open source, ain’t open source.
Note that “release early, release often” needs to be explained to admin-types in a way that doesn’t mean you’re committing your institution to devoting most of its time to upgrading the same software over and over again.
The quoting scheme uses JavaScript to push the text-to-be-quoted into the comment form. I’ll have to take a look at it to make sure it’s working right. ’salright, though — you got the point across, and that is the point, right?
Thanks for the comment about ‘release early, release often’. I’ll take a small exception to it, though, to say that we should prepare our administrators (and our systems) for small, incremental updates. Much of the software in the library arena is still based on the monolithic release paradigm. We’ve got version 2.0 of the software now, and our vendor just release version 2.1 — it is going to take us a week to reprofile, upgrade the screens, rewrite documentation, prepare staff, etc… Note that the “Web 2.0″ style doesn’t have “releases” per se — there isn’t a big announcement when Amazon, Google, Technorati, Flickr, and the like bring out ‘new versions.’ Stuff just incrementally appears.
That’s a good point, Peter. Maybe the key is to show them that the “sip not gulp” model of upgrading is healthier all around. it does require library staff who can roll with incremental changes… but that’s a training issue as well; wouldn’t you rather learn one small thing a week than 104 every two years? Well, I would
wouldn’t you rather learn one small thing a week than 104 every two years? Well, I would
Hmmm. I think I’m going for the 104 every two years. When the 104 were scheduled, I’d take vacation. By the time I got back the 104 things that were taught would be obsolete anyway.
Post a Comment