5 ms·

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 fo

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.
- sodality2 6y ago
  >So if you aren't going to engage, why open source it? I'd argue engagement is only a medium part of open source: plenty of projects publish code and never accept requests/issues, and are very popular. It is always nice to open source even if you don't accept PR's/review issues, because it gives me more trust.
  - mooreds 6y ago
    So the main benefit of OSS you see is promoting trust in the company building the open source software? I'm sure there are plenty of blog posts out there, but I can see the following benefits: * marketing halo ("we do open source") * community feedback, both bugs and features * community contributions * trust in the company * trust in continuity of the product (even if the company fails, I can continue to run this product) * cost As I said, I'm sure there are more, I'm not experienced enough to weigh them all, and I'm guessing they vary based on the size, stage and goals of the company. That said, feedback from the community does seem pretty important to me.
- pwdisswordfish0 6y ago
  You're conflating open source software, which is any software published under an OSS license, with an open development model. (Not to mention the assumption that "open source" automatically means publishing to GitHub—it doesn't.) Apple, for example, publishes a ton of stuff over at opensource.apple.com. But the majority of it is stuff thrown over the wall, and not attached to a community that has to be actively managed. The insistence on confusing these things for other people is perhaps one of the biggest threats to open source.
  - mooreds 6y ago
    Fair. Would you say that the author of the post was speaking about the issues with an open development model? That's a great distinction as there are companies out there doing open development who may have a closed source product.
    - yw3410 6y ago
      Yes; but you have to remember that git forges like GitHub and Gitlab push you towards that the open development model with their defaults.
dwohnitmok 6y ago
> If engaging with interactions is taking too much time away, one could simply, not engage with them. This choice isn't always as simple as it sounds. There is, strange as it is, a real reputational risk to be known as a disengaged open source maintainer. It's a real PR risk to have a demanding open source user who personally emails you then takes to Twitter to denounce the project if you don't engage. It's also definitely a risk for a paid, proprietary project too, but for some reason it doesn't seem to happen as often.
- Jaygles 6y ago
  I agree, I just phrased it as a black and white thing as a way of trying to make the point I was making more clear. There's nuance in all things.
  - dwohnitmok 6y ago
    Sure, but then I think mooreds comment is a convincing rebuttal of > 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. It's not that the author was overly focused on one thing. It was just that he didn't want to pay the cost.
    - Jaygles 6y ago
      That's fair, I was making some assumptions when making that statement. Maybe a better point to make would be that he was overly prioritizing one aspect over others.
      - dwohnitmok 6y ago
        > overly Again I think this is an unfair characterization of the author's point. All that being said, I think your original point, that you can have open source without engagement and minimal PR risk, is doable on reflection, you just need to break away from the usual open source mould. So e.g. that means not using GitHub, GitLab, Sourcehut, etc. to host your code. Instead just provide a contact method that customers can use to request code on demand such as an email address or mailing address. Minimize any other contact surface area and enforce trademark heavily so that any users re-uploading the code to other sites must change the name. Basically make sure to hide the official open source channel away from non-paying users. At that point it's another interesting question whether it's still worth it to the author to go open source (since you're giving up most of the stated commercial benefits of open source, especially those surrounding reputation), but it's a way of minimizing the reputational risk of non-engagement. And of course sometimes you may judge the reputational risk to be acceptable.
evanelias 6y ago
This makes sense for feature requests, but not always for other types of support. When a user opens an issue, sometimes it can be very time-consuming just to determine whether the user is encountering a legitimate edge-case bug, vs the user doing something wrong and not reporting it accurately. This type of issue can't be ignored entirely, because if it's a legit bug, then it's present in the paid SaaS product as well. Also consider that many GitHub accounts don't mention real names or company affiliations. It can be hard to tell whether an issue submitter is some rando or a loyal paying customer. Even if you have a separate bug tracker or support system for paying customers, some of them will submit issues to the open source project by mistake.
- musingsole 6y ago
  Given the response times to bugs by paid teams compelled on threat of terminated employment to implement fixes for things...an open source maintainer absolutely could ignore even critical bugs. I've seen many maintainers whinging about the demands of communities on their time. But it's all 'choose-your-level-of-involvement'. Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be.
  - evanelias 6y ago
    > an open source maintainer absolutely could ignore even critical bugs If the maintainer is a solopreneur, whose source of income is a paid SaaS version of the open source project, then no they typically cannot ignore critical bugs. > Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be. Out of curiosity have you ever maintained a decently popular single-primary-maintainer open source project? How about one with a SaaS or commercial version? Frequent frustrating interactions with users isn't exactly beneficial to one's sense of motivation, at least in my experience (which mirrors the original article quite closely).
    - musingsole 6y ago

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.
sodality2 6y ago
>So if you aren't going to engage, why open source it? I'd argue engagement is only a medium part of open source: plenty of projects publish code and never accept requests/issues, and are very popular. It is always nice to open source even if you don't accept PR's/review issues, because it gives me more trust.
- mooreds 6y ago
  So the main benefit of OSS you see is promoting trust in the company building the open source software? I'm sure there are plenty of blog posts out there, but I can see the following benefits: * marketing halo ("we do open source") * community feedback, both bugs and features * community contributions * trust in the company * trust in continuity of the product (even if the company fails, I can continue to run this product) * cost As I said, I'm sure there are more, I'm not experienced enough to weigh them all, and I'm guessing they vary based on the size, stage and goals of the company. That said, feedback from the community does seem pretty important to me.
