Gitea blocks PR from community, charging $ for open-source contributions | Hacker News Reader

Gitea blocks PR from community, charging $$ for open-source contributions

github.com

68 pointsironmagma79 comments

The controversy here is described in the following comment:

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

> This is a cynical take, but I have raised these concerns in private channels and there has been no evidence to refute it. If Gitea Ltd. wants to focus its efforts on the private fork and to make money, that is fine with me, but unfortunately, they also decide what gets merged here, so there is a massive conflict of interest (cough open core). Since Lunny has blocked it and refuses to say why, it appears we are stuck.

> I have asked them to commit publicly to not merging code in their private codebase that is still open for review upstream, but that hasn’t been well received, leaving me and some other members of the community pretty disheartened.

The person who made that comment appears to be CTO of a company whose product is a (seemingly closed-source?) fork of Gitea [1].

I mean obviously that's fine legally, it's MIT licensed, and also his company contributes code to Gitea. But, it seems rather hypocritical to complain about the maintainers of Gitea having a private Enterprise repo for profit, when the person complaining does the exact same thing.

[1] "AllSpice Hub is based on a fork of Gitea, so you get all the power and functionality of Gitea, but with the hardware specific features that let you see schematic changes instead of binary blobs." https://allspice.io/post/which-git-clients-work-for-hardware...

He may be, but also contributes quite heavily to the open source repo and sponsors bounties. It may not absolve him of profit motive, but at least earns the right to critique the Gitea administration.

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.

I'd like to understand whether Gitea really merged a version of that code, or if they had a separate implementation that's in the enterprise version.

If they've merged that code but refuse to make it available in the community version - when it's been contributed by the community - that's one (very uncool) thing. It's slightly different if they already have the feature from homegrown code and they don't want to merge a second version in the community version which causes additional maintenance headaches for them.

I commented here: https://news.ycombinator.com/item?id=41514547, but it's a different code, much more of an MVP than the fully fleshed-out functionality of this PR. Once the PR is merged, effort to resolve conflicts would be minimal, as the other code logs only a fraction of the PR and doesn't overlap in most places.

I commented here: https://news.ycombinator.com/item?id=41514547, but I wasn't able to continue my conversation with Kyle due to health reasons, but as I am recovering I am working on continuing them.

This is very shady. If there were plans to introduce a certain feature in their proprietary code base, then it should have been raised much earlier in the PR so people don't spend time and energy developing this. Further, "already merged a version of this code into the private gitea repo" euh, hello licensing?

Gitea was already controversial in the sense - why leave a perfectly good closed source solution (GitHub) to another closed solution?

I think, for anyone seriously into self-hosting their source codes - https://forgejo.org is the way forward.

I've been very wary of Gitea since Gitea Cloud and CommitGo, Inc. became a thing. One commercial entity (Gitea Ltd.) is one thing (although the trademark fiasco around that was a bad look on its own [0]), but when a second for-profit quietly spun up around the same open source project with little explanation I got a bit sketched out and have been cautiously using Forgejo instead (it has its own problems I won't get into here).

That said, I'd like to see more information before we jump on the outrage bandwagon. The only thing we have here is a PR that was blocked by a maintainer who's not very communicative and the speculation of a random participant in the PR discussion that they're intentionally blocking the merge because of a conflict of interest with the enterprise version. That's not a lot to go on, and there are other possible explanations besides malfeasance.

[0] https://news.ycombinator.com/item?id=33394280

Just to add some heads up, CommitGo was on the roadmap, but establishing a company in the US takes time, so the initial org was created so that something could exist while the primary one was established. Hopefully more entities that are localized to specific geographic regions can be created as funding maintainers cross borders is a headache.

edit: we (the project and the company) are also receiving advice from several major open-source foundations on what establishing a foundation for the project would look like.

Heads up would have been explaining this at the time and not silently transferring ownership of the domain to a second for-profit entity with no lead up and no announcement [0]. I'd have thought that after the trademark fiasco you'd have learned to be more open about your intentions for your for-profit arms, but it seems you might have taken the opposite lesson.

[0] This announced Gitea Cloud but gave no explanation for why a second for-profit was created instead of just using the already-controversial Gitea Ltd: http://web.archive.org/web/20231127091431/https://blog.gitea...

