11 ms·

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

175 points by angry_octet 3y ago

arcfour 3y ago
Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.
- SushiHippie 3y ago
  > Ah, the SSO tax For others that are not aware: https://sso.tax/ https://sso.tax/
- Avamander 3y ago
  Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.
- paulryanrogers 3y ago
  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.
  - Avamander 3y ago
    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.
  - kbolino 3y ago
    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.
- IshKebab 3y ago
  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".)
  - dugite-code 3y ago
    > 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
    - IshKebab 3y ago
      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.
      - kuschku 3y ago
        If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO. Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked) So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.
- gehen88 3y ago
  SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly). Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
  - kuschku 3y ago
    For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access. Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary. I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them. I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them. I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place. The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.
nrabulinski 3y ago
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
- i80and 3y ago
  What's worse is it can change at the whims of executives. You can invest time and effort into improving an open core product because the leadership is very open and collaborative, then the CTO changes or a bad quarter comes around and OOPS they're done playing with the community now
  - byefruit 3y ago
    But you've always got the right to fork it. What you're saying is you want them to continue maintaining it at their cost because the community don't want to?
    - deleted 3y ago
      [deleted]
- pydry 3y ago
  Situations like this one bring out the difference between people who want open source to be supported and those who just want a freebee.
  - nrabulinski 3y ago
    The only freebie here is the PR implementing a major feature which people were excited for, that was ignored for months
  - gtirloni 3y ago
    The PR author apparently didn't want a freebee and actually spent time contributing.
deleted 3y ago
[deleted]
mariocesar 3y ago
This is expected but still disappointing.
- urig 3y ago
  Disappointing that the maintainers need to make a living (or, godforbid, even a profit) and that users can't get everything for free? Nope.
  - kuschku 3y ago
    "get" "for free"? Where do users expect to "get" something for free? In fact, users are offering something "for free".
    - ericb 3y ago
      A company went to the free weekly picnic and offered to chop-down the tree that provided the shade everyone was eating under "for free" so they could build themselves a picnic table, because they didn't feel like paying for a chair or settling for the free blanket.
  - mariocesar 3y ago
    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.
madeofpalk 3y ago
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.
- johannes1234321 3y ago
  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.
- xondono 3y ago
  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.
- klabb3 3y ago
  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.
  - arccy 3y ago
    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.
  - 3y ago
prepend 3y ago
One of the many reasons why I think “open core” is not so hot and users should choose to avoid them and prefer OSI-conformant open source licenses that give them options when the company does lame stuff like this-fork and continue on.
- byefruit 3y ago
  [dead]
- madeofpalk 3y ago
  This project is MIT licensed. It is not source available, but is open source (if your definition of open source means OSI-conformant license). The author/community is welcome to exercise those options that MIT affords them, such as forking and launching a competing product.
  - nailer 3y ago
    OSI conformant license is the only definition of open source - the OSI coined and popularised the term - but you’re otherwise correct.
    - LegibleCrimson 3y ago
      The definition is whatever the majority of people use it to mean. Just like what happened with REST. It might not be palatable, but you either choose to understand what people mean, or you struggle and shout into the void about people with a common understanding that doesn't match what you think a term should mean.
      - nailer 3y ago
        This is a false dichotomy: just like REST, people can choose to understand what people mean and still know they are incorrect.
  - prepend 3y ago
    Thanks, sorry I misunderstood and thought the license was open core. I should have checked the license instead of just reading through the issue and assuming based on the headline.
mariocesar 3y ago
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://news.ycombinator.com/item?id=39653718 https://www.usebruno.com/ https://www.usebruno.com/ Good timing to find alternatives.
- goku12 3y ago
  Bruno uses the same license and licensing model: https://www.usebruno.com/pricing https://www.usebruno.com/pricing
  - SloopJon 3y ago
    [dead]
haolez 3y ago
Which relevant open source projects with a SaaS feel don't suffer from this? I.e. they are not open core and subject to some startup's agenda and risks. From the top of my mind, I remember Apache Airflow, which has a lot of open core competition right now.
- pm90 3y ago
  Temporal. Kubernetes. Postgres. MySQL (MariaDB). Any all of Hashicorp tooling (Terraform, Consul, Vault etc).
  - gtirloni 3y ago
    Hashicorp tooling is not a good example anymore. They are source available, not open source anymore.
  - evanelias 3y ago
    MySQL and MariaDB both have enterprise editions, and they (completely understandably!) will not merge pull requests which attempt to re-implement enterprise-only features.
  - haolez 3y ago
    From your list, I think only Kubernetes and Postgres fit my contraints and they don't have (mostly) a SaaS feel.
