Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

101–110 of 202 posts

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

#101

Post by evanelias »

pm90 wrote: post #61
haolez wrote: post #9

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.

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

MySQL and MariaDB both have enterprise editions, and they (completely understandably!) will not merge pull requests which attempt to re-implement enterprise-only features.

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

#102

Post by latortuga »

move-on-by wrote: post #37

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…

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.

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

#103

Post by bmitc »

pydry wrote: post #90
bmitc wrote: post #50

Earlier quoted context omitted.

I personally think it's up to maintainers to set expectations. Many times maintainers will use open source projects on their resumes, advertise them on forums, give presentations, and then will be antagonistic towards even very friendly and objective issues and PRs. 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…

No. It's up to contributors to set expectations about the work they do with the project maintainer before they do it if they have any wish to see it merged. 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 wors…

There are burdens on both sides and communication on both sides is important. I have had even the most simple reports receive antagonistic responses as if I was demanding (I wasn't) free work from the maintainers. That's unacceptable communication in my view. Any such communication will eliminate any willingness of mine that I had to help contribute.

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

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

#104

Post by foxhop »

zellyn wrote: post #80

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

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

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

#105

Post by anthomtb »

pm90 wrote: post #51

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

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?

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

#106

Post by School-Cotton »

prepend wrote: post #52
bmitc wrote: post #41

Earlier quoted context omitted.

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

But with open source projects the community has the option to fork and carry on the code as the community wishes. 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.

You can fork this, otherwise it would not be open source by definition.

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

#107

Post by Karellen »

sethops1 wrote: post #82
gr4vityWall wrote: post #10

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

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

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.

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

#108

Post by lukaszwojtow »

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.

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

#109

Post by marcosdumay »

pm90 wrote: post #51

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

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.

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

#110

Post by dugite-code »

IshKebab wrote: post #98
arcfour wrote: post #6

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

That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO . That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it. (Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean li…

> only enterprises care about SSO.

Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature

You might have an argument with saml, because it's a right pain, but not OIDC

Post reply on HN