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

181–190 of 202 posts

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

#181

Post by Ferret7446 »

bmitc wrote: post #50
pydry wrote: post #32

Earlier quoted context omitted.

>show a fundamental issue with the open core model 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 madde…

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…

The license already sets expectations: THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND

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

#182

Post by Ferret7446 »

bmitc wrote: post #103
pydry wrote: post #90

Earlier quoted context omitted.

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

As someone who has received PRs, simply reading the PR is a demand. Hell, getting a notification about the PR is a demand.

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

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

#183

Post by Ferret7446 »

bmitc wrote: post #162
growse wrote: post #154

Earlier quoted context omitted.

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.

> and they're not obligated to publish their evaluation criteria God forbid people communicate.

Communication requires work from both side. Authors of open source software owe you nothing, including the work of communication.

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"

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

#184

Post by danenania »

IshKebab wrote: post #179
danenania wrote: post #167

Earlier quoted context omitted.

Thumbs up and hearts produce no notifications afaik so they could easily be unaware if they weren’t specifically following and checking up on the thread. And a PR being open for a long time could be an indication that it has been forgotten about rather than being purposefully ignored. You could definitely be right but you are also making some big assumptions imo that may not be true.

It has quite a few comments too. You get notifications for those. I'm sorry but there's no chance they didn't notice this. And they didn't even try and use that excuse!

Notifications which are often ignored. In a large project, emails from Github frequently aren’t even going to be opened by anyone.

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.

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

#185

Post by LegibleCrimson »

sowbug wrote: post #171
LegibleCrimson wrote: post #147

Earlier quoted context omitted.

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…

What I'm hearing is that you object to cases where the entity exerting the most control over the direction of an open-core project has an incentive to restrict the project in favor of something else the entity also controls -- usually their non-open project. It's a reasonable position, but I can imagine open-core projects that aren't conflicted this way, and open-source projects that are.

Exactly, I'm sure good projects exist, but that involves active goodwill from the company. The incentives are loaded in the favor of exploitation rather than public good.

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

#186

Post by glomph »

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 mean they did post on the open issue that they were working on it and got no reply.

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

#187

Post by bmitc »

Ferret7446 wrote: post #183
bmitc wrote: post #162

Earlier quoted context omitted.

> and they're not obligated to publish their evaluation criteria God forbid people communicate.

Communication requires work from both side. Authors of open source software owe you nothing, including the work of communication. 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?…

> Authors of open source software owe you nothing, including the work of communication.

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?

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

#188

Post by bmitc »

growse wrote: post #152
bmitc wrote: post #132

Earlier quoted context omitted.

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

Still not realistic. If this is the end state of open source software (i.e., "just fork it"), then it's not exactly a winning model, is it?

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

#189

Post by abenga »

growse wrote: post #160
prabhatsharma wrote: post #46

Earlier quoted context omitted.

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?

There's an easy enough way to prove or disprove this: fork the project, rename it, and overtake the original product in quality/features.

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

#190

Post by growse »

bmitc wrote: post #188
growse wrote: post #152

Earlier quoted context omitted.

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

Still not realistic. If this is the end state of open source software (i.e., "just fork it"), then it's not exactly a winning model, is it?

This is literally one of the primary points of OSS.
Post reply on HN