Meeting notes between Forgejo and the Dutch government via Git commits
codeberg.org
codeberg.org
I'm a self hosting GoGogs / Gitea user for almost 10 years, I did follow the Gitea fork. However regarding the Forgejo fork: the main contributors stayed with Gitea. The ideologically forked Forgejo made some license changes and hard fork decisions that increased the maintenance burden even more, resulting in missing upstream features and decreased security. Forgejo is more busy managing ideals, than creating software.
But then a couple of years have passed, and I started to hear about Forgejo more often only very recently, so I was wondering, if maybe the original project actually had some downfall and questionable technical decisions since. I still haven't switched, and was wondering if I should do so. As far, as I've heard it's still basically a matter of running the different docker container with the same volume, and it should work seamlessly. So what's about this "hard fork" you are mentioning? Did it actually break compatibility?
Forgejo used to be a set of patches applied on Gitea, but they moved to a fork with cherry picking Gitea commits, this is more work. In my view they don't have the development to keep up with Gitea.
Isn't it sensible for a European government to talk to a player that is being backed by European companies and has a cleaner approach to open source?
I'm not arguing, I'm asking what's the rationale here.
> resulting in missing upstream features and decreased security
I.e. it's a matter of technical superiority, which, to me, how the decisions should be made. Not by having friends in the community and all of us being Europeans and so on. (But, of course, I would be glad to hear more particular details/examples of Forgejo lagging behind.)
We've stuck with Gitea, after not being impressed by the extremely FUDish behavior of the main driver of the fork, and this has proven to be the right choice so far. In spite of what some people claim, all of the major contributors to Gitea have continued developing it, none of the "heavy hitters" have left. It shows.
The database can be downgraded anyway. I've been doing backwards migrations for each new version all the way back to 1.22 (which is the last Gitea version that is "side-gradable" to Forgejo).
There's no such thing as some apolitical, objectively best approach to a technical problem. Instead of arguing about specific merits about specific issues people throw out this big wide handwave about how "idea X is simply technically the wrong choice", as if this is a legit position to have.
Take a philosophy course for god's sake before you engineer us all to death.
Security wise, Gitea was safer in this case.
Also note the SECURITY.md was deleted: https://codeberg.org/forgejo/forgejo/commit/277dd02e706b6e51..., there is a security https://forgejo.org/docs/next/contributor/discussions/#secur... but it's a bit harder to find.
The problem is, Forgejo changed the license (https://codeberg.org/forgejo/governance/pulls/24#issuecommen...) and ended up doing a hard fork (https://forgejo.org/2024-02-forking-forward/#consequences-of...) which creates quite some maintenance burden. There used to be a (weekly) gitea chery-pick (e.g. https://codeberg.org/forgejo/forgejo/pulls?state=closed&labe...) but the TODO section was getting ever larger, and it seems it stopped in July (week 26).
So they start missing stuff, e.g. features like https://codeberg.org/forgejo/forgejo/issues/9552
Re: license change, hard forking, and new features: my understanding is that Gitea wasn't very open to contributions coming from Forgejo. The hard fork seems to be a consequence of that. Yes, there used to be weekly cherry picks, I assume they stopped exactly because Forgejo and Gitea diverged to much and they became too much of a maintenance burden. Yes, this means Gitea has gotten features that aren't present in Forgejo since then. But you miss the point of the hard fork if you count this as a negative: Forgejo is deliberately diverging from Gitea now. Cooperation didn't work out, so they are no longer a superset of Gitea, but an entirely separate project. And as such they don't have more maintenance burden than Gitea itself.
And Forgejo definitely does not lack development power as its own now-independent project. They have features themselves that Gitea doesn't have. One notable that comes to mind is storage quotas, but there are many more too.
My point was that you don't need to compete with paid features, just please give the developers money to develop the software further (and fix bugs/issues), so e.g. buy some 'enterprise license', even if you don't need it in terms of features.
Lets be clear. These "some license changes" that you reference was Forgejo forked Gitea and replaced MIT license with GPLv3. Forgejo doesn't want to be contributing to receiving effort from contributors into a project that then gets re-used, re-branded, and exploited by a big corp. By making the project copyleft they ensured that the contributions stay Free. This was an ethical move.
Gitea on the other hand doesn't mind sucking up free-of-charge contributions and handing them to a company to build their walled garden around.
The issue with deviating from the upstream license is that only the code author can upstream a patch, since GPLv3 cannot be changed by a non-author of the code to MIT. Resulting in less being patched upstream, and so more merge conflicts, the maintenance burden I was talking about.
But managing ideals is far more important than creating software. Software is just a tool. It's a mean to an end, it's not the end in itself.
If software improves humanity we should create it. If not, we shouldn't. We shouldn't create software just because. We can, but that's not ethical.
And regarding your comments that "the original contributors stayed with Gitea", as if that's a point in favor of Gitea: Well of course! If the original contributors wanted copyleft that's how they would've licensed it. To me that just reinforces that I don't want to contribute to their project.
When deciding which software fork to pick, it is about the development power. Also note my point about security: https://news.ycombinator.com/item?id=45929247#45930310
Can't say I agree with this point. Zig has been trying out Forgejo/Codeberg as an alternative to GitHub, and about two months into the experiment, almost all of our technical concerns with Forgejo (and Forgejo Actions) have been addressed, with the only straggler being a UI bug related to the Cancel button in the Actions infrastructure (which has a WIP PR open, and which also has a straightforward workaround).
I can't speak to the platforms themselves, but in regards to their CI systems, it looks to me like the Forgejo Actions runner sees more development than the Gitea act_runner. For example, Forgejo gained support for concurrency groups recently, which to my knowledge are still not supported in Gitea.
How many Elastic Searches will it take for people to realize that this is mandatory. Linux would not be where it is today were it not for some ideals wrangling.
IMHO a MIT license is better than AGPL with a Contributor License Agreement (CLA) like with Elastic.
Gitea is MIT, so free and open-source, permissive.
Also see https://news.ycombinator.com/item?id=45929247#45930949
And from other comments:
> When deciding which software fork to pick, it is about the development power.
> In my view they don't have the development to keep up with Gitea.
How do you come to the conclusion that Gitea has more development power? Looking at the Insights / Activities overview of each repository there were slightly more authors with more contributions to Forgejo over the last month. Acknowledging that this fluctuates I'd estimate that both projects are similarly active.
Also, Forgejo is actually dogfooding its development, which is much more reassuring than what Gitea does IMO.
If they move to self hosted Forgejo (which I assume this meeting is all about) Microsoft is going to lose a pretty big customer.
And yes, (good) CI is still is a big blocker to move to Forgejo for any org (or self hosting). Hope they can speed things up a bit there now they now a gov org is seriously interested.
But yes, they also should work on making it super easy to integrate best of breed OSS CI/CD with their SCM and turn Actions off. If they manage that they are on their way making a product which blows GitHub and Gitlab right out of the water. Because while Gitlab allows to integrate third party CI/CD it really feels clunky. (at least at the time I've used it professionally)
I'm a 5+ year government employee, I touched quite some governmental repositories but all are non-paid.
I'm also a fan of the government hosting the code in an EU jurisdiction, preferably our own Dutch jurisdiction, and even better, self host.
1. you need to create an organization for each group (lang, tools, template, etc.)
2. you can't create more complex organization structure (e.g. template/python/python-flask-template)
3. you can't group projects with different top-level names (e.g. apps, tools, lang; such as lang/java and tools/gradle) or across a top-level name (e.g. by programming language such as lang/typescript and lang/python)
Good to see forgejo making inroads as someone who also self-hosts it.
It often seems like a trick to make is so that nobody really knows what they're voting on, as opposed to a wholesale "replace that entire section with the readable information below". I suppose, to be charitable, it may have originated as a conflict-avoidance strategy.
Ideally, bills would be changesets that can easily be turned into before-vs-after comparisons for legislators to review and approve.
Words matter, and this would've been a great opportunity to raise awareness to the problem of oppressive software. I think these days most people have an intuition that this is happening.