I find it somewhat telling that they aren’t dogfooding.
If your project is all about hosting code repos and you don’t host your own code, something is wrong.
If they were doing that “just cuz,” I’d agree with you, but the fact they have a thorough list of what they need to self-host, plus my own experiences working on Kiln, make me give them the benefit of the doubt.
When I was working on Kiln, I was constantly pushing for self-hosting, way before the product was “ready,” for the exact reason you’re pointing out: we should put our money where our mouth was. And I won that fight pretty early, when we were right around the level of features Gitea 1.0 or 1.1, albeit with a less-polished UI. My theory was that going to the product even before we hit our minimal internal viable product (MIVP?) would help us shape those features, and that at any rate using Kiln couldn’t be worse than using bare Mercurial hosting.
Oh boy was I wrong. What actually happened was that we implemented the shittiest possible version of the missing features almost immediately so that we could get work done. I’m talking hybrid Perl/Smalltalk services running on my personal desktop busy-polling the Kiln prototype installation to generate RSS and email notifications based on hand-written rules I modified when people asked me to. I’m talking having to take time out from getting to feature completion to write a Mercurial history import rebuilder that we never would’ve had to build if we’d waited for our schema to stabilize. I’m talking shoving out a clunky ASP.NET adapter that buffered the whole Mercurial request in RAM before even starting to process the thing because it at least worked and I didn’t have time to fully wrap my head around writing a proper ISAPI plugin.
The result was we got distracted from actually making Kiln work and probably lost a month doing one-off POS versions of features we knew we’d need to build properly anyway, plus damaged a bunch of internal goodwill at Fog Creek on the quality of Kiln, plus hurt our own morale by associating our own product with being incomplete and annoying. I am not proud of that decision and would not repeat it.
We can argue a bit over some of the things Gitea throws in their MIVP bucket (becoming an OAuth provider would definitely be nice, but you could always just make an extra account and give your CI explicit login permissions), but a few key ones, like line comments on pull requests or improving the notification system, have really, really strong echoes of the situation I saw on Kiln. They’re targeting getting to self-hosting, and they know why they don’t want to go there yet. I support them waiting.
That said, I’m happily using Gitea myself and have been really pleased with its stability, UI, and upgrade story. Doing viable backups is also really easy, and abandoning it for another Git hosting option would be really, really easy, because Git. So don’t use it if you need the same features the Gitea team does, but if it’s just a light install on a non-review-heavy workload, I’d at least give it a look.
Infrastructure is money and pain; I don’t blame them at all for using a platform that’s ready to go. Plus it seems weird to complain that they should put more of their time and money into the project?
Luckily we got some sponsoring, so our time is the “only” investment we have to give.
I don’t know. How much effort and expense is involved in standing up a $10 linode for hosting?
I mean, I understand what you’re saying, but at the same time, this seems to be solidly within their target audience. If hosting your own gogs/gitea is too hard, how well do you understand your audience?
Right from their own site: Hosted and sponsored by DigitalOcean
So, for the “pain” part of it: if they’re not capable of organising someone to setup their own software on a server, I’m not sure I have much faith in their ability to write said software, or their goals for it.
It’s not a pain to host or setup, we are providing all the infrastructure on sponsored machines, we have not started dogfooding because of the reasons mentioned above. We have also published our scripting to launch the infrastructure to be entirety open, you can find the terraform and ansible scripting at https://github.com/go-gitea/infrastructure.
Thanks for confirmation, good luck getting to the point where you are ready to self host!
Fair comment. I can only think that Gitea doesn’t yet provide some of the core functionality they need (maybe pull requests or an issue tracker?). That said, a quick glance at their website didn’t actually tell me what functionality they do provide.
Still, I do like the idea of a lighter weight self-hosted alternative to GitLab.
Currently we provide only parts of the stuff we expect for hosting our code on our own. Contributions must be easy for everybody who wants to contribute, that’s why we said we need specific features to start with it.
Edit: For the list of features (needs to be updated after the 1.1.0 release) just take a look at https://docs.gitea.io/en-US/#features
Thanks for the reply - I didn’t mean to come across as critical and apologise if I did.
I did see that list but it wasn’t detailed enough for me - it didn’t give me a comprehensive picture of Gitea’s functionality. I don’t want to have to install and configure something just to discover it’s missing a key feature I need.
That said, I’m definitely going to give it a try - I’d been eyeing Gogs for quite a while before the fork.
As a result of this we have extended the feature list now: https://github.com/go-gitea/docs/pull/99
To discover more than just the key features it’s much easier to follow the button in the middle of https://gitea.io/en-US/, there you will get to https://try.gitea.io to play around with it, no need to install anything ;)
Edit: https://try.gitea.io is always running on the latest version from the master branch.