10 ms·

The burden of an Open Source maintainer

126 points by geerlingguy 5y ago

clock99 5y ago
mrtksn 5y ago
A developer creates a work, gives it for free(in writing) and receives fame and applause by the terms of the social contract. When the products turns out to have problems, an issue arises between the supplier of the product and the supplier of the fame and praise. I think that's why people feel entitled to customer service. If the developer fails to provide a good customer service, the users demand refund, that's why it feels very similar to regular customer support. In fact, the users of the free software can often be much more demanding. Maybe they are rightfully so, since they paid with social capital that is limited, precious thing - unlike money that can be earned in by doing work for a bit. The pain as a result of the product failure is also the same, it doesn't matter if you paid for it by a monetary transaction or tapping the like button. Even if you haven't done anything directly, you inflated the developers stats - which are the main KPI anyway. IMHO, if someone wants to make money from their work they should explicitly charge for it. You can't expect to receive all the street cred for giving away your work for free and also receive money for your work. The maintenance is simply, street cred maintenance. Many years ago I learned my lesson for giving stuff away for free. It's tough to sell your stuff in exchange for a reputation, the demands of the customer never ends. Your part in the deal is also not clearly defined, you are expected to fulfil your obligation by working on every single request no matter what is the scope and if you fail to do that your free users will be mean as if you scammed them. edit: Sorry for not being able to reply to you all but my account seems to be rate limited. Unpopular opinions have consequences I guess. Shouldn't hold them.
- deleted 5y ago
  [deleted]
- ahelwer 5y ago
  Not sure about this model. I write open source software because of the inherent human desire to create. Benefits from admiration I receive comes a distant second to the happiness of exploring a problem then crafting a nice solution, on my own time, in my own way. In a lot of ways, working without compensation then freely releasing the output is weirdly selfish. It is appealing because you are so free from the obligations to others brought by getting paid. Users might invest time in using your software, and it is this time they feel robbed of when things go awry. I have been on both sides of this. I used to become very angry when something doesn't work right out of the box after quickly skimming a setup tutorial. At the time I was working for salary. Any free time I had was very valuable and couldn't be sucked up doing the same thing I do at work - debugging config issues, retrying with different options or environmental changes, etc. It was only after becoming a part time independent contractor that I developed the patience to really deal with open source software. To feel I had enough mental energy to really read the documentation or look inside the source code and debug what's going on - totally different from the customer service experience of dealing with proprietary software. People become frustrated when the effort needed to understand or deal with something is beyond what they are willing to put in. I don't think open source can escape its problems until a substantial portion of users have the time and energy to really engage with it. We should be working far fewer hours than we actually do.
  - mrtksn 5y ago
    I agree, the work comes from desire to create but I think the public github repo and the promises you give to the potential users comes from the desire to receive praise and cred for your work. From the users perspective, the joy and the pain is the same as with the paid product. If you promised them something and underdeliver, they feel scammed.
- White_Wolf 5y ago
  I'm not sure about others but when I publish a piece of software or script it's because I needed it for something and I'm done working on it for my needs. If someone has different needs than mine they can DIY or pay someone to do it. If anyone else needs it, they are free to copy and use it. If they find a problem that I think needs fixing or my stuff will cause me problems, I'll fix it. Otherwise, they are free to fix it and(if kind enough) submit it. I have 0 obligation to fix anything that I don't personally need and anyone that copies it has 0 obligation to give me anything in return. I only published it to save someone else the time for the bulk of the work. I'm not doing it for money or cred. I do it because it's something I already finished(more or less) and it won't cost me anything to share. Anyone elses needs(family and friends exempt) are not my problem unless It's my (paid) job to make them my problem.
  - mrtksn 5y ago
    But why upload it to Github or somewhere similar, do the marketing(a README that often promises something like enterprise ready Atomic transactions) and licensing? If the work was to fulfil your own needs it would have been a private repo or a folder in your drive. The moment you publish it, a social contract is established similar to creators of other free work like youtube videos etc. You receive cudos and fame, they receive a tool, entertainment, knowledge etc. When you fail your part of the contract, people can be very mean as the are mean on a Youtube vide that they don't like.
    - andrewzah 5y ago
      No. No. No. There is no such thing as this "social contract". I publish software on github with MIT or (A)GPL licenses for various reasons: * In case someone else has the same issue I did * In case someone is working on something similar and wants to learn from my code * As an external backup in addition to my hard drive / private git repo / etc. * Because I can. (deal with it.) There is NO expectation or "contract" or anything. People can open issues or politely request things, but getting upset or pushy over F/OSS released on someone else's own terms is just entitlement.
      - 5y ago
- hitekker 5y ago
  I agree. There's a kind of social-transactional element to Open Source that people don't like to talk about. Like, chasing clout instead of dollars. If you're a committed maintainer who writes a lot of packages and sacrifices a lot of your free time, chances are you have some self-interest in the mix. The illusion of universal altruism probably helps insulate people from thinking about the uncomfortable politics of Open Source. I'd like to read an article covering your insights.
- pure_simplicity 5y ago
  I think this mindset is fundamentally wrong on multiple levels. 1. There is no contract, not even implicitly, that promises software maintenance in exchange for praise. The praise may be a motivating factor for the developer, but anyone who thinks they are entitled to anything just cuz they showed some appreciation has not read the Open source License, which almost always states the software is provided as is without warranties. 2. Genuine praise is not transactional. The only factor affecting praise or criticism should be merit. Any other quid pro quo makes praise into hollow lip service, meaningless fungible gibberish uttered for personal gain. Praise is more like a donation than a payment. 3. Even if praise/fame somehow could function as currency, then any individual is not providing enough of it to earn themselves any significant privileges. Maybe in aggregate the community would have a 'claim' (if the developer agreed to this contract), but even then the obligations incumbent on the developer would be limited and unclear, because no one person can speak on behalf of the community and for most projects their community does not organize itself in such a way as to permit concerted group action that can be recognized as the will of the community. 4. if you feel like you have been robbed of your praise, you simply withdraw it or voice criticism. Or you recognize that your praise was still applicable and valid to the parts of the project that you were aware of at the time of voicing your opinion, so therefore is still deserved. If you think you provided more praise than is merited by the project, then that's an error in judgment on your part. No one asked you to proclaim project [projectname] the best thing since sliced bread and the hope of humanity that is literally gonna change the world. Just be more careful with who you choose to praise.
  - mrtksn 5y ago
    See, no one is suing you when you don't help people or don't maintain your work. They simply say bad things about you and your work, the exact opposite of the "payment" your receive. It's practically a chargeback.
