7 ms·

I don't think the author made a compelling argument as to why open-sourcing his code led to the problems he describes. It sounds like having the code open sourc

I don't think the author made a compelling argument as to why open-sourcing his code led to the problems he describes. It sounds like having the code open sourced took too much of his time away since it allowed people to make requests for things. But I don't see why that means he necessarily has to take time to fulfill the requests. Sounds like he was too focused in one area of his project, and needed to take a step back to get a broader view of the state of things. I'm not convinced the closed/open source nature of his code is responsible for that.

mooreds 6y ago
I think his point was that folks who participate in open source have higher demands for changes and support. If a business is pure SaaS only with no open source code behind it, there is less interaction in general. I'm sure there's still support tickets and whatnot, but there's not the same level of "please fix this" requests. People just move on from commercial packages if they don't do what they need, in my experience. From the post: > In the past, when it came to running a business as a solo-founder, having it open source created too much maintenance burden for very specific feature requests. In particular from non-paying users, who sometimes sent me emails directly, demanding I look at their issue, or help them fix things “as soon as possible”. This lack of interaction is both a feature (lets you focus, you have time to take care of paying users) and a bug (less interaction means you could build the wrong thing, the source is no longer a marketing mechanism for you).
- Jaygles 6y ago
  Right, I agree with you, but as I said > It sounds like having the code open sourced took too much of his time away since it allowed people to make requests for things. But I don't see why that means he necessarily has to take time to fulfill the requests. The existence of the interactions doesn't necessitate engaging with them. If engaging with interactions is taking too much time away, one could simply, not engage with them.
  - mooreds 6y ago
    > The existence of the interactions doesn't necessitate engaging with them. If engaging with interactions is taking too much time away, one could simply, not engage with them. Sure, I get it, everyone needs to prioritize. But if you are ignoring interactions on your OSS project, you can expect more, oh, I'll call it 'heat'. I have seen those github issue threads, where people get frustrated because someone hasn't engaged. So if you aren't going to engage, why open source it? Sure, there are other reasons, but the community feedback loop is a crucial part of the value of OSS for building a business. Also, I get there's nuance and you can choose to engage when there's been a certain level of commitment from the community (a number of upvotes is what my current company uses to help prioritize efforts), but for a solo founder it can be really hard to prioritize, and the author apparently found all the requests a distraction. His choice, but I sympathize.
    - Jaygles 6y ago
      There's certainly value in engaging with the community through the open sourced code. In the end its all a balancing act and getting it right is the hard part. I'm not trying to claim to know how much effort should be going in each aspect. If I did, I'd be running a successful business right about now.
    - bachmeier 6y ago
      > Sure, I get it, everyone needs to prioritize. But if you are ignoring interactions on your OSS project, you can expect more, oh, I'll call it 'heat'. I have seen those github issue threads, where people get frustrated because someone hasn't engaged. Companies selling non-OSS products get slammed with requests on a large scale and they have to deal with them somehow. Todoist immediately comes to mind. I mean, sure, it's possible that some users of a paid product will conclude you don't know what you're doing and take their business elsewhere, but that's kind of like boasting about fixing your broken finger by cutting off your arm.
      - brobdingnagians 6y ago
        I think the key thing is whether the people making the feature requests are paying you. We get feature requests all the time, but they are the people paying us thousands of dollars, so those take priority. If they aren't, or it doesn't appear that anyone else paying us will use it, then they shouldn't take priority. This is a way of whittling down what is really valuable to people, rather than just they took long enough to write an email about a cool thing they really think you should do.
serial_dev 6y ago
Exactly, I think people misunderstand what open source means. Open source doesn't mean that you need to provide hours of free support to someone who couldn't even bother to write a proper issue description. For a matter of fact, you don't even need to provide free support to anyone, no matter how nice they are and no matter how well they written the issue You can help them, but you don't have to. You also don't need to accept pull requests: if you think that the feature doesn't make sense or the code quality is terrible, or it's just not important to you, you don't need to accept pull requests. You also don't need to bend over backwards to maintain a stabile API. It makes your life easier if you communicate this in the README of the package, tell people that it's the early days of the product, you develop in the open, but you aren't going to abide by other people's unrealistic expectations about your open source work.
- Qwertious 6y ago
  >Exactly, I think people misunderstand what open source means. "Misunderstand" implies there's some authoritative definition on "open source" means here. I remember people considering Dasura "not open source" even though it was GPLv2, simply because they didn't accept patches and only threw code over the wall. To a lot of people, open source means engaging on Github. You can say "they're wrong", but that's just disagreement.
- ipaddr 6y ago
  I find just throwing code into github is my perfect level of open sourcing. It's public and I can pull the code into any project. No pesky user requests or stars. Accepting pull requests on smaller projects seems strange. If I wrote this why do I want someone else sharing credit.
