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

161–170 of 202 posts

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

#161

Post by advaitruia »

Chiming in here as the cofounder of an 'open core' company:

This obviously wasnt handled as well as it could have been.

On the fundamental issue of building EE features: If 100% of the code was open source, there would be less incentive for them to continue to maintain, update, upgrade the product. The EE features ensures that there is an incentive for them to continue to work on this project. Infact, the community _should_ want project maintainers to be compensated.

As someone else said, the project is open source, you can always fork and add any specific feature you want. It comes down to how useful is the actual open source project. If it is very limited in features and functioning, then yes - it is against the spirit of the open source. But if its a fully usable, functioning product (not for all but atleast some number of usecases), then it has created value which it is not capturing for itself - which is a net good for society and the industry.

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

#162

Post by bmitc »

growse wrote: post #154
bmitc wrote: post #137

Earlier quoted context omitted.

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

That's a very absolutist view. In reality, some PRs are good quality and worth paying the ongoing cost to maintain. Others are good quality, but not worth the ongoing cost. Maintainers get to decide, and they're not obligated to publish their evaluation criteria.

> and they're not obligated to publish their evaluation criteria

God forbid people communicate.

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

#163

Post by IshKebab »

dugite-code wrote: post #110
IshKebab wrote: post #98

Earlier quoted context omitted.

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

> only enterprises care about SSO. Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature You might have an argument with saml, because it's a right pain, but not OIDC

I don't really follow. If you're setting this up for a couple of people you can just manually add accounts. It's probably even easier than setting up OIDC or whatever.

It's only when you get to enterprise level and IT departments want centralised accounts that it matters. They really need SSO.

Frankly I think it's a pretty great status quo. Consider the alternative, which is that the software would either not exist or be closed source.

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

#164

Post by IshKebab »

danenania wrote: post #140
IshKebab wrote: post #92

Earlier quoted context omitted.

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

> There may be a queue of 25 other prs/issues/discussions that also need a response.

There are 30 open PRs. No other open PR has more than 2 thumbs ups/hearts. This one was open for months.

There's zero chance they were unaware of it.

They may have thought "ugh that's awkward; let's not think about it", but that falls firmly into "hoping that nothing happens".

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

#165

Post by IshKebab »

lakomen wrote: post #151
IshKebab wrote: post #91

Earlier quoted context omitted.

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

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?

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

#166

Post by int_19h »

LegibleCrimson wrote: post #72

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

Because you're using the product for whatever reason, and you really want that one feature, but you don't want to be stuck maintaining the fork just for that.

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

#167

Post by danenania »

IshKebab wrote: post #164
danenania wrote: post #140

Earlier quoted context omitted.

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

> There may be a queue of 25 other prs/issues/discussions that also need a response. There are 30 open PRs. No other open PR has more than 2 thumbs ups/hearts. This one was open for months. There's zero chance they were unaware of it. They may have thought "ugh that's awkward; let's not think about it", but that falls firmly into "hoping that nothing happens".

Thumbs up and hearts produce no notifications afaik so they could easily be unaware if they weren’t specifically following and checking up on the thread. And a PR being open for a long time could be an indication that it has been forgotten about rather than being purposefully ignored.

You could definitely be right but you are also making some big assumptions imo that may not be true.

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

#168

Post by evanelias »

starkparker wrote: post #136

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

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

I don't think that holds as a general rule, because there's no conceptual moat preventing any feature from being reimplemented by a third party with sufficient motivation and resources. "The community" sometimes includes larger companies who build an open-source re-implementation of a smaller company's closed-source enterprise features. At best, they do this purely for self-serving reasons; and at worst, for anti-competitive ones.

> Nor is it a bad thing when a community implementation competes with the enterprise implementation

Personally I don't think it is reasonable to expect the maintainers of this project to maintain two separate OIDC implementations, one of which they didn't write in-house. They may have different naming conventions, config options, etc. Sounds like a support and maintenance nightmare.

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

#170

Post by CoolCold »

pydry wrote: post #23
nrabulinski wrote: post #2

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

this, +1 from me
Post reply on HN