- rockbruno 5y ago
  >fame and applause >Maybe they are rightfully so, since they paid with social capital I'm sorry, but I think you're exaggerating a lot here about the worth of "fame" in something as niche as writing open source software. It's like when people try to pay artists with "exposure" -- flashy, but worthless in every imaginable way. Case in point: The creator of Homebrew who famously failed to get a job at Google despite having all "street cred" imaginable.
- BeetleB 5y ago
  > A developer creates a work, gives it for free(in writing) and receives fame and applause by the terms of the social contract. There is no "the" social contract. There are many social contracts, and they are not all compatible with one another. The whole point of written, legal contracts is due to a recognition of this fact. I don't abide by that (or any) social contract when I put something on Github, and nor should I. When I say that I can't guarantee this code won't cause harm (e.g. destroy HW or files on your HD), I mean that. If you want to labor under unspoken, unwritten contracts, be my guest.
  - webmaven 5y ago
    > When I say that I can't guarantee this code won't cause harm (e.g. destroy HW or files on your HD), I mean that. Okay, but imagine for a moment that you don't say that. The README is silent on the issue of potential problems. Are you violating any social contract then? Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README. Are you violating any social contract at that point? If you don't like the term "social contract", would you agree that you would be violating some norms?
    - BeetleB 5y ago
      Of course I'm violating some contract/norm. I am also conforming to some contract/norm. That was the whole point of: > There is no "the" social contract. There are many social contracts, and they are not all compatible with one another. Similarly, those expecting my code won't cause damage are also violating certain social norms. The code is there for anyone to do what they want with it. Do with it what you will, and own the consequences. > Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README. My Github repositories are very low in importance on my list of important things in life. I reroute most notifications to a folder and will go through that folder only a few times a year, so I likely won't even know about any such issues for months. Now personally, I do put a disclaimer in the README stating that people should view the code as unsupported and unmaintained (even though I do update the code from time to time), but I do it merely as a courtesy, not as an expectation. I do not at all endorse that people should put such disclaimers.
0xbadcafebee 5y ago
As a user, I feel pain when I use something free that seems like it should work, and I invest a lot of my time in making it work, and then I run into a bug, and report it, and the bug isn't fixed because there's no investment in it. I know it's my own fault for trying to use something without paying for support. But I get upset anyway, probably because I wasted my own time, and believed the unconscious lie that I told myself that using this thing [without support] was a good idea. (And even paying for support isn't a guarantee a bug will be fixed!) I develop open source projects too, so I'm intimately familiar with both sides. It's a bizarre feeling when I realize I am acting (as a user) the same way other users act towards me (as a maintainer). I think being a maintainer is a healthy reminder that I should lower my expectations as a user of free stuff. The reason I create open source stuff is there was a problem I wanted to solve, and I want to share my solution with others so they don't struggle with the same problems. I try hard to make it easy for people to use my solution, and I hate the feeling that someone might be inconvenienced by using it. I really do want to fix all reported bugs. But at the end of the day I have a life (and a job) that gets in the way. I feel bad about any bugs, but I don't feel bad about taking a long time to fix them, because my quality of life is more important.
- geerlingguy 5y ago
  I sometimes feel this too, especially if I spend a day or two working on a bugfix that feels (to me) simple and logical, and then it sits rotting in the PR queue for a few months. There's a feeling of indignation, but I constantly remind myself that on the other end of the PR is a maintainer like myself, so I try to remember to bite my tongue and be extra nice.
indymike 5y ago
"I'll recommend they fork the project" This is really the right answer a lot of the time. The first few times I submitted a PR and got rejected or ignored, I took it personally. Then a maintainer explained it to me (ran into him at an in-person meetup), and it was very similar to Jeff's explanation here. Also, what makes it really hard for maintainers is that a lot of the requests they get are from people who don't have the ability or desire to fork the project (and even less ability/desire to maintain the fork).
PragmaticPulp 5y ago
> I maintain over 200 open source projects That’s just a little bit beyond what the average open source maintainer has on their plate. Regardless, the attitude of recommending that people fork a project if they really need something is the way to go. It’s okay to say “no” to an influx of requests and demands. The maintainers who burn out the fastest are the ones who view every comment, suggestion, request, or piece of feedback as equally important. It’s okay to let something be your personal project and not let the community take a sort of control over your time. Do it long enough and you will develop a thick skin, if only out of necessity. Open source will expose you to some of the nicest, smartest, most thoughtful people you’ve ever worked with. It will also expose you to some of the most demanding, manipulative people who will use every social pressure technique they know to try to make you feel bad about not doing exactly what they want.
- duxup 5y ago
  It seems like the Open Source ethos also could also use some additions like: 1. How to maintain a healthy approach to your popular code. 2. How / why to say no without looking like the jerk. 3. How to find / manage help when you need it. Handy skills for life too... Granted plenty of folks do it very well, but there's nothing about Open Source that necessarily provides any of that and some folks who love to help, share, and solve problems fall into bad places. That also leads me to wonder how much complexity for most projects is even needed. I kinda wonder if for most projects maybe 90% of the people using the code use it for a handful of tasks, and yet the vocal loud folks demanding more are a very small minority...
  - latchkey 5y ago
    After ~25 years of open source and regretting a lot of my earlier behaviors as a younger human, a couple years ago I created another open source project [0]. I made a point of setting it up right from the beginning. Easy build system, fully unit tested, code of conduct, automated CLA signing, examples, good documentation and most importantly, I am excessively kind to anyone who comments or gives feedback. This took an inordinate amount of time up front, but was worth it. I'd say the result of this is that I've gotten a couple high quality contributions, zero stress and very very little feedback. It has been a pleasure to maintain this project because it causes me no pain at all. I'd say that maintaining 200+ projects is just insane really. You've overdone it. It is impossible to do any of them extremely well and of course you're just going to invite 200x more drama. Don't do that. [0] https://github.com/lookfirst/mui-rff https://github.com/lookfirst/mui-rff
