4 ms·

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 oth

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.
- Jaygles 6y ago
  Well, in the author's own words... > I was too focused on developing every feature, trying to give support to every single ticket, and I completely ignored the marketing aspects of it as I had no time for it. Saying the author was overly prioritizing responding to the communications that open sourcing the code allowed to come through shouldn't be controversial. He himself is admitting to it. My main point is that the author hasn't convinced me that blame should be placed on open sourcing the code. To me that's akin to blaming the messenger. He should instead be looking to why he felt obligated to spend the time supporting "every single ticket", when he himself knew that he was neglecting other aspects of the business side of things.
  - dwohnitmok 6y ago
    I don't think the author is using "too focused" in the way you're saying that "he was overly prioritizing one aspect over others." Your contention as I understand it is that this was effectively the author's choice and that he conflating two concerns. There is the choice of whether to open source code and whether to support the code. Nobody was holding a gun to his head and forcing him to support code. Hence his misprioritization is of his own doing. The author's implied contention is that the two concerns are not independent. That while it may not have been a gun to his head, there are a variety of factors that link the two together. I'm expanding on that contention and saying that there is valid reason, if you have code on GitHub, to feel a need to support it. It's a trade-off. You can decide the risk is small enough to ignore which is fine, but it's still there.

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.

Jaygles 6y ago
Well, in the author's own words... > I was too focused on developing every feature, trying to give support to every single ticket, and I completely ignored the marketing aspects of it as I had no time for it. Saying the author was overly prioritizing responding to the communications that open sourcing the code allowed to come through shouldn't be controversial. He himself is admitting to it. My main point is that the author hasn't convinced me that blame should be placed on open sourcing the code. To me that's akin to blaming the messenger. He should instead be looking to why he felt obligated to spend the time supporting "every single ticket", when he himself knew that he was neglecting other aspects of the business side of things.
- dwohnitmok 6y ago
  I don't think the author is using "too focused" in the way you're saying that "he was overly prioritizing one aspect over others." Your contention as I understand it is that this was effectively the author's choice and that he conflating two concerns. There is the choice of whether to open source code and whether to support the code. Nobody was holding a gun to his head and forcing him to support code. Hence his misprioritization is of his own doing. The author's implied contention is that the two concerns are not independent. That while it may not have been a gun to his head, there are a variety of factors that link the two together. I'm expanding on that contention and saying that there is valid reason, if you have code on GitHub, to feel a need to support it. It's a trade-off. You can decide the risk is small enough to ignore which is fine, but it's still there.