Hacker News Reader

Comment by madeofpalk | Hacker News Reader

One lesson from this is to not contribute a 'major feature' to an open source project without a signal that it would actually be accepted. Even if the feature doesn't conflict with enterprise/monetisation, the feature could just be against the goals of ideals of the maintainers, of whom the project is up to.

Open source is not a mandate that the maintainers must accept every contribution. The author should consider why they don't want to maintain a fork, and whether that's the same reason why this PR was rejected in favor of an enterprise feature.

View on HN

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.

and this is how we have a mental health crisis in open source maintainers.

a project's issue tracker is first and foremost for the maintainers, any "community" that builds up there is secondary.

> It’s toxic positivity.

You're completely right, though obviously they didn't lock it because it was "too heated" despite what they wrote. They locked it because people were writing negative comments about them.

Frankly I think they're totally justified in this. They need to eat. The things they should have done differently are:

1. Confront the issue at the start rather than waiting months and just hoping it would go away.

2. Less bullshit corporate speak response. They could have been honest that they didn't want to give this away for free otherwise they'd go out of business, and that it's open source so the author is free to maintain their patch/fork if they want. Most reasonable people would understand this. "It doesn't align with our vision" is just vomit-inducing weaseling.

Agreed. For the open core model to work in practice, there needs to be clarity in what’s open and what’s off the table. The problem is that open core appears to be, most of the time, not a serious commitment. At least I don’t trust “self-hostable” at face value anymore if there’s a company behind it. In the worst case, it’s bait and switch.

There’s still value-add in eg source-available products. So there’s a meaningful spectrum of openness, assuming the decision makers are willing to explain their commitment upfront and stand by it.

No. "They need to eat" is a bullshit excuse. Everything is justifiable by "they need to eat".

Doesn't seem like a bullshit excuse to me. How do you propose they make money if nobody has to pay for anything?

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

If they don't want to provide the best possible product and not accept outside contributions, they should not provide a free and open source repository.

"If you run an open source project, I'm entitled to have my contribution accepted"

_This_ is the sense of entitlement that people (rightly) disparage.

I agree - I think the maintainers of the project could have handled this better by responding to it immediately. But that wouldn't have resolved the wasted effort of the whole PR.

> Just accept the grief and venting, people deserve it. It’s toxic positivity.

Absolutely not. No one is entitled to vent at a project, and no maintainer deserves to have that directed to them.

Why should they accept venting and grief on their territory? Let venters and grievers do their stuff on some other premises. HN, for one, is particularly acceptable.

And even for a "true" open source project and even if the feature matches the aims of the project maintainers may still not accept it, as they don't want to commit to the maintenance work.

They can't rely on the contributor to be quick to respond to issues and flaws fall back on them.

For me this has become one of the biggest frictions when trying to help in open source projects.

Most issues either look like someone has been working on them for quite some time (which seems rude to barge in and waste their time), or there’s no clear indication of what would be valuable to help with.

Reply on news.ycombinator.com