Maybe closed source organizations are more willing to accept slop code that is bad but can barely work versus open source which won’t?
Because most software is internal to the organisation (therefore closed by definition) and never gets compared or used outside that organisation: Yes, I think that when that software barely works, it is taken as good enough and there’s no incentive to put more effort to improve it.
My past year (and more) of programming business-internal applications have been characterised by upper management imperatives to “use Generative AI, and we expect that to make you nerd faster” without any effort spent to figure out whether there is any net improvement in the result.
Certainly there’s no effort spent to determine whether it’s a net drain on our time and on the quality of the result. Which everyone on our teams can see is the case. But we are pressured to continue using it anyway.
Magit, which is the best Git porcelain around. Git, because it has an unparalleled free-software ecosystem of developer tools that work with it.
Why is Git’s free-software ecosystem so much better than all the other VCSen?
Largely because of marketing (the maker of Linux made this! hey look, GitHub!), but also because it has a solid internal data model that quickly proved to experts that it is fast and flexible and reliable.
Git’s command-line interface is atrocious compared to contemporary DVCSen. This was seen originally as no problem because Git developers intentionally released it as the “plumbing” for a VCS, intending that other motivated projects would create various VCS “porcelain” for various user audiences. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain The interface with sensible operations and coherent interface language, resides in that “porcelain”, which the Git developers explicitly said they were not focussed on creating.
But, of course, the “plumbing” command line interface itself immediately became the primary way people were told to use Git, and the “porcelain” applications had much slower development and nowhere near the universal recognition of Git. So either people didn’t learn Git (learning only a couple of operations in a web app, for example), or to learn Git they were required to use the dreadful user-hostile default “plumbing” commands. It became cemented as the primary way to learn Git for many years.
I was a holdout with Bazaar VCS for quite a while, because its command-line interface dealt in coherent user-facing language and consistent commands and options. It was deliberately designed to first have a good command-line UI, and make a solid DVCS under that. Which it did, quite well; but it was no match for the market forces behind Git.
Well, eventually I found that Magit is the best porcelain for Git, and now I have my favourite VCS.