perhaps a blog post that will be churning in my head for the next several weeks is on the burden of open source maintainership. it's something i could quickly write tonight for here but i have no real interest in "discussion" so it will probably go on my blog where the comments can't hurt me because they are on the orange website and we Do Not Read That In This House, Young Enby.
the summary, though, is that everything being open source is not the answer, because one must (still! in 2022!) weigh the pros and cons of open sourcing something. and the primary con is the labor involved in being an open source maintainer: answering the same questions over and over again. writing out the reasons for rejecting pull requests to the person on the other side of the wall who might take it as an insult. a community of individuals not working toward a common goal holding a codebase to a higher standard than it otherwise would be if it's just a handful of people working internally on it. (and this is before you even get to "wait hold on have capitalists figured out how to extract free labor by arguing code they can't use isn't 'open source'?")
if you only have a handful of people working on a project, the effort of maintaining your code base and your community out in the open will far outpace the effort actually building the thing you want to build.
i do not do consulting because i would go insane, but if i did do open source consulting my #1 advice for most small businesses would be to not even think about making projects open source, because that is focus you are taking away from your product being good and, more importantly, your company being self-sufficient. you do need a plan for how you are going to keep track of the open source software you use (and redistribute), because get real it's 2022 you're going to use some random code you found on the internet, but being an open source maintainer is a full time job you probably didn't sign up for.
[an aside on my current job and open source maintainership]
i am continuing my 15 years (half my life!) of working in open source at my current employer, who argues that any software we ship to a customer buying our hardware should be open source. there are very good reasons for this that outweigh the effort of fielding external questions and pull requests and managing a community etc etc — especially because in the vast majority of our repositories, we explicitly tell people that looking at external contributions is a non-goal for us.
ok i know xie just said xie's not interested in discussion but i have a semi-related ramble that i already typed and i dont want to delete so
in one sense, the difference between closed source and open source is if your github repo is set to public and you have the right kind of license in it, and so being open source isn't more work. a lot of teams at work have their main repo set to public and with the right kind of license, and my team has our main repo set to private, and afaik they don't do more work than we do just because their code is public.
in another sense, making your project open source is leaving your front door open for a bunch of stray cats to wander in.
- some of them may just be looking for a place to sleep, and they might pass through for a bit but they won't make nuisances of themselves. these are Just Users, and you may never notice they exist if you don't go looking for them
- some of them want food, and if you don't give them food, they will nag you incessantly. maybe you already had cat food and you can just give them some, maybe you don't and you have to either go get cat food just for them or tell them to fuck off. they have Bug Reports and Feature Requests
- some of them found a really delicious critter that they would like to offer you as a gift. you don't eat critters, you didn't ask for a gift, and it might be the thought that counts but sometimes it's the damn work that counts. or maybe they found something shiny that you want to hang up on your wall, who's to say. they have Pull Requests
what all of them have in common is they are making their problems your problem. in the first case, their problem was already the same as your problem, and they can make your solution their solution without bothering you. this is the actual best case scenario for open sourcing the shit you were making anyway. in the other cases, their problems extend beyond your solution; if you're lucky, their problems are also your problems, and you just reprioritize work you were going to do anyway or you don't have to do it yourself at all. you will not always be lucky, and now you have to either include irrelevant bullshit or exclude it and maybe step on the toes of people who assumed that you wanted their opinion.
(i dont actually know if this is a defensible characterization of stray cats, it's a metaphor ok don't at me)
fun fact: github lets you disable issues on a repository, but it does not let you disable pull requests, as far as i can tell. i also can't find a way to allow those contributions from preexisting collaborators but not from randoms, aside from making the whole repo private.
i suspect that what happens at work is our metaphorical house is really out of the way and so no stray cats walk in through the front door to bother us at all, because a lot of our code is specific to us and of limited utility to anyone else. but i can easily imagine that if that changed, it would get old fast, and before long we'd be thinking about just closing the damn door.
i think there are reasons it is neat to have your code be public, and it can sometimes even be a good idea to use a real license. and technically, literally, that's all it means to be open source. but by all accounts Open Source Maintenance is frequently hell and also a scam, and at the bare minimum you should make damn sure you're signing up for it on purpose.
the timing on this is uncanny, as I've been debating open sourcing my side projects recently, AND there's been some discussion from folks who "would literally pay to be able to fix small things in the cohost frontend"..
One thing I'd be open sourcing is a web app with multiple components that are relatively annoying to operates and so I would need to plaster a big DO NOT USE THIS YOURSELF, THIS IS ONLY HERE SO YOU CAN FIX THINGS THAT BOTHER YOU, I WILL EXPEND ZERO EFFORT CATERING TO USE CASES THAT ARENT MINE, BUT FEEL FREE TO GET INSPIRATION FROM IT
The problem with such a notice is that everyone goes this sign cannot stop me because I cannot read and before you know it you get issues like:
I convinced my boss to switch to this and/or staked my entire life savings onto using this in production and am now realizing it's not meant to do what I need at all, do you mind if start changing everything
Like, I want my thing to be open source so I can accept a little help like "that CSS is wonky on Firefox" or "here, have a workaround for a Safari bug", I don't want to actually have another toddler compete for my already-in-short-supply attention.