cube00 5y ago
While everyone is free to maintain their projects as they wish, you don't necessarily need to maintain this level of control. As the project gains traction you'll develop a community of trusted developers around you and you could consider granting commit access to some of them to help reduce your workload. It can also reduce the stress of feeling that you'll be blamed if something goes wrong and it becomes more of a community effort which is one of the benefits of open source.
Shish2k 5y ago
I wonder if we need a middle-class of open source contributor — I see a lot of over-worked maintainers, and I see a lot of drive-by contributors with interesting half-baked ideas or PRs that fix one bug but fail CI tests — I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy...
- pc86 5y ago
  Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that?
  - webmaven 5y ago
    > Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that? Sure, especially if your (meta) goal is minimizing individual maintainer effort. But if you want instead to maximize maintainer and contributor return on effort (counting both the originator and the polisher as contributors), a different approach may be called for. Maintainers "just" need to figure out for themselves not just how much work they are willing to put in, but what sort of work, and what work (if any) they are able and willing to delegate or offload onto others. For a maintainer who isn't willing or able to do the work of polishing contributions or handholding potential contributors, and doesn't have anyone they trust that is willing or able to do that work, rejecting most PRs (and even issues, for that matter) outright can be an entirely valid approach. Open source success and sustainability don't look the same for every project or for every maintainer.
- pbowyer 5y ago
  > I wonder if we need a middle-class of open source contributor [...] I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy... We need a valuing of non-coding contributions, and a way of welcoming them into projects. I like building community and dealing with people. I like project management, planning, and thinking about funding opportunities. I even like (but am not good at) writing documentaiton - but only if the author of the code is willing to explain _why_ they wrote the code this way rather than get me to write how it works. I haven't come across a project that is open to welcoming people who bring these skills. People do these things have got to that place through long-term involvement, or because the role fell to them. Or no one does it. A decade ago there was a drive to get designers and UX people involved in open source projects [0]. It came to little, to the detriment of the entire open source community. Writing code isn't the only skill important in a project, and if we embrace that the whole experience of using the framework, library or software improves. 0. https://markboulton.co.uk/journal/design-in-open-source/ https://markboulton.co.uk/journal/design-in-open-source/
canyonero 5y ago
I really liked an article on the subject of sustainability in open source by Dave Rupert. See https://daverupert.com/2021/12/sustaining-maintaining/ https://daverupert.com/2021/12/sustaining-maintaining/ One of the of the points Rupert drives home is that open source with the goal of sustainability doesn’t have a framework in place that doesn’t lead to burnout. Everyone just learns lessons the hard way without any real manual for successful outcomes.
- ozim 5y ago
  Why there should be sustainability built in? Not everyone should be publishing their code and definitely not everyone should be OSS maintainer. From what I see and how I look at things, people think it "fun" or "cool" and don't understand full picture of what it really is to be OSS maintainer. I also don't think that simply more OSS is better - while yes, corporations should share more, software written with taxpayers money should be open - but randoms from around the globe should keep their leftpads for themselves and their friends.
  - janfoeh 5y ago
    I wholeheartedly disagree with your underlying premise of what open source is or should be. It's not a job. It's not a résumé. It's not a damn lifestyle or an in-group to define yourself through. It's a way of saying "I wrote this. I allow you to look at it and use it for yourself, if you like". Nothing more, nothing less. > randoms from around the globe should keep their leftpads for themselves and their friends. That seems like a bizarre inversion of responsibility to me. Randoms can publish whatever they please; if you use their left-pad, that's on you and you alone.
    - ozim 5y ago
      If it is not a job then why people are getting burned out, why people nag about not getting compensated?
  - canyonero 5y ago
    > Why there should be sustainability built in? I don't think it should be built in by default to any software that is released open-source. But, I do think having guidelines for how software can be developed in such a way that doesn't lead to burnout. The linked article pertains to avoiding the path to burnout, which if you are sharing code that an author a.) expects to "own" and maintain and b.) hopes other people will use, then you need should educate yourself as to how this can be achieved. Good literature on the subject is limited IMO. > Not everyone should be publishing their code and definitely not everyone should be OSS maintainer. I partially agree with this. I do think not everyone is up for the task of OSS maintenance and development, some of which is likely stemming because they don't have a good framework for how to do so sustainably. I do think anyone should be able to freely publish their code if they like. Sometimes folks want to share things for fun or education or demonstration purposes, when they don't intend to accept or want PRs or contributions or downstream consumption or maintain it. There is value in OSS for many different reasons. I think GitHub in particular does a poor job of signaling to readers which software is sustainable and which is not.
blakesterz 5y ago
I just want to give a BIG thank you to geerlingguy. I use a couple of your Ansible roles and they're great! It's amazing how much work you put in and it's most appreciated!
BoysenberryPi 5y ago
I'm more interested in how Jeff manages to maintain 200 open source repos and still have time for all the other extracurricular he does like the graphics card RPi testing he has going on. Please tell me your time management secrets.
- geerlingguy 5y ago
  Two things: saying no to the majority of time requests (it used to be very hard for me, but now I realize the power it gives me over my own time), and focusing on one task until it's done (I have a few Trello boards and have gotten more religious about 'WIP' during my working hours... though I probably hang out on HN and Reddit a bit too much still).
