𝘋𝘪𝘳𝘬

They not only force their user to buy their crap, they also intentionally and maliciously frame the AGPL in a certain way.

There are issues with some of your accounts and orgs.

There will always be this one asshole of a coworker who happily name-dropping you in a conference call with the project owner.

That’s the downside, yes.

Write an ungodly large amount of code-comments - up to a point where you add 20 lines of explanations to a 6 lines long function where two lines are variables assignments.

Source code is for humans to read. The compiler ignores the comments.

Okay, bye!

unit-test: passed

I gave up Bash scripting. I explicitly do “shell scripting” now, where “shell” is implied to be a POSIX compliant shell of any type.

The only one who is winning here is the Chinese government.

There – of course – won’t be a singular official source stating “Hey guys, we’re open core now”. You need to put this together bit-by-bit.

Here are some links for research

• Official statement on the takeover
• Gitea Enterprise/Gitea Cloud hiding features behind a cloud solution and a paywall which makes Gitea itself open-core
• Open Letter to the new Gitea owners with a summary and a reply, signed by a lot of Gitea devs and FOSS scene people.
• As @gratux@lemmy.blahaj.zone mentioned: A fork under the name Forgejo was done due to new Gitea owners did not care much about the concerns. (Started as asoft-fork but with 10.0 it became a hard fork.)
• Gitea owners made it mandaroy to remove copyright headers and set the corporation as copyright holder. Here, here, and here

Never heard of 99% in that list.

Also, Gitea should not be there. It is a corporate -owned open core project that was hostilely taken away from the community.

If I know the information isn’t available anywhere else and I really need it, I use a temporary unrestricted browser profile.

Otherwise, Ctrl+w it is.

How do you handle SSL certs and internet access in your setup?

I have NPM running as “gateway” between my LAN and the Internet and let handle it all of my vertificates using the built-in Let’s Encrypt features. None of my hosted applications know anything about certificates in their Docker containers.

As for your questions:

1. You can and should – it makes managing the applications much easier. You should use some containerization. Subdomains and correct routing will be done by the reverse proxy. You basically tell the proxy “when a request for foo.example.com comes in, forward it to myserver.local, port 12345” where 12345 is the port the container communicates over.
2. 100% depends on your use case. I purchased a domain because I host stuff for external access, too. I just have my setup to report it’s external IP address to my domain provider. It basically is some dynamic DNS service but with a “real domain”. If you plan to just host for yourself and your friends, some generic subdomain from a dynamic DNS service would do the trick. (Using NPMs Let’s Encrypt configuration will work with that, too.)
3. You can’t. Every georestricting can be circumvented. If you want to restrict access, use HTTP basic auth. You can set that up using NPM, too. So users authenticate against NPM and only when it was successful,m the routing to the actual content will be done.
4. You might want to look into Cloudflare Tunnel to hide your real IP address and protect against DDoS attacks.
5. No 🙂

That poor IT support person:

---------------------------^
indentation error

Keep your American politics bullshit to Lemmygrad and Heaxbear.

Have a look at Forgejo which is a soft fork run by a nonprofit organization of Gitea which is owned by a for-profit company.

https://forgejo.org/

It need very little system resources and still gives you all the common features you know from commercial Git hosting providers.

And yes, you can mirror existing Git repos using a web UI.