gr4vityWall 3y ago
What a sad page that merge request is. I feel bad for the developer who waited 4 months and got that as a response. :|
- sethops1 3y ago
  Why didn't they discuss the feature with the maintainers before working on it?
  - Karellen 3y ago
    I've submitted series-of-patches to open-source projects that I've worked on before contacting the project. Partly this is because I wasn't sure if I could even implement the feature. Or, if I technically could, I wasn't sure that I'd be able to see the implementation through to the point it was mergeable (the number of half-started projects I have laying around...) I didn't want to say "hey, I've got this great idea..." and then disappear into the aether and never deliver. Or, worse, have someone else contact the project with the same idea, and they say "Nah, Karellen is already working on that...", so they move on to something else, and the feature which could have been developed by this other person isn't, so it never happens. But also, I wanted to give the maintainers a prototype they could look at and play with, rather than vapourware, to get real feedback. If they say "no, that's not for us", well, I can always put up my own fork if I want to. And I can keep the branch for my local install, which I can continue to rebase or merge into upstream, because the feature is useful to me. Also, I learned a few things by creating the implementation - even if it doesn't go anywhere. The work is no less a waste of time than, e.g. doing the Advent Of Code.
  - glomph 3y ago
    I mean they did post on the open issue that they were working on it and got no reply.
- PartiallyTyped 3y ago
  I think that this has resulted in a very sour after-taste to the people who've commented or tested the feature. I know it has left such for me and I don't even use the project. On one hand, I get it, but on the other hand, it could have been handled better.
byefruit 3y ago
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 see why project maintainers gets called out on this but AWS reselling open source projects whilst contributing very little to them isn't.
- MrBuddyCasino 3y ago
  Yeah I understand the disappointment, but „open core“ implies that there are parts that are not part of the core, and therefore not open. Those parts will usually be something that enterprises value. At the end of the day, maintainers for complex projects need to get paid.
- hannob 3y ago
  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" means, but you usually don't expect that an open source project will actively want to be worse than it could be. But "open core" is exactly that: It's a software trying to be worse than it could be.
  - pydry 3y ago
    >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 maddening.
Sytten 3y ago
How dare them wanting to make money. Seriously this is fine, if you are not happy fork it and maintain it yourself. AFAIK this is the whole point of open core. What you are asking here is that business to support code for free that reduces their revenue. Code is a liability most of the time not an asset.
- mhx1138 3y ago
  I think the problem is the terminology. People grew up when open source software was also free. Open core uses the same terminology, although products are only open and free in a limited way. I don’t want to assume intend, but many users are mislead that way.
  - pydry 3y ago
    I think the problem is entitlement more than terminology.
    - kuschku 3y ago
      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?
      - Sl1mb0 3y ago
        The expectation that the feature should be merged in. Just because you created an amazing pull request that everyone wants merged in, doesn't mean the maintainer should or want to do so.
      - pydry 3y ago
        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.
    - 3y ago
000ooo000 3y ago
[dead]
prabhatsharma 3y ago
They need to be able to differentiate core from Enterprise. If they can't make money in a sustainable way the open core company will die and so will the open source project. Those who fail to see this reality are only hurting themselves. This is perfectly fine.
- kuschku 3y ago
  If the community is able to implement new features better, faster, and more open than the company, then the company probably should be pushed out of the project. If that has to happen via forking and directly competing with them, so be it.
  - prabhatsharma 3y ago
    98 to 99 percent of the contributions in all open core projects come from core contributors. You take the core team out and you will see the project die.
    - growse 3y ago
      Which way round is this causation though? Are they the only contributors because they're the only people who care, or are they the only contributors because they're hostile to any external contributors?
      - abenga 3y ago
        There's an easy enough way to prove or disprove this: fork the project, rename it, and overtake the original product in quality/features.