deleted 5y ago
[deleted]
j1elo 5y ago
> Despite how much some people detest the stale bot [...] I detest the stale bot :-) And I really think it only is a disservice to the project, 99% times I see it used. If the code has a genuine, real defect, it will not "go away" magically just because nobody complained again, or the authors didn't have time to look on it. See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue. I really hate when googling about some problem and then finding a promising bug tracker conversation that then... got comments closed because of old age. That's literally swiping the problem under the rug. Now regarding burnout and burden of OSS maintainers, I might lack a bit of empathy here, but I just don't get it. Really the license text says it all: THIS PROJECT IS OFFERED AS-IS. Most if not all OSS licenses have a phrase like this. Just quote those words 100 times if it's needed. My mental health as an OSS maintainer is very well and I cannot see it being changed by some, even lots, of demanding users at any point. Every time someone takes my code and uses it, there is an implicit conversation where I go "hey, here you are take this work for free, I'm lending it to you AS-IS, do whatever you want with it!". Absolutely at no point in time I feel pressure about defects in the code, after having this imaginary conversation. I guess we need more spreading of the notion of "not giving a sh*t" so the idea gets extended to more and more OSS maintainers, helping them have a happy life not encumbered by the work they decided to release by sheer goodness. EDIT: with this last phrase I mean that one should have the mentality of contributing up to, and not more, what one is able to do within their own limits. The "not caring" I mention is for after reaching this limit: it will help not pushing through the burnout line, and thus as a result being happier in the long term.
- corndoge 5y ago
  Your latter point doesn't make a lot of sense to me. I write and maintain open source software because I enjoy seeing people use it. For me, not giving a shit about it means not working on it at all. It seems like it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra but in reality that just doesn't work for me. And I bet I'm not so different from most foss maintainers.
  - j1elo 5y ago
lol768 5y ago
I honestly detest stalebot - if you don't want to keep on top of your projects' issues/PRs, fine - but don't artificially and automatically close issues that explain very real limitations in your project just because you don't have the time to look at them. If you do that, you rob the next n visitors the ability to understand what works and more importantly what doesn't work at a glance, from the open issues/PRs list. That security vulnerability or bug isn't going to vanish into the ether because a "helpful" bot closed the issue. It'll still be there - but it'll get lost in every other closed issue. I will happily just comment on the issue every single time the bot closes it out of spite to force it to be re-opened. Hell, it's probably overdue someone writing an anti-stale-bot that does exactly that. Related: https://drewdevault.com/2021/10/26/stalebot.html https://drewdevault.com/2021/10/26/stalebot.html
- lostdog 5y ago
  Really stalebot shouldn't close issues. It should put them into a "stale" state, where they still exist for users to read, but are filtered out when maintainers look at a list of issues with the project.
- geerlingguy 5y ago
  If there is a bug, I typically mark it with a `bug` label, and I configured stale bot to ignore those issues, so they do remain open: https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/stale.yml#L15 https://github.com/geerlingguy/ansible-role-docker/blob/mast...
  - remram 5y ago
    If triage is happening stalebot is fine. Unleash it on "need-more-info" issues, or feature requests with no upvotes, I don't think anyone has a problem with that. I think people are objecting to un-triaged issues being able to go stale, and you then have to keep fighting the bot every month because the maintainer doesn't spend the time to confirm it while demanding you waste your own time to bump it.
tomcam 5y ago
First off, my sympathies and awe go to someone with that much to give. Thank you, Jeff. Second… I desperately want a post describing how one person maintains 200 projects! Wow!
- geerlingguy 5y ago
  The cynical take is that said maintainer doesn't really 'maintain', but rather 'lets rot'. The optimistic take (and what I prefer to believe) is that if a project works, and solves the problem the maintainer wants it to solve, it doesn't need to be changed unless/until it breaks.
  - lostapathy 5y ago
    I agree with your optimistic take here. A lot of people are reading the “200 projects” and assuming they are all big projects. On the contrary, a lot of your projects seem to keep a very narrow focus that allows them to get to a state of “done for now” even is nothing is truly ever finished due to upstream and downstream changes around the project.
  - tomcam 5y ago
    The optimistic take is a good one. Thank you very much for your reply.
