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

91–100 of 202 posts

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

#91

Post by IshKebab »

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.

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

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

#92

Post by IshKebab »

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.

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

#94

Post by pjmlp »

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

It is the consequence of many developers not wanting to pay for the tools that make their job possible in first place.

So it is either full commercial, SaaS (not applicable to every kind of software), or open core.

Consulting only works when users are willing to pay for support, instead of sorting out by themselves during long nights and rainy weekends.

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

#95

Post by relativ575 »

bmitc wrote: post #50
pydry wrote: post #32

Earlier quoted context omitted.

>show a fundamental issue with the open core model The alternative is the code doesnt exist. >Usually, you expect that developers When developers give away software for free I have no expections of them. If they fix a bug I consider that a favor not an obligation on their part. There is a culture of entitlement surrounding open source which drives "expectations" from people who give stuff away for free and it's madde…

I personally think it's up to maintainers to set expectations. 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. Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs…

> 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?

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

#96

Post by bmitc »

relativ575 wrote: post #95
bmitc wrote: post #50

Earlier quoted context omitted.

I personally think it's up to maintainers to set expectations. 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. Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs…

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

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

#97

Post by pydry »

kuschku wrote: post #31
pydry wrote: post #25

Earlier quoted context omitted.

I think the problem is entitlement more than terminology.

If someone builds a feature faster, better, and more open than the paid alternative and gives it away long before the enterprise version even announces the feature, where is the entitlement?

Expecting it to be merged of course!

If they think theyve built something better theyre always free to fork the original. If they dont want to put the legwork in and have expectations that somebody else should maintain their code anyway, they should fuck off.

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

#98

Post by IshKebab »

arcfour wrote: post #6

Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.

That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO.

That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it.

(Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean literally nobody. You aren't proving me wrong by saying "ackshewally I use SSO and I'm not an enterprise".)

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

#99

Post by kbolino »

paulryanrogers wrote: post #70
arcfour wrote: post #6

Ah, 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.

The problem is that login without SSO usually means even more fiddly and bespoke password and MFA implementations.

Can I paste in the password field? What and how many characters are allowed? Is it fed into a properly salted KDF? Can the password be intercepted by common logging/monitoring tools? How do I reset my password? Are there MFA options other than either SMS or TOTP? Can I have multiple MFA options active simultaneously, in case I lose access to one? Does an attacker having access to my email bypass all the other security measures? etc.

The support burden of doing that right has to be higher than that of doing SSO right. Of course, many won't prioritize hardening the open core security model until a large client suffers a breach, and a large client won't usually be using the open core anyway.

However, I actually agree with you about SSO implementations being too fiddly and bespoke, and moreover even doing OAuth2/OIDC the right way is tricky. Many/most guides online focus on using auth tokens to talk to first-party or tightly integrated APIs. Whereas, when using an OIDC provider for SSO, you actually just want proof-of-identity. Do I get an auth token and then call an identity endpoint? If so, do they support PKCE in the code flow? Do I get an ID token and then validate it? If so, do they support nonces in the flow? Which algorithms will be used to sign the token, and where do I get the keys? Even the major social-login providers don't all agree on the answers to these questions.

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

#100

Post by roamerz »

LegibleCrimson wrote: post #43
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…

It's pretty rude to ignore a PR for months only to give it a rejection that you could have levied earlier, especially for a feature that wasn't even in the Enterprise Edition when the PR was created.

That’s exactly what I was thinking. If the information is maybe business confidential then yeah but at least acknowledge the requests with something.
Post reply on HN