Other than months in silence, I don't see why this is wrong. Granted it sucks for the OP.
Agree
When 'open core' projects reject contributions for competing with the EE
71–80 of 202 posts
Re: When 'open core' projects reject contributions for competing with the EE
#72I'm honestly confused why anybody would waste their time working for free to improve an Open Core project. You're donating your labor to a private company to improve their product.
Re: When 'open core' projects reject contributions for competing with the EE
#73Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.
SSO isn't fundamental to most "open core" projects' security. So excluding from core seems like a reasonable compromise. They have to make money somehow. And IME the SSO implementations can be fidly and bespoke, so worth charging a premium to support.
It is, because even without looking at the product I can be very certain they don't implement nearly as good 2FA as say Keycloak or other solutions like that out there.
If anything, save some money and stop reimplementing all the login and account management functionality and let the OIDC (or worse, SAML) provider do it.
Re: When 'open core' projects reject contributions for competing with the EE
#74A lot of the comments here are along the lines of “this is fine. They should be able to make money to survive. Stop complaining or forkit. This is what open core is”. IMO I don’t think this is what open core is. Open Core should mean that, if a user is not happy with a commercial offering, they are able to roll their own. Perhaps it would take them a bit of time operationally to do this. Maybe they need to spin up th…
> but this should be possible for them to do this within a reasonable amount of time
That's not the end game of any "open core" company I have ever seen.
They usually will restrict certain software features only to paying customers.
From Wikipedia [0]:
> The open-core model is a business model for the monetization of commercially produced open-source software. The open-core model primarily involves offering a "core" or feature-limited version of a software product as free and open-source software, while offering "commercial" versions or add-ons as proprietary software. The term was coined by Andrew Lampitt in 2008.
Re: When 'open core' projects reject contributions for competing with the EE
#75This is expected but still disappointing.
Disappointing that the maintainers need to make a living (or, godforbid, even a profit) and that users can't get everything for free? Nope.
A contributor offered the feature for free, the maintainers don't want it to be free. It's expected because is a business.
It's disappointing because it's a problem with no clear winners. It's difficult to solve it for all.
I was not trying to be contentious, just observing that open core is difficult to do it right for all parts involved.
Things will align themselves, probably a fork, users moving to alternatives, or something else.
Re: When 'open core' projects reject contributions for competing with the EE
#76Earlier quoted context omitted.
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.
This project is MIT-licensed, so that applies here too?
MIT license is one of the most permissive open source software licenses. What’s the problem?
Re: When 'open core' projects reject contributions for competing with the EE
#77Just 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
Re: When 'open core' projects reject contributions for competing with the EE
#78Earlier quoted context omitted.
The only one giving stuff away for free is the author of the PR. And yet, you're calling that person entitled.
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.
Re: When 'open core' projects reject contributions for competing with the EE
#79Situations like this one make a company show whether they really are open source or only do so for marketability and to artificially appear more trustworthy. And sadly too often it comes out that it’s the latter
Situations like this one bring out the difference between people who want open source to be supported and those who just want a freebee.
The PR author apparently didn't want a freebee and actually spent time contributing.
Re: When 'open core' projects reject contributions for competing with the EE
#80What 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 patch-based fork.