flucivja 5y ago
I wonder if OSS world needs kind of Spotify/Netflix platform for OSS distribution. If I would put in analogy OSS Developers to Music authors and songs/albums to OSS projects then such distribution platform would be paying developers depending on how much their project is used and maybe some other criteria and everybody who would like to use some OSS would need to pay monthly subscription to that platform.
- lomereiter 5y ago
  You are describing Tidelift (https://tidelift.com/ https://tidelift.com/) except the bit where the users would "need to pay" - although that could be addressed e.g. via regulations for enterprises but not individuals.
- pjmlp 5y ago
  They had it back in the day with stuff like the Walnut Creek CD-ROM distributions. In the long run, the only monetary solution is to go back to some kind of PD/Shareware, which is what all those public core, commercial full solution end up being. 30 years ago we called those public core parts, playable demos.
remram 5y ago
This might be an unpopular take, and I'm aware of how it sounds, but why don't you stop maintaining those projects if you can't do it properly? You are not required to do this. It doesn't even mean you have to stop making new things, you can just not take on that role as a focus point of each of their respective communities. As a user of a library, I don't hold it against their author when I find a piece of software that is abandoned. I will create my own fork and start maintaining it if I have too, or understand the state that it's in. I will find alternative avenues to discuss issues if the GitHub issue tracker is closed. Just don't make yourself the center of a community if you are going to unleash a stalebot trashing other people's genuine issues. You are making it impossible for someone to fork. because they would be competing with the author; people might even find it distasteful. So everyone is forced to go through you, leading to both suboptimal software governance and burnout on your part. You are not getting paid, why force yourself?
- gnubison 5y ago
  > why don't you stop maintaining those projects if you can't do it properly? Well, perhaps they are doing it properly, and everyone else has the wrong definition of “proper”. Good stewardship does not mean accepting every patch and every new feature.
  - remram 5y ago
    By "improperly" I don't mean a disagreement on the project's direction; apologies if that wasn't clear. I mean using things like stalebot, shutting down discussions and increasing the demand on other people's time in your community just because you personally don't have the time to keep up. If you have reviewed a patch and you don't think it's the way to go, or you don't think it can be maintained going forward, that's fine. If you set up stalebot to close and lock merge requests because you don't have time to review, that's something else.

126 points by geerlingguy 5y ago

A developer creates a work, gives it for free(in writing) and receives fame and applause by the terms of the social contract. When the products turns out to have problems, an issue arises between the supplier of the product and the supplier of the fame and praise. I think that's why people feel entitled to customer service. If the developer fails to provide a good customer service, the users demand refund, that's why it feels very similar to regular customer support. In fact, the users of the free software can often be much more demanding. Maybe they are rightfully so, since they paid with social capital that is limited, precious thing - unlike money that can be earned in by doing work for a bit. The pain as a result of the product failure is also the same, it doesn't matter if you paid for it by a monetary transaction or tapping the like button. Even if you haven't done anything directly, you inflated the developers stats - which are the main KPI anyway. IMHO, if someone wants to make money from their work they should explicitly charge for it. You can't expect to receive all the street cred for giving away your work for free and also receive money for your work. The maintenance is simply, street cred maintenance. Many years ago I learned my lesson for giving stuff away for free. It's tough to sell your stuff in exchange for a reputation, the demands of the customer never ends. Your part in the deal is also not clearly defined, you are expected to fulfil your obligation by working on every single request no matter what is the scope and if you fail to do that your free users will be mean as if you scammed them. edit: Sorry for not being able to reply to you all but my account seems to be rate limited. Unpopular opinions have consequences I guess. Shouldn't hold them.

deleted 5y ago
[deleted]
ahelwer 5y ago
Not sure about this model. I write open source software because of the inherent human desire to create. Benefits from admiration I receive comes a distant second to the happiness of exploring a problem then crafting a nice solution, on my own time, in my own way. In a lot of ways, working without compensation then freely releasing the output is weirdly selfish. It is appealing because you are so free from the obligations to others brought by getting paid. Users might invest time in using your software, and it is this time they feel robbed of when things go awry. I have been on both sides of this. I used to become very angry when something doesn't work right out of the box after quickly skimming a setup tutorial. At the time I was working for salary. Any free time I had was very valuable and couldn't be sucked up doing the same thing I do at work - debugging config issues, retrying with different options or environmental changes, etc. It was only after becoming a part time independent contractor that I developed the patience to really deal with open source software. To feel I had enough mental energy to really read the documentation or look inside the source code and debug what's going on - totally different from the customer service experience of dealing with proprietary software. People become frustrated when the effort needed to understand or deal with something is beyond what they are willing to put in. I don't think open source can escape its problems until a substantial portion of users have the time and energy to really engage with it. We should be working far fewer hours than we actually do.
- mrtksn 5y ago
  I agree, the work comes from desire to create but I think the public github repo and the promises you give to the potential users comes from the desire to receive praise and cred for your work. From the users perspective, the joy and the pain is the same as with the paid product. If you promised them something and underdeliver, they feel scammed.
White_Wolf 5y ago
I'm not sure about others but when I publish a piece of software or script it's because I needed it for something and I'm done working on it for my needs. If someone has different needs than mine they can DIY or pay someone to do it. If anyone else needs it, they are free to copy and use it. If they find a problem that I think needs fixing or my stuff will cause me problems, I'll fix it. Otherwise, they are free to fix it and(if kind enough) submit it. I have 0 obligation to fix anything that I don't personally need and anyone that copies it has 0 obligation to give me anything in return. I only published it to save someone else the time for the bulk of the work. I'm not doing it for money or cred. I do it because it's something I already finished(more or less) and it won't cost me anything to share. Anyone elses needs(family and friends exempt) are not my problem unless It's my (paid) job to make them my problem.
- mrtksn 5y ago
  But why upload it to Github or somewhere similar, do the marketing(a README that often promises something like enterprise ready Atomic transactions) and licensing? If the work was to fulfil your own needs it would have been a private repo or a folder in your drive. The moment you publish it, a social contract is established similar to creators of other free work like youtube videos etc. You receive cudos and fame, they receive a tool, entertainment, knowledge etc. When you fail your part of the contract, people can be very mean as the are mean on a Youtube vide that they don't like.
  - andrewzah 5y ago
    No. No. No. There is no such thing as this "social contract". I publish software on github with MIT or (A)GPL licenses for various reasons: * In case someone else has the same issue I did * In case someone is working on something similar and wants to learn from my code * As an external backup in addition to my hard drive / private git repo / etc. * Because I can. (deal with it.) There is NO expectation or "contract" or anything. People can open issues or politely request things, but getting upset or pushy over F/OSS released on someone else's own terms is just entitlement.
    - 5y ago
hitekker 5y ago
I agree. There's a kind of social-transactional element to Open Source that people don't like to talk about. Like, chasing clout instead of dollars. If you're a committed maintainer who writes a lot of packages and sacrifices a lot of your free time, chances are you have some self-interest in the mix. The illusion of universal altruism probably helps insulate people from thinking about the uncomfortable politics of Open Source. I'd like to read an article covering your insights.
pure_simplicity 5y ago
I think this mindset is fundamentally wrong on multiple levels. 1. There is no contract, not even implicitly, that promises software maintenance in exchange for praise. The praise may be a motivating factor for the developer, but anyone who thinks they are entitled to anything just cuz they showed some appreciation has not read the Open source License, which almost always states the software is provided as is without warranties. 2. Genuine praise is not transactional. The only factor affecting praise or criticism should be merit. Any other quid pro quo makes praise into hollow lip service, meaningless fungible gibberish uttered for personal gain. Praise is more like a donation than a payment. 3. Even if praise/fame somehow could function as currency, then any individual is not providing enough of it to earn themselves any significant privileges. Maybe in aggregate the community would have a 'claim' (if the developer agreed to this contract), but even then the obligations incumbent on the developer would be limited and unclear, because no one person can speak on behalf of the community and for most projects their community does not organize itself in such a way as to permit concerted group action that can be recognized as the will of the community. 4. if you feel like you have been robbed of your praise, you simply withdraw it or voice criticism. Or you recognize that your praise was still applicable and valid to the parts of the project that you were aware of at the time of voicing your opinion, so therefore is still deserved. If you think you provided more praise than is merited by the project, then that's an error in judgment on your part. No one asked you to proclaim project [projectname] the best thing since sliced bread and the hope of humanity that is literally gonna change the world. Just be more careful with who you choose to praise.
- mrtksn 5y ago
  See, no one is suing you when you don't help people or don't maintain your work. They simply say bad things about you and your work, the exact opposite of the "payment" your receive. It's practically a chargeback.
rockbruno 5y ago
>fame and applause >Maybe they are rightfully so, since they paid with social capital I'm sorry, but I think you're exaggerating a lot here about the worth of "fame" in something as niche as writing open source software. It's like when people try to pay artists with "exposure" -- flashy, but worthless in every imaginable way. Case in point: The creator of Homebrew who famously failed to get a job at Google despite having all "street cred" imaginable.
BeetleB 5y ago
> A developer creates a work, gives it for free(in writing) and receives fame and applause by the terms of the social contract. There is no "the" social contract. There are many social contracts, and they are not all compatible with one another. The whole point of written, legal contracts is due to a recognition of this fact. I don't abide by that (or any) social contract when I put something on Github, and nor should I. When I say that I can't guarantee this code won't cause harm (e.g. destroy HW or files on your HD), I mean that. If you want to labor under unspoken, unwritten contracts, be my guest.
- webmaven 5y ago
  > When I say that I can't guarantee this code won't cause harm (e.g. destroy HW or files on your HD), I mean that. Okay, but imagine for a moment that you don't say that. The README is silent on the issue of potential problems. Are you violating any social contract then? Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README. Are you violating any social contract at that point? If you don't like the term "social contract", would you agree that you would be violating some norms?
  - BeetleB 5y ago
    Of course I'm violating some contract/norm. I am also conforming to some contract/norm. That was the whole point of: > There is no "the" social contract. There are many social contracts, and they are not all compatible with one another. Similarly, those expecting my code won't cause damage are also violating certain social norms. The code is there for anyone to do what they want with it. Do with it what you will, and own the consequences. > Or suppose an issue is reported to you. You don't feel like fixing it, close the issue, and even delete it, and don't add a mention of the problem to the README. My Github repositories are very low in importance on my list of important things in life. I reroute most notifications to a folder and will go through that folder only a few times a year, so I likely won't even know about any such issues for months. Now personally, I do put a disclaimer in the README stating that people should view the code as unsupported and unmaintained (even though I do update the code from time to time), but I do it merely as a courtesy, not as an expectation. I do not at all endorse that people should put such disclaimers.

0xbadcafebee 5y ago

As a user, I feel pain when I use something free that seems like it should work, and I invest a lot of my time in making it work, and then I run into a bug, and report it, and the bug isn't fixed because there's no investment in it. I know it's my own fault for trying to use something without paying for support. But I get upset anyway, probably because I wasted my own time, and believed the unconscious lie that I told myself that using this thing [without support] was a good idea. (And even paying for support isn't a guarantee a bug will be fixed!) I develop open source projects too, so I'm intimately familiar with both sides. It's a bizarre feeling when I realize I am acting (as a user) the same way other users act towards me (as a maintainer). I think being a maintainer is a healthy reminder that I should lower my expectations as a user of free stuff. The reason I create open source stuff is there was a problem I wanted to solve, and I want to share my solution with others so they don't struggle with the same problems. I try hard to make it easy for people to use my solution, and I hate the feeling that someone might be inconvenienced by using it. I really do want to fix all reported bugs. But at the end of the day I have a life (and a job) that gets in the way. I feel bad about any bugs, but I don't feel bad about taking a long time to fix them, because my quality of life is more important.

