techknowlogick

Thanks for saying so <3 If you ever run into any issues with it please feel free to report an issue or hop into chat.

I'm a project lead of Gitea, and former elected board member of Codeberg. Gitea remains opensource (feel free to check out the repo and you can see that the license remiains as is), and maintains yearly community elections. The codeberg board was informed a full year prior to their "we just found out blog post", and so "catching the whole community by surprise" is very much not accurate since they very much knew. As well, we (the company) were very public with our activities prior to our blog post announcing things, including working to support other open source projects migrate, and posting about it through various channels (social media, chat, etc..).

I'm one of the project leads of Gitea (and am paid for some of my work on Gitea), and here are some more details around the specific incident you are talking about: We were alerted to an issue, and investigated provided a patch, and then waited until the end of the embargo to release the next version with the fix. It turns out they had sent a follow up after our response to them that, due to their usage of an email relay that gets blocked for spam often, went into the spam box for all of the maintainers on the security team (across multiple mail providers). We informed them of this and they still haven't corrected the record on their blog post. This is after previously giving us 10 and 2 day "embargoes" on "severe" issues and a multi-hundred line patch that rewrote core portions of the codebase and introduced issues in itself, we notified them of this and provided them with out patch. In our interactions with them we have also followed our documented approach, that we have followed with codeberg previously (that we were thanked and applauded), but they have changed their stance and claimed we are now acting improperly (and when we asked for how we could adjust our approach to something that works for their adjusted expectations we never received a response, even after receiving multiple emails from multiple non-company maintainers and even messages in multiple chatrooms).

Disclaimer: I was also previously an elected member of Codeberg's board (presidium), where before the company that was founded to support Gitea's community maintainers was created, I had asked for assistance with multiple matters to aid in project development and was denied.

Not yet, but it is something that is being worked on.

Gitea would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.

Gitea has SSO using many different ways, such as LDAP, OAuth2/OIDC, OpenID, SMTP, etc.., and it would have SAML too (I'm the main author on the SAML PR to the Gitea project), but it's been held up by community reviews requiring esentially an entire re-write with another library. We'd love some help to get it across the finish line :) In open-source, money isn't the only thing that can be spent; we can also use our time.

The difference between the Gitea project and the Gitea Enterprise software offering is with Gitea Enterprise we are able to include code written that was rejected by maintainers (eg. mandatory 2FA as an example) as there was still a desire for it. Luckily it was since rewritten in a way that was acceptable for the project and now it's been accepted/merged. The company has also written code that was under contract from other companies, and so they own the IP and thus cannot be accepted by the project due to not being able to be DCO compliant. Those companies are receptive to open-source, and we are working with their legal teams to be able to have them release their claim to the code so we can submit it to the project (large corpos are not known for their speed and understandably want to do their due diligence to ensure that all i's are dotted and t's crossed). There are around ~50 community maintainers that have exactly equal say over PR reviews, etc.., and that process has always been strictly adhered to.

Edit: Gitea has LDAP, OAuth2/OIDC, OpenID, SMTP, reverse proxy, and others as SSO options.

Yes there are :) You can use the Package limit setting to change it (search the config docs for `LIMIT_SIZE_CONTAINER`), by default there is no limit, but if you are running into a 413 due to container uploads being so large, then it could be a reverse proxy configuration you might be running into.

It does :) Gitea Actions are compatible with GitHub Actions. For the most part the same workflows you'd use on GitHub will work with Gitea.

Yup, this is the case. I'm the main author on that PR. It sadly stalled due to reviews from other maintainers requiring it to be rewritten using another library, but hopefully I'll be able to get back to it, or someone else will be able to pick it up. We've been able to get other functionality into Gitea already, and I've personally funded maintainers and others' work for the project, which goes directly into the project itself.

I'm the main author of the PR to implement SAML in Gitea, and it sadly has stalled due to reviews from maintainers requiring it to be rewritten entirely using another library. Our governance charter requires a certain process for PRs going into Gitea, and cannot be side-stepped by anyone. As for some of the others, we've been able to merge them in already.

I'm not sure what you mean, as Gitea has SSO using many different ways, such as LDAP, OAuth2/OIDC, OpenID, SMTP, and more.

Thanks :)

Thank YOU for using it :)

Thanks so much for saying so. Not sure if you are on the latest major release yet, but hopefully you've seen that resource usage is much lower and response times are even faster.

Thanks so much for saying so :) If you ever need any help please don't hesitate to hop into our forum, chat or issues tracker

The Gitea project is still community-driven and has the same yearly elections for leadership that has been around for close to a decade now :)

edit: Gitea is fully MIT and per our governance charter that cannot change

We are shipping ~300 PRs monthly (plus more getting reviewed), so there are always new things :) I have a few big PRs for longstanding feature requests that should go in soon that I'm pretty excited for.

edit: Im also pretty excited about the anti-crawler enhancements that went in the latest major release

Hey, I'm a part of the Gitea project leadership. Thanks for sharing. If you have any questions, please don't hesitate to ask :)

I'm on the Gitea TOC. The fork does still merge from upstream. The Gitea project has 4x'd the number of monthly PRs we handle (~400) and have increased the maintainers teams, and the number of contributors. I'd say we have a lot of momentum.

Hi, I'm on the TOC of Gitea, and I can definitively say that there is no cryptocurrency in Gitea or related to Gitea. As well, the project is not open-core, and you can verify that yourself by going to the project and seeing that all the code is MIT licensed: https://github.com/go-gitea/gitea

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.

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.

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.

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

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.

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