I’ll make a counter-point: it’s more subtle then that. I highly recommend reading Roads and Bridges for a lot of background why and how people maintain FOSS and the issues. It casts are far wider net and models far more cases then this post, which only assumes one.
Most maintainers start working on open source software because it’s fun and solves a problem they have.
I would like to see a statistic for that. If you start “maintaining”, you either picked maintenance for fun or you should have thought about that for a night or seven.
The license has nothing to do with all that. It’s the legal disclaimer.
There’s obviously multiple groups here. There’s a non-negligible group of people that just wanted to build a cool thing for themselves, hit a nerve and suddenly, there’s a rush of users. Yes, for them, all of this is true. You never encouraged, you should plainly state that you have no intention of structured maintenance. The study quoted above documents a group that maintains software out of guilt, to avoid letting adopters down. This is far from “every maintainer”, though.
But it’s hard to find maintainers of larger projects that not at least at some point have said “I want people to use that”.
Let’s talk about projects that do set out to change the world and get adopted. Say, your bug number 1 is killing the Microsoft mono-culture. Or you want to make sure we have a JS base library doesn’t break the Array.prototype.flatten. Or you build a JS framework within a large enterprise that they want to push to the masses. Or you want a free desktop. If adoption is in any way your goal, adopters directly work on the goals of your project. They bet on you and rely on you. Everyone who introduces your project at their workplace, family or even personal computer makes a bet on your reliability and help. At the beginning of a project people literally put their careers at risk for that. They might not always be able to fix issues and they might not always be able to even competently do so. Their work and effort for the project lies elsewhere.
I’m selling a niche programming language. Adopters are our most important human factor! We owe them a lot.
This doesn’t mean you have to fulfill every wish, but you owe them a response, and explanation and a roadmap. You owe them at least to own your mistakes and to communicate plainly about the state of things. This also yields great results.
Seeing this whole meme about maintainers owing their users nothing is the saddest take FOSS currently has to offer. Your reliability and willingness to solve problems (or assisting in solving problems) is your largest credit.
I’d say a much larger part of the issue stems from the fact that people start projects without thinking about what it means to have a project and not a bunch of characters in a file structure.
Nicely said. In general, I basically agree with you! I want to lend one teeny piece of perspective to one part:
Seeing this whole meme about maintainers owing their users nothing is the saddest take FOSS currently has to offer. Your reliability and willingness to solve problems (or assisting in solving problems) is your largest credit.
I somewhat agree, but there’s another take here. I don’t think the OP is looking outward, but rather, looking inward. In particular, the opening is crucial to setting the context here:
Burnout is a big problem for open source software maintainers. This is avoidable; maintainers can have fun, keep healthy and be productive working long-term on open source projects. How? By realising they have zero obligations to any other maintainers, contributors or users of their software even if they have personally benefited from the project (e.g. through self-promotion or donations).
The language here is maybe a bit too generalized for my taste, but overlooking that, it seems like the OP is trying to describe their own personal coping strategy. It’s hard to take issue with things like that, because each individual deals with their own shit in their own way. Some coping strategies might be more popular than others, but I definitely identify with the OP here on this point. It is critically important for my own state of well being that I not allow myself to feel obligated to the projects I work on in my spare time. It’s the only way I know how to make the process sustainable. I maintain so many projects that there’s almost always something going on, and if I felt beholden to them every minute of the day, I’d be an emotional wreck. When I see an email for a project pop up on my phone, I don’t feel guilty when I dismiss it, only to check on it a week later. If I did feel guilty, then I’d wind up feeling shitty several times every single day. It ain’t sustainable.
With that said, yeah, there are definitely weird parts of this post that I have trouble identifying with (I don’t understand the appeal to the warranty disclaimer, and perhaps suggests that my interpretation here is actually wrong!), and it probably could have been communicated better overall. But I think coping strategies are a totally legitimate angle to take on this problem. It doesn’t always need to about The FOSS Community. It can be about the individual too.
I agree with your points! This is one of the reasons I don’t maintain Rust projects in my spare time next to my community work. I wouldn’t be able to fulfill any request proper.
If FOSS maintainership is seriously getting to you health over extended time and you can’t find an emotionally sustainable way to continue, by all means, quit. It’s perfectly fine to let people down. This is one of the reasons why I think “make yourself replaceable” is a very good strategy.
I can only encourage people to not take a simple position and blame things on the users. Introspection and taking the right steps is helping there. If that right step might is “shut down earlier then later”, all power to you.
By the way, if anyone here is running a conference concerned with FOSS: skip one of the “scale” talks, get a talk about these subjects.
When you realize all the same things, from the lack of warranty on down, apply to closed-source maintainers, you will have achieved enlightenment. Or at least a healthier understanding of what paying for something buys you, which may very well make you less annoying to be in line behind at the checkout.
Even if you do buy a warranty, well, the cure for a company not living up to a warranty isn’t making them work on their software. That’s specific performance, and the courts tend to not like that. The cure is money. If you have problems which can’t be cured by money, think very hard in advance and take your own steps.
That’s usually true about warranties in general. The businesses I’ve known that warranty software do fix it for you, though. So they won’t do free work forever, they often do it for specific number of defects in components they custom-built at a premium. Altran Praxis’s Correct by Construction comes to mind. Enough companies doing this might be used in court to establish it can be done with the rest just not doing it on purpose because they don’t care. From there, we might be able to use courts to force them to fix their software.
There’s at least potential there. I do agree it’s best to be ready for situation where money doesn’t cover resulting problems. Reputational effects come to mind.
I understand where this is coming from. Folks show up on projects that I work on and some of them act like entitled assholes who think I owe them my time. They are rude, obnoxious, and act like they are paying me.
When I’m a volunteer, ie unpaid, that the equiv of an organization that someone volunteers for complaining that I don’t volunteer enough. It’s infuriating.
This doesn’t describe all open source projects. But it’s clearly the sort of maintainer in mind for this article.
For these types of projects, I don’t think you can talk about this subject without discussing a variety of other topics.
For example, folks who get paid to do a job that uses a volunteer project that act entitled and don’t contribute. These are the worst.
But… how about the project that tries to get popular but also refuses to grow it’s maintainer bass enough to keep up? This refusal can be unintended or intentional, it happens though.
We don’t have the knowledge or tools to maintain sustainable open source.
But… maintainers play a role in this.
There are no easy answers here. And “maintainers owe you nothing” articles aren’t helpful. Especially when they lack nuance.
Open source succeeds when there’s a community. We need more conversations around building sustainable, respectful communities.
While I agree to some extent, there are two important counter arguments:
Everything that’s being said only apply to maintainers working for free:
if I pay you to fix an issue, than you have to fix it
if a widely used project is maintained by a company (or by a large community), there is at least a moral duty to evaluate and accept security fixes as fast as possible, whatever the license
Also, independently of the license (and even independently of the way a project brands itself), I think it’s important to distinguish between Free Software and Open Source, since the first implies Hackers’ ethics while the second is a marketing tool (and thus you cannot make assumptions about the leaders’ behaviour when bad things happen).
I think there’s also a big difference how much weight is on each individual maintainer’s shoulders.
Small project, 1 to few maintainers = mostly not a problem
Big project, many active maintainers = often less of a problem “this person annoys me, I will ignore THIS issue”
Hugely popular project, not enough maintainers = problems. Suddenly you have to take all the annoying rants about entitled users.
Just a few thoughts from someone who has always just had mostly ignored projects or was part of a big and/or awesome team and wouldn’t want to be lead maintainer on something like homebrew.
I’ve never maintained an open source project, so I’m in no way an expert on this, but the part about contributors has a back side of the coin. It’s implied by the wording of the article, but I thought I’d spell it out anyway. From the original post:
For contributors: defer to maintainers and ensure that you’ve read all relevant contribution documentation. They are the ones running the project and ultimately their word goes. Understand that it’s not the job of the maintainers to teach you how the project works (or actually anything).
This implies that good documentation is available. As a maintainer, write (or ask existing, knowledgeable contributors to write) clear and good documentation to guide newcomers. This is especially true for larger, more complicated projects. Make sure it’s easy to find that documentation for those who care to look for it.
I’ll make a counter-point: it’s more subtle then that. I highly recommend reading Roads and Bridges for a lot of background why and how people maintain FOSS and the issues. It casts are far wider net and models far more cases then this post, which only assumes one.
I would like to see a statistic for that. If you start “maintaining”, you either picked maintenance for fun or you should have thought about that for a night or seven.
The license has nothing to do with all that. It’s the legal disclaimer.
There’s obviously multiple groups here. There’s a non-negligible group of people that just wanted to build a cool thing for themselves, hit a nerve and suddenly, there’s a rush of users. Yes, for them, all of this is true. You never encouraged, you should plainly state that you have no intention of structured maintenance. The study quoted above documents a group that maintains software out of guilt, to avoid letting adopters down. This is far from “every maintainer”, though.
But it’s hard to find maintainers of larger projects that not at least at some point have said “I want people to use that”.
Let’s talk about projects that do set out to change the world and get adopted. Say, your bug number 1 is killing the Microsoft mono-culture. Or you want to make sure we have a JS base library doesn’t break the Array.prototype.flatten. Or you build a JS framework within a large enterprise that they want to push to the masses. Or you want a free desktop. If adoption is in any way your goal, adopters directly work on the goals of your project. They bet on you and rely on you. Everyone who introduces your project at their workplace, family or even personal computer makes a bet on your reliability and help. At the beginning of a project people literally put their careers at risk for that. They might not always be able to fix issues and they might not always be able to even competently do so. Their work and effort for the project lies elsewhere.
I’m selling a niche programming language. Adopters are our most important human factor! We owe them a lot.
This doesn’t mean you have to fulfill every wish, but you owe them a response, and explanation and a roadmap. You owe them at least to own your mistakes and to communicate plainly about the state of things. This also yields great results.
Seeing this whole meme about maintainers owing their users nothing is the saddest take FOSS currently has to offer. Your reliability and willingness to solve problems (or assisting in solving problems) is your largest credit.
I’d say a much larger part of the issue stems from the fact that people start projects without thinking about what it means to have a project and not a bunch of characters in a file structure.
People have expectations, and reasonably so.
Nicely said. In general, I basically agree with you! I want to lend one teeny piece of perspective to one part:
I somewhat agree, but there’s another take here. I don’t think the OP is looking outward, but rather, looking inward. In particular, the opening is crucial to setting the context here:
The language here is maybe a bit too generalized for my taste, but overlooking that, it seems like the OP is trying to describe their own personal coping strategy. It’s hard to take issue with things like that, because each individual deals with their own shit in their own way. Some coping strategies might be more popular than others, but I definitely identify with the OP here on this point. It is critically important for my own state of well being that I not allow myself to feel obligated to the projects I work on in my spare time. It’s the only way I know how to make the process sustainable. I maintain so many projects that there’s almost always something going on, and if I felt beholden to them every minute of the day, I’d be an emotional wreck. When I see an email for a project pop up on my phone, I don’t feel guilty when I dismiss it, only to check on it a week later. If I did feel guilty, then I’d wind up feeling shitty several times every single day. It ain’t sustainable.
With that said, yeah, there are definitely weird parts of this post that I have trouble identifying with (I don’t understand the appeal to the warranty disclaimer, and perhaps suggests that my interpretation here is actually wrong!), and it probably could have been communicated better overall. But I think coping strategies are a totally legitimate angle to take on this problem. It doesn’t always need to about The FOSS Community. It can be about the individual too.
I agree with your points! This is one of the reasons I don’t maintain Rust projects in my spare time next to my community work. I wouldn’t be able to fulfill any request proper.
If FOSS maintainership is seriously getting to you health over extended time and you can’t find an emotionally sustainable way to continue, by all means, quit. It’s perfectly fine to let people down. This is one of the reasons why I think “make yourself replaceable” is a very good strategy.
I can only encourage people to not take a simple position and blame things on the users. Introspection and taking the right steps is helping there. If that right step might is “shut down earlier then later”, all power to you.
By the way, if anyone here is running a conference concerned with FOSS: skip one of the “scale” talks, get a talk about these subjects.
When you realize all the same things, from the lack of warranty on down, apply to closed-source maintainers, you will have achieved enlightenment. Or at least a healthier understanding of what paying for something buys you, which may very well make you less annoying to be in line behind at the checkout.
Even if you do buy a warranty, well, the cure for a company not living up to a warranty isn’t making them work on their software. That’s specific performance, and the courts tend to not like that. The cure is money. If you have problems which can’t be cured by money, think very hard in advance and take your own steps.
That’s usually true about warranties in general. The businesses I’ve known that warranty software do fix it for you, though. So they won’t do free work forever, they often do it for specific number of defects in components they custom-built at a premium. Altran Praxis’s Correct by Construction comes to mind. Enough companies doing this might be used in court to establish it can be done with the rest just not doing it on purpose because they don’t care. From there, we might be able to use courts to force them to fix their software.
There’s at least potential there. I do agree it’s best to be ready for situation where money doesn’t cover resulting problems. Reputational effects come to mind.
I understand where this is coming from. Folks show up on projects that I work on and some of them act like entitled assholes who think I owe them my time. They are rude, obnoxious, and act like they are paying me.
When I’m a volunteer, ie unpaid, that the equiv of an organization that someone volunteers for complaining that I don’t volunteer enough. It’s infuriating.
This doesn’t describe all open source projects. But it’s clearly the sort of maintainer in mind for this article.
For these types of projects, I don’t think you can talk about this subject without discussing a variety of other topics.
For example, folks who get paid to do a job that uses a volunteer project that act entitled and don’t contribute. These are the worst.
But… how about the project that tries to get popular but also refuses to grow it’s maintainer bass enough to keep up? This refusal can be unintended or intentional, it happens though.
We don’t have the knowledge or tools to maintain sustainable open source.
But… maintainers play a role in this.
There are no easy answers here. And “maintainers owe you nothing” articles aren’t helpful. Especially when they lack nuance.
Open source succeeds when there’s a community. We need more conversations around building sustainable, respectful communities.
While I agree to some extent, there are two important counter arguments:
Also, independently of the license (and even independently of the way a project brands itself), I think it’s important to distinguish between Free Software and Open Source, since the first implies Hackers’ ethics while the second is a marketing tool (and thus you cannot make assumptions about the leaders’ behaviour when bad things happen).
Thanks for your insight, Mr. Stallman.
You are welcome, Mr. Ballmer! ;-)
Or give you your money back. ;)
I think there’s also a big difference how much weight is on each individual maintainer’s shoulders.
Just a few thoughts from someone who has always just had mostly ignored projects or was part of a big and/or awesome team and wouldn’t want to be lead maintainer on something like homebrew.
I’ve never maintained an open source project, so I’m in no way an expert on this, but the part about contributors has a back side of the coin. It’s implied by the wording of the article, but I thought I’d spell it out anyway. From the original post:
This implies that good documentation is available. As a maintainer, write (or ask existing, knowledgeable contributors to write) clear and good documentation to guide newcomers. This is especially true for larger, more complicated projects. Make sure it’s easy to find that documentation for those who care to look for it.
Yes, a thousand times yes 🙌