geerlingguy 5y ago
I sometimes feel this too, especially if I spend a day or two working on a bugfix that feels (to me) simple and logical, and then it sits rotting in the PR queue for a few months. There's a feeling of indignation, but I constantly remind myself that on the other end of the PR is a maintainer like myself, so I try to remember to bite my tongue and be extra nice.

indymike 5y ago

"I'll recommend they fork the project" This is really the right answer a lot of the time. The first few times I submitted a PR and got rejected or ignored, I took it personally. Then a maintainer explained it to me (ran into him at an in-person meetup), and it was very similar to Jeff's explanation here. Also, what makes it really hard for maintainers is that a lot of the requests they get are from people who don't have the ability or desire to fork the project (and even less ability/desire to maintain the fork).

PragmaticPulp 5y ago

> I maintain over 200 open source projects That’s just a little bit beyond what the average open source maintainer has on their plate. Regardless, the attitude of recommending that people fork a project if they really need something is the way to go. It’s okay to say “no” to an influx of requests and demands. The maintainers who burn out the fastest are the ones who view every comment, suggestion, request, or piece of feedback as equally important. It’s okay to let something be your personal project and not let the community take a sort of control over your time. Do it long enough and you will develop a thick skin, if only out of necessity. Open source will expose you to some of the nicest, smartest, most thoughtful people you’ve ever worked with. It will also expose you to some of the most demanding, manipulative people who will use every social pressure technique they know to try to make you feel bad about not doing exactly what they want.

duxup 5y ago
It seems like the Open Source ethos also could also use some additions like: 1. How to maintain a healthy approach to your popular code. 2. How / why to say no without looking like the jerk. 3. How to find / manage help when you need it. Handy skills for life too... Granted plenty of folks do it very well, but there's nothing about Open Source that necessarily provides any of that and some folks who love to help, share, and solve problems fall into bad places. That also leads me to wonder how much complexity for most projects is even needed. I kinda wonder if for most projects maybe 90% of the people using the code use it for a handful of tasks, and yet the vocal loud folks demanding more are a very small minority...
- latchkey 5y ago
  After ~25 years of open source and regretting a lot of my earlier behaviors as a younger human, a couple years ago I created another open source project [0]. I made a point of setting it up right from the beginning. Easy build system, fully unit tested, code of conduct, automated CLA signing, examples, good documentation and most importantly, I am excessively kind to anyone who comments or gives feedback. This took an inordinate amount of time up front, but was worth it. I'd say the result of this is that I've gotten a couple high quality contributions, zero stress and very very little feedback. It has been a pleasure to maintain this project because it causes me no pain at all. I'd say that maintaining 200+ projects is just insane really. You've overdone it. It is impossible to do any of them extremely well and of course you're just going to invite 200x more drama. Don't do that. [0] https://github.com/lookfirst/mui-rff https://github.com/lookfirst/mui-rff