Hi. I'm techknowlogick, one of the two reviewers who have requested changes on this PR. A couple of clarifications: 1. I hadn't been able to continue my conversation with Kyle due to illness, and I am still dealing with it, but I am working on continuing that conversation. 2. The feedback that is holding up the PR is technical. Logging that amount of data has performance implications, and one of Gitea's main tenants is that it can run on reduced hardware. We know what impact it would have, as we are dealing with it from other tables. We don't have the ability to backport migrations to add indexes, etc.. (something that CommitGo has put a bounty on, though), so if it gets merged now and "well fix the filtering/etc.. later" means that if it gets merged then we have at least 6 months of bug reports around performance issues. 3. the code that is in the alternate distribution is different and doesn't include that PR. It is a few SQL inserts to log logins, package downloads, and git clones. 4. I am largely in favour of getting the PR merged, but if it means degraded performance and bug reports that we have to ask users to create DB indexes manually, that's something that I would hope could be avoided.

CommitGo, is the largest contributor to Gitea, and has contributed Actions in its entirety to the project. If the goal is to keep code away from the project for profit, that would be the one.

The priority of the company is to ensure the continued success of Gitea.

A recent comment indicates that this outcome was more like a mistake and less line the skulduggery that the title indicates.

Public shaming might be a good tool for this kind of thing in general but maybe in this case it was premature.

Also let's please be careful about creating situations that pressure a maintainer to merge a PR before they're fully comfortable with it. That's how ssh got backdoored via xz (no reason to believe that that's what's happening here).

If somebody wants to embrace YOLO with their $$ project and be a bit more cautious with their OSS project, that's ok.

Didn’t xz get backdoored through extreme cunning and an exhausted solo maintainer?

Yes but the exhaustion was not 100% organic. There was a bit of social engineering towards wearing the maintainer down even further.

I'm just pointing it out because I think it's going to be a tricky balance to strike. How can we, as a community of people who care about free and/or open source software tell the difference between:

- a good faith effort to inform the wider community of a maintainer who is behaving badly

- a bad-faith contributor pressuring an overworked maintainer to include a malicious commit

I think you're the former, but I'm rather worried about the latter. And I'm interested in strategies for telling the two apart.

I’m actually neither. I’m a big fan of forks. If something isn’t working out well, it should be very easy to create a fork and switch to the fork (i.e. forks should be lightweight just like branches).

We can’t rely on everyone to follow our schedules, so if there’s a desire we should take the lead on getting it done instead of dragging each other down. As such, I didn’t post this to shame anyone, mostly to provide an onus for switching to a fork. (Or I should say, another onus, since there are already a few reasons to not contribute to Gitea, mostly coming down to size of the project and inertia preventing refactors or redesigns.)

That's a very reasonable position to have, sorry for jumping to conclusions :)

xz was not maintained by for profit corporation.

Hi, yes. That was me. I'm dealing with some health things and wasn't able to do much until recently, and I am working on continuing that conversation.

I wonder what the legality of saying "this PR is available under the MIT license upon being merged into this repo" would be. A PR is copyrighted, and I guess it's just implied that a PR is available under the same license as the main repository, but an explicit PR license could override this (maybe?, IANAL).

I suppose they could merge it, copy it under the MIT license, and then remove it, which overall seems kind of silly, but it would at least get your PR merged. Plus, this trick would look really bad from a PR perspective.

GitHub's TOS include a clause that says you agree your PRs are under the same license as the project ("license in = license out"). I don't know what happens if you assert a specific license that contradicts that. It would be bad to do what you say, because if the PR is never merged, then third parties could never use the PR in forks. A better alternative would be to offer the patch under MIT or GPL at the maintainer's discretion, but that would create more confusion than it's worth.

After all, nobody is currently prevented from maintaining Gitea with the linked PR merged. The problem is that the major community maintainer is prevented from merging it due to a conflict of interest. License juggling won't help with that.

Your proposed "trick" does not seem to achieve anything - the code is still not present in the main ditribution, no?

Good to know.

My proposed "trick" was just to illustrate that it's futile to make a contribution MIT licensed for some people/purposes and not others. I think we're in agreement on this.

So the evidence here is that the Gitea Enterprise page now advertises an audit feature? Mainly for thoroughness: how sure are we that it's the same code?

We're not, and they're still in the process of discussion. It seems a bit early to fork and witch-hunt [0]:

> So clarification here: you asked me about that, but I haven’t been able to respond to you due to my illnesses and I’m just getting back on my feet now. So it’s not that it hasn’t been well received, it’s that I’ve been physically unable to respond to you.

[0]: https://github.com/go-gitea/gitea/pull/24257#issuecomment-23...

The quoted comment does say

> Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it.

So if they can be trusted at face value, "a version of this code" means it's the same code, and would be an incorrect way of describing "an analogous feature with an unrelated implementation". But they could be making a mistake, of course.

Yeah, I read that. I'm just not prepared to rule out a mistake, either. For example, to play devil's advocate, if Gitea decided they didn't like this code but did want an audit feature, they might throw together their own. (Which would still be a bit of a dick move, but not on the same level.)

