Live data from Hacker News

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

github.com

151–160 of 202 posts

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

#151
post #47

Earlier quoted context omitted.

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.

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

No. "They need to eat" is a bullshit excuse. Everything is justifiable by "they need to eat".

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

#152
post #132
post #52

Earlier quoted context omitted.

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.

(a) You could do that here. (b) It's not exactly realistic to take on every open source project because the maintainers refuse certain simple fixes and additions. You'd very quickly become a hoarder of open source projects.

You can solve (b) by hiring people to do this for you.

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

#153
post #40

Earlier quoted context omitted.

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

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.

This is a false dichotomy: just like REST, people can choose to understand what people mean and still know they are incorrect.

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

#154
post #137

Earlier quoted context omitted.

From the maintainer's point of view, any new contribution requires work to vet it and check that it won't break something else, insidiously inject malware, etc., so what value it adds has to appear to be worth the trouble. Even when the contributor is certain that their PR is perfect and should be "no trouble" for the maintainer. This "hill" that has to be gotten over by the contributor is just a reality of the situa…

Just document it on the README: PRs are will not be accepted or vetted due to . It's as simple as that.

That's a very absolutist view. In reality, some PRs are good quality and worth paying the ongoing cost to maintain. Others are good quality, but not worth the ongoing cost.

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

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

#155

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

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.

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.

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

#156
post #113

Earlier quoted context omitted.

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

If they don't want to provide the best possible product and not accept outside contributions, they should not provide a free and open source repository.

"If you run an open source project, I'm entitled to have my contribution accepted"

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

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

#157
post #94
post #24

Earlier quoted context omitted.

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

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.

I used to pay for Gitlab but my experience with their billing and customer support was horrible so I stopped. Companies need to make it easy to pay them too.

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

#158
post #6

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

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.

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

#159

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…

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.

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.

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

#160
post #28

Earlier quoted context omitted.

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.

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.

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?

Post reply on HN