Release ORCID code as open source NOW
ORCID has always planned to release its source openly (MIT license), but hasn't done it yet. This suggestion is to do it *now*, so that many of us can help fix bugs.
The ORCID open source project is now available. You can read more about it at http://about.orcid.org/blog/2013/02/21/orcid-open-source
Mike T and Mike T - dear fellows, why don't you each get one of them, you know, unique watchamacallit, identifers so the rest of us can see who's who? Damn ambiguity is killing me.
Taylor, Michael (ELS-OXF) commented
And this is me.
(Just for the record, the comment two before this one is by me, Michael P. Taylor the open-access advocate, not Mike Taylor the Elsevier guy.)
Christian Pietsch commented
I am surprised that ORCID sources are not open already. Please do not wait until “the site is stabe”.
Having many times made the same coding shortcut as Geoffrey (hardwiring credentials, URLs, etc.) I'm sympathetic to the plea that these need to be factored out into a congfiguration file before the code can be released. We do NOT want a code release that gives away passwords and the like!
That said, it shouldn't be THAT big a deal to fix -- reading the sensitive information from environment variables or similar. I see this as a reason why the code legitimately has not been released yet; but not as a reason to delay more than a day or two more.
Khadijah Britton commented
I agree that there is nothing but good to be gained from opening up the code on GitHub or the like. +1.
Geoffrey Bilder commented
First- FTR, I was involved in the early technical development of ORCID. Having said that, my opinions here are my own and not ORCID's.
I, like most people posting here, think that the earlier ORCID releases the code the better- but not because I am worried about ORCID's commitment to opening the code. I know from experience that the ORCID board was *insistent* that a condition of their accepting the base code from Thomson Reuters (background here-> http://goo.gl/y51aA) was that the code could be open sourced. ORCID probably could have launched the service many months earlier if this hadn't been a pre-condition. The board was absolutely committed to it.
Having said that, I also disagree that opening the code immediately should be the first priority after launch. It isn't just a question of ORCID not being ready to handle community co-development. As many have pointed out, the issues of releasing the code and co-development are entirely separate.
The problem is that releasing the the code does actually require a fair amount of work. ORCID can't just open the existing working Github repo (as has been suggested). For example, they need to have a mechanism for replacing branding, assets, sensitive info (db passwords, encryption salts, etc). And they want to be able to do this automatically and with minimal intervention. In theory, this shouldn't be too hard, but the truth is, in the push to launch the service and due to ORCID's inexperience (read *my* inexperience) developing open source software, a lot of this stuff got hard-wired and so now some work needs to be done to decouple things and make the process of releasing the community code as automatic and efficient as possible. ORCID technical staff is currently *one* person, a few contractors and a handful of volunteers (who's primary role is to give staff & contractors contradictory advice and priorities).
The service has been released for just about a week- it seems entirely reasonable to me that they are focusing on getting the existing service stable, usable and on getting properly staffed *before* turning their attention to refactoring the configuration management code so that they can create a reasonable community release of the system.
Still, I think once the service is stable and they have staff in place to manage the service, they should move as quickly as possible to release the code as per their commitment. I advocate this primarily it will fulfil an important promise and because it will force a better level of engineering and configuration management on the system- not because I doubt the organisation's commitment to openness.
In short, I think releasing the code soon is important. Releasing it "now" would be an unessesary distraction.
Chris Maloney commented
> we do not have the structure in place to support community co-development of our base code
Just to make it crystal clear: that's not what Heather or the others are asking for here. Presumably, you use version control in-house. Putting the code into the open, as they're asking for, would only entail moving the version-control system to some open platform platform. GitHub would be great, but there are others that are just as good (if you don't like git).
The only cost is that your developers would have to spend about a day, maybe, on average, installing git, creating accounts and learning the basic commands, and then uploading the code. It really is very simple. You would retain all the control over who can make changes to the code. As others have suggested, you might be pleasantly surprised that you get some "pull requests" that solve problems you don't have time for, or even for things you never thought of.
What distinguishes ORCID from other author identifiers, if it isn't open? Without the community the whole thing is doomed, and without open code you won't build community.
Jason Priem commented
Laure, thanks for responding. I certainly undersand that y'all are in active development right now and don't want to spend time on a bunch of documentation and questions from well-meaning but distracting contributors.
That said, there is a BIG difference between opening your source and supporting and community development. You don't have to be ready for the latter to embrace the former. Opening the source code makes a commitment to openness. Now. Not in the hazy, maybe, wouldn't-it-be-nice future.
"We'll make it open one of these days" send a very strong message to potential users and developers about ORCID's commitment to openness, and it's not an encouraging one. it says that openness is not a priority. That makes me really sad, because I want to give ORCID my full support.
But as long as the source code is proprietary and hidden, I (and I think a lot of like-minded folks) can't do that.
Don't fix the ugly bits. Don't add documentation. Don't support external devs. It's early; no one is going to fault you for that stuff at this stage. But please make a solid commitment to actually being open by releasing your code under an open license. Thanks!
That's a big ol' +1 from me.
William Denton commented
Heather Piwowar commented
Laure, I appreciate that co-development is a different type of work and now may not be the time to make that move. That said, there is a spectrum between co-development and the-community-cant-help-at-all: once your code is open you may find that accepting some pull-requests for bugs and features on ORCID's todo list is worthwhile.
I do hope you plan to make it "working open" on GitHub and not just a periodic upload, so that both ORCID and the community can fully realize the benefits.
Jason Priem commented
The O in ORCID stands, I'm told, for "open." Until the source code is available...it ain't open.
David Jay commented
I'd be interested in plugging in!
Marcus D. Hanwell commented
Couldn't agree more with Egon, release soon (or early), release often!
Heather Piwowar commented
See @orcid_org's commitment to releasing its software as open source in ORCID's awesome Principles, #8: http://about.orcid.org/about/what-is-orcid/our-principles.
Scott Chamberlain commented
Yes, agreed agreed!
Egon Willighagen commented
Agreed! "Release soon, release often" works particularly well, when the community can help fix things, and add new features.