4 ms·

Because by sharing your work, especially if you charge money, you’ll start feeling the pressure ... to improve, to support your customers, to react to your comp

Because by sharing your work, especially if you charge money, you’ll start feeling the pressure ... to improve, to support your customers, to react to your competition. This is actually the reason for why many open source developers burn out, even if they aren’t making any money, which is tragic. And you might say that you’ll not fall for it. Well good luck with that. In my experience the minute you share your work with others, that’s when it becomes slightly less fun and it’s all downhill from there.

jfk13 8y ago
> In my experience the minute you share your work with others, that’s when it becomes slightly less fun and it’s all downhill from there. Unfortunately, this is often true -- but there are exceptions. I've had a couple of projects where the experience has been almost entirely positive. There's a lot of satisfaction in seeing that something I designed and created purely to suit my needs has turned out to be used and appreciated by others as well.
madengr 8y ago
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".
- 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

jfk13 8y ago

> In my experience the minute you share your work with others, that’s when it becomes slightly less fun and it’s all downhill from there. Unfortunately, this is often true -- but there are exceptions. I've had a couple of projects where the experience has been almost entirely positive. There's a lot of satisfaction in seeing that something I designed and created purely to suit my needs has turned out to be used and appreciated by others as well.

madengr 8y ago

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