@redstarfish @schratze Fascist folks will write very useful software for fascist folks. I can’t believe there’s even a debate about whether it’s good to work with fascists if they agree to slap a GPL license on their work.
“Hey, let me introduce you to my friend Chad. He’s a Nazi, but he sure writes some sick code.”
Yeah, no.
*smh*
Real question : what about forking their work ? :thinking: like i’m not contributing to their code i’m using theirs and improving my fork ? Not sure of where that falls on the spectrum of ok-not ok…
@Guerin @aral @redstarfish@social.linux.pizza @schratze Speaking from experience in a slightly different context (software that's designed for businesses vs. software that's designed for humans/communities), it is *incredibly* difficult to untangle all of the implicit assumptions that have gone into a piece of software, let alone remove them without ending up in perpetual bikesheds. You are often better off starting from scratch.
Like, there's an incredible amount of problems and suboptimal design choices in widely-used software and libraries that can be traced back to "money favours business-oriented development", but it's almost impossible to spot them all, let alone explain to other people (unfamiliar with the topic) why they're a problem.
@Guerin @aral @schratze Many of these problems are widely viewed as "well, that's just how software is" or even as best practices (eg. a heavy focus on automated testing or static typing), even though when you *really* start looking into it, you would discover that they are not in fact the optimal solution for software *in general*, they just make a lot of business sense in a commercial environment.
@Guerin @aral @schratze (For automated testing and static typing, the business argument is basically that they achieve workable results with a minimal upfront training investment and minimal human-to-human coordination, and that they easily scale up to large monolithic teams; none of which is actually relevant outside of business development)