4 ms·

Argh, this article is going to give researchers the misleading impression that releasing code as open-source is complicated, that you need to maintain it, ask y

by a3_nm 7y ago

Argh, this article is going to give researchers the misleading impression that releasing code as open-source is complicated, that you need to maintain it, ask yourself difficult questions, be an expert in programming, find funding to keep it around, etc. But in my field, in most cases the source code is never released at all. That's a far bigger problem that not having support to use it. So fellow academics, please don't use this article as an excuse to not release your code. When in doubt, just push the thing to Gitlab as is, add a README that says "This is research code for paper X and it is unmaintained.", and disappear. It's not ideal, it's not the best way to do science -- but it's much better than not releasing your code. Related: the CRAPL http://matt.might.net/articles/crapl/ http://matt.might.net/articles/crapl/

_dps 7y ago
> But in my field, in most cases the source code is never released at all. That's a far bigger problem that not having support to use it. I agree but I think it's good for people to know that almost any moderately successful open project will attract whiners, complainers, entitled people, and in some cases outright abuse. From the perspective of society, having no open code is worse than having open code that's unmaintained. We're agreed here. From an individual contributor's perspective, opening yourself up to varying forms of whining and abuse "for the social good" (and not, say, for your tenure or publication count or whatever a researcher cares about in the moment) is a bigger problem than just sitting quietly on stuff you don't want to become a drain on your life.
- Bakary 7y ago
  What exactly are the whiners going to do if you just ignore them?
  - _dps 7y ago
    Leaving aside the outright abusive, probably nothing. But how excited would you be to receive in your inbox "Your [beloved project] didn't solve my pet problem the way I wanted! This software sucks and the devs are lazy bastards who don't listen to the community". Then imagine getting one of these a month, a week, even a day if your project is very successful. It's of course nothing like actual abuse or threats of violence but it's an emotional toll that I certainly wouldn't want to pay. I have better things to do with my life.
    - exolymph 7y ago
      Publish the repo and then immediately archive it. The code is out there but people won't be able to leave issues, comments, etc.
  - krageon 7y ago
    If you use an online presence that is traceable across the internet, some subset of them will bother you everywhere or decide to make your life miserable when you ignore them. As such, anything that can remotely be seen as connected to you with any longevity is best put online without your name and with a throwaway nickname. Given that precaution, nothing! Sadly a lot of people don't take this precaution.
    - zrobotics 7y ago
      If the code is released anonymously, what good is it though (in the context of research code)? Ideally it should be connected to the paper to allow for replication, and what academic would want to release a paper anonymously?
      - krageon 7y ago
        I think we agree then that releasing code connected to a paper is something I wouldn't recommend anyone actually do, even if I do like it when it does happen :)
slavik81 7y ago
Note that the CRAPL license is not an open source license. It is extremely restrictive about what you can do with the code. It doesn't even give you permission to share the code with anyone else. It's also poor for people distributing code under the license. It jokes about how the program was constructed without thought or design, but that's the very basis of the program's copyright protection. If you ever try to enforce the license, you might regret having to spend time arguing the implications of that joke in court. Nobody should ever use CRAPL. Use the MIT or GPL licenses and set expectations for maintenance or support to zero in the README as you said. Previous discussion: https://news.ycombinator.com/item?id=9670497 https://news.ycombinator.com/item?id=9670497

by a3_nm 7y ago

_dps 7y ago

> But in my field, in most cases the source code is never released at all. That's a far bigger problem that not having support to use it. I agree but I think it's good for people to know that almost any moderately successful open project will attract whiners, complainers, entitled people, and in some cases outright abuse. From the perspective of society, having no open code is worse than having open code that's unmaintained. We're agreed here. From an individual contributor's perspective, opening yourself up to varying forms of whining and abuse "for the social good" (and not, say, for your tenure or publication count or whatever a researcher cares about in the moment) is a bigger problem than just sitting quietly on stuff you don't want to become a drain on your life.

Bakary 7y ago
What exactly are the whiners going to do if you just ignore them?
- _dps 7y ago
  Leaving aside the outright abusive, probably nothing. But how excited would you be to receive in your inbox "Your [beloved project] didn't solve my pet problem the way I wanted! This software sucks and the devs are lazy bastards who don't listen to the community". Then imagine getting one of these a month, a week, even a day if your project is very successful. It's of course nothing like actual abuse or threats of violence but it's an emotional toll that I certainly wouldn't want to pay. I have better things to do with my life.
  - exolymph 7y ago
    Publish the repo and then immediately archive it. The code is out there but people won't be able to leave issues, comments, etc.
- krageon 7y ago
  If you use an online presence that is traceable across the internet, some subset of them will bother you everywhere or decide to make your life miserable when you ignore them. As such, anything that can remotely be seen as connected to you with any longevity is best put online without your name and with a throwaway nickname. Given that precaution, nothing! Sadly a lot of people don't take this precaution.
  - zrobotics 7y ago
    If the code is released anonymously, what good is it though (in the context of research code)? Ideally it should be connected to the paper to allow for replication, and what academic would want to release a paper anonymously?
    - krageon 7y ago
      I think we agree then that releasing code connected to a paper is something I wouldn't recommend anyone actually do, even if I do like it when it does happen :)

slavik81 7y ago

Note that the CRAPL license is not an open source license. It is extremely restrictive about what you can do with the code. It doesn't even give you permission to share the code with anyone else. It's also poor for people distributing code under the license. It jokes about how the program was constructed without thought or design, but that's the very basis of the program's copyright protection. If you ever try to enforce the license, you might regret having to spend time arguing the implications of that joke in court. Nobody should ever use CRAPL. Use the MIT or GPL licenses and set expectations for maintenance or support to zero in the README as you said. Previous discussion: https://news.ycombinator.com/item?id=9670497 https://news.ycombinator.com/item?id=9670497