pwdisswordfish0 6y ago
You're conflating open source software, which is any software published under an OSS license, with an open development model. (Not to mention the assumption that "open source" automatically means publishing to GitHub—it doesn't.) Apple, for example, publishes a ton of stuff over at opensource.apple.com. But the majority of it is stuff thrown over the wall, and not attached to a community that has to be actively managed. The insistence on confusing these things for other people is perhaps one of the biggest threats to open source.
- mooreds 6y ago
  Fair. Would you say that the author of the post was speaking about the issues with an open development model? That's a great distinction as there are companies out there doing open development who may have a closed source product.
  - yw3410 6y ago
    Yes; but you have to remember that git forges like GitHub and Gitlab push you towards that the open development model with their defaults.

dwohnitmok 6y ago

> If engaging with interactions is taking too much time away, one could simply, not engage with them. This choice isn't always as simple as it sounds. There is, strange as it is, a real reputational risk to be known as a disengaged open source maintainer. It's a real PR risk to have a demanding open source user who personally emails you then takes to Twitter to denounce the project if you don't engage. It's also definitely a risk for a paid, proprietary project too, but for some reason it doesn't seem to happen as often.

Jaygles 6y ago
I agree, I just phrased it as a black and white thing as a way of trying to make the point I was making more clear. There's nuance in all things.
- dwohnitmok 6y ago
  Sure, but then I think mooreds comment is a convincing rebuttal of > 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. It's not that the author was overly focused on one thing. It was just that he didn't want to pay the cost.
  - Jaygles 6y ago
    That's fair, I was making some assumptions when making that statement. Maybe a better point to make would be that he was overly prioritizing one aspect over others.
    - dwohnitmok 6y ago
      > overly Again I think this is an unfair characterization of the author's point. All that being said, I think your original point, that you can have open source without engagement and minimal PR risk, is doable on reflection, you just need to break away from the usual open source mould. So e.g. that means not using GitHub, GitLab, Sourcehut, etc. to host your code. Instead just provide a contact method that customers can use to request code on demand such as an email address or mailing address. Minimize any other contact surface area and enforce trademark heavily so that any users re-uploading the code to other sites must change the name. Basically make sure to hide the official open source channel away from non-paying users. At that point it's another interesting question whether it's still worth it to the author to go open source (since you're giving up most of the stated commercial benefits of open source, especially those surrounding reputation), but it's a way of minimizing the reputational risk of non-engagement. And of course sometimes you may judge the reputational risk to be acceptable.

evanelias 6y ago

This makes sense for feature requests, but not always for other types of support. When a user opens an issue, sometimes it can be very time-consuming just to determine whether the user is encountering a legitimate edge-case bug, vs the user doing something wrong and not reporting it accurately. This type of issue can't be ignored entirely, because if it's a legit bug, then it's present in the paid SaaS product as well. Also consider that many GitHub accounts don't mention real names or company affiliations. It can be hard to tell whether an issue submitter is some rando or a loyal paying customer. Even if you have a separate bug tracker or support system for paying customers, some of them will submit issues to the open source project by mistake.

musingsole 6y ago
Given the response times to bugs by paid teams compelled on threat of terminated employment to implement fixes for things...an open source maintainer absolutely could ignore even critical bugs. I've seen many maintainers whinging about the demands of communities on their time. But it's all 'choose-your-level-of-involvement'. Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be.
- evanelias 6y ago
  > an open source maintainer absolutely could ignore even critical bugs If the maintainer is a solopreneur, whose source of income is a paid SaaS version of the open source project, then no they typically cannot ignore critical bugs. > Those people clamoring for attention may be annoyed and frustrated with you, but that doesn't answer the question as to why that's a problem unless you choose for it to be. Out of curiosity have you ever maintained a decently popular single-primary-maintainer open source project? How about one with a SaaS or commercial version? Frequent frustrating interactions with users isn't exactly beneficial to one's sense of motivation, at least in my experience (which mirrors the original article quite closely).
  - musingsole 6y ago