Live data from Hacker News

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

github.com

141–150 of 202 posts

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

#141
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…

Agreed. For the open core model to work in practice, there needs to be clarity in what’s open and what’s off the table. The problem is that open core appears to be, most of the time, not a serious commitment. At least I don’t trust “self-hostable” at face value anymore if there’s a company behind it. In the worst case, it’s bait and switch.

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.

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

#142
post #24

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

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

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

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

#143

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.

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.

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

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

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.

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

#145
post #47

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

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.

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.

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

#146

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.

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

#147
post #143

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.

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.

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.

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

#148
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…

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

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

#150
post #113
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.

> 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.
Post reply on HN