Moonchild wrote: ↑
I'm afraid that's not within our budget, also not under our control, software-wise (on-premises is the same idea as Github on-premises; meaning they control the forge), and is much too heavy because they focus on agile development which is at odds with our workflow (because that requires full-fledged devops and we can't even start on that because we don't do CI/CD). their presentations obviously aim at convincing management teams of larger organisations and not catering to developers' needs, so it'd be something for top-down heavy orgs, perhaps.
I was actually looking at their Community Edition, which I don't think is under their control because you have to install and update it yourself. I probably should have clarified that, but the other points you bring up are valid.
SCM Manager is... I don't know what it is, really. There are no demos, no examples, nothing but a description that is a little too concise.
I believe it's along the same lines as RhodeCode, but more intended to be something you host yourself. It would only be worth a look if you wanted to pair it with an issue tracker. I believe that unless we are going with Gitea, the only other option is to pair Redmine (or some other issue tracker) with something that does code/repository management. And you seemed concerned that would be as much of a mess as Phabricator.
Moonchild wrote: ↑
Also your previous concern about storage of forks being inefficient; I'd think that any forge that does this kind of work will have efficient delta-only storage of repos and not create a full clone for everyone making a fork? I mean that would be rather silly because forks have common ancestry that would just be needlessly duplicated. It does mean however that it has to remain centralised.
If it's a fully-featured GitHub clone, possibly, but I actually doubt most software does this out of the box. The whole concept of just clicking a button and making your own fork that's more like a branch was born on GitHub I believe. Hmm... so the intention is really that we remain centralized, everyone will have to move over to whatever is chosen? If having the ability of people to have and maintain their own forks on a server we're paying for is important, then it absolutely has to be the thing that's lightest on resources, have decent security, and most likely to be adopted without pushback. We could get away with a lot of solutions if we only have to host our own repository and an issue tracker, but needing this functionality means we only have so many good options.
So to recap: Pagure is the Pythonic mess I was thinking it was, and unmanageable. New options offered are a mismatch and/or out-of-budget. That leaves pretty much Gitea as our top contender now.
It's really looking that way to me as well.
There's an option out there that offers hosted Gitea for $37 a month. I don't know how that compares to the options you've been evaluating for hosting, but if it winds up being cheaper after you've figured out how much it costs to host Gitea, and we don't have to maintain it ourselves for the time being, it might be worth a look. Of course, using Gitea means we can migrate to a self-hosted solution at any time.
The more I consider this question, the more I feel the arguments in favor of Gitea are basically devastating. Here's why I'm reluctantly coming around to accepting that it's the only good option:
1. Most people on this thread have proposed something similar to GitHub or expressed a distaste for GitLab's interface, myself included. adesh proposed Gitea, Lootyhoof proposed Gitprep, Tobin proposed Pagure configured to look like GitHub. And I myself was looking at solutions that I thought would be configurable enough to be made to look more like GitHub, much like Tobin was (only difference is I wanted something that was configurable via server plugins rather than having to mess with code). That means if we can't get a solution that's similar enough to GitHub, it will be met with some resistance. Our best chance of keeping everyone together in a centralized environment is a near-perfect GitHub clone, in my estimation.
2. The fact that it's written in Go likely means it's light on resources. Regardless of how I feel about languages like Go and Rust, they've become the go-to languages for anyone who wants to make an application faster or less of a strain on system resources. Basically everything besides Phabricator or Tuleap Community Edition (which are in PHP) are written in "heavy" languages, like Python and Java. I have the luxury of using something heavier or older on my own system where the only one suffering is me, if I just don't like the best options for principled reasons. But on a server, there's no room for that. We absolutely have to use what will make the best use of system resources because every bit of resources we need costs more money, especially if we're running a multi-user system with actual source code moving back and forth. There's no room for bloat, and the only way to get more efficient than languages like Go or Rust is to use something written in C or Assembler (which as far as I can tell doesn't exist). That is why we see them on the server end increasingly whether we like them or not, and people who dislike them mostly favoring high-level languages like Python or Java. Google has much of the world's best engineering talent and runs a lot of servers with a lot of users, it only stands to reason they'd invent a programming language that's perfect for that use case. We would be using one Google technology mostly meant for their internal use, to avoid being consumed by the one they've dished out to consumers.
3. The popularity of Gitea likely means it's somewhat easy to deploy, relatively speaking. At the very least, there will be a lot of help with the deployment available in the community. Everything in the self-hosted Forge community right now that isn't corporate GitHub/GitLab seems really Gogs/Gitea-centered, with everything else having fallen by the wayside and mostly being used by people who chose something else years ago. That fact was incredibly frustrating to me as I was looking for alternatives. I found none that were viable, except maybe
Redmine as an issue tracker, but that would still mean finding something it pairs nicely with.
4. Retraining time/costs. Let's face it, not all our developers are super familiar with Git on the command line, or good at learning something new. A lot of them are dependent on the way GitHub works to do their jobs, and have invested a lot of energy into learning it already. The less similar to GitHub our eventual final choice is, the more time we have to spend retraining those people, and the longer it will take to get development back to a pre-transition pace. Once again, Gitea solves that problem by being as similar to GitHub as possible.
In short... if we're really serious about having Forge software and a GitHub-like experience on our own server, then Gitea is basically our only option. Nothing else even comes close, in my opinion even GitLab (the other top contender) pales in comparison because it's simply too different from GitHub and there's no guarantee that they won't move to a fake on-premises option like GitHub did. If the providers of the software have a way to make you pay monthly for the on-premises option, they must have a way of disabling it if you don't pay one month, or their business model wouldn't work. And they can leverage that to control the product if they decide to implement undesirable changes, you can't just block it from phoning home and expect it to keep working. Which means they might let us defer updates for up to a year, but then a year later we might be right back here.
The only other possibility is to radically change the goal. We could also host a simple git server and an issue tracker, and let everyone work with the code using their own desktop git clients like Sourcetree or something. That would involve a severe learning curve, but also significantly lessen the resources required. There's also the option of trying something like Fossil or Mercurial that has a somewhat better web interface that can do more with repos out of the box, but I'm pretty sure we want to stick with git. If we are set on a GitHub-like experience on our own servers (I suspect we are), and we want it out of the box without having to develop anything ourselves, I genuinely see no other option than Gitea at this point. Everything else seems like a downgrade in a lot of ways.
To be honest, I pretty much knew that two pages ago even before you said it was feeling like Gitea and GitLab were the only real options. I knew that GitLab was the only other real corporate option, and Gitea was the only real open-source/free option. My gut was telling me that, and I was not happy about that fact. I didn't want to believe it, and I bet you didn't either, but there is literally nothing out there but decent paid options with a steep learning curve, disjointed garbage like Phabricator, a few complicated/messy Python options, and GitHub clones written in Go. That's what we have to choose from.
There is nothing out there that really appeals to my more idealistic side, but corporate/business me thinks Gitea could save us all a lot of time, money, and energy if we just compromise our principles just a little (GitHub is already a compromise in that department), bite the bullet, and use the ready-made package written in Go that practically everyone not on GitHub or GitLab is now using. We might regret it later on if we actually have to fork Gitea due to undesirable changes (I really hope we don't), but we can cross that bridge when we come to it. I do think someone from our team should start learning Go now just in case we have to patch it up ourselves, if we go this route.