cube00 5y ago

While everyone is free to maintain their projects as they wish, you don't necessarily need to maintain this level of control. As the project gains traction you'll develop a community of trusted developers around you and you could consider granting commit access to some of them to help reduce your workload. It can also reduce the stress of feeling that you'll be blamed if something goes wrong and it becomes more of a community effort which is one of the benefits of open source.

Shish2k 5y ago

I wonder if we need a middle-class of open source contributor — I see a lot of over-worked maintainers, and I see a lot of drive-by contributors with interesting half-baked ideas or PRs that fix one bug but fail CI tests — I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy...

pc86 5y ago
Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that?
- webmaven 5y ago
  > Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that? Sure, especially if your (meta) goal is minimizing individual maintainer effort. But if you want instead to maximize maintainer and contributor return on effort (counting both the originator and the polisher as contributors), a different approach may be called for. Maintainers "just" need to figure out for themselves not just how much work they are willing to put in, but what sort of work, and what work (if any) they are able and willing to delegate or offload onto others. For a maintainer who isn't willing or able to do the work of polishing contributions or handholding potential contributors, and doesn't have anyone they trust that is willing or able to do that work, rejecting most PRs (and even issues, for that matter) outright can be an entirely valid approach. Open source success and sustainability don't look the same for every project or for every maintainer.
pbowyer 5y ago
> I wonder if we need a middle-class of open source contributor [...] I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy... We need a valuing of non-coding contributions, and a way of welcoming them into projects. I like building community and dealing with people. I like project management, planning, and thinking about funding opportunities. I even like (but am not good at) writing documentaiton - but only if the author of the code is willing to explain _why_ they wrote the code this way rather than get me to write how it works. I haven't come across a project that is open to welcoming people who bring these skills. People do these things have got to that place through long-term involvement, or because the role fell to them. Or no one does it. A decade ago there was a drive to get designers and UX people involved in open source projects [0]. It came to little, to the detriment of the entire open source community. Writing code isn't the only skill important in a project, and if we embrace that the whole experience of using the framework, library or software improves. 0. https://markboulton.co.uk/journal/design-in-open-source/ https://markboulton.co.uk/journal/design-in-open-source/

canyonero 5y ago

I really liked an article on the subject of sustainability in open source by Dave Rupert. See https://daverupert.com/2021/12/sustaining-maintaining/ https://daverupert.com/2021/12/sustaining-maintaining/ One of the of the points Rupert drives home is that open source with the goal of sustainability doesn’t have a framework in place that doesn’t lead to burnout. Everyone just learns lessons the hard way without any real manual for successful outcomes.

ozim 5y ago
Why there should be sustainability built in? Not everyone should be publishing their code and definitely not everyone should be OSS maintainer. From what I see and how I look at things, people think it "fun" or "cool" and don't understand full picture of what it really is to be OSS maintainer. I also don't think that simply more OSS is better - while yes, corporations should share more, software written with taxpayers money should be open - but randoms from around the globe should keep their leftpads for themselves and their friends.
- janfoeh 5y ago
  I wholeheartedly disagree with your underlying premise of what open source is or should be. It's not a job. It's not a résumé. It's not a damn lifestyle or an in-group to define yourself through. It's a way of saying "I wrote this. I allow you to look at it and use it for yourself, if you like". Nothing more, nothing less. > randoms from around the globe should keep their leftpads for themselves and their friends. That seems like a bizarre inversion of responsibility to me. Randoms can publish whatever they please; if you use their left-pad, that's on you and you alone.
  - ozim 5y ago
    If it is not a job then why people are getting burned out, why people nag about not getting compensated?
- canyonero 5y ago
  > Why there should be sustainability built in? I don't think it should be built in by default to any software that is released open-source. But, I do think having guidelines for how software can be developed in such a way that doesn't lead to burnout. The linked article pertains to avoiding the path to burnout, which if you are sharing code that an author a.) expects to "own" and maintain and b.) hopes other people will use, then you need should educate yourself as to how this can be achieved. Good literature on the subject is limited IMO. > Not everyone should be publishing their code and definitely not everyone should be OSS maintainer. I partially agree with this. I do think not everyone is up for the task of OSS maintenance and development, some of which is likely stemming because they don't have a good framework for how to do so sustainably. I do think anyone should be able to freely publish their code if they like. Sometimes folks want to share things for fun or education or demonstration purposes, when they don't intend to accept or want PRs or contributions or downstream consumption or maintain it. There is value in OSS for many different reasons. I think GitHub in particular does a poor job of signaling to readers which software is sustainable and which is not.

blakesterz 5y ago

I just want to give a BIG thank you to geerlingguy. I use a couple of your Ansible roles and they're great! It's amazing how much work you put in and it's most appreciated!

BoysenberryPi 5y ago

I'm more interested in how Jeff manages to maintain 200 open source repos and still have time for all the other extracurricular he does like the graphics card RPi testing he has going on. Please tell me your time management secrets.

geerlingguy 5y ago
Two things: saying no to the majority of time requests (it used to be very hard for me, but now I realize the power it gives me over my own time), and focusing on one task until it's done (I have a few Trello boards and have gotten more religious about 'WIP' during my working hours... though I probably hang out on HN and Reddit a bit too much still).

deleted 5y ago

[deleted]

j1elo 5y ago

