from Hacker News

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

by angry_octet on 3/10/24, 11:47 AM with 184 comments

by byefruit on 3/10/24, 1:37 PM
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.
by madeofpalk on 3/10/24, 1:37 PM
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.
by move-on-by on 3/10/24, 1:59 PM
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?
by pm90 on 3/10/24, 2:06 PM
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.
by arcfour on 3/10/24, 1:35 PM
Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.
by nrabulinski on 3/10/24, 1:29 PM
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
by gr4vityWall on 3/10/24, 1:36 PM
What a sad page that merge request is. I feel bad for the developer who waited 4 months and got that as a response. :|
by zellyn on 3/10/24, 2:38 PM
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.
by mariocesar on 3/10/24, 1:35 PM
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.
by starkparker on 3/10/24, 4:02 PM
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.
by prabhatsharma on 3/10/24, 1:42 PM
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.
by monkey26 on 3/10/24, 3:39 PM
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.
by asadalt on 3/10/24, 2:07 PM
Other than months in silence, I don't see why this is wrong. Granted it sucks for the OP.
by lijok on 3/10/24, 2:44 PM
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.
by advaitruia on 3/10/24, 6:42 PM
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.
by PeterZaitsev on 3/13/24, 1:31 PM
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.
by lukaszwojtow on 3/10/24, 3:01 PM
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.
by INTPenis on 3/10/24, 1:59 PM
The point of open source is that you fork it and add this feature, and have to maintain the project yourself.
by haolez on 3/10/24, 1:36 PM
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.
by prepend on 3/10/24, 1:35 PM
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.
by hamilyon2 on 3/10/24, 3:23 PM
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.
by gtirloni on 3/10/24, 2:41 PM
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.
by Vanit on 3/10/24, 9:22 PM
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.
by htyden on 3/10/24, 8:38 PM
EE is short for "enterprise edition", I assume.
I hope that is correct, and perhaps it is obvious to most people.
by b800h on 3/10/24, 2:48 PM
Well I hope to God the Enterprise code looks nothing like the pull request..
by LegibleCrimson on 3/10/24, 2:27 PM
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.
by vrighter on 3/10/24, 3:32 PM
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
by koolhead on 3/10/24, 2:11 PM
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?
by Sytten on 3/10/24, 1:39 PM
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.
by mariocesar on 3/10/24, 1:32 PM
This is expected but still disappointing.