[jrochkind1]

This is poignant for me, for reasons that have nothing to do with the technical merits of git vs mercurial, or github/Microsoft specifically as a company.

> It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.

The bar has been raised for developer tools in 2021. The OP recognizes it, it's true.

The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially.

It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure.

(It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...)

And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in.

We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted.

But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to.

The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.

[qbasic_forever]

You don't have to compete with hosted systems that have dedicated teams of developers and operations shipping features though. Linus Torvalds manages the development of the entire Linux kernel (millions of lines of code, thousands of contributors) with just an email client, text editor, and git CLI.

I will say too don't expect these hosted services to free you of operations burden. On the contrary you're even less connected and more at risk of operations burdens when these hosted services are facing issues. When Github actions CI/CD is acting up, or the hubot issue manager isn't working, or the release artifact store doesn't have the bits you expect, etc. your entire project grinds to a halt and it's not easy (by design) to eject out and work around them. Projects that depend heavily on all these hosted services are going to find over time that they need to buffer and insulate themselves from these centralized, single points of failure. It's just a different kind of operations burden.

[stu2b50]

I mean that may be technically true but practically without something Github-like it's very difficult to make it work.

If you started a FOSS project today with a mailing list wherein contributors mail you git patches, you would get exactly 0 contributors.

And maybe that's ok, maybe this is your baby, and if someone wants to push code to it they can learn how to email a patch to you.

But for many developers, they do want to have some of the load taken off of them by other developers. They want to reap that benefit of OSS.

[moron4hire]

Well, to be fair, regardless of what you do, the likelihood that you will get exactly zero contributors is very high.

Oh, you'll get complaints, that much is very achievable. But actual contributions? Even simple, bullshit code boot camp homework exercises? Good luck.

[jrochkind1]

Why would someone want to contribute to a bullshit boot camp homework exersize? That seems literally the least likely thing to get any collaborators on.

But, sure, if you don't care about making the development tools something that anyone other than you find convenient, than you can of course just pick whatever you find convenient, nobody is going to stop you.

That's still not a mailing list with patches for most people, but if it is for you, that's great, nobody's going to tell you you can't do that.

The OP said he was switching because he thought their current systems were taking too much of his time to maintain, and were still too hard to use for other collaborators.

You seem to be trying to tell him he's wrong and those systems didn't really take too much of his time, and he actually didn't have any other potential collaborators anyway.... it's a weird argument.

[Jach]

> Why would someone want to contribute to a bullshit boot camp homework exersize? That seems literally the least likely thing to get any collaborators on.

You've misunderstood, the coding boot camp assigns homework, and sometimes that homework is: "Contribute to an open source project!" This usually takes the form of something like a pull request to "Fix typos in README" or something otherwise insignificant. GP is just saying that however you release your FOSS project, you're unlikely to get even that tiny level of outside contribution, so using "no one will contribute" as an argument against a mailing list isn't very persuasive. The argument that mailing lists suck, perhaps more so, but GP didn't opine on that.

[moron4hire]

I was saying that the few contributions I've ever gotten on any of my projects are basically people completing bullshit codecamp exercises. The contribution is low impact and the contributor never returns. The actual act of submitting the contribution was a larger percentage of the effort than the actual change itself.

[jrochkind1]

That works out well for you that you and Linus and others find that system to have just as good user experience as the sort of hosted systems far more projects are using, but the majority of current actual and potential developers do not.

I think you are unlikely to persuade them to change their minds with an argument in an HN comment, but you can keep trying!

[jillesvangurp]

You can self host Gitlabs. I did that a few years back and it's quite nice. It has a similar feature set to Github. Gitlab these days is a perfectly good alternative and it's popular as well though not nearly as popular as Github.

Self hosted gitlab is nice, until you realize that you can get the same functionality for free from Github and any second of devops spent on your self hosted thing is technically just money down the drain. In our case, I got a little worried about our flaky backups and the fact we were using a single node vm in AWS to host this. The fix would have been increasing cost by spending on more vms and devops. Instead, we switched to Github. And that was before they had free plans with unlimited repositories and developers. We actually paid for it and saved money (not to mention stress). These days it's a no-brainer because at 0$ per month you get source hosting, CI via github actions, and all the rest. I'd actually gladly pay for it before considering other options. But it seems MS has decided that's not worth the effort.

The thing with OSS is that it's not the world you want but the world we all build together. Plenty of people that want stuff but rarely enough that go out there and actually build it, persist with building it, find the right people to collaborate with to get things done, and then collectively deliver results. That takes a platform to collaborate on and for better or worse that platform is Github and git.

Mercurial just never got of the ground as a mainstream solution and fell behind as Git got more popular. It had a shot as long as it was the third option (along with subversion and git) on Sourceforge before Github was a thing. But then Github happened and offered a nice UI for pull requests and that turned out to have been the killer feature developers wanted and needed.