Fair question, you shouldn't be getting downvoted for it imo.
Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request.
When these are set up and run well, they are very powerful for mid-to-larger organizations.
I would like to second this and point out that while someone can self host and set all of this stuff up, at some points there are economies of scale for using a provider to do this because the provider's raison d'etre is to create these interfaces that make it easy for everyone to interact with git. The developers on KDE, etc. probably don't want to spend their time working on the UI for their bug/issue/feature/commit request tool when they could be working on KDE things.
Finally, there's the fact that many more users will be familiar with GitLab (or GitHub, BitBucket, and so on) than they would with each and every opensource project's flavor of bug/issue/feature/commit tracker. For instance, I know exactly how to find the "releases" section on github quickly - if KDE wrote their own bug/issue/feature/commit tracker, I'd have to find the "releases" area and remember where it is every time since I don't use that UI as often as I use github.
Actually, gitlab is open source and the majority of the features aren't pay walled off. You can self host ~70% of the gitlab features on your own hardware, without paying a dime. Or you can self host and pay a subscription to enable all the enterprise features. At work, we use this for code which is too sensitive to host outside of our infrastructure. Closed source development needs management too.
> Fair question, you shouldn't be getting downvoted for it imo.
Well, the question is pretty much answered in the actual article. From the looks of it, this seems to be responding to just the title without having actually read the page.
I would say that hosting on a centralised service like GitHub it Gitlab also reduces friction for contributors - bug reports, code, docs - as people will usually already have an account so they can make drive by contributions.
Having to find a bug tracker, create an account, log a bug is a lot of hassle for a random library or small project. I know I've given up raising bugs for some things as I couldn't be bothered with the rigmarole of sign-up, verification, etc... On Gitlab/GitHub there is much less friction because I use both regularly and and can use them for multiple projects, large and small.
It uses maildir files in a hidden directory, which can be tracked like any other files; e.g. when committing a bug fix we can also commit the closing of the associated issue. I've also configured Emacs to make using it even smoother (opening issues/comments in a derivative of message-mode for syntax highlighting, with a C-c C-c binding to save and stage; I've partially finished a derivative of tabulated-list-mode for browsing issues interactively).
off-topic: I'm around HN for >10years and I vaguely remember a UI change where I could not see some voting counters any more. How do you know if a comment has been voted or downvoted?
When I first replied to the parent comment, it was gray text -- HN's UI for "this comment has less than one point". I couldn't tell you the comment's score right now. It doesn't look like hn.algolia.com has comment scores anymore either.
I remember that UI change. At the time HN was really starting to look like it was getting gamed, with comment scores having too much influence on popularity. HN's response to hide scores seems to have helped.
Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request.
When these are set up and run well, they are very powerful for mid-to-larger organizations.