j_san 6y ago
While it's technically not open-sourcing code itself it's human nature in my opinion. As a founder you want to support and don't upset your customers, even if they are using the free version of your product. Yes, you could simply not fulfill these requests or not help these customers, but I think for most people it will still introduce stress. There may be people who can deal easily with this, but I think it's natural to be stressed by this and run after things that you shouldn't. Still I agree that it's probably possible to open-source without these problems and that this is not a complete compelling argument for every case. For me personally at least not open-sourcing at the beginning (like the author did) would probably be preferred as well for a solo-founded project.
- KajMagnus 6y ago
  > I think for most people it will still introduce stress [... ] run after things that you shouldn't. I think so too. There's personality trait that I wonder if it is related to this: Agreeable vs Assertive, in the Big 5 personality traits, (Actually I wrote a sibling reply (sibling to yours) and mentioned this, here: https://news.ycombinator.com/item?id=26433328 https://news.ycombinator.com/item?id=26433328 hmm maybe it'd been better if I had replied to you instead :- ) didn't see your reply until now though.)
jandrewrogers 6y ago
My experience is strongly aligned with the author's. There is a substantial real-world overhead associated with open sourcing code, all other things being equal. This overhead is imposed on you whether you want it or not. If you are operating in a resource constrained environment, like the author, then not open sourcing is a sensible cost containment measure. Open sourcing code is a luxury for those with ample time or money. I have code I could open source (e.g. some very useful Postgres extensions created for a company) but I value my time more, and I know many others that view the calculus similarly. There is value in open sourcing code but we should be honest about the associated costs and not pretend they don't exist.
- mixmastamyk 6y ago
  I'd tend to agree for a small package. But, this was a company with a community (according to author). Pointing requests to the paid support page would turn lemons into lemonade. We can only speculate why this didn't happen.
- 3np 6y ago
  Shat kind of overhead do you mean, exactly? You could just push it to a public repo on GH/GL/whatever, and then choose your own level of involvement? You don’t have to engage or even provide a means of contact.
  - mkj 6y ago
    Github doesn't allow disabling pull requests, so there's always that means of contact.
    - 3np 6y ago
      Right, I think this can be done in GitLab though, if one doesn't want to self-host?
KajMagnus 6y ago
> I'm not convinced the closed/open source nature of his code is responsible for that Could that depend on the personality traits of the solo founder? What if it's in some people's nature, to feel bad about rejecting make-sense feature request and bug fixes, in order to instead focus on money making things? (Even if logically it'd be the long term good thing to do.) Whilst someone else might have felt just fine, doing that? If you know about the Big 5 personality traits, maybe this is related to where you are, in the Agreeable vs Assertive dimension. For someone who is more Agreeable, then, keeping the SaaS closed source, might be the way to go — so there simply won't be any unsupported platform installation problems to ignore but feel bad about.

mooreds 6y ago

I think his point was that folks who participate in open source have higher demands for changes and support. If a business is pure SaaS only with no open source code behind it, there is less interaction in general. I'm sure there's still support tickets and whatnot, but there's not the same level of "please fix this" requests. People just move on from commercial packages if they don't do what they need, in my experience. From the post: > In the past, when it came to running a business as a solo-founder, having it open source created too much maintenance burden for very specific feature requests. In particular from non-paying users, who sometimes sent me emails directly, demanding I look at their issue, or help them fix things “as soon as possible”. This lack of interaction is both a feature (lets you focus, you have time to take care of paying users) and a bug (less interaction means you could build the wrong thing, the source is no longer a marketing mechanism for you).

Jaygles 6y ago
Right, I agree with you, but as I said > It sounds like having the code open sourced took too much of his time away since it allowed people to make requests for things. But I don't see why that means he necessarily has to take time to fulfill the requests. The existence of the interactions doesn't necessitate engaging with them. If engaging with interactions is taking too much time away, one could simply, not engage with them.
- mooreds 6y ago
  > The existence of the interactions doesn't necessitate engaging with them. If engaging with interactions is taking too much time away, one could simply, not engage with them. Sure, I get it, everyone needs to prioritize. But if you are ignoring interactions on your OSS project, you can expect more, oh, I'll call it 'heat'. I have seen those github issue threads, where people get frustrated because someone hasn't engaged. So if you aren't going to engage, why open source it? Sure, there are other reasons, but the community feedback loop is a crucial part of the value of OSS for building a business. Also, I get there's nuance and you can choose to engage when there's been a certain level of commitment from the community (a number of upvotes is what my current company uses to help prioritize efforts), but for a solo founder it can be really hard to prioritize, and the author apparently found all the requests a distraction. His choice, but I sympathize.
  - Jaygles 6y ago
    There's certainly value in engaging with the community through the open sourced code. In the end its all a balancing act and getting it right is the hard part. I'm not trying to claim to know how much effort should be going in each aspect. If I did, I'd be running a successful business right about now.
  - bachmeier 6y ago
    > Sure, I get it, everyone needs to prioritize. But if you are ignoring interactions on your OSS project, you can expect more, oh, I'll call it 'heat'. I have seen those github issue threads, where people get frustrated because someone hasn't engaged. Companies selling non-OSS products get slammed with requests on a large scale and they have to deal with them somehow. Todoist immediately comes to mind. I mean, sure, it's possible that some users of a paid product will conclude you don't know what you're doing and take their business elsewhere, but that's kind of like boasting about fixing your broken finger by cutting off your arm.
    - brobdingnagians 6y ago
      I think the key thing is whether the people making the feature requests are paying you. We get feature requests all the time, but they are the people paying us thousands of dollars, so those take priority. If they aren't, or it doesn't appear that anyone else paying us will use it, then they shouldn't take priority. This is a way of whittling down what is really valuable to people, rather than just they took long enough to write an email about a cool thing they really think you should do.

