Comment by evanelias | Hacker News Reader

Comment by evanelias | Hacker News Reader

Parent Full thread

I don't see how it gives him the right to critique the maintainers over this specific topic and situation. He clearly has no qualms about profiting from their work himself. So why does he have a problem with them profiting from other contributors' work?

Gitea's stance regarding why certain features are Enterprise-only is quite reasonable: "Many features, and enhancements are prevented from being included in the Gitea project due to high upfront costs, and lack of resources to maintain them. This leads to them not being developed or accepted into the project. With this offering, we are able to provide a version to paying customers with a support contract, allowing us to develop and maintain these features for the Gitea project." https://docs.gitea.com/enterprise/faq#why-is-this-a-paid-off...

That certainly sounds like it would apply to this particular PR, which is a 4000-line diff affecting 144 files, and with a 350+ comment discussion history spanning over 16 months. Review, cleanup, and long-term maintenance for this sort of PR are faaaaar from free. I can understand 100% why this would be an Enterprise-only feature, and complaints about the maintainers' profit motive in that context seem utterly ridiculous to me. Especially when the commenter is complaining about a "massive conflict of interest" when not mentioning his own extremely similar conflict of interest.

If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch.

It may be expensive; that’s why there was a community-funded bounty placed on it.

If the complaint is that Gitea is too complex to maintain for free, then great, start a company around it to fund a private fork. But then you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain and care about. Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest.

> If it’s good enough to merge into the enterprise branch, it’s good enough to merge into the community branch.

It's not clear yet that the Enterprise version of this feature is the same code as this PR, right? Do you have evidence otherwise?

> It may be expensive; that’s why there was a community-funded bounty placed on it.

How much was the bounty, who funded it, and who receives it? I don't see any information about that on the PR or the linked issue.

> you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain

If the community really maintains it 100%, then they would all be maintainers and by definition they would be able to merge it already. That doesn't appear to be the situation here.

> Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest.

Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project?

And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well?

> Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project?

Absolutely not, and I never made that claim.

> How much was the bounty, who funded it, and who receives it?

I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better.

> Do you have evidence otherwise?

That was the thrust of the submission. I tried to link the fragment but I don't think Hacker News allows that and erased it: "Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it."

As for conflicts of interest, perhaps. Who knows the actual extent of it? Posting here is intended a matter of visibility rather than activism; that's why I'm so surprised that the thread was closed on grounds of brigading, since that was neither the intended nor the actual effect.

> I happen to have some inside knowledge here, that at least Allspice and Copia provided parts of the bounty. Some of that is mentioned in the thread but the transparency could be better.

Can you please link to whatever part of this bounty is public? I just expanded searched the PR comments for "bounty" and absolutely nothing came up, and likewise on the issue linked from the PR.

In any case, if the bounty is coming from companies other than Gitea Ltd, and it presumably will be paid to the PR submitter (and not to Gitea Ltd), then how does this bounty help compensate for the massive amount of time Gitea Ltd employees spend on code review and long-term maintenance of this huge PR?

> That was the thrust of the submission. I tried to link the fragment

That quote is an unsubstantiated claim from the commenter making the complaint. It might be accurate or it might not. As a neutral third party I have no way of evaluating that, as no evidence has been presented. Personally, I haven't flagged this thread, but I can absolutely understand why others did so, given the complete lack of any concrete evidence of the main thing being claimed here.

> Do you really think it is accurate to say Gitea LTD is merely gatekeeping and not actually doing a ton of work to steer and maintain this project?

One does not preclude the other.

> And since the complaining commenter is CTO of a company who benefits from being able to include this feature in his company's own private fork, doesn't he have a conflict of interest as well?

He isn't controlling what goes into community repo, so that's irrelevant.

Hi to be clear, there is a TOC of 6 members which there are elections yearly for the community spots, and it is the formal body that leads the project. The project has also more than doubled the number of community maintainers that can merge PRs, and over the past two years active PRs (merged, review, etc..) has gone from 100/mo to ~400/mo. But reviews from maintainers hold equal weight, and if they didn't then I would've been able to merge one of my PRs that took over 2 years to get in much faster.

I commented here: https://news.ycombinator.com/item?id=41514547, but tldr, its different code (a much more minimal implementation), and the PR isn't being prevented from merging, there is review that has feedback that hasn't been addressed yet. We have seen with other DB tables how when they grow significantly (and if you are logging every action this will happen) then performance is impacted. So there are suggestions on ways of addressing it in a way that wouldn't require manual intervention from users to resolve while waiting for additional PRs.

Reply on news.ycombinator.com