deleted 3y ago
[deleted]
move-on-by 3y ago
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 surely there was a better course of action…. it probably starts with not ignoring the PR for months. What were they doing? Clearly they had eyes on it… just wishing it would disappear of its own accord?
- IshKebab 3y ago
  > 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.
  - danenania 3y ago
    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.
    - IshKebab 3y ago
      > 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".
INTPenis 3y ago
The point of open source is that you fork it and add this feature, and have to maintain the project yourself.
nailer 3y ago
[dead]
pm90 3y ago
A 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 their own infra (eg cloud VMs, cloud database etc) but this should be possible for them to do this within a reasonable amount of time. I think the change being rejected here is fundamental to the operation of this tool. Without SAML auth, you simply cannot deploy it yourself for your internal users. I am willing and open to other views on this. But I am not convinced that project owners should be allowed to call their project open core without having some reasonable burden to allow the software to be self hosted.
- bbkane 3y ago
  I think open core means the authors maintain a less capable open source version of their project. I don't think there's any expectations beyond that about internal hosting capabilities or anything else, certainly not in the license anyway.
- gtirloni 3y ago
  > 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. 0 - https://en.wikipedia.org/wiki/Open-core_model https://en.wikipedia.org/wiki/Open-core_model
- anthomtb 3y ago
  Maybe its my grug-brain showing up but could you not: 1) Clone the latest version of the tool 2) Apply the patches needed for this feature 3) Profit. Or is there some reason why the change has to live in the "main" branch for the official project on github?
asadalt 3y ago
Other than months in silence, I don't see why this is wrong. Granted it sucks for the OP.
- prabhatsharma 3y ago
  Agree
koolhead 3y ago
I don't see a problem here ¯\_(ツ)_/¯ The simple way to look at this is - as long as an open source project is serving the core basic use of a product and choose to keep certain features behind a feature flag/pay wall, it's perfectly fine. Companies need to survive, and thats important for them to continue to contribute to the core open source product. That's most important. You don't want to run a product in your company on someone's hobby project, would you?
glub103011 3y ago
[dead]
LegibleCrimson 3y ago
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.
- sowbug 3y ago
  The same is true of any successful open-source project, isn't it? Almost all popular projects are used by for-profit companies, regardless of who owns the copyright on the code.
  - LegibleCrimson 3y ago
    I feel different about fully open source projects. You are working for free for the benefit of the company, all other companies who want to use it, and the rest of the world. I'm happy to work for free when it benefits everybody equally. I don't care that for profits benefit, because they all benefit potentially the same amount. It's a boon for the world. With open core, you're working for free for the benefit of the leverage of a company to better position their secret sauce. It asymmetrically benefits the company more than everybody else. I only do that when I'm getting paid to do it.
    - sowbug 3y ago
      What I'm hearing is that you object to cases where the entity exerting the most control over the direction of an open-core project has an incentive to restrict the project in favor of something else the entity also controls -- usually their non-open project. It's a reasonable position, but I can imagine open-core projects that aren't conflicted this way, and open-source projects that are.
      - LegibleCrimson 3y ago
        Exactly, I'm sure good projects exist, but that involves active goodwill from the company. The incentives are loaded in the favor of exploitation rather than public good.
zellyn 3y ago
What 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.
- Karellen 3y ago
  There's always `quilt` https://savannah.nongnu.org/projects/quilt https://savannah.nongnu.org/projects/quilt https://manpages.debian.org/bookworm/quilt/quilt.1.en.html https://manpages.debian.org/bookworm/quilt/quilt.1.en.html
- foxhop 3y ago
  a set of patches to run on the Repo works but it breaks when a big refactor happens upstream.
- PartiallyTyped 3y ago
  I think at some point you will diverge to the point that sync-ing or submitting patches is unmanageable. I heard stories of projects where every X weeks a person gets assigned to syncing, and it's almost guaranteed that the person will quit soon after. The team even had a tool to assist with the process.
