I suggest you ...

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.

91 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Heather PiwowarHeather Piwowar shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous shared a merged idea: The ORCID code can be considered as open source  ·   · 

    19 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • MummiMummi commented  ·   ·  Flag as inappropriate

        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.

      • Mike TaylorMike Taylor commented  ·   ·  Flag as inappropriate

        (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.)

      • Mike TaylorMike Taylor commented  ·   ·  Flag as inappropriate

        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.

      • Geoffrey BilderGeoffrey Bilder commented  ·   ·  Flag as inappropriate

        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 MaloneyChris Maloney commented  ·   ·  Flag as inappropriate

        > 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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 PriemJason Priem commented  ·   ·  Flag as inappropriate

        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!

      • Heather PiwowarHeather Piwowar commented  ·   ·  Flag as inappropriate

        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 PriemJason Priem commented  ·   ·  Flag as inappropriate

        The O in ORCID stands, I'm told, for "open." Until the source code is available...it ain't open.

      • Egon WillighagenEgon Willighagen commented  ·   ·  Flag as inappropriate

        Agreed! "Release soon, release often" works particularly well, when the community can help fix things, and add new features.

      Feedback and Knowledge Base