5 ms·

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

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.

qbasic_forever 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.