serial_dev 6y ago

Exactly, I think people misunderstand what open source means. Open source doesn't mean that you need to provide hours of free support to someone who couldn't even bother to write a proper issue description. For a matter of fact, you don't even need to provide free support to anyone, no matter how nice they are and no matter how well they written the issue You can help them, but you don't have to. You also don't need to accept pull requests: if you think that the feature doesn't make sense or the code quality is terrible, or it's just not important to you, you don't need to accept pull requests. You also don't need to bend over backwards to maintain a stabile API. It makes your life easier if you communicate this in the README of the package, tell people that it's the early days of the product, you develop in the open, but you aren't going to abide by other people's unrealistic expectations about your open source work.

Qwertious 6y ago
>Exactly, I think people misunderstand what open source means. "Misunderstand" implies there's some authoritative definition on "open source" means here. I remember people considering Dasura "not open source" even though it was GPLv2, simply because they didn't accept patches and only threw code over the wall. To a lot of people, open source means engaging on Github. You can say "they're wrong", but that's just disagreement.
ipaddr 6y ago
I find just throwing code into github is my perfect level of open sourcing. It's public and I can pull the code into any project. No pesky user requests or stars. Accepting pull requests on smaller projects seems strange. If I wrote this why do I want someone else sharing credit.

j_san 6y ago

While it's technically not open-sourcing code itself it's human nature in my opinion. As a founder you want to support and don't upset your customers, even if they are using the free version of your product. Yes, you could simply not fulfill these requests or not help these customers, but I think for most people it will still introduce stress. There may be people who can deal easily with this, but I think it's natural to be stressed by this and run after things that you shouldn't. Still I agree that it's probably possible to open-source without these problems and that this is not a complete compelling argument for every case. For me personally at least not open-sourcing at the beginning (like the author did) would probably be preferred as well for a solo-founded project.

KajMagnus 6y ago
> I think for most people it will still introduce stress [... ] run after things that you shouldn't. I think so too. There's personality trait that I wonder if it is related to this: Agreeable vs Assertive, in the Big 5 personality traits, (Actually I wrote a sibling reply (sibling to yours) and mentioned this, here: https://news.ycombinator.com/item?id=26433328 https://news.ycombinator.com/item?id=26433328 hmm maybe it'd been better if I had replied to you instead :- ) didn't see your reply until now though.)

jandrewrogers 6y ago

My experience is strongly aligned with the author's. There is a substantial real-world overhead associated with open sourcing code, all other things being equal. This overhead is imposed on you whether you want it or not. If you are operating in a resource constrained environment, like the author, then not open sourcing is a sensible cost containment measure. Open sourcing code is a luxury for those with ample time or money. I have code I could open source (e.g. some very useful Postgres extensions created for a company) but I value my time more, and I know many others that view the calculus similarly. There is value in open sourcing code but we should be honest about the associated costs and not pretend they don't exist.

mixmastamyk 6y ago
I'd tend to agree for a small package. But, this was a company with a community (according to author). Pointing requests to the paid support page would turn lemons into lemonade. We can only speculate why this didn't happen.
3np 6y ago
Shat kind of overhead do you mean, exactly? You could just push it to a public repo on GH/GL/whatever, and then choose your own level of involvement? You don’t have to engage or even provide a means of contact.
- mkj 6y ago
  Github doesn't allow disabling pull requests, so there's always that means of contact.
  - 3np 6y ago
    Right, I think this can be done in GitLab though, if one doesn't want to self-host?

KajMagnus 6y ago

> I'm not convinced the closed/open source nature of his code is responsible for that Could that depend on the personality traits of the solo founder? What if it's in some people's nature, to feel bad about rejecting make-sense feature request and bug fixes, in order to instead focus on money making things? (Even if logically it'd be the long term good thing to do.) Whilst someone else might have felt just fine, doing that? If you know about the Big 5 personality traits, maybe this is related to where you are, in the Agreeable vs Assertive dimension. For someone who is more Agreeable, then, keeping the SaaS closed source, might be the way to go — so there simply won't be any unsupported platform installation problems to ignore but feel bad about.