gtirloni 3y ago
This is natural to all "open core" and "source available" projects. Nothing new about that here. These tensions will always exist in not true open source projects.
lijok 3y ago
Seeing the discourse around OSS contributions reminds me how inexperienced and naive our industry is. We should invest heavily in teaching grads not just how to code, but how to manage relationships, build trust with your peers and above all; communicate effectively. Look at this PR and you’ll see a person who sacrificed their personal time to implement a highly requested feature. The company sees a person they’ve never interacted with, send a large PR without asking, implementing a feature that undermines their Enterprise tier, for which they now need to allocate resource to get it reviewed, revised and integrated.
b800h 3y ago
Well I hope to God the Enterprise code looks nothing like the pull request..
lukaszwojtow 3y ago
I guess they can fork that "open core", introduce that feature, then maintain it themselves forever. Pull changes from original open core and their "open" branch will be better than original. Of course they don't want this work. They want the company to maintain it instead.
- kuschku 3y ago
  And that's how I ended up forking dozens of projects spending a lot of my free time just maintaining my patches. Still better than having to give in to this open core enshittification.
hamilyon2 3y ago
When an equivalent MR would be issued to linux kernel, and it would be closed with wording "become a platinum supporter", will the reaction be the same? Something like this happened in the past with android fork and subsequent merge back. I think the answer "we already implemented this the way we wanted, it is in paid version, supported, by us, so pay us" is good leadership of the project, ensuring it's long term health.
deleted 3y ago
[deleted]
vrighter 3y ago
it took lots of months for the dev to partially (if you build from source) support trusting self signed keys. It literally made the product utterly useless for development
monkey26 3y ago
I work on a fully open project that sustains itself… And we really push for a ticket before any major work is done just to make sure it fits our scope. At the end of the day most contributions come from people as part of their job, and they move on. We’re left to maintain it.
nicognaw 3y ago
[dead]
starkparker 3y ago
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.
- evanelias 3y ago
  > 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.
neomantra 3y ago
[dead]
lakomen 3y ago
[dead]
advaitruia 3y ago
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.
htyden 3y ago
EE is short for "enterprise edition", I assume. I hope that is correct, and perhaps it is obvious to most people.
Vanit 3y ago
The second I saw this was about OIDC support I knew what's up. This is a great way to flood your support bandwidth with "doesn't work with X" complaints.
arsh4151 3y ago
[dead]
PeterZaitsev 3y ago
This is well known potential conflict between Enterprise and Community in Open Core project. If you are unwise and reject too many important features community may come together and excersize their right to fork.

175 points by angry_octet 3y ago

arcfour 3y ago

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

SushiHippie 3y ago
> Ah, the SSO tax For others that are not aware: https://sso.tax/ https://sso.tax/
Avamander 3y ago
Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.
paulryanrogers 3y ago
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.
- Avamander 3y ago
  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.
- kbolino 3y ago
  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.
IshKebab 3y ago
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".)
- dugite-code 3y ago
  > 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
  - IshKebab 3y ago
    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.
    - kuschku 3y ago
      If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO. Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked) So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.
gehen88 3y ago
SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly). Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
- kuschku 3y ago
  For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access. Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary. I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them. I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them. I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place. The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.

nrabulinski 3y ago

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

i80and 3y ago
What's worse is it can change at the whims of executives. You can invest time and effort into improving an open core product because the leadership is very open and collaborative, then the CTO changes or a bad quarter comes around and OOPS they're done playing with the community now
- byefruit 3y ago
  But you've always got the right to fork it. What you're saying is you want them to continue maintaining it at their cost because the community don't want to?
  - deleted 3y ago
    [deleted]
pydry 3y ago
Situations like this one bring out the difference between people who want open source to be supported and those who just want a freebee.
- nrabulinski 3y ago
  The only freebie here is the PR implementing a major feature which people were excited for, that was ignored for months
- gtirloni 3y ago
  The PR author apparently didn't want a freebee and actually spent time contributing.

deleted 3y ago

[deleted]

mariocesar 3y ago

This is expected but still disappointing.

urig 3y ago
Disappointing that the maintainers need to make a living (or, godforbid, even a profit) and that users can't get everything for free? Nope.
- kuschku 3y ago
  "get" "for free"? Where do users expect to "get" something for free? In fact, users are offering something "for free".
  - ericb 3y ago
    A company went to the free weekly picnic and offered to chop-down the tree that provided the shade everyone was eating under "for free" so they could build themselves a picnic table, because they didn't feel like paying for a chair or settling for the free blanket.