I commented here: https://news.ycombinator.com/item?id=41514547, but tldr it's different code, much more of an MVP than the fully fleshed-out functionality of this PR. Once the PR is merged, effort to resolve conflicts would be minimal, as the other code logs only a fraction of the PR and doesn't overlap in most places. Hopefully the technical concerns can be addressed and the PR can be mereged.

Why would someone be motivated to contribute free code to Gitea after everything? Is "forgejo" really so stupid a name that people are willing to risk being exploited by Gitea?

I'm still very much on the fence about Forgejo. I use it, but I don't trust the maintainers after seeing how they handled dissent in appointment of a moderator, and I wouldn't invest time in contributing to it directly at this stage.

I added more details here for the curious: https://news.ycombinator.com/item?id=41489578

That kind of stuff is unavoidable with orgs like this (though tbf I've seen it more with European orgs...). Anywhere there's a group of people, there's a smaller group of people who are power hungry psychopaths.

Considering the supposed evidence was deleted, I'm not just going to take your word for it (next time, use archive.org or similar). But either way, I don't care. The software works very well for me, and stroking an egomaniac or two's ego is a small price to pay for that.

I don't expect you to take me at face value (though I will note that I linked to an HN discussion where other people comment on how weird the behavior was even before they nuked the whole discussion), but I will continue to share the story because I'm uncomfortable with how thoroughly quashed it was.

I'm relatively confident it was on archive.org and has been purged by the Forgejo team. There's only one entry on archive.org and it's a month after the event.

And I agree—the software works and I use it and I'm less sketched out by Forgejo than I am by Gitea. I'm just explaining why I'm not going to sink anytime into contributing to their project.

Seems like just some people wanting to merge stuff ASAP and others having other priorities/IRL stuff and some commenters shilling our unfounded conspiracy theories.

Yes, the 3k+ LOC, 144 file PR is 1 year old and still not merged. Join the club.

You're missing the point, if this was just an unmerged PR no one would care.

But it's likely the paid Enterprise edition has merged this already, and now the same entity has an incentive to block this from the OSS version.

> it's likely

Says who? A random commenter on the thread who's not even the submitter of the code?

Okay let's charitably assume this PR for an Audit feature is completely unrelated to the Enterprise Audit feature introduced several months later.

The reviewers of the OSS code are still heavily incentivized to block this PR. Worse, if they knew a similar feature was being built for enterprise and this would never be merged into the free version, they be wasting months of contributors' time and effort.

I commented here: https://news.ycombinator.com/item?id=41514547, but it's different code, much more of an MVP than the fully fleshed-out functionality of this PR. Hopefully, it can be merged once the technical feedback has been addressed. We've seen with other areas of the project how DB degradation can impact the whole application, and have to deal with reports from users when they run into that. I'd rather the performance impact had at the very least a work around before it gets merged so when those issues are opened, then triaging them is much easier.

The title is sensationalized. I read the whole thread. Gitea doesn't seem to be "blocking" the PR. They aren't preventing it from going in a release. However, they did pull the in-progress PR into their private repo early, presumably in order to make more money. Not great, but not bad faith.

"Blocking" would suggest to me that the PR is rejected but still ends up in the closed-source codebase, which isn't the case at all.

@dang I flagged this because we're at risk of brigading a community over a nothingburger.

> they did pull the in-progress PR into their private repo early, presumably in order to make more money. Not great, but not bad faith.

Is this fact, or just speculation? I read the start and the end (though not the 175 items in the middle), and all I see is a vague block by a maintainer and speculation that it's because they have a similar feature in enterprise.

Hypothetically, if they never finish reviewing the PR, isn't that the same as "blocking"? Ghosting is still considered a rejection and arguably a much worse one.

Brigading? Well I definitely didn’t intend that, although I also don’t see anyone from here having commented on the thread so I don’t see how that is reality.

Stall may have been a better word, although this PR has been crawling along for over a year now, with little response from the maintainers. If something is neglected for long enough it’s topologically equivalent to blocking it.

I did say "at risk of" - the front page of HN is a powerful place. :-) Looks like my fears did not come to pass.

>... but not bad faith

That is literally in bad faith.

The in-progress PR was not pulled in, different code was written to log a small subset of events that this PR does. I commented here: https://news.ycombinator.com/item?id=41514547, but the PR is more fully fleshed-out and has more functionality, which hopefully can be merged.

In the link is a comment describing how Gitea LTD is stalling on a pull request and instead merged it into their private repo which they charge money for.

This is a PR that was funded with a bounty with the idea of contributing to open source.

Now is a great time to switch to Forgejo :-)

If this doesn't track well, I suggest you repost indicating, in subject, that they're also withholding the patch from the OSS version.

