Live data from Hacker News

When 'open core' projects reject contributions for competing with the EE

github.com

121–130 of 202 posts

Re: When 'open core' projects reject contributions for competing with the EE

#121

I am I very much in the ‘it’s their project and they can do what they want with it’ camp, BUT the way they handled it was absolutely awful. Total radio silence until a comment: > At this point, I see them as doing us a favor by keeping the PR open because that enables us to easily find this code which we can then use to bake our own Docker images. Then swoop in to close and lock the PR. Again, it’s their project- but…

So they can merge/not merge but they aren't allowed to talk/not talk? Just because I have an inbox doesn't mean I have to respond to everything that shows up in it.

They’re allowed to do whatever they want. Doesn’t mean that they weren’t shitty about it.

Re: When 'open core' projects reject contributions for competing with the EE

#123
post #113
post #47

Earlier quoted context omitted.

Look at the timestamps. It’s months of complete silence, which is not a great sign from a saas. It was clear that the feature was popular. Another thing that annoys me to no end is locking threads because it’s “heated”. Just accept the grief and venting, people deserve it. It’s toxic positivity.

> Just accept the grief and venting Maintainers do not owe you this, in addition to maintaining the software that you can use for free. You're entitled to be upset, and they're just as entitled to say "please go somewhere else to vent, we're busy".

[dead]

Re: When 'open core' projects reject contributions for competing with the EE

#124

Earlier quoted context omitted.

Author of the pr gave stuff for free. He showed no signs of entitlement. But he is not there only one who gave stuff for free. The open source project gave code for free that is 100 times bigger than the pr. Not acknowledging that is a problem.

The author of the PR expected it to be merged. That is entitlement. They could have discussed the feature with the maintainers beforehand but AFAICT they did not.

AFAICT, the maintainer is the one lacking communication skills. Perhaps the author commented something to the effect of 'you could have told me this before I wasted my time' in the deleted comments towards the end. Or perhaps they were profanity laden. Perhaps a mix of both. We'll never know for sure.

What we do know, is the maintainer chose to ignore any communication related to this PR, for months, until someone pointed out it was helpful keeping the PR open, as it allowed people to apply it themselves locally. Then, all of a sudden, the PR is closed, and communication finally occurs. Could be coincidence, but that's doubtful considering the time span and specific comment involved.

Re: When 'open core' projects reject contributions for competing with the EE

#125
I work on a fully open project that sustains itself… And we really push for a ticket before any major work is done just to make sure it fits our scope.

At the end of the day most contributions come from people as part of their job, and they move on. We’re left to maintain it.

Re: When 'open core' projects reject contributions for competing with the EE

#126
post #80

What this makes me wonder is whether there could be a way for GitHub or its equivalents to make the concept of “a fork by patching” a first-class concept. I’ve definitely done this for company-internal forks by trying to keep the changes as a clean list of linear commits that can be rebased as easily as possible, but it’s interesting to imagine what purpose-built tooling could do to facilitate maintaining such a patc…

I think at some point you will diverge to the point that sync-ing or submitting patches is unmanageable.

I heard stories of projects where every X weeks a person gets assigned to syncing, and it's almost guaranteed that the person will quit soon after. The team even had a tool to assist with the process.

Re: When 'open core' projects reject contributions for competing with the EE

#127

I am I very much in the ‘it’s their project and they can do what they want with it’ camp, BUT the way they handled it was absolutely awful. Total radio silence until a comment: > At this point, I see them as doing us a favor by keeping the PR open because that enables us to easily find this code which we can then use to bake our own Docker images. Then swoop in to close and lock the PR. Again, it’s their project- but…

So they can merge/not merge but they aren't allowed to talk/not talk? Just because I have an inbox doesn't mean I have to respond to everything that shows up in it.

I never said they were not ‘allowed’ to do anything, I also never said they ‘had’ to do anything. It’s their project and can handle it as they wish- I thought I was pretty clear on that point.

Re: When 'open core' projects reject contributions for competing with the EE

#128
post #96

Earlier quoted context omitted.

> Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs. Is it different than someone advertising their FAANG's credentials?

To me, it just sets an implicit expectation of "this is something I support and maintain for my and others' uses" unless otherwise stated.

> There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's maddening.

Re: When 'open core' projects reject contributions for competing with the EE

#129

What a sad page that merge request is. I feel bad for the developer who waited 4 months and got that as a response. :|

I think that this has resulted in a very sour after-taste to the people who've commented or tested the feature. I know it has left such for me and I don't even use the project.

On one hand, I get it, but on the other hand, it could have been handled better.

Re: When 'open core' projects reject contributions for competing with the EE

#130
post #128
post #96

Earlier quoted context omitted.

To me, it just sets an implicit expectation of "this is something I support and maintain for my and others' uses" unless otherwise stated.

> There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's maddening.

Again, expecting a product to be supported unless otherwise stated is not entitlement. Expecting support is not the same as demanding or even expecting people to work for free or at all. What it does mean is that issues and PRs are treated professionally and without antagonistic behavior.

Once again, if you feel every contributor is entitled, don't open source your project or disable issues and make it very clear issues and contributions are not welcome.

Post reply on HN