- mariocesar 3y ago
  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.

madeofpalk 3y ago

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.

johannes1234321 3y ago
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.
xondono 3y ago
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.
klabb3 3y ago
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.
- arccy 3y ago
  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.
- 3y ago

prepend 3y ago

One of the many reasons why I think “open core” is not so hot and users should choose to avoid them and prefer OSI-conformant open source licenses that give them options when the company does lame stuff like this-fork and continue on.

byefruit 3y ago
[dead]
madeofpalk 3y ago
This project is MIT licensed. It is not source available, but is open source (if your definition of open source means OSI-conformant license). The author/community is welcome to exercise those options that MIT affords them, such as forking and launching a competing product.
- nailer 3y ago
  OSI conformant license is the only definition of open source - the OSI coined and popularised the term - but you’re otherwise correct.
  - LegibleCrimson 3y ago
    The definition is whatever the majority of people use it to mean. Just like what happened with REST. It might not be palatable, but you either choose to understand what people mean, or you struggle and shout into the void about people with a common understanding that doesn't match what you think a term should mean.
    - nailer 3y ago
      This is a false dichotomy: just like REST, people can choose to understand what people mean and still know they are incorrect.
- prepend 3y ago
  Thanks, sorry I misunderstood and thought the license was open core. I should have checked the license instead of just reading through the issue and assuming based on the headline.

mariocesar 3y ago

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://news.ycombinator.com/item?id=39653718 https://www.usebruno.com/ https://www.usebruno.com/ Good timing to find alternatives.

goku12 3y ago
Bruno uses the same license and licensing model: https://www.usebruno.com/pricing https://www.usebruno.com/pricing
- SloopJon 3y ago
  [dead]

haolez 3y ago

Which relevant open source projects with a SaaS feel don't suffer from this? I.e. they are not open core and subject to some startup's agenda and risks. From the top of my mind, I remember Apache Airflow, which has a lot of open core competition right now.

pm90 3y ago
Temporal. Kubernetes. Postgres. MySQL (MariaDB). Any all of Hashicorp tooling (Terraform, Consul, Vault etc).
- gtirloni 3y ago
  Hashicorp tooling is not a good example anymore. They are source available, not open source anymore.
- evanelias 3y ago
  MySQL and MariaDB both have enterprise editions, and they (completely understandably!) will not merge pull requests which attempt to re-implement enterprise-only features.
- haolez 3y ago
  From your list, I think only Kubernetes and Postgres fit my contraints and they don't have (mostly) a SaaS feel.

gr4vityWall 3y ago

What a sad page that merge request is. I feel bad for the developer who waited 4 months and got that as a response. :|

sethops1 3y ago
Why didn't they discuss the feature with the maintainers before working on it?
- Karellen 3y ago
  I've submitted series-of-patches to open-source projects that I've worked on before contacting the project. Partly this is because I wasn't sure if I could even implement the feature. Or, if I technically could, I wasn't sure that I'd be able to see the implementation through to the point it was mergeable (the number of half-started projects I have laying around...) I didn't want to say "hey, I've got this great idea..." and then disappear into the aether and never deliver. Or, worse, have someone else contact the project with the same idea, and they say "Nah, Karellen is already working on that...", so they move on to something else, and the feature which could have been developed by this other person isn't, so it never happens. But also, I wanted to give the maintainers a prototype they could look at and play with, rather than vapourware, to get real feedback. If they say "no, that's not for us", well, I can always put up my own fork if I want to. And I can keep the branch for my local install, which I can continue to rebase or merge into upstream, because the feature is useful to me. Also, I learned a few things by creating the implementation - even if it doesn't go anywhere. The work is no less a waste of time than, e.g. doing the Advent Of Code.
- glomph 3y ago
  I mean they did post on the open issue that they were working on it and got no reply.
PartiallyTyped 3y ago
I think that this has resulted in a very sour after-taste to the people who've commented or tested the feature. I know it has left such for me and I don't even use the project. On one hand, I get it, but on the other hand, it could have been handled better.

byefruit 3y ago

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 see why project maintainers gets called out on this but AWS reselling open source projects whilst contributing very little to them isn't.

