iliana
@iliana

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.


cactus
@cactus

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.


fasterthanlime
@fasterthanlime

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.


You must log in to comment.

in reply to @iliana's post:

Open source with an explicit non-focus on taking contributions, just for the sake of visibility, is really interesting. I've been following 0xide for a while because pretty racks but I respect that ethos a lot. I think one of the biggest examples of the other approach where it's an open source project maintained by a company but does accept contributions is VSCode -- amazing editor that I use 100% of the time, but there are some really conceptually simple issues open with 1k+ upvotes that have been around since 2017 and I can't help but wonder if they were just working on it themselves whether the community management time could have been allocated to just fixing it.

This is Microsoft we're talking about though so maybe not 😇

in reply to @cactus's post:

Really interesting to see this discussion come up again. 4 years ago, Clojure creator Rich Hickey wrote “Open Source is Not About You” that generated a lot of chatter on this topic. His stance is that Open Source only means “source code is available and usable within the bounds of the license” and nothing more, and everything else (community, issues, PRs, help) is up to each maintainer to determine for themselves.

When I first read it, it felt really harsh and rude, and as a Clojure dev I sometimes brush against places where I wish Clojure itself was different. But over the years I’ve also become a maintainer for a couple open source projects and have come to appreciate the hard line that says, “I made this for me and I’m willing to share it with you, but I don’t want to and won’t do any more than that.”

At this point, I want to write more “Source available” code with permissive licenses because I don’t have the time or energy for anything extra.

in reply to @fasterthanlime's post:

open source should not automatically imply community development. disabling the issue tracker is Valid™ and it's stupid that github doesn't have the option to disable PRs as well. gitea does :p

but funnily enough I've never had to disable issues. it's just the kind of projects that I publish?? they're mostly so obscure and personal that almost nobody cares about most of them. but even the somewhat successful ones like the systemstat and secstr crates are like… really not attracting any "demanding users" to the issue tracker. idk if it's just all about the kind of project or also the fact that I basically don't promote mine and they just never look "product-ish" or what