The issue a lot of people don't seem to get is that when you publish software, you create a dependency by others on your work. That dependency can be essential to the way people work or change their workflow to fit your software into their routine or even business. Having others depend on something you create and maintain generates serious responsibility. That responsibility leads to consequences for you and for your users, especially if your published software is, or can easily become, a "daily driver" for users, i.e. a tool they will use for essential things every day.
I am of the opinion that this is why one-shot 15-minute hackjob programs really shouldn't be put out to a general audience, and why it is important to take responsibility for what you put out, and by extension, why you should never offload that responsibility on others by saying your published software is something it is not. That also means you should never use someone else's branding for something that hasn't been quality-checked or at least verified by the people owning the brand, and should not give resistance when a brand owner says what you are doing is "not okay". Close to home we've seen this happen more than once.
I think Tom Scott touched on this effectively in one of his videos, which I'll quote below:
I wholly agree with Mr. Scott here, and I do think that more people who publish software need to be acutely aware of the dependency and responsibility they create by publishing something. And that isn't even limited to software either; it goes for every kind of publication. Whether it's a program, a document, a reference, a wikipedia article, news, guides, diagrams... anything. It all comes with a certain level of responsibility and even if you can't (or won't) take on that responsibility yourself, you have to be clear and transparent to the people who rely on your publication about the potential risks and pitfalls of it. Don't try to up-sell your own work, or offload your responsibility on others. Have respect for others who you rely on to create (and help you publish) what you do. Follow the rules, be honest about what you publish is and is not, and realise: what you do can (and will) change other people's lives.Tom Scott wrote:I've talked about 'bodging' things in the past. I encourage it for hobby projects; just slapping something together as a proof of concept, just so it works for you is a great principle when you're making a thing for yourself. But if you're making something for the public, for mass consumption, particularly something that's going to be used by people in very vulnerable moments, then you've got to take a lot more care.
Every time we build something for the public, we have to start making the trade-off: how much time and money is it worth to deal with every edge case? [...]
The problem is that we're often dealing with unknown harms and unintended consequences. Far too often, a bodged-together system that was just meant to be a test [sic: proof of concept] gets rolled out into production, and everyone just has to deal with the bugs because that's all anyone can afford to do.
I will always bet on incompetence rather than malice; I will always bet on someone just not thinking about consequences rather than thinking about them and going "Eh, who cares".
Every time that we design a system, we have to minimise the potential harm. Look at the code you write, look at the systems you design, and think: How could this be abused? How could this fall apart? What are the failure states here? If you were a bad actor, if you wanted to use this maliciously, how would you go about it? Think about how you'd attack your own systems, explore those failure states, deliberately screw things up and see how your code copes. Because if you don't, someone else will.
Thanks for reading.