4 ms·
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 ar
by Buttons840 2y ago
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.
- evanelias 2y agoThe 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-engineers-and-why https://allspice.io/post/which-git-clients-work-for-hardware...
- ironmagma 2y agoHe 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.
- evanelias 2y agoI 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-offering 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.
- ironmagma 2y agoIf 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.
- evanelias 2y ago> 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?
- jzb 2y agoI'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.
- techknowlogick 2y agoI commented here: https://news.ycombinator.com/item?id=41514547 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.
- techknowlogick 2y agoI commented here: https://news.ycombinator.com/item?id=41514547 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.