I'm not sure how to write the subject that way, within character limits, but there is zero outrage at charging $$ for OSS contributions, so the subject seems very "meh".

After all, millions of companies do that.

Good suggestion, updated the title. Thanks!

TBH the new title suggested me that they were charging $$ for merging the PR

The specific outrage in this case is that the open core doesn't get the feature, even though it was developed by an outsider. That is certainly not common, and not the expectation of contributors.

> Forgejo

Switch to the fork of the fork - brilliant. Especially when the fork fork doesn't seem to do much except bicker and merge controversial PRs on occasion.

https://news.ycombinator.com/item?id=39393794

I don't know how they're run internally, but they seem to have merged a lot of good features that the Codeberg folks developed, so they must do at least a bit more than bicker.

What controversial PRs have they merged? I haven't heard about that and it makes me a bit nervous, but I'm not finding anything obviously wrong searching for it.

I can't speak to controversial PRs, but I got very nervous about Forgejo when they memory-holed a good faith critique of the appointment of a specific new moderator.

Someone on HN linked a discussion where Forgejo was appointing a moderator [0] and had received pushback. A critic of the decision had said something along the lines of "this person has severely abused authority in this community in the past and I'm not comfortable with them getting new authority". They went back and forth for a bit with the maintainers, but by the time the link ended up on an HN thread they'd edited out the critic's comments with a warning not to post ad hominem attacks. At the time you could still read the critic's actual comments in the edit history and it was clear that they were being very reasonable.

A few weeks later I went back to that thread and the entire discussion with the critic was gone. The moderator was appointed, and all record of the dissent was eliminated. If you go to that issue thread now, there are 10-12 comments that I read before that are now missing, and it looks like this person was appointed without dissent.

That sketched me out, and I've been very cautious of Forgejo since. I trust Gitea even less, so I stick with Forgejo, but I wish I had better options.

[0] https://news.ycombinator.com/item?id=39397269

[1] https://codeberg.org/forgejo/governance/issues/78

ouch; that does sound unfortunate, I'll look into it, thanks.

Instead of linking to comments (wtf), I'm gonna link to their surprisingly active list of merged PRs.

https://codeberg.org/forgejo/forgejo/pulls?q=&type=all&sort=...

Not sure what your claim about "doesn't seem to do much" is based on.

The first two pages are docs, dependency bot, and one XSS patch. Hard to know what's going on when 90% of those PRs are bot generated. Maybe they're active, maybe not, I certainly don't know, but it's definitely not clear from the link you posted.

That patch doesn't exist in forgejo though does it? (I find it to be a terrible name by the way)

Forgejo is a word from a non-English language (Esperanto). It's pronounced "for-jay-o" which I find pretty easy to say.

A non-English, fake language invented in the late 19th century.

How is it fake? You are right that it was invented in the 19th century and is not English.

There’s nothing preventing it from being dual-contributed.

I agree the name isn’t great. Very awkward to pronounce using English phonetics.

But anecdotally, I have seen a lot less red tape contributing there and a lot less bickering than on Gitea, which is perhaps too big for its britches. Just a lot of discussion and very hard to get things done on the Gitea side.

Not sure I see the conspiracy here. It's a 144-file PR that has significant management and performance issues, which seem to be the focus of the long discussion thread.

There's a specific comment in the middle that I think the title refers to where someone mentions that this has already been merged into the paid version, but now suddenly they can't get reviews for the free version:

https://github.com/go-gitea/gitea/pull/24257#issuecomment-23...

End of the page he claims to have been physically impaired from working on this. No idea if that's true, just saying what's at the bottom of the page. It is a pretty huge patch though(I missed that upon first glance)

So? Why does a business have an obligation to give away their intellectual property for free? When you submit a PR to a business’s intellectual property, it’s still theirs.

The years go by and the beggar attitude of open source users gets more and more tiring.

Open source contributors don’t get paid for their contributions, but gitea org does.

Expecting your volunteer contributions to not get paywalled is not a beggar attitude…

Gitea specifically has a track record of taking advantage of the good will of open source contributors, which is why the forgejo fork exists.

I commented here: https://news.ycombinator.com/item?id=41514547, but CommitGo was founded to ensure the longevity of the Gitea project. Due to the formation of the company more maintainers have been able to be paid for their time, and bounties/contracted work etc.. all go straight to the project.

It's hard to distinguish this comment from a troll response. But just to deal with the factual claim:

> When you submit a PR to a business’s intellectual property, it’s still theirs.

Nope, contributions do not "belong" to the receiving project unless explicitly agreed so. They were created under a license, and are (usually) reciprocally licensed to the project. The owner is and always was the contributor.

To call someone a beggar for asking for their code back is beyond belief.

Reply on news.ycombinator.com