MrBuddyCasino 3y ago
Yeah I understand the disappointment, but „open core“ implies that there are parts that are not part of the core, and therefore not open. Those parts will usually be something that enterprises value. At the end of the day, maintainers for complex projects need to get paid.
hannob 3y ago
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" means, but you usually don't expect that an open source project will actively want to be worse than it could be. But "open core" is exactly that: It's a software trying to be worse than it could be.
- pydry 3y ago
  >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 maddening.

Sytten 3y ago

How dare them wanting to make money. Seriously this is fine, if you are not happy fork it and maintain it yourself. AFAIK this is the whole point of open core. What you are asking here is that business to support code for free that reduces their revenue. Code is a liability most of the time not an asset.

mhx1138 3y ago
I think the problem is the terminology. People grew up when open source software was also free. Open core uses the same terminology, although products are only open and free in a limited way. I don’t want to assume intend, but many users are mislead that way.
- pydry 3y ago
  I think the problem is entitlement more than terminology.
  - kuschku 3y ago
    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?
    - Sl1mb0 3y ago
      The expectation that the feature should be merged in. Just because you created an amazing pull request that everyone wants merged in, doesn't mean the maintainer should or want to do so.
    - pydry 3y ago
      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.
  - 3y ago

000ooo000 3y ago

[dead]

prabhatsharma 3y ago

They need to be able to differentiate core from Enterprise. If they can't make money in a sustainable way the open core company will die and so will the open source project. Those who fail to see this reality are only hurting themselves. This is perfectly fine.

kuschku 3y ago
If the community is able to implement new features better, faster, and more open than the company, then the company probably should be pushed out of the project. If that has to happen via forking and directly competing with them, so be it.
- prabhatsharma 3y ago
  98 to 99 percent of the contributions in all open core projects come from core contributors. You take the core team out and you will see the project die.
  - growse 3y ago
    Which way round is this causation though? Are they the only contributors because they're the only people who care, or are they the only contributors because they're hostile to any external contributors?
    - abenga 3y ago
      There's an easy enough way to prove or disprove this: fork the project, rename it, and overtake the original product in quality/features.

deleted 3y ago

[deleted]

move-on-by 3y ago

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 surely there was a better course of action…. it probably starts with not ignoring the PR for months. What were they doing? Clearly they had eyes on it… just wishing it would disappear of its own accord?

IshKebab 3y ago
> 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.
- danenania 3y ago
  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.
  - IshKebab 3y ago
    > 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".

INTPenis 3y ago

The point of open source is that you fork it and add this feature, and have to maintain the project yourself.

nailer 3y ago

[dead]

pm90 3y ago

A 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 their own infra (eg cloud VMs, cloud database etc) but this should be possible for them to do this within a reasonable amount of time. I think the change being rejected here is fundamental to the operation of this tool. Without SAML auth, you simply cannot deploy it yourself for your internal users. I am willing and open to other views on this. But I am not convinced that project owners should be allowed to call their project open core without having some reasonable burden to allow the software to be self hosted.

bbkane 3y ago
I think open core means the authors maintain a less capable open source version of their project. I don't think there's any expectations beyond that about internal hosting capabilities or anything else, certainly not in the license anyway.
gtirloni 3y ago
> 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. 0 - https://en.wikipedia.org/wiki/Open-core_model https://en.wikipedia.org/wiki/Open-core_model
anthomtb 3y ago
Maybe its my grug-brain showing up but could you not: 1) Clone the latest version of the tool 2) Apply the patches needed for this feature 3) Profit. Or is there some reason why the change has to live in the "main" branch for the official project on github?

asadalt 3y ago

Other than months in silence, I don't see why this is wrong. Granted it sucks for the OP.

prabhatsharma 3y ago
Agree

koolhead 3y ago

I don't see a problem here ¯\_(ツ)_/¯ The simple way to look at this is - as long as an open source project is serving the core basic use of a product and choose to keep certain features behind a feature flag/pay wall, it's perfectly fine. Companies need to survive, and thats important for them to continue to contribute to the core open source product. That's most important. You don't want to run a product in your company on someone's hobby project, would you?

glub103011 3y ago

[dead]

LegibleCrimson 3y ago

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.

sowbug 3y ago
The same is true of any successful open-source project, isn't it? Almost all popular projects are used by for-profit companies, regardless of who owns the copyright on the code.
- LegibleCrimson 3y ago
  I feel different about fully open source projects. You are working for free for the benefit of the company, all other companies who want to use it, and the rest of the world. I'm happy to work for free when it benefits everybody equally. I don't care that for profits benefit, because they all benefit potentially the same amount. It's a boon for the world. With open core, you're working for free for the benefit of the leverage of a company to better position their secret sauce. It asymmetrically benefits the company more than everybody else. I only do that when I'm getting paid to do it.
  - sowbug 3y ago
    What I'm hearing is that you object to cases where the entity exerting the most control over the direction of an open-core project has an incentive to restrict the project in favor of something else the entity also controls -- usually their non-open project. It's a reasonable position, but I can imagine open-core projects that aren't conflicted this way, and open-source projects that are.
    - LegibleCrimson 3y ago
      Exactly, I'm sure good projects exist, but that involves active goodwill from the company. The incentives are loaded in the favor of exploitation rather than public good.

zellyn 3y ago

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

Karellen 3y ago
There's always `quilt` https://savannah.nongnu.org/projects/quilt https://savannah.nongnu.org/projects/quilt https://manpages.debian.org/bookworm/quilt/quilt.1.en.html https://manpages.debian.org/bookworm/quilt/quilt.1.en.html
foxhop 3y ago
a set of patches to run on the Repo works but it breaks when a big refactor happens upstream.
PartiallyTyped 3y ago
I think at some point you will diverge to the point that sync-ing or submitting patches is unmanageable. I heard stories of projects where every X weeks a person gets assigned to syncing, and it's almost guaranteed that the person will quit soon after. The team even had a tool to assist with the process.

gtirloni 3y ago

This is natural to all "open core" and "source available" projects. Nothing new about that here. These tensions will always exist in not true open source projects.

lijok 3y ago

Seeing the discourse around OSS contributions reminds me how inexperienced and naive our industry is. We should invest heavily in teaching grads not just how to code, but how to manage relationships, build trust with your peers and above all; communicate effectively. Look at this PR and you’ll see a person who sacrificed their personal time to implement a highly requested feature. The company sees a person they’ve never interacted with, send a large PR without asking, implementing a feature that undermines their Enterprise tier, for which they now need to allocate resource to get it reviewed, revised and integrated.

b800h 3y ago

Well I hope to God the Enterprise code looks nothing like the pull request..

lukaszwojtow 3y ago

I guess they can fork that "open core", introduce that feature, then maintain it themselves forever. Pull changes from original open core and their "open" branch will be better than original. Of course they don't want this work. They want the company to maintain it instead.

kuschku 3y ago
And that's how I ended up forking dozens of projects spending a lot of my free time just maintaining my patches. Still better than having to give in to this open core enshittification.

hamilyon2 3y ago

When an equivalent MR would be issued to linux kernel, and it would be closed with wording "become a platinum supporter", will the reaction be the same? Something like this happened in the past with android fork and subsequent merge back. I think the answer "we already implemented this the way we wanted, it is in paid version, supported, by us, so pay us" is good leadership of the project, ensuring it's long term health.

deleted 3y ago

[deleted]

vrighter 3y ago

it took lots of months for the dev to partially (if you build from source) support trusting self signed keys. It literally made the product utterly useless for development

monkey26 3y ago

I work on a fully open project that sustains itself… And we really push for a ticket before any major work is done just to make sure it fits our scope. At the end of the day most contributions come from people as part of their job, and they move on. We’re left to maintain it.

nicognaw 3y ago

[dead]

starkparker 3y ago

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.

evanelias 3y ago
> 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.

neomantra 3y ago

[dead]

lakomen 3y ago

[dead]

advaitruia 3y ago

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.

htyden 3y ago

EE is short for "enterprise edition", I assume. I hope that is correct, and perhaps it is obvious to most people.

Vanit 3y ago

The second I saw this was about OIDC support I knew what's up. This is a great way to flood your support bandwidth with "doesn't work with X" complaints.

arsh4151 3y ago

[dead]

PeterZaitsev 3y ago

This is well known potential conflict between Enterprise and Community in Open Core project. If you are unwise and reject too many important features community may come together and excersize their right to fork.