7 ms·

I have a program I created as a hobby, put on github, then it grew popular enough to need occasional support and updating. Sometimes I wish I did not put it ou

I have a program I created as a hobby, put on github, then it grew popular enough to need occasional support and updating. Sometimes I wish I did not put it out there. It can quickly become work instead of fun; work you are not paid for. Though if you accept donations for it, then you have an obligation to keep it going.

mrfusion 8y ago
Just tell people to make pull requests. There’s nothing wrong with that.
- alistairSH 8y ago
  He still has to review those requests. Depending on the quality of contributor, that might be MORE work!
- Klathmon 8y ago
  Sadly that doesn't work out so well. Just look at the recent npm event-stream debacle for an example. An author didn't really want to deal with a library any more, someone came out and offered to maintain it, the original creator agreed and moved things over, and the new author added exploits to the code. Most of HN and other social media was lambasting the original creator for doing something so "careless". Many people wanted them to just shut it down when they were done with it, others wanted them to more carefully vet potential maintainers, still others said that shutting the project down would be irresponsible as there could be vulnerabilities found that need to be fixed. There really isn't a right answer, and with how social media sites feel these days with witch hunts and outrage flying around everywhere, I personally have shied away from open sourcing a few tools that I've created simply because I don't have the time or care to maintain them. The last thing I want is "social media" to collectively decide that I've made terrible mistakes that no sane programmer would ever make in their code, and that I deserve to never work in this industry again.
  - swiley 8y ago
    >Most of HN I'm part of HN, my general attitude here is that the maintainers of the consuming software are at fault. If you have so many dependencies (especially in javascript, hah) that you can't keep track of what's happening with them then either your scope is too big or you're just carelessly glueing things together because you can't be bothered to build sane things on your own. I understand using things like jasmine and one or two other big things, but at that point those big things are critical components of what you've built and you need to be paying close attention to them for the duration that you're responsible for the maintenance of the code. TL;DR: the fault is with the consumers for being careless, not the people who actually put work in.
    - Klathmon 8y ago
      But you can't hope to watch every dependency of every dependency of every dependency all the way down, at some point you need to trust that the code will do what it says. Dependencies don't just end at a package.json. Their dependencies matter, as do theirs. The C++ code use in the javascript engine is a dependency, as is the python code they use during the build process, which itself relies on Python and their interpreter, which is again more C code, which means you need a compiler, which also has a large suite of dependencies and relies on an OS to provide many things, which themselves rely on more compilers and eventually machine code that should be consumed correctly, and that depends on the microcode running in the CPU to be created correctly and without any vulnerabilities. Of course that microcode is generated using more higher-level code, and the cycle continues. You literally can't check everything, and I'd argue that you can't even check more than 2 steps out from your own code realistically. That's not to say you shouldn't try, but you can't just pretend that it's the fault of the consuming dev that they got exploited just like you can't pretend that it's the fault of the original creator of the code who doesn't want to maintain it any more. These things are going to happen, and I think we would all be better off if we just accepted that, stopped trying to place blame on a specific person or group, and instead continue working on making it harder to accomplish those bad things. Otherwise we get into a situation where "the only winning move is not to play".
      - 8y ago
latexr 8y ago
> Sometimes I wish I did not put it out there. You can always take it down or disable issues[1]. > Though if you accept donations for it, then you have an obligation to keep it going. You most certainly do not. In the same place you ask for donations, make it clear they’re for people to thank you for the work you already put into it, not to “buy” future work time. If you don’t want to work on a feature, say “no”. If a user acts entitled, explain (tip: keep a non-confrontational text snippet ready) that you’ve developed the software in your free time and are under no obligation to fix other people’s bugs; when you do, it’s because you want to. Lock the thread if need be. Does the user come back to open another issue, guns blazing? Block them. I spend hours every day on open-source. I’ve learnt that most users are reasonable and can take a “no” if you add a “because”. It does not have to be the soul-wrenching experience many maintainers make it out to be. [1]: https://help.github.com/en/articles/disabling-issues https://help.github.com/en/articles/disabling-issues

mrfusion 8y ago

Just tell people to make pull requests. There’s nothing wrong with that.

alistairSH 8y ago
He still has to review those requests. Depending on the quality of contributor, that might be MORE work!
Klathmon 8y ago
Sadly that doesn't work out so well. Just look at the recent npm event-stream debacle for an example. An author didn't really want to deal with a library any more, someone came out and offered to maintain it, the original creator agreed and moved things over, and the new author added exploits to the code. Most of HN and other social media was lambasting the original creator for doing something so "careless". Many people wanted them to just shut it down when they were done with it, others wanted them to more carefully vet potential maintainers, still others said that shutting the project down would be irresponsible as there could be vulnerabilities found that need to be fixed. There really isn't a right answer, and with how social media sites feel these days with witch hunts and outrage flying around everywhere, I personally have shied away from open sourcing a few tools that I've created simply because I don't have the time or care to maintain them. The last thing I want is "social media" to collectively decide that I've made terrible mistakes that no sane programmer would ever make in their code, and that I deserve to never work in this industry again.
- swiley 8y ago
  >Most of HN I'm part of HN, my general attitude here is that the maintainers of the consuming software are at fault. If you have so many dependencies (especially in javascript, hah) that you can't keep track of what's happening with them then either your scope is too big or you're just carelessly glueing things together because you can't be bothered to build sane things on your own. I understand using things like jasmine and one or two other big things, but at that point those big things are critical components of what you've built and you need to be paying close attention to them for the duration that you're responsible for the maintenance of the code. TL;DR: the fault is with the consumers for being careless, not the people who actually put work in.
  - Klathmon 8y ago
    But you can't hope to watch every dependency of every dependency of every dependency all the way down, at some point you need to trust that the code will do what it says. Dependencies don't just end at a package.json. Their dependencies matter, as do theirs. The C++ code use in the javascript engine is a dependency, as is the python code they use during the build process, which itself relies on Python and their interpreter, which is again more C code, which means you need a compiler, which also has a large suite of dependencies and relies on an OS to provide many things, which themselves rely on more compilers and eventually machine code that should be consumed correctly, and that depends on the microcode running in the CPU to be created correctly and without any vulnerabilities. Of course that microcode is generated using more higher-level code, and the cycle continues. You literally can't check everything, and I'd argue that you can't even check more than 2 steps out from your own code realistically. That's not to say you shouldn't try, but you can't just pretend that it's the fault of the consuming dev that they got exploited just like you can't pretend that it's the fault of the original creator of the code who doesn't want to maintain it any more. These things are going to happen, and I think we would all be better off if we just accepted that, stopped trying to place blame on a specific person or group, and instead continue working on making it harder to accomplish those bad things. Otherwise we get into a situation where "the only winning move is not to play".
    - 8y ago

latexr 8y ago

> Sometimes I wish I did not put it out there. You can always take it down or disable issues[1]. > Though if you accept donations for it, then you have an obligation to keep it going. You most certainly do not. In the same place you ask for donations, make it clear they’re for people to thank you for the work you already put into it, not to “buy” future work time. If you don’t want to work on a feature, say “no”. If a user acts entitled, explain (tip: keep a non-confrontational text snippet ready) that you’ve developed the software in your free time and are under no obligation to fix other people’s bugs; when you do, it’s because you want to. Lock the thread if need be. Does the user come back to open another issue, guns blazing? Block them. I spend hours every day on open-source. I’ve learnt that most users are reasonable and can take a “no” if you add a “because”. It does not have to be the soul-wrenching experience many maintainers make it out to be. [1]: https://help.github.com/en/articles/disabling-issues https://help.github.com/en/articles/disabling-issues