I also don't have a problem if open source developers try to monetize their work. In fact I think it's great, if done right. But context is important here.
In Gitea's case, I think this could have been done right, with the community's knowledge and involvement. But that's not what happened. Two of the three "elected owners" of the project effectively undertook a hostile takeover, transferring the ownership of the domains and trademarks to a secretive private company, without telling anyone until after the fact.
I know people who were formerly active maintainers, and they were taken completely by surprise – even though it turns out that preparations for this had been ongoing behind closed doors for many months.
At first, I and many others thought it was perhaps a case of failures of communication, and were prepared to give them the benefit of the doubt. But after an open letter was signed by many community members, and the people behind Gitea Ltd had ample opportunity to improve the situation, they only dug their heels in and made things worse, and refused to answer questions beyond corporate-speak PR posts. It was at that point that the decision was taken to fork.
As a Gitea user and as someone who is excited about the forge ecosystem and the future of forge federation, I truly hope that Gitea as a community project continues to thrive, and that the company ultimately doesn't derail the community.
Unfortunately, I am also very pessimistic about that being the reality, and so I think this fork is a very positive development.
Some of them have migrated. I imagine others are taking more of a "wait-and-see" approach.
For what it's worth, Codeberg is quite a major contributor to Gitea as well as the biggest public instance, and they are supporting the fork and will be switching over after the first stable release.
I'm curious whether this can actually be considered to be a "CAPTCHA" in the true sense of the term. It doesn't seem to be intended to "tell computers and humans apart", but rather to force the client computer (not the human user) to do some work in order to slow down DOS attacks.
Of course slowing down DOS attacks is a great goal in itself, and it's very often what captchas have been (ab)used for, but it doesn't seem to me to replace all or most use cases for a captcha.
In particular, since it can be completed by an automated system at least as easily as by a human, it doesn't seem like it would limit spambot signups or spambot comment or contact form submissions in any meaningful way.
I used "captcha" to simplify mCaptcha's application, calling it a captcha is much simpler to say than calling it a PoW-powered rate limiter :D
That said, yes it doesn't do spambot form-abuse detection. Bypassing captchas like hCaptcha and reCAPTCHA with computer vision is difficult but its is stupid easy to do it with services offered by CAPTCHA farms(employ humans to solve captchas; available via API calls), which are sometimes cheaper than what reCAPTCHA charges.
So IMHO, reCAPTCHA and hCaptcha are only making it difficult for visitors to access web services without hurting bots/spammers in any reasonable way.
Thanks for the reply! That's basically what I thought then – but as you say, traditional captchas are deeply flawed and ineffective anyway, and I totally agree that in many cases the cost to real users outweighs any benefit.
So I'm excited to see alternatives such as mCaptcha popping up. It'll be interesting to see how it works out for people in real-world use.