> Despite how much some people detest the stale bot [...] I detest the stale bot :-) And I really think it only is a disservice to the project, 99% times I see it used. If the code has a genuine, real defect, it will not "go away" magically just because nobody complained again, or the authors didn't have time to look on it. See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue. I really hate when googling about some problem and then finding a promising bug tracker conversation that then... got comments closed because of old age. That's literally swiping the problem under the rug. Now regarding burnout and burden of OSS maintainers, I might lack a bit of empathy here, but I just don't get it. Really the license text says it all: THIS PROJECT IS OFFERED AS-IS. Most if not all OSS licenses have a phrase like this. Just quote those words 100 times if it's needed. My mental health as an OSS maintainer is very well and I cannot see it being changed by some, even lots, of demanding users at any point. Every time someone takes my code and uses it, there is an implicit conversation where I go "hey, here you are take this work for free, I'm lending it to you AS-IS, do whatever you want with it!". Absolutely at no point in time I feel pressure about defects in the code, after having this imaginary conversation. I guess we need more spreading of the notion of "not giving a sh*t" so the idea gets extended to more and more OSS maintainers, helping them have a happy life not encumbered by the work they decided to release by sheer goodness. EDIT: with this last phrase I mean that one should have the mentality of contributing up to, and not more, what one is able to do within their own limits. The "not caring" I mention is for after reaching this limit: it will help not pushing through the burnout line, and thus as a result being happier in the long term.

corndoge 5y ago
Your latter point doesn't make a lot of sense to me. I write and maintain open source software because I enjoy seeing people use it. For me, not giving a shit about it means not working on it at all. It seems like it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra but in reality that just doesn't work for me. And I bet I'm not so different from most foss maintainers.
- j1elo 5y ago

lol768 5y ago

I honestly detest stalebot - if you don't want to keep on top of your projects' issues/PRs, fine - but don't artificially and automatically close issues that explain very real limitations in your project just because you don't have the time to look at them. If you do that, you rob the next n visitors the ability to understand what works and more importantly what doesn't work at a glance, from the open issues/PRs list. That security vulnerability or bug isn't going to vanish into the ether because a "helpful" bot closed the issue. It'll still be there - but it'll get lost in every other closed issue. I will happily just comment on the issue every single time the bot closes it out of spite to force it to be re-opened. Hell, it's probably overdue someone writing an anti-stale-bot that does exactly that. Related: https://drewdevault.com/2021/10/26/stalebot.html https://drewdevault.com/2021/10/26/stalebot.html

lostdog 5y ago
Really stalebot shouldn't close issues. It should put them into a "stale" state, where they still exist for users to read, but are filtered out when maintainers look at a list of issues with the project.
geerlingguy 5y ago
If there is a bug, I typically mark it with a `bug` label, and I configured stale bot to ignore those issues, so they do remain open: https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/stale.yml#L15 https://github.com/geerlingguy/ansible-role-docker/blob/mast...
- remram 5y ago
  If triage is happening stalebot is fine. Unleash it on "need-more-info" issues, or feature requests with no upvotes, I don't think anyone has a problem with that. I think people are objecting to un-triaged issues being able to go stale, and you then have to keep fighting the bot every month because the maintainer doesn't spend the time to confirm it while demanding you waste your own time to bump it.

tomcam 5y ago

First off, my sympathies and awe go to someone with that much to give. Thank you, Jeff. Second… I desperately want a post describing how one person maintains 200 projects! Wow!

geerlingguy 5y ago
The cynical take is that said maintainer doesn't really 'maintain', but rather 'lets rot'. The optimistic take (and what I prefer to believe) is that if a project works, and solves the problem the maintainer wants it to solve, it doesn't need to be changed unless/until it breaks.
- lostapathy 5y ago
  I agree with your optimistic take here. A lot of people are reading the “200 projects” and assuming they are all big projects. On the contrary, a lot of your projects seem to keep a very narrow focus that allows them to get to a state of “done for now” even is nothing is truly ever finished due to upstream and downstream changes around the project.
- tomcam 5y ago
  The optimistic take is a good one. Thank you very much for your reply.

flucivja 5y ago

I wonder if OSS world needs kind of Spotify/Netflix platform for OSS distribution. If I would put in analogy OSS Developers to Music authors and songs/albums to OSS projects then such distribution platform would be paying developers depending on how much their project is used and maybe some other criteria and everybody who would like to use some OSS would need to pay monthly subscription to that platform.

lomereiter 5y ago
You are describing Tidelift (https://tidelift.com/ https://tidelift.com/) except the bit where the users would "need to pay" - although that could be addressed e.g. via regulations for enterprises but not individuals.
pjmlp 5y ago
They had it back in the day with stuff like the Walnut Creek CD-ROM distributions. In the long run, the only monetary solution is to go back to some kind of PD/Shareware, which is what all those public core, commercial full solution end up being. 30 years ago we called those public core parts, playable demos.

remram 5y ago

This might be an unpopular take, and I'm aware of how it sounds, but why don't you stop maintaining those projects if you can't do it properly? You are not required to do this. It doesn't even mean you have to stop making new things, you can just not take on that role as a focus point of each of their respective communities. As a user of a library, I don't hold it against their author when I find a piece of software that is abandoned. I will create my own fork and start maintaining it if I have too, or understand the state that it's in. I will find alternative avenues to discuss issues if the GitHub issue tracker is closed. Just don't make yourself the center of a community if you are going to unleash a stalebot trashing other people's genuine issues. You are making it impossible for someone to fork. because they would be competing with the author; people might even find it distasteful. So everyone is forced to go through you, leading to both suboptimal software governance and burnout on your part. You are not getting paid, why force yourself?

gnubison 5y ago
> why don't you stop maintaining those projects if you can't do it properly? Well, perhaps they are doing it properly, and everyone else has the wrong definition of “proper”. Good stewardship does not mean accepting every patch and every new feature.
- remram 5y ago
  By "improperly" I don't mean a disagreement on the project's direction; apologies if that wasn't clear. I mean using things like stalebot, shutting down discussions and increasing the demand on other people's time in your community just because you personally don't have the time to keep up. If you have reviewed a patch and you don't think it's the way to go, or you don't think it can be maintained going forward, that's fine. If you set up stalebot to close and lock merge requests because you don't have time to review, that's something else.