So, why should LaunchPad (Malone) be open sourced?*
I’m not going to say because other groups need to use the bug tracking/code hosting/question answering/multi-project-resource unifying features. No, I do believe that it wouldn’t make much sense for there to be multiple Launchpads out there dealing with bugs/code/etc (maybe a little of sense, but not much).
That market is already taken by launchpad.net and others (bugzilla, trac, savannah, et. al.)
Ok, so what market am I looking at? Scholarly communication <BORING!>
Not really boring actually. If you haven’t been paying attention to the scholarly communication world lately, let me tell you, a lot is changing. University libraries are spending more and more money every year on electronic journals. The rate of increase for the same product is higher than that of inflation, for a product which doesn’t improve (can we say monopoly/oligopoly?). In response many institutions (university libraries) are beginning to provide competing services. Full disclosure, my current employer is the Scholarly Publishing Office at the University of Michigan where we publish scholarly journals in an online and Open Access fashion. So, we are providing an alternative to the current commercial publisher vendor lock-in.
What does this have to do with LaunchPad and Open Source Software? Well, we are now in a global situation where there are many many many many open access journals and publications out there. There are some services out there than can help you navigate them, like the Directory of Open Access Journals. But, that service only indexes Open Access journals. Plus, there are now these things called Institutional Repositories, which are collections of preprints and articles and data from the “scholars” in a given “institution” (university, research lab, etc).
Then you have the commercial vendors. They don’t like people looking at their stuff, they don’t play nice with others unless they think they will lose money if they don’t. Libraries are getting better and better at letting their patrons search both sets of journals in one place, but the interface ALWAYS is hideous and creates MANY hoops the user has to jump through. In a word, it is LAME.
I haven’t answered what LP has to do with this yet. I’m getting there, I promise.
What does LaunchPad do really well? Linking various bugtrackers so that people can work together more efficiently to solve problems, right? That was the whole goal of Launchpad, otherwise Ubuntu would have stayed with bugzilla. What is the analogue for the scholarly publishing/communication world? You have those many distinct collections of articles (Open Access journals, Institutional Repositories, and commercial vendors) that do not talk to each other, ever. Yes, there are groups out there trying to improve this situation like the Open Archives Initiative where they are setting metadata standards and standards for transferring that information to others. That is a great thing, but it is only a start.
<The Answer, Finally> If we created a LaunchPad for scholarly works, we could solve many of the beginning access issues associated with this crappy situation. Here’s the idea:
Think of a bug, that is the article in this case. The article (bug) can have a published status like draft version or published in a journal (New, Incomplete, Fix Committed). But for it to even be an article in this Scholar’s LP it needs to have a reference to where it is, physically. So instead of a bug originating in LP and then being linked to other trackers as time goes on, the article needs to have an initial link to some place (OA journal, IR, or Comm. Vendor) using some standard like Digital Object Identifier or Handle.net (which assigns a unique id to object online that can point to any address, so the changing of URLs won’t effect findability).
Then, this article (bug) can also have different versions linked to it. So, example: I publish an article in a prestigious journal, Nature, and I’m proud of it. So, I go to the Scholar’s LP and submit a new article. I give it the DOI or handle.net id and it automagically retrieves the metadata from the article’s current place of residence (that is if the provide it, if it is a commercial vendor, I might have to fill it in myself). Then it shows up as a new article in the system. My advisor, who thinks the work I did was cool, thinks that my previous drafts before publication are also pretty good. Since the version in Nature is not available to everyone for free, he links the preprint version that resides in my University’s Institutional Repository to my article. That is just like linking to an upstream bug in LP.
Of course, all the metadata is editable and updatable with information like author(s), publication data, place, copyright status (license), etc etc. Plus, if we wanted, we could limit certain metadata elements (like copyright status) to only the article’s author(s), we can do that by verifying emails with respect to what is in the actual article’s author list.
This Scholar’s LP could provide a wonderful unified interface so that “scholars” (define that however you want) can navigate this crazy mess of publishing easily (or at least easier). The “killer app” part of this is the ability to link a published article which is under crappy copyright restrictions to other versions which are available for everyone via institutional repositories or other places, in one place.
There are plenty of fancy cool things which could be done with this model, and I will talk about those later. One example is automatically linking to works cited to another Scholar’s LP or to an external link. But for now, I just wanted to get this idea out there and see if anyone has any comments.
* yes, you are right, we don’t need LaunchPad to be opensourced to do this, it was just a way to get you to read this, sorry.
Bringing Things Together 