Making Open Source Software Available
Oct 18th, 2007 by Karen
Over at Circulatable in response to my Open Source Software Pet Peeve post Steve ponders
Is it better to release something half-baked, in the hopes that it will be useful, or to keep it purely internal and let someone else solve the problem?
The answer in my opinion is to release the thing and let the community make it better. So many libraries build nifty little applications to solve their own problem but never share the code. So then some other library comes along and builds another system that performs the same functions. This is a waste of resources in my opinion when instead collaboration could be occurring and a single better application to perform the necessary functions created.
In my mind, the Oregon State / UH LibraryFind partnership is an example of this type of collaboration in action. While Oregon State University Libraries bears the burden of classic development. The Web Services department at the UH Libraries has our own contributions. We provide feedback and help out with questions on the listserv. We are working on contributing to the LibraryFind documentation, in the form of collection configuration settings and instructions, and trying to get other vendors to have their systems be compatible with LibraryFind. By working together LibraryFind is getting better.
Our library has also provided feedback on other pieces of open source library software as well. We were an early implementor of Archon and although we haven’t had a chance to migrate to the latest version we provide fairly regular feedback.
The bottom line is if you have a cool tool that fills a niche and you are willing to take responsibility to maintaining it you should get it out there. This is the only way that a true community will form and the tool will get iteratively better over time.
“and you are willing to take responsibility to maintaining it you should get it out there.”
That’s a pretty big “and”. There’s another part though too. I have realized lately that releasing code that other people can config to use locally _without_ changing your code also takes more time. The more typical way libraries do ‘open source’ is I’ll give you my code, and then you’ll hack it to do what you want. But now we each have different codebases, and it becomes difficult to share our improvements with each other, we each are running different ‘forks’. Compare to succesful open source, where everyone runs the same code, but _configures_ it through flexible config to be different.
Anyway, I guess the end point is that, to get the kind of open source that will really benefit our community, it IS more work than just taking what you would have done anyway internally and releasing it. Pretending you can get the real open source benefits for free helps nobody; instead, we need to realize that it does take effort, and that effort needs to be supported, but that effort can result in dividends that make it worthwhile.
Releasing it is a HUGE first step though in my opinion. When say maintain I mean more champion/believe in. One institution can’t bear the support burden forever. Also getting it out there may help make the code more portable (people can config to use locally _without_ changing your code). Not everyone knows how to write code that allows for flexible configuration and getting the code out there may help people get the feedback they need to make the system more portable or perhaps someone else will take on that task and contribute the changes back to the community.
Oops — I was actually the author of that post, not Steve. Circulatable doesn’t make that very clear ;-)
Jonathan: Yup. There’s quite a lot of work involved in making all those changes that localize a product general enough that they’ll make other installers happy. Sometimes we need to apply hacks for our local environment that can’t easily be made general, and it’s hard to know what to do in those cases — do we run a local fork of our own project? That sucks.
Karen: I’ve run into two main hurdles in the “release, and let the community improve things” approach.
First, reviewing, testing, and applying patches takes a nontrivial amount of time. Is this patch of reasonable quality? Do I like what it does? Is it likely to break things for me or someone else?
Secondly, community involvement beyond “This doesn’t work, can you help?” is very rare — I can count the number of submitted patches on one hand. This is not meant as a complaint — getting deeply enough into a project to commit code is a huge investment — but the “build it and the world will contribute” thing Just Does Not Happen.