Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

131–140 of 202 posts

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

#131

Post by pulvinar »

bmitc wrote: post #103
pydry wrote: post #90

Earlier quoted context omitted.

No. It's up to contributors to set expectations about the work they do with the project maintainer before they do it if they have any wish to see it merged. You were given something for free . That doesnt confer any rights, legal, moral or otherwise. Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing . PRs are even wors…

There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute. > You were given something for free. I wasn't given anything. Somet…

From the maintainer's point of view, any new contribution requires work to vet it and check that it won't break something else, insidiously inject malware, etc., so what value it adds has to appear to be worth the trouble. Even when the contributor is certain that their PR is perfect and should be "no trouble" for the maintainer.

This "hill" that has to be gotten over by the contributor is just a reality of the situation. I don't see any way around it.

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

#132

Post by bmitc »

prepend wrote: post #52
bmitc wrote: post #41

Earlier quoted context omitted.

This happens in open source projects, too, often for even more subjective reasons.

But with open source projects the community has the option to fork and carry on the code as the community wishes. With licenses where a company owns and limits the IP, the community is stuck and can just stop using the project. I think that’s a big difference.

(a) You could do that here. (b) It's not exactly realistic to take on every open source project because the maintainers refuse certain simple fixes and additions. You'd very quickly become a hoarder of open source projects.

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

#133

Post by pessimizer »

hannob wrote: post #24
byefruit wrote: post #12

I don't see the problem here? It's their project and they can choose what they want to maintain. If you disagree, it's perfectly fine to fork the project and implement this but then you bear the cost of maintenance. These kinds of open source projects need to be sustainable, you can't expect the companies producing them to continue maintaining and investing in them without some sustainable way of doing it. I don't se…

Without putting blame on anyone, this does show a fundamental issue with the open core model. It is built on the premise that your "open" product will not be as good as possible, so you can still have the higher priced "enterprise" product. I think it's fair to point that out. Usually, you expect that developers want to create software that is "as good as possible". They may have a different idea what exactly "good"…

> Without putting blame on anyone, this does show a fundamental issue with the open core model.

The "fundamental issue" isn't a matter of blame, it's entirely intentional. The problems that it can lead to for consumers is that they might have to host and maintain their own patches if they prefer to write than to pay, and otherwise if they can share the responsibility for that maintenance with a group of people, they've pretty much created a hostile fork. For the projects themselves, the problem is that people will create hostile forks if your prices aren't low enough.

As far as I can tell, the solution for open core stuff has been to pour most of the effort into the proprietary features and support, and to market to enterprise. That way the sky is the limit on price, and hostile forks that add the features you forbid can't catch up with you, at least in the enterprise market. This isn't always successful, but it makes sense to me.

There's no spirit of Open Source. Open Source is software that you're allowed to use, copy, modify, and distribute freely. It isn't required to be good, it isn't required to take any contributions, it isn't required to take any suggestions.

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

#134

Post by SloopJon »

goku12 wrote: post #77
mariocesar wrote: post #8

Just saw this on the same day in HN. Bruno: Fast and Git-friendly open-source API client (Postman alternative) https://news.ycombinator.com/item?id=39653718 https://www.usebruno.com/ Good timing to find alternatives.

Bruno uses the same license and licensing model: https://www.usebruno.com/pricing

[dead]

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

#136

Post by starkparker »

If a feature of an open core product can be provided by the community, it's not valuable enough to gate behind an enterprise wall.

Nor is it a bad thing when a community implementation competes with the enterprise implementation. At a minimum it gives you a standard to exceed. For a feature like this, accepting the community offer to configure arbitrary providers lets you define which providers get enterprise-level support going forward.

The response to this makes it clear that the company has no intention of working with contributors. As many have said here, that's their right, but as a prospective customer it looks like they're unable or unwilling to compete on quality against even their own userbase's freely developed contributions, which reduces my confidence in the quality of their enterprise offering more than if they had accepted it and built a better equivalent interface or defined better support for it.

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

#137

Post by bmitc »

pulvinar wrote: post #131
bmitc wrote: post #103

Earlier quoted context omitted.

There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute. > You were given something for free. I wasn't given anything. Somet…

From the maintainer's point of view, any new contribution requires work to vet it and check that it won't break something else, insidiously inject malware, etc., so what value it adds has to appear to be worth the trouble. Even when the contributor is certain that their PR is perfect and should be "no trouble" for the maintainer. This "hill" that has to be gotten over by the contributor is just a reality of the situa…

Just document it on the README: PRs are will not be accepted or vetted due to . It's as simple as that.

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

#139

Post by madeofpalk »

klabb3 wrote: post #47
madeofpalk wrote: post #11

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 w…

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.

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.

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

#140

Post by danenania »

IshKebab wrote: post #92
move-on-by wrote: post #37

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…

> just wishing it would disappear of its own accord? Almost certainly. I see people sometimes closing PRs when they get no response from project maintainers. They must have hoped that would happen. Or at least that it would stay open and mostly unnoticed, avoiding this sort of negative publicity.

They are running a large project and are likely getting notifications from Github all day every day.

Rather than having purposely ignored it, someone may have looked at it and thought “hmm we’ll have to discuss this” but since people are busy it never got prioritized because it wasn’t urgent. There may be a queue of 25 other prs/issues/discussions that also need a response.

Sure it’s better from a community and support perspective to respond quickly and be transparent, but I wouldn’t necessarily assume there is some ulterior motive to their lack of response.

Post reply on HN