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

https://github.com/hoppscotch/hoppscotch/pull/3266

by angry_octet • 2 years ago

175 184 2 years 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• 2 years 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

byefruit3• 2 years 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?

pydry11• 2 years 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.

nrabulinski2• 2 years ago

The only freebie here is the PR implementing a major feature which people were excited for, that was ignored for months

gtirloni5• 2 years ago

The PR author apparently didn't want a freebee and actually spent time contributing.

CoolCold• 2 years ago

this, +1 from me

manojlds• 2 years ago

That's the definition of Open Core. You cannot say open core and also say they didn't accept the PR for a feature that is there in EE.

Pet_Ant• 2 years ago

The features in the EE should be there because the effort requires expertise and cost. If it can be done by the community then it’s not really enterprise grade.

vikramkr2• 2 years ago

Their code is open source you can fork it and patch it - idk what you mean by "really" open source lol. It just - is open source, there's the code there's the license. A blimp isn't not a blimp because it's got a different color of paint

mariocesar3• 2 years ago

This is expected but still disappointing.

urig• 2 years 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.

kuschku8• 2 years ago

"get" "for free"? Where do users expect to "get" something for free? In fact, users are offering something "for free".

mariocesar3• 2 years 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.

arcfour• 2 years ago

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

SushiHippie• 2 years ago

Ah, the SSO tax

For others that are not aware: https://sso.tax/

Avamander2• 2 years 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.

paulryanrogers2• 2 years 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.

Avamander2• 2 years 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• 2 years 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.

IshKebab8• 2 years 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-code2• 2 years 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

gehen88• 2 years 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.

kuschku8• 2 years 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.

prepend3• 2 years 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.

madeofpalk3• 2 years 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.

nailer2• 2 years ago

OSI conformant license is the only definition of open source - the OSI coined and popularised the term - but you’re otherwise correct.

prepend3• 2 years 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.

mritchie712• 2 years ago

for most b2b software (especially one with a UI / requires a good design, e.g. a CRM or BI), I prefer to just pay a reasonable subscription and get a good product in return. Most "open source alternatives" in these categories are a farce.

mariocesar3• 2 years 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://www.usebruno.com/

Good timing to find alternatives.

goku122• 2 years ago

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

haolez2• 2 years 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.

pm902• 2 years ago

Temporal. Kubernetes. Postgres. MySQL (MariaDB). Any all of Hashicorp tooling (Terraform, Consul, Vault etc).

gtirloni5• 2 years ago

Hashicorp tooling is not a good example anymore. They are source available, not open source anymore.

evanelias2• 2 years 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.

haolez2• 2 years ago

From your list, I think only Kubernetes and Postgres fit my contraints and they don't have (mostly) a SaaS feel.

gr4vityWall• 2 years 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. :|

sethops12• 2 years ago

Why didn't they discuss the feature with the maintainers before working on it?

Karellen2• 2 years 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• 2 years ago

I mean they did post on the open issue that they were working on it and got no reply.

PartiallyTyped2• 2 years 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.

madeofpalk3• 2 years 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• 2 years 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• 2 years 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.

klabb32• 2 years 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• 2 years 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.

IshKebab8• 2 years ago

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.

soamv• 2 years ago

Just accept the grief and venting

Maintainers do not owe you this, in addition to maintaining the software that you can use for free. You're entitled to be upset, and they're just as entitled to say "please go somewhere else to vent, we're busy".

madeofpalk3• 2 years ago

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.

SergeAx4• 2 years ago

Why should they accept venting and grief on their territory? Let venters and grievers do their stuff on some other premises. HN, for one, is particularly acceptable.

byefruit3• 2 years 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• 2 years 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• 2 years 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.

pydry11• 2 years 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.

bmitc12• 2 years ago

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

remram• 2 years ago

This "issue" you claim to have found is the entire definition of "open core". I don't think there's any hidden defect here.

pjmlp2• 2 years ago

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.

pessimizer• 2 years ago

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.

SergeAx4• 2 years ago

No, you are wrong here. "Open" means anyone can fork the code, modify it to their taste/needs and maintain their fork from that moment on. Authors of open projects doesn't implicitly owes anything to anybody, unless they have a separate agreement.

Also, most devs want to create "good enough" software, not "the best possible".

LegibleCrimson5• 2 years ago

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.

roamerz• 2 years ago

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

Sytten2• 2 years 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• 2 years 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.

pydry11• 2 years ago

I think the problem is entitlement more than terminology.

pjmlp2• 2 years ago

We have had free source code for decades, it is also a reason why UNIX didn't die inside Bell Labs.

