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

What you're saying is you want them to continue maintaining it at their cost because the community don't want to?

The people who agree with that are the ones who see FOSS as a freebie.

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.

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

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

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

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.

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.

For an enterprise with hundreds of users, that would mean thousands or tens of thousands of accounts to manage manually. Totally impossible.

It's a feature that's absolutely mandatory for enterprises, but "nice to have" for anyone else. That's why it's a great feature to use for price discrimination.

Because afaict, the only way to get proper 2FA with this project is by paying them for SSO.

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.

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.

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.

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.

The author/community is welcome to exercise those options that MIT affords them, such as forking and launching a competing product.

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.

From the top of my mind, I remember Apache Airflow, which has a lot of open core competition right now.

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.

On one hand, I get it, but on the other hand, it could have been handled better.

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.

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.

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

a project's issue tracker is first and foremost for the maintainers, any "community" that builds up there is secondary.

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

_This_ is the sense of entitlement that people (rightly) disparage.

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.

There’s still value-add in eg source-available products. So there’s a meaningful spectrum of openness, assuming the decision makers are willing to explain their commitment upfront and stand by it.

They can't rely on the contributor to be quick to respond to issues and flaws fall back on them.

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.

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.

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.

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.

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

With licenses where a company owns and limits the IP, the community is stuck and can just stop using the project.

I think that’s a big difference.

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.

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.

Even something as simple as "I built this for my own needs and have open sourced it for open knowledge and will only fix issues that further my own needs and will not accept anything but simple PRs" goes a long way.

Is it different than someone advertising their FAANG's credentials?

Once again, if you feel every contributor is entitled, don't open source your project or disable issues and make it very clear issues and contributions are not welcome.

It 100% is entitlement, and open source is not a "product" because you don't pay for it. The developers of open source owe you nothing.

For the umpteenth time in this discussion, no one said they did. And please note what I implicitly defined as supported, which is basically that a non-antagonistic conversation can be had about issues and contributions. That is not entitlement.

Actually you did when you said, among other things:

>To me, it just sets an implicit expectation of "this is something I support"

>Again, expecting a product to be supported unless otherwise stated is not entitlement

If you describing an expectation, you are describing something that you feel like you are owed, for whatever reason. You fully exhibit the culture of entitlement surrounding open source that I was describing.

Why even participate in open source if everyone seems to hate it and be on edge?

You were given something for free. That doesnt confer any rights, legal, moral or otherwise.

Drive by pull requests are not always welcome for any number of reasons which are the sole prerogative of the project maintainers who owe you nothing.

PRs are even worse when theyre big. If you do a large PR without informing anyone you should expect by default for it to be ignored.

> You were given something for free.

I wasn't given anything. Something was released into the open to be interacted with at some level. If a maintainer wants to complain about any interaction whatsoever, then take it private or disable issues, write a contributing (or non-contributing) guideline, and reject PRs professionally.

> That doesnt confer any rights, legal, moral or otherwise.

That's completely obvious. But like I said, a simple PR or issue filing does not imply a demand of the maintainer by the reporter or contributor. So you're basically showcasing what I'm saying isn't great, in that maintainers have this bias already set in their mind that any communication to them is a demand of their time and effort and a claim of rights, which it's very often not.

This "hill" that has to be gotten over by the contributor is just a reality of the situation. I don't see any way around it.

Maintainers get to decide, and they're not obligated to publish their evaluation criteria.

God forbid people communicate.

At a baseline, you are responsible for the maintainer's communication burden too, such as reading in between the lines and accommodating for their schedule (they may need weeks to respond).

If you don't think it's a burden, then why not fork the project and become the maintainer yourself?

"Before you criticize someone, walk a mile in their shoes"

This is a tiring discussion, because this is exactly what I'm talking about. No one is here talking about how anyone owes one anything. In fact, no one in any part of life owes one anything if you'd like to go that route. But effective communication and expectation setting avoids the vast amount of communication issues. If a maintainer wants to release software and then complain about it every step of the way and claim everyone is demanding how they spend their time and effort and not reading their mind and now bowing at their feet, that's their prerogative. But that isn't some righteous path. It's an annoying one.

If maintainers are such sensitive souls, then they should either: communicate early and stop complaining, or take the project private or disable issues and stop complaining. Why almost go out of your way just to complain and make your job harder?

You were. You were describing what you "expect" from maintainers. That is the same thing as saying what you are owed.

E.g. when I make a contract I expect the other side to honor it. I am owed that because they signed a contract.

I expect people to not spit on me on the street - that's part of an unspoken societal contract.

If somebody makes a commitment, I expect them to follow through on it (even if they are not legally bound to) - again, part of an unspoken societal contract.

If I email somebody, I don't expect a response under all circumstances - again, unspoken societal contract.

What you were describing above were additional expectations you have on people who gave you something for free in exchange for nothing.

You're not owed an explanation just because somebody gave you something for free. The maintainer might have complicated reasons for wanting to accept some PRs and not others and might not want to put the work in to write it down.

They're not obligated to explain this to the all and sundry just in case somebody wants to raise a drive by PR.

If you think they are obligated, that's indicative of a culture of entitlement.

Reading the message is a demand. Reading the code is a demand. Thinking about whether the approach is satisfactory is a demand. Thinking of a response is a demand.

If you want to maximize your chances, you had better put as much effort into making things as easy for the maintainer as possible, such as including alternate approaches you considered and why they were not chosen, written as succinctly yet clearly as possible. Your code should completely match the existing style and formatting of the code; your own style preferences are irrelevant. Of course, you need to be as polite as possible without being condescending. And even then, you are owed nothing.

That is the approach I take when writing my PRs, and my success rate is rather high (but I still get rejected or ignored).

What we do know, is the maintainer chose to ignore any communication related to this PR, for months, until someone pointed out it was helpful keeping the PR open, as it allowed people to apply it themselves locally. Then, all of a sudden, the PR is closed, and communication finally occurs. Could be coincidence, but that's doubtful considering the time span and specific comment involved.

Which is entirely their prerogative. All they did was build something and give it away for free.

As I said, it's a culture of entitlement that drives people to think that anyone's PR should be looked at is owed.

At the end of the day, maintainers for complex projects need to get paid.

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.

Just because you created an amazing pull request that everyone wants merged in, doesn't mean the maintainer should or want to do so.

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.

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

This is perfectly fine.

If that has to happen via forking and directly competing with them, so be it.

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?

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

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.

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.

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

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

In fact, you have no idea and are confidently speculating about something which you have no way of knowing. But don’t let that stop you I guess.

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.

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.

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

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.

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?

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.

I don't think there's any expectations beyond that about internal hosting capabilities or anything else, certainly not in the license anyway.

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

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?

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.

It's a reasonable position, but I can imagine open-core projects that aren't conflicted this way, and open-source projects that are.

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.

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.

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

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

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.

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.

Still better than having to give in to this open core enshittification.

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.

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.

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.

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.

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.

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