The difference is that older generations understand developers have bills to pay.

vextea• 2 years ago

Its the combination of disappointment that it wasn't merged and that it took several months to get back on a significant contribution (whilst adding their own version into their enterprise offering in the meantime). Of course there's going to be some emotions, and rightfully so.

blueaquilae• 2 years ago

They just let the guy create the feature and it will be integrated to the EE.

prabhatsharma4• 2 years 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.

kuschku8• 2 years 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.

prabhatsharma4• 2 years 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.

move-on-by3• 2 years 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?

IshKebab8• 2 years 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.

danenania4• 2 years 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.

latortuga• 2 years ago

So they can merge/not merge but they aren't allowed to talk/not talk? Just because I have an inbox doesn't mean I have to respond to everything that shows up in it.

catlifeonmars• 2 years ago

They’re allowed to do whatever they want. Doesn’t mean that they weren’t shitty about it.

move-on-by3• 2 years ago

I never said they were not ‘allowed’ to do anything, I also never said they ‘had’ to do anything. It’s their project and can handle it as they wish- I thought I was pretty clear on that point.

SergeAx4• 2 years ago

But the code is still there and we still can build Docker images of it. The PR itself is still searchable, both internally and externally.

move-on-by3• 2 years ago

Right, it’s still all there. It just leaves a bad impression behind for absolutely no reason. It seems like there would have been a better way to achieve the same results. This is way outside my wheelhouse but something like:

Thanks for the PR, it’s clear you spent a time on it. We already support this on example.com- so I’m going to close this PR as a dupe. Next time, please feel free to start a conversation with us prior to starting any large PRs and we can make sure to align on goals.

Same end result- gives people a link to your SASS offering and doesn’t leave a hostile impression behind. It costs nothing to be nice.

INTPenis• 2 years ago

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

pm902• 2 years 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• 2 years 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.

gtirloni5• 2 years 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

anthomtb• 2 years 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?

danenania4• 2 years ago

You could, but then you will have to continuously monitor the main branch and pull in updates if you want new features, bug fixes, security updates etc., and possibly you'll need to deal with merge conflicts.

You might also need custom release, install, and upgrade tooling for your fork. And if there are bugs in anything that has diverged, it will be up to you to fix those yourself.

It's significant extra work, in short.

marcosdumay• 2 years ago

Can you fork it? If so it's open source, if not, it's not.

There's no subjectivity for you to have an opinion differently.

And yes, the authors are free to run their project any way they want. You are free to not interact with them if you don't want, and since they published the code, you are also free to fork it.

Open core is an incredibly hard model to get right. Make your code too free, and you are at the risk of being pushed off the market by some large player that doesn't need to invest on it; make your code too closed and you'll become an asshole and your customers will go away. Often the margin here is negative, and both too free and too close intersect instead of having some space between them.

SergeAx4• 2 years ago

Without SAML auth, you simply cannot deploy it yourself for your internal users

Of course you can, you just need to do (relatively small) extra job syncing credentials with your IDP.

asadalt• 2 years ago

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

prabhatsharma4• 2 years ago

Agree

koolhead• 2 years 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?

LegibleCrimson5• 2 years 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.

goku122• 2 years ago

The real problem here is that the contributor (presumably) didn't give a heads up before implementing the feature. The maintainer also stayed silent for nearly 4 months. This incident shows how important it's for them to communicate.

Other than that, there is no problem contributing to an open core project if it gets accepted. The community gets to benefit as well. On the other hand, a CLA in such a project is something you need to avoid by all means.

sowbug2• 2 years 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.

LegibleCrimson5• 2 years 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.

int_19h• 2 years ago

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.

zellyn• 2 years 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.

Karellen2• 2 years ago

There's always `quilt`

https://savannah.nongnu.org/projects/quilt

https://manpages.debian.org/bookworm/quilt/quilt.1.en.html

foxhop• 2 years ago

a set of patches to run on the Repo works but it breaks when a big refactor happens upstream.

PartiallyTyped2• 2 years 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.

gtirloni5• 2 years 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• 2 years 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• 2 years ago

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

lukaszwojtow2• 2 years 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.

kuschku8• 2 years 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• 2 years 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.

vrighter• 2 years 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• 2 years 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.

starkparker• 2 years 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.

evanelias2• 2 years 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.

advaitruia• 2 years 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• 2 years ago

EE is short for "enterprise edition", I assume.

I hope that is correct, and perhaps it is obvious to most people.

Vanit• 2 years 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.

PeterZaitsev• 2 years 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.

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

Related Stories