10 ms·

My boundaries as an open source developer

370 points by cakeplease 5y ago

Pieman103021 5y ago
Archive - https://web.archive.org/web/20220105000136/https://joeldenning.com/?p=29 https://web.archive.org/web/20220105000136/https://joeldenni...
- lloydatkinson 5y ago
  Are you expecting the author to delete it?
  - amflare 5y ago
    Archive links allow others to read the article if the site suffers a Hug of Death from hitting the front page of HN.
    - gkbrk 5y ago
      Case in point, the link isn't loading for me right now. Seems to be hugged to death.
  - YATA0 5y ago
LAC-Tech 5y ago
Stuff like this is why I've never bothered to promote any of the open source stuff I've released. Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking). Best case scenario - the situation in TFA happens, where people act like I owe them something.
jeff-davis 5y ago
I suggest cultivating a sense of shared ownership. The author is trying to do that, which is great, but it seems like it's not there yet. That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so? No, you want a process and a team/community.
- mplanchard 5y ago
  To be fair, this is really hard. Even finding other people willing to review PRs is difficult, much less people willing to spend the time understanding the entire codebase and being able to contribute to it in a meaningful way.
pabs3 5y ago
> Part of the stress is in interacting with so many people a single time, never having a solid relationship with any of them. I found that working in the Linux distro space doesn't have this problem, especially in the pre-COVID times when there were annual in-person conferences and lots of socialising.
- jlokier 5y ago
  I found working in the Linux space did have that problem in pre-COVID times. Especially the lack of solid relationships, due to never meeting people and getting to know anyone personally. I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part! LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.
  - pabs3 5y ago
    It sounds like we are talking about different spaces, I was talking about Linux distros (specifically Debian). Even before I started going to the conference there was some feel of community. Perhaps the Linux community is larger than Debian or more subject to churn as people change employers and thus change which part of Linux they work on. Or maybe as you say attending the conferences is a bit part of community feeling. I'm surprised you read LKML, the volume is enough to put anyone off. If you are still interested in reading some of it, these days there is lore+lei to filter down the volume just to your personal interests. https://lwn.net/Articles/878205/ https://lwn.net/Articles/878205/
lmilcin 5y ago
I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.
- einpoklum 5y ago
  Doesn't (almost) every bug report/feature request meet this criterion?
  - not2b 5y ago
    This post is about when it is or isn't appropriate to directly contact the principal developer instead of using the established Slack or Github flows.
- qbasic_forever 5y ago
  The preference of the developer doesn't feed into your decision to contact them? What if the repo readme says "this is provided as-is, I don't offer support"?
- lawn 5y ago
  A counterpoint: You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.
  - TheCoelacanth 5y ago
    You can't know that before you contact them, though.
deleted 5y ago
[deleted]
lamontcg 5y ago
Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.
- akvadrako 5y ago
  You don't need to use github, especially when you don't want the public making issues.
  - lamontcg 5y ago
    800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.
    - YorickPeterse 5y ago
      Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.
      - legobmw99 5y ago
        GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account
    - MadeThisToReply 5y ago
      An aside, but is it a standard thing to write # to mean "pound" when you're talking about pounds as a unit of weight? Like as opposed to "800lb"? I knew what you meant, it's just I've never seen that notation before so I'm wondering if you just made it up or if I'm out of the loop somehow.
      - 5y ago
lloydatkinson 5y ago
Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.
- TheTaytay 5y ago
  I got the opposite read regarding their mental health. This was a very clear and well thought out statement of reasonable boundaries, especially for someone volunteering their time. I admire them for it.
- macintux 5y ago
  I don’t see a dislike of users, just a dislike of the stress that being an open source maintainer tends to place on people.
- sfink 5y ago
  That wasn't my impression from reading it. The writeup actually seemed very reasonable to me. They perhaps sound like they're having a bit more trouble than many at handling the onslaught and saying no, but given that, this felt like a fine way to set things up. So I'm curious: what in the writeup indicates a dislike of users?
- c0nfused 5y ago
  Probably not. I think there is a difference between having guidelines for how to.contact you is not dislike if users. Waking up at 4 am to reply to a poorly worded bug report with a demand you fix it immediately is exhausting and sucks your will to live
- ChrisMarshallNY 5y ago
  I didn't get that vibe. Seems to me, that he wants to keep going on it, but isn't really a "people person," and wants to control his agenda. I can respect that. I managed an open-source project for a decade, that was designed to serve an ... interesting ... demographic. I think many of the folks here, would have defecated masonry, if they got some of the contacts that I did. But I'm a fairly tough old coot. I held my own. It wasn't pleasant, though, and I learned a great deal, about interacting with ... interesting ... people.
moron4hire 5y ago
I had a very similar experience with running open source projects. I was getting frustrated with people not contributing in any significant way. Functionally useless bug reports. Coding bootcamp students submitting PRs that did nothing but change some grammar in the README (and never actually changing it correctly). Feature requests for things I had explained in several other issues that I would never do. Requests for support in setting up other people's software. But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem? I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity. Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software. I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory. I didn't like that view of myself, so I stopped opening my software.
- travisjungroth 5y ago
  You’re saying no one uses your software whether it’s open or closed, you just got annoying “contributions”. How did you know no one was using it? How would you know if someone was?
  - moron4hire 5y ago
    No, I didn't say people weren't using the software. I could see that in a lot of different ways: how many people were active on the project site, how many people had forked the project on github, etc. My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software. Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves. I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need. The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time? Thus the realization that I had been deluding myself.
GoToRO 5y ago
- henryfjordan 5y ago
  The license very clearly tells you that you should not assume that the software is "production ready" and that if you do, that's on you. > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ...
  - cweagans 5y ago
    You beat me to it :)
  - GoToRO 5y ago
    You quote doesn't mean what you think it means. It just means "we will hide the real state of our software because we can, so you can choose to loose valuable time evaluating it now or else more time fixing it later. We could tell exactly how production ready it is, but we choose not to."
    - henryfjordan 5y ago
      The code is open-source, nobody is hiding the "real state of the software". "Production-ready" means different things to different people. For many, "production-ready" means "we have a support contract with the software vendor". In that case, the project would never be usable in production. To others with higher risk tolerance, a 1.0.0 release is all you need! You'd have to consider each user before making a recommendation about production-readiness. Instead the author offers the software AS-IS and you can decide for yourself. The author doesn't owe anyone anything, least of all a personal consultation about whether using the software is prudent.
    - jjav 5y ago
      No, the license means exactly what it says. An open source project (in most licenses) offers zero assurance of it being usable for production and that's what it means. If you want to use it for production you need to either (a) do whatever evaluations you feel necessary to ensure it will be stable for production for your needs, or (b) pay the authors for a signed support contract so they take on that responsibility.
GoToRO 5y ago
woah 5y ago
I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.
- jjav 5y ago
  > it does make it sound like unsupported software Nearly all open source software is by definition unsupported (read the license). If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).
- jjav 5y ago
  > I totally get where they are coming from but it does make it sound like unsupported software. It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway). > After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you. Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble. If you need more certainty, pay for a support contract with SLAs.
- deleted 5y ago
  [deleted]
- FooBarWidget 5y ago
  > but it does make it sound like unsupported software Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly. Open source software is unsupported software unless you paid for a support contract. If you still get support despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.
langsoul-com 5y ago
Although FOSS software is nice, it just doesn't seem worth the hassle to be involved any more.
thenerdhead 5y ago
I think the missing aspect is that the platforms put this stuff in front of your face and human curiosity will have your attention directed at it anyway. You will actively be thinking about that troll who opened up an issue or someone in your Twitter DMs asking for help. Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do. I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.
- deleted 5y ago
  [deleted]
einpoklum 5y ago
> I am contacted dozens of times every week with varying requests to answer people’s questions Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times. > fix bugs "Please file an issue at http://the.issue.tracker/wherever http://the.issue.tracker/wherever" > or build new features "Please file an issue at http://the.issue.tracker/wherever http://the.issue.tracker/wherever" > set up consultations So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then: "I am currently not available for consultancy. You may inquire again, if relevant, in ____ months." > or discuss business opportunities. "I'm sorry, not interested. Good luck with your business." Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)
Crazyontap 5y ago
I think there should be term like suffering from open-source fatigue. Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts. It's like being a mini celebrity feeling happy when somebody asks for your first autograph but as you become more successful more people want your time and attention and then you don't want it anymore. Also unlike being a celebrity you may get some fame but rarely any fortune, so that makes it all the more easy to get annoyed when people try to eat your attention for their own benefit.
- ascar 5y ago
  > Also unlike being a celebrity you may get some fame but rarely any fortune I know this isn't your main point, but afaik most low-level celebrities barely make money from it either. So it's actually even more similar than you thought.
- weq 5y ago
  This! Open source can make your career, just as much as the Op says; it can break your back. From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different. Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.
ikiris 5y ago
- afarrell 5y ago
  This isn't hate. This is indifference and conservation of energy.
- gurchik 5y ago
  I don't think this is a fair characterization of the article. It's really not too much to ask to ask a user to go through official channels like a bug tracker or a mailing list instead of messaging the author directly. And I don't think it's right to accuse someone of hating their users for creating those channels. The only reason an author would make those channels is if they believe it would increase the chances of everyone receiving the best help. It's usually harder to find an authors direct contact information than the official channels. If the user has a legitimate bug report or issue, being told they accidentally found the wrong contact information wouldn't bother many. However if the user is going through backdoor channels specifically to get special treatment then that isn't fair to others.
newshorts 5y ago
Honestly, I don’t understand the entitlement that causes someone to have to write this. Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you. If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute. This might be a bit hostile but truly, c’mon people.
- NorwegianDude 5y ago
  That's not hostile at all. If someone decides it's best to use your code then you have already helped them out. Expecting you to do work for free for them because you already did something useful for them is just stupid.
  - mickael-kerjean 5y ago
    It's great to have that kind of post published. I had that exact conversation just yesterday with a director who "love" open source and see it as "the future". When asked to pay market rate for the extra features he want, he was struggling to understand that 8k won't get him a few months of work and felt entitled on a discount on the basis that I'm doing open source and he is helping the project ...
- 89vision 5y ago
  I don't think this is hostile in the slightest. Nobody should expect free work
- deleted 5y ago
  [deleted]
NorwegianDude 5y ago
There is a lot of idiots out there who expects you to work for them and help them fix their issues just because you made your code public for those who find it useful. Just look at some of the answers, even here on HN. One should be happy for the work that people do make available for others. If you're not paying for it and it's run by people who just want to make something cool then you should be prepared to contribute if you want someone to go out of their way to help you. You don't have to contribute financially or by writing/fixing code. If you need help with a bug, make sure you write good bug reports, and be patient. Also, if you don't want spam, just turn off notifications for non important things and limit the communication channels to something you'll be able to control. That's the beauty of digital communication: you control exactly how and when people can get in touch with you.
JJMcJ 5y ago
An XKCD that's right on target: https://xkcd.com/2347/ https://xkcd.com/2347/
gsliepen 5y ago
Dealing with users/contributors in open source indeed has its issues due to the low barrier and global nature, meaning you can receive both high and low quality comments/patches/etc, and sometimes the language barrier makes a good quality interaction look bad. In order not to drain your energy dealing with them, you have learn how to deal with them efficiently. What works for me is: - Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out. - Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask https://stackoverflow.com/help/how-to-ask). - Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out. - When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future. - I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.
- account42 5y ago
  > When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future. I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.
xiwenc 5y ago
Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed. People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).
- bwindels 5y ago
  > bringing something out as open source does come with some responsibilities. No, it does not.
- TonyTrapp 5y ago
  There are many, many projects where "simply adding more maintainers" is not possible at all, i.e. there are no people that you personally can trust to do the right thing, and that have the necessary experience. For various projects that I maintain, I couldn't name a single person that would have the skill and would actually want to take over. Granted they may not be as popular as this persons's repositories, but still - this claim is not generally true.
deleted 5y ago
[deleted]
chmod600 5y ago
If an author can publish code with a take-it-or-leave-it attitude, why can't people make requests with the same attitude? If the author is under no obligations at all, a request is no problem, right? Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence. I'm not suggesting a real obligation, but there is... something? If there wasn't, then these requests would be treated like random mail to a famous person and just discarded.
- d4mi3n 5y ago
  > Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence. I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion. The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions. There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers. There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
- wildmanx 5y ago
  No there is not something. That's a misconception. The author is under no obligation at all. Of course a request is no problem. But then if that request is ignored, then that's no problem either. Who knows why there is no response. Maybe the person has other things in life needing attention. Maybe they have a bad day/week/month. Maybe they are burnt out. Maybe they have already responded to you 100x or maybe they just don't like your name. If they do respond -- great! It's likely in their interest to respond to bug reports since it's likely in their interest to have less buggy software for themselves (if they use their own software) or for their customers (if their customers use their software). But maybe it's not, maybe they have moved on, or maybe they are just on vacation. If they are nice, then they tell you. But even that's something they don't have to do. You are free to dislike them for that, and you are free to not use your software anymore. You are usually even free to fork the project if you want your pull requests in and they keep being ignored or rejected. If others think like you, you get a community right away. But many people don't fork. Because it's a lot of work suddenly being a maintainer. Then you suddenly get those requests and opinions and pressure. Don't like that? See! That's the issue here! If you don't like it, then don't criticize others for not liking it either.
wildmanx 5y ago
So much this. I'm glad he put this out there. I'll start linking to it too. There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not. When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal. It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it. That's it. This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about. It's about a specific deal. Nothing more, nothing less.
- enraged_camel 5y ago
  I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals. In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest. The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment. Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk. Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it. Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect. You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer. IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work. Be kind, be clear, be upfront. That's it!
deleted 5y ago
[deleted]
qwertywert_ 5y ago
I read Joe Elden Ring.
brunoborges 5y ago
Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code, whether they had discussed about it or not. Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone. This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default: - Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions - Allow maintainer to "Open Issue for Pull Requests" This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted. This flow would be much better for setting the right expectations, in my opinion.
- duskwuff 5y ago
  There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.
  - brunoborges 5y ago
    What I described is what I believe GitHub should support. Not that they support it today.
    - duskwuff 5y ago
      Right, I mean that there is a (caveat-ridden) workaround as it stands. I agree that repository maintainers should have the option to restrict or disable pull requests, just like they can disable other features.
erwincoumans 5y ago
Indeed, love this article. Especially after receiving this tweet, getting public attention for a bug: https://mobile.twitter.com/araffin2/status/1501314248114413573 https://mobile.twitter.com/araffin2/status/15013142481144135...
yblu 5y ago
I used to maintain several popular open-source projects and contribute to even more popular ones. It was always fun at the beginning, especially because I built them for my own needs. But I kept getting asked to fix bugs or improve things even long after my needs had expired. I tried the donation route for a little while but it didn't go anywhere - I received maybe a few hours worth of money (versus hundreds if not thousands of hours I had spent working on those projects). I also tried releasing a paid version for one of the projects and got buried with hate mails and, unfortunately, online abuse. That was when I stopped working on open-source and I'm happier than ever. I'm very happy for people who make it from doing serious open-source work. I think they deserve it. But at the same time I feel bad for those who build or maintain no less serious or popular work and yet couldn't make enough to worth even a portion of the time they'd spend.
- mwattsun 5y ago
  The reality is: most companies are taking economic advantage of the generous spirit of open source developers. That needs to stop. SPONSORING OPEN SOURCE DEVELOPERS Rich Hickey - December 15, 2020 https://cognitect.com/blog/2020/12/15/sponsoring-open-source-developers https://cognitect.com/blog/2020/12/15/sponsoring-open-source... HN Thread here: https://news.ycombinator.com/item?id=25436335 https://news.ycombinator.com/item?id=25436335
  - smashah 5y ago
    Sponsorship is not a panacea unfortunately as corporate use of a project is not proportional to the maintainership burden. Hopefully the industry can fix this one day.
    - hawkesnest 5y ago
      If you could even get it! Think about all the millions of dollars dealing with the Log4J issues last December. How much has that prompted sponsorship of any logging libraries by the affected companies? Not much, from what I've seen.
- mikepurvis 5y ago
graderjs 5y ago
Exactly. I talked about this in my 22120 interview[0] a couple years ago. You have to learn to say no. Self-management taking care of yourself and setting boundaries, protecting your space to ensure you can continue making contribution on something you care about. People can be so demanding you have to push back. Use the block feature on GitHub if they're real trouble. I don't have a ton of experience but in my experience of this somehow by pushing back and setting boundaries and saying no it seems you change the expectation or culture and it's a persistent thing. Then the "little community" you have seems to behave better. [0]: https://console.substack.com/p/console-28?utm_source=url https://console.substack.com/p/console-28?utm_source=url
wly_cdgr 5y ago
Always good to see an open source dev standing up for themselves, if only a little, against all the entitled freeloaders and techbros who are all too happy to exploit them and to encourage them to continue exploiting themselves If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat
- orangecat 5y ago
  you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay". (Separately, the tipping model is awful and something we should be moving away from rather than expanding).
mholt 5y ago
Good on him. I wrote fairly comprehensively about boundaries in open source recently: https://matt.life/writing/the-asymmetry-of-open-source https://matt.life/writing/the-asymmetry-of-open-source A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.
jurassic 5y ago
A few years back I was in a role where it was my job to maintain a small but non-trivial open source project (~1500 github stars, 5 core contributors). I burned out after about two years in that role. People repeatedly demanding help in the github issues without even providing repro steps. Hate mail to the project email list from users angry we didn't implement the feature they want in the latest release. We had people second-guessing all the time if we didn't ship the things they wanted or they disagreed with the decisions we made. Some people just like to get in touch to let you know your work sucks. The worst was the CEO of a small competitor company repeatedly hassling me over slack DMs and in github issues threads shamelessly trying to get me to prioritize free work that he wanted for his clients. Separately, over a period of several weeks, this same person asked me a ton of support questions and then compiled my answers without edits or attribution into a "white paper" he used as a resource to get people into the marketing funnel for his consulting shop. I came to hate that guy, such an asshole, but I couldn't totally block him because his company was a member of the open source foundation governing the ecosystem of tools my project was under. Honestly, it was hell. The most stress and irritation I've ever had in any job. When I started the job I thought it was a dream getting paid to do open source, but now I consider that an anti-goal for any future role.
- wintermutestwin 5y ago
  Sounds like OS developers would benefit from Product Managers who could shield them from the users (among other PM tasks). Do many OS projects have PMs? Are there any "standards" around non dev roles in OS projects?
  - morgante 5y ago
    Unfortunately my experience is that most PMs are not sufficiently technical. They will often add more work by injecting useless processes and try to "demonstrate value" by coming up with new ideas without actually understanding the problem domain. The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.
neilv 5y ago
I appreciate that an open source developer is likely to be burned out on some people's expectations or unthinking requests, but that page was too long for me to even skim. Usability-wise, one could lead with a terse bulleted list of "use cases" for which people should contact you, and how. Then state you can't handle all the other usual reasons people want to interact with an open source developer, maybe giving examples. Then follow it with explanation of why.
zzzeek 5y ago
This is a good read. just to get a sense of some of the OSS maintainer experience. As far as a practical guide, it's my experience that the vast majority of users of OSS software libraries "get" these things already and therefore you don't hear from them. However, just 1% of users who don't "get" it at all, and do all the direct messaging / manipulative stuff are still there, and that's who ruins your day. Which then leads to, those people are absolutely not going to read a blog post like this, they can't even read GIANT LETTERS IN BOLDFACE at the top of a github template telling them to please provide a test case / stack trace / etc. After doing this for 16 years I have realized that while you need to put up guidelines, instructions for interacting, issue templates, etc., at some point you can't keep putting up signs to PLEASE DONT DO THIS - because the people for whom the ALL CAPS is intended for are the last people to read/ care about any of this, and the stern messaging otherwise brings the mood down for that vast majority of users who aren't going to be bothersome in any case. You have to just have a pre-packaged response for the various things you get: 1. "hi" on IRC in private message from someone you don't know (obviously looking for help) - ignore. there's no response you can have for this person in this setting that will make the situation better (keep in mind, there are many forums / chats/ systems this person can use to get help, and they are well documented. these people ignored all that and are trying to go right to the main dev to get private help. they most certainly know how to find things because they found your nickname on an irc network. so this is overall a pretty rude move, but even then, some people just arent aware of what they're doing or how to act) 2. email asking for help - this is probably not too different from the "hi" in private message thing but I tend to give folks like this a short answer and point them to github discussions / irc, mentioning "there's some folks there who can help us further" (note the word "us", to soften the blow a bit). the emailers tend to be completely bewildered and generally lean heavily towards overall beginner types so I do try to gently guide them into the wider community for help. 3. recruiters - geezus, they just don't stop. I pretty much ignore them, which they have all caught onto these days so they email you over and over again...I will send back a one liner about 50% of the time after they've pinged me three times 4. weird link-sharing emails who want to put some kind of endorsement for some programming tool on my site that makes absolutely no sense to be in the context they are proposing - I usually just ignore these. Hard to tell if those are spam robots or what but they can be persistent with fairly emotionally charged "can you at least tell me what you'd be interested in?" kinds of replies...I mean these folks I'm sure are sending thousands of these emails out, are they sending out hundreds of frustrated third-requests to everyone who doesn't reply also? I do feel for this developer since producing a JS web-development oriented library is going to generate lots more attention from a lot of users with relatively low levels of technical sophistication. I'm thankful that the Python world still attracts high quality people with reasonably good manners about things.
SavageBeast 5y ago
Open Source Software promulgated by GitHub is made commonly available in the form of actual source code. If this code does not suit your needs, change it such that it does. We're all engineers/developers/coders/hackers with Top Notch Skills right? Make a fix thats well thought out and well integrated, commit, pull request and hope the maintainer finds value in integrating your code into the next release. Should you come across a maintainer that doesn't share your view of the issue and depending on licensing constraints simply maintain the code you were given for free on your own. That or ... I dunno... Maybe pay someone? Venmo is a thing? Do you even Crypto bruh? * I spent 5 years working for a company that successfully took this approach. Pre-GitHub of course. * OP is totally on target.
andrew_ 5y ago
https://liberamanifesto.com/ https://liberamanifesto.com/
travisgriggs 5y ago
Is this kind of burnout perhaps in part due to the level of mechanization provided by the defacto platform for open source projects now: GitHub? It seems like it’s more frequent, but maybe that’s just me. It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, that can actually take a lot of the fun out of it. And make one feel trapped by the process machine. It seems in old days, when things were less standardized, maintainers had more creative control over not only the code, but the process/community around it. I’m not advocating for a demise of GitHub. Just kind of wondering if this is the price we pay.
- TAForObvReasons 5y ago
  Cultural norms around Slack / Discord (compared to the IRC of old) are also to blame. With email, people understand that there is a reply and that process takes time. Discord and Slack encourage people to keep the apps running, continually sapping time and energy. The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.
- outsomnia 5y ago
  Yes, many issues are simply users deciding that it is quicker to abuse maintainer time to get and answer than find out themselves, github does facilitate that. What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.
awill88 5y ago
I wonder if there could be a way to just turn off issues and only accept PRs. Contribution-driven feature requests. That would be a boundary that I think would protect the maintainer from the potential outcome that the article about boundaries does absolutely nothing. Open is open, people are relentless and unforgiving, that’s why I don’t have the stomach for it. But if I see something I’d like to do with a project, I will take a whack at implementing it and giving back. I can imagine gaining a distaste for seeing companies benefit without being rewarded in return. With that, perhaps it’s time to seek out other maintainers? If we’re talking open source here, shouldn’t successful projects become co-owned (ie maintained) by the community? While a single maintainer who creates a successful open sourced software certainly earns the discretion to choose to share their invention(s) or not, holding tightly onto the projects as opposed to donating them seems as unproductive as a random person demanding features. But I am not the maintainer so I don’t mean to convey apathy, my completely naive, lizard brain would just want to troll the worst of them with “open a PR and we’ll talk”
- mhils 5y ago
  FWIW, you can disable the Issues tab on GitHub, there's a setting for it.
- vaylian 5y ago
  > I wonder if there could be a way to just turn off issues and only accept PRs That would create the problem, that people won't able to ask if a feature is desired by the maintainer. New contributors would spend time on a PR and then learn that the original developer considers that feature to be out of scope and therefore the development effort would be wasted. I understand your wish for removing the issue tab. But there is a downside to it.
- hbx 5y ago
  Since Nov 2021, you can allow some people to bypass pull requests requirements. https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/ https://github.blog/changelog/2021-11-19-allow-bypassing-req...
lukaseder 5y ago
How about charging money for work?
stdbrouw 5y ago
Most of the comments here remind me of the famous Neil Gaiman quote, "George R.R. Martin is not your bitch." [1] But I don't think that's the right framing. People buy the first book because they hope there will be a second, even though they haven't paid for that second book and hence are not entitled to it. People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. That's not about a false sense of entitlement or callousness on the part of your users at all. It's also not about freeloading, because a lot of those pull requests and issues on Github will be coming from people who publish their own open-source software. Instead, it's about managing expectations, like the post does. Put a big "this project is not maintained" warning on top, and nobody will bother you. Although I do understand that for larger active projects, it can be hard to explain to users exactly where on the spectrum between "don't bother me" and "I'll fix your problem yesterday" you are, and the bigger a project gets, the more likely you'll be to encounter people who enjoy exploiting your free labor. [1] https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
- otikik 5y ago
  It's funny, because I think I have pretty much the opposite expectation. When I encounter a new open source project it means that I can make it better by providing pull requests with new features, or fixing bugs. And then everyone benefits. If they choose to listen to me that's fine, but that's the icing on the cake, not the main course.
  - jcbrand 5y ago
    There are people like that, and they're usually great to have on an OSS project, but they're a minority.
- uranusjr 5y ago
  > People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. > Put a big "this project is not maintained" warning on top, and nobody will bother you. I think this is exactly the problem. The author never promises they would maintain the software, nor expect their definition of “this works” to match the users’. Why do they need to put up a sign in the first place for people to not assume? “Expecting things that were never promised” is pretty much the definition of self-entitlement. IMO this should be entirely the other way around. People should not expect anything unless the authors say they are willing to maintain.
CR007 5y ago
Does it works? I also have issues with users and in my case they don't read this kind of instructions.
pengwing 5y ago
In refusing to accept that any contribution you make to society is in fact a business, you will be doomed to build a bad business. You will talk about the emotional turmoil a feature request puts you through instead of being proud of your streamlined business processes and your ever increasing MRR.
wink 5y ago
I have only one problem with this: > In Slack or Github, it’s usually not necessary to mention me. That's kinda how it has always worked in these forms of communication though - if I want X to see something, I mention. It's not that I personally would be keen on to be mentioned all the time, but I've been on open source project IRC for 20 years and it is like it is. People need to configure their client to not spam them, or not use [medium] if they can't do that. It's unreasonable to have the general populace have rules of whom to mention and whom not to mention. We all should be sparingly using it, it's async after all.
specialist 5y ago
If my OSS projects ever get traction, I'll probably forward support to a public listserv or web bbs thing. Extra credit for wiring that up to some kind of ticketing and bug tracking thing. Automate the FIFO queue. Biggest benefit to me will be transparency. Everyone can see exactly where they are in my priority queue. Huh. Could lead to some fun incentive structures. Want my attention? Then pay me. Like charge $1 per slot. So moving from 100th to 5th place would cost $95. Maybe increase the price-to-slot logarithmically. Any way. It's nice to dream. A small inhibitor to me working on my OSS fulltime and exclusively is figuring out how to pay for food and rent and insurance while saving humanity (from itself).
iiroj 5y ago
I originally set out to fix a performance problem in lint-staged that was preventing my then-company from using it in their large git repo (related to long histories, git read/write tree, and clearing index caches). Here I am, many years later, still maintaining it and overally enjoying the work. I just chose to never take on any implied responsibility like described in the article. This means it's ok to ignore or close tickets, or simply not be active for some months if there was better things to do. So far the interest has kept up, and I'm improving it on our own terms.
zivkovicp 5y ago
> noticing people cozying up to me so that they can exploit our acquaintanceship later Unfortunately this is common in many other parts of life as well; setting boundaries is important.

370 points by cakeplease 5y ago

Archive - https://web.archive.org/web/20220105000136/https://joeldenning.com/?p=29 https://web.archive.org/web/20220105000136/https://joeldenni...

lloydatkinson 5y ago
Are you expecting the author to delete it?
- amflare 5y ago
  Archive links allow others to read the article if the site suffers a Hug of Death from hitting the front page of HN.
  - gkbrk 5y ago
    Case in point, the link isn't loading for me right now. Seems to be hugged to death.
- YATA0 5y ago

LAC-Tech 5y ago

Stuff like this is why I've never bothered to promote any of the open source stuff I've released. Worst case scenario - people tell me my ideas are dumb and xyz does it better (I'm probably aware of xyz and found it lacking). Best case scenario - the situation in TFA happens, where people act like I owe them something.

jeff-davis 5y ago

I suggest cultivating a sense of shared ownership. The author is trying to do that, which is great, but it seems like it's not there yet. That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so? No, you want a process and a team/community.

mplanchard 5y ago
To be fair, this is really hard. Even finding other people willing to review PRs is difficult, much less people willing to spend the time understanding the entire codebase and being able to contribute to it in a meaningful way.

pabs3 5y ago

> Part of the stress is in interacting with so many people a single time, never having a solid relationship with any of them. I found that working in the Linux distro space doesn't have this problem, especially in the pre-COVID times when there were annual in-person conferences and lots of socialising.

jlokier 5y ago
I found working in the Linux space did have that problem in pre-COVID times. Especially the lack of solid relationships, due to never meeting people and getting to know anyone personally. I spent too much time working on things for free (not just open source, but also voluntary work, and a couple of tech R&D ventures that ate my savings) and as a result I couldn't afford to attend any of the in-person conferences in far off countries, where the real action seemed to migrate to. That was a strategic error on my part! LKML also become stressful for me after a decade of reading, just due to the energy to skim the mails each morning due to sheer volume. So I fell off, which was a shame because I had a very solid understanding of the entire kernel at one time.
- pabs3 5y ago
  It sounds like we are talking about different spaces, I was talking about Linux distros (specifically Debian). Even before I started going to the conference there was some feel of community. Perhaps the Linux community is larger than Debian or more subject to churn as people change employers and thus change which part of Linux they work on. Or maybe as you say attending the conferences is a bit part of community feeling. I'm surprised you read LKML, the volume is enough to put anyone off. If you are still interested in reading some of it, these days there is lore+lei to filter down the volume just to your personal interests. https://lwn.net/Articles/878205/ https://lwn.net/Articles/878205/

lmilcin 5y ago

I only have one rule: I only contact an open source developer if I believe resolving the problem would make the product better unless I am willing to offer them reasonable money to do it.

einpoklum 5y ago
Doesn't (almost) every bug report/feature request meet this criterion?
- not2b 5y ago
  This post is about when it is or isn't appropriate to directly contact the principal developer instead of using the established Slack or Github flows.
qbasic_forever 5y ago
The preference of the developer doesn't feed into your decision to contact them? What if the repo readme says "this is provided as-is, I don't offer support"?
lawn 5y ago
A counterpoint: You may view this feature as making the product better, but it might not fit the vision of the owner/developer and to them it will only generate a maintenance burden and bloat.
- TheCoelacanth 5y ago
  You can't know that before you contact them, though.

deleted 5y ago

[deleted]

lamontcg 5y ago

Once again I wish github would allow the ability to limit who could open issues and PRs in order to do development in the open with a trusted/vetted set of collaborators without being subject to every zero-effort bug report from users.

akvadrako 5y ago
You don't need to use github, especially when you don't want the public making issues.
- lamontcg 5y ago
  800# gorilla. don't think gitlab supports this either. that probably leaves self-hosting and all the brittleness and pain around that.
  - YorickPeterse 5y ago
    Correct, there's no way to restrict GitLab merge requests to trusted users, while still allowing others to view merge requests. It's either visible/accessible to all, or only to project members.
    - legobmw99 5y ago
      GitLab can have this “feature” if the accounts are locked behind an entity like a school which doesn’t allow arbitrary users to make a new account
  - MadeThisToReply 5y ago
    An aside, but is it a standard thing to write # to mean "pound" when you're talking about pounds as a unit of weight? Like as opposed to "800lb"? I knew what you meant, it's just I've never seen that notation before so I'm wondering if you just made it up or if I'm out of the loop somehow.
    - 5y ago

lloydatkinson 5y ago

Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.

TheTaytay 5y ago
I got the opposite read regarding their mental health. This was a very clear and well thought out statement of reasonable boundaries, especially for someone volunteering their time. I admire them for it.
macintux 5y ago
I don’t see a dislike of users, just a dislike of the stress that being an open source maintainer tends to place on people.
sfink 5y ago
That wasn't my impression from reading it. The writeup actually seemed very reasonable to me. They perhaps sound like they're having a bit more trouble than many at handling the onslaught and saying no, but given that, this felt like a fine way to set things up. So I'm curious: what in the writeup indicates a dislike of users?
c0nfused 5y ago
Probably not. I think there is a difference between having guidelines for how to.contact you is not dislike if users. Waking up at 4 am to reply to a poorly worded bug report with a demand you fix it immediately is exhausting and sucks your will to live
ChrisMarshallNY 5y ago
I didn't get that vibe. Seems to me, that he wants to keep going on it, but isn't really a "people person," and wants to control his agenda. I can respect that. I managed an open-source project for a decade, that was designed to serve an ... interesting ... demographic. I think many of the folks here, would have defecated masonry, if they got some of the contacts that I did. But I'm a fairly tough old coot. I held my own. It wasn't pleasant, though, and I learned a great deal, about interacting with ... interesting ... people.

moron4hire 5y ago

I had a very similar experience with running open source projects. I was getting frustrated with people not contributing in any significant way. Functionally useless bug reports. Coding bootcamp students submitting PRs that did nothing but change some grammar in the README (and never actually changing it correctly). Feature requests for things I had explained in several other issues that I would never do. Requests for support in setting up other people's software. But if people are contacting me about my project, they must be using it, right? Isn't that the point? Can't I just ignore the noise? What's the problem? I eventually realized my motivations for developing open source software were rooted in vanity. Just making programs is something I do all the time, I find it very rewarding. But the part about open sourcing it, that was the vanity. Before opening the project, nobody else was contributing anything to it, either. After opening it, all that changed was that my expectations for how people would react to it were not met. Expecting people to want to use my software in exactly the way I wanted was a hell of a lot of arrogance. Those people who were requesting features, they weren't "wrong", they just wanted different software. More like a service that did the things my software could enable, rather than building things with my software. I don't write the software to get rich or escape a dead-end job. I used to have that fantasy, but nowadays life is pretty happy, and I also have realized the fantasy was always a myth, anyway. So in the end, the difference between writing software and writing open source software is nothing more than me wanting recognition for the thing I created; aka a vain search for glory. I didn't like that view of myself, so I stopped opening my software.

travisjungroth 5y ago
You’re saying no one uses your software whether it’s open or closed, you just got annoying “contributions”. How did you know no one was using it? How would you know if someone was?
- moron4hire 5y ago
  No, I didn't say people weren't using the software. I could see that in a lot of different ways: how many people were active on the project site, how many people had forked the project on github, etc. My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software. Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves. I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need. The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time? Thus the realization that I had been deluding myself.

GoToRO 5y ago

henryfjordan 5y ago
The license very clearly tells you that you should not assume that the software is "production ready" and that if you do, that's on you. > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ...
- cweagans 5y ago
  You beat me to it :)
- GoToRO 5y ago
  You quote doesn't mean what you think it means. It just means "we will hide the real state of our software because we can, so you can choose to loose valuable time evaluating it now or else more time fixing it later. We could tell exactly how production ready it is, but we choose not to."
  - henryfjordan 5y ago
    The code is open-source, nobody is hiding the "real state of the software". "Production-ready" means different things to different people. For many, "production-ready" means "we have a support contract with the software vendor". In that case, the project would never be usable in production. To others with higher risk tolerance, a 1.0.0 release is all you need! You'd have to consider each user before making a recommendation about production-readiness. Instead the author offers the software AS-IS and you can decide for yourself. The author doesn't owe anyone anything, least of all a personal consultation about whether using the software is prudent.
  - jjav 5y ago
    No, the license means exactly what it says. An open source project (in most licenses) offers zero assurance of it being usable for production and that's what it means. If you want to use it for production you need to either (a) do whatever evaluations you feel necessary to ensure it will be stable for production for your needs, or (b) pay the authors for a signed support contract so they take on that responsibility.

GoToRO 5y ago

woah 5y ago

I totally get where they are coming from but it does make it sound like unsupported software. After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). I would probably look for another open source project to use instead. There seems to be a constant supply of people starting open source projects who are willing to support them, and I'm guessing that an alternative to this project will supersede it, resulting in people not bugging the author any more.

jjav 5y ago
> it does make it sound like unsupported software Nearly all open source software is by definition unsupported (read the license). If you need support you can pay for it (and in the blog the author specifically states they are open to communications regarding paid consulting work).
jjav 5y ago
> I totally get where they are coming from but it does make it sound like unsupported software. It is very specifically unsupported software! Read the license, it's right there in a legal document clearly spelled out (for many licenses, anyway). > After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway). A good phrase is that importing an open source library is like adopting a puppy. Sure you get the initial code for free, but all the work and mess from there on it's all on you. Yes, if you want to rely on an open source library for production you do need to understand it as if you'd written it yourself! I know this principle has been lost in more recent times, but it remains reality. If you don't, you're just gambling on the hope that it'll work out. It can, but it's a gamble. If you need more certainty, pay for a support contract with SLAs.
deleted 5y ago
[deleted]
FooBarWidget 5y ago
> but it does make it sound like unsupported software Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly. Open source software is unsupported software unless you paid for a support contract. If you still get support despite not having paid for such a contract, then that support is an incidental gift that can go away at any time for any reason.

langsoul-com 5y ago

Although FOSS software is nice, it just doesn't seem worth the hassle to be involved any more.

thenerdhead 5y ago

I think the missing aspect is that the platforms put this stuff in front of your face and human curiosity will have your attention directed at it anyway. You will actively be thinking about that troll who opened up an issue or someone in your Twitter DMs asking for help. Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do. I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.

deleted 5y ago
[deleted]

einpoklum 5y ago

> I am contacted dozens of times every week with varying requests to answer people’s questions Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times. > fix bugs "Please file an issue at http://the.issue.tracker/wherever http://the.issue.tracker/wherever" > or build new features "Please file an issue at http://the.issue.tracker/wherever http://the.issue.tracker/wherever" > set up consultations So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then: "I am currently not available for consultancy. You may inquire again, if relevant, in ____ months." > or discuss business opportunities. "I'm sorry, not interested. Good luck with your business." Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)

Crazyontap 5y ago

I think there should be term like suffering from open-source fatigue. Being an active open source dev myself I can relate to this but at the same time I also have been on the other side of the fence when my oss projects didn't get a lot of traction and any mention from anyone, even if it was an issue, got me really excited and it also kinda validated my efforts. It's like being a mini celebrity feeling happy when somebody asks for your first autograph but as you become more successful more people want your time and attention and then you don't want it anymore. Also unlike being a celebrity you may get some fame but rarely any fortune, so that makes it all the more easy to get annoyed when people try to eat your attention for their own benefit.

ascar 5y ago
> Also unlike being a celebrity you may get some fame but rarely any fortune I know this isn't your main point, but afaik most low-level celebrities barely make money from it either. So it's actually even more similar than you thought.
weq 5y ago
This! Open source can make your career, just as much as the Op says; it can break your back. From the outset i would say that most people releasing OSS stuff wants it to be used in production. thats until you get the hungry corps looking for free support. IMO at that stage an OSS maintainer needs to start a consulting company and funnel everything into it to avoid the burn. if this guy was making 6 figures consulting for those same companies, i think the conversation was different. Unfortunately knowing how to write software is not always compatible with self-marketing and has a keen business acumen.

ikiris 5y ago

afarrell 5y ago
This isn't hate. This is indifference and conservation of energy.
gurchik 5y ago
I don't think this is a fair characterization of the article. It's really not too much to ask to ask a user to go through official channels like a bug tracker or a mailing list instead of messaging the author directly. And I don't think it's right to accuse someone of hating their users for creating those channels. The only reason an author would make those channels is if they believe it would increase the chances of everyone receiving the best help. It's usually harder to find an authors direct contact information than the official channels. If the user has a legitimate bug report or issue, being told they accidentally found the wrong contact information wouldn't bother many. However if the user is going through backdoor channels specifically to get special treatment then that isn't fair to others.

newshorts 5y ago

Honestly, I don’t understand the entitlement that causes someone to have to write this. Having experienced the “overwhelmed with requests” thing myself, I now find myself thinking anyone who becomes demanding of open source maintainers is not seeing reality. These folks have day jobs, they don’t work for you. If you’ve implemented my library in a mission critical part of your system, then feel free to fork & fix or pony up the dough. Otherwise you’ll get the update (if it should be updated at all) when/if I have a minute. This might be a bit hostile but truly, c’mon people.

NorwegianDude 5y ago
That's not hostile at all. If someone decides it's best to use your code then you have already helped them out. Expecting you to do work for free for them because you already did something useful for them is just stupid.
- mickael-kerjean 5y ago
  It's great to have that kind of post published. I had that exact conversation just yesterday with a director who "love" open source and see it as "the future". When asked to pay market rate for the extra features he want, he was struggling to understand that 8k won't get him a few months of work and felt entitled on a discount on the basis that I'm doing open source and he is helping the project ...
89vision 5y ago
I don't think this is hostile in the slightest. Nobody should expect free work
deleted 5y ago
[deleted]

NorwegianDude 5y ago

There is a lot of idiots out there who expects you to work for them and help them fix their issues just because you made your code public for those who find it useful. Just look at some of the answers, even here on HN. One should be happy for the work that people do make available for others. If you're not paying for it and it's run by people who just want to make something cool then you should be prepared to contribute if you want someone to go out of their way to help you. You don't have to contribute financially or by writing/fixing code. If you need help with a bug, make sure you write good bug reports, and be patient. Also, if you don't want spam, just turn off notifications for non important things and limit the communication channels to something you'll be able to control. That's the beauty of digital communication: you control exactly how and when people can get in touch with you.

JJMcJ 5y ago

An XKCD that's right on target: https://xkcd.com/2347/ https://xkcd.com/2347/

gsliepen 5y ago

Dealing with users/contributors in open source indeed has its issues due to the low barrier and global nature, meaning you can receive both high and low quality comments/patches/etc, and sometimes the language barrier makes a good quality interaction look bad. In order not to drain your energy dealing with them, you have learn how to deal with them efficiently. What works for me is: - Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out. - Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask https://stackoverflow.com/help/how-to-ask). - Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out. - When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future. - I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.

account42 5y ago
> When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future. I agree that this probably the ideal thing to do in the long run but, especially as a less social person, often it feels much easier to just do the minor fixes required myself. Training people to be good contributors is a good thing to do, but it is also something that can be very draining.

xiwenc 5y ago

Why not grow the maintainers group to multiple people? A trusted group of people that share the vision of the project. This way the project becomes a living thing that doesn’t depend on the goodwill of a single person. And that single person would not be overwhelmed. People are not entitled for support but bringing something out as open source does come with some responsibilities. If not when others fork it the original author gets upset others stealing their project (assumption here).

bwindels 5y ago
> bringing something out as open source does come with some responsibilities. No, it does not.
TonyTrapp 5y ago
There are many, many projects where "simply adding more maintainers" is not possible at all, i.e. there are no people that you personally can trust to do the right thing, and that have the necessary experience. For various projects that I maintain, I couldn't name a single person that would have the skill and would actually want to take over. Granted they may not be as popular as this persons's repositories, but still - this claim is not generally true.

deleted 5y ago

[deleted]

chmod600 5y ago

If an author can publish code with a take-it-or-leave-it attitude, why can't people make requests with the same attitude? If the author is under no obligations at all, a request is no problem, right? Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence. I'm not suggesting a real obligation, but there is... something? If there wasn't, then these requests would be treated like random mail to a famous person and just discarded.

d4mi3n 5y ago
> Well, the problem is that it's not so absolute. Publishing something normally invites feedback and it's awkward to completely ignore it. Just like it's awkward when you report a bug and get silence. I think in a perfect world every request would be polite and reasonable, making what you say here objectively correct. Since this is not the case, this sadly becomes a subjective opinion. The fact of the matter is that when one deals with the general public in any form you get all forms of good and bad interactions. There's also an inherent asymmetry between the effort it takes for a small number of project maintainers to respond to a large number of project consumers. There's no clear-cut answer here, but I think it is reasonable to state that someone sending requests to a project should set their expectations to match whatever licensing or contractual agreements are present in the projects they interact with.
wildmanx 5y ago
No there is not something. That's a misconception. The author is under no obligation at all. Of course a request is no problem. But then if that request is ignored, then that's no problem either. Who knows why there is no response. Maybe the person has other things in life needing attention. Maybe they have a bad day/week/month. Maybe they are burnt out. Maybe they have already responded to you 100x or maybe they just don't like your name. If they do respond -- great! It's likely in their interest to respond to bug reports since it's likely in their interest to have less buggy software for themselves (if they use their own software) or for their customers (if their customers use their software). But maybe it's not, maybe they have moved on, or maybe they are just on vacation. If they are nice, then they tell you. But even that's something they don't have to do. You are free to dislike them for that, and you are free to not use your software anymore. You are usually even free to fork the project if you want your pull requests in and they keep being ignored or rejected. If others think like you, you get a community right away. But many people don't fork. Because it's a lot of work suddenly being a maintainer. Then you suddenly get those requests and opinions and pressure. Don't like that? See! That's the issue here! If you don't like it, then don't criticize others for not liking it either.

wildmanx 5y ago

So much this. I'm glad he put this out there. I'll start linking to it too. There seems to be a common misconception about open source. When I release software as open source, it does not mean I work for you for free, need to provide you with anything, even need to be nice to you. I may. Or I may not. When I release software under an open source license, then we have a very specific deal. You are entitled to do certain things with the software, for example use it free of charge, or change it, or redistribute it, and I'm entitled to certain things in return, for example you keep attribution, you publish changes that you made under the same license, etc. Nothing more, nothing less. I could be an individual that hacked something in their free time, or I'm a multi-national mega-corp. Does not matter. It just means we have a deal. It's nice if a community emerges, and if I feel like it, I may participate in it. And accept pull requests or help with troubleshooting or implement new features. But I don't have to and I don't have to feel any obligation whatsoever. Anybody who thinks otherwise has misunderstood the concept or is maliciously misusing it. That's it. This is misunderstood not just by users, but even by creators themselves. They feel pressure, they feel bad if they don't respond in time, or implement new requested features, or accept pull requests. They shouldn't. Open source just means I published it once with a very specific deal. I may continue to do so if it makes sense to me, but I can also just stop doing so. I implement features when I have a reason for it, for example I like to have them in the software so I can use them myself, or maybe because I'm a corp that sees a business need. But implementing them for free just because somebody asked for it, that's just asking for trouble. If you do that regularly, and not mostly because you think it's fun, but because you want to "support the community" or whatnot, you are taking steps towards burnout, and ultimately are not just hurting yourself but even the larger community, because you are fostering the expectation that that's what open source devs should do. No, they shouldn't. That's not what open source is about. It's about a specific deal. Nothing more, nothing less.

enraged_camel 5y ago
I will preface this by saying I have immense respect for anyone who open-sources their work. I think the web as we know it today would not exist without such kind and hard-working individuals. In my opinion, I think most of these issues outlined in the article are caused by lack of communication combined with unclear expectations, to be honest. The only thing I ask of open-source library authors/maintainers is this: be upfront and clear about the nature of your library, and your level of commitment. Is it just a hobby app? Totally fine, just put in bold text "this is a hobby app, not recommended for production use". That way, everyone knows what to expect, and if they do decide to use it in production, they do it at their own risk. Do you feel that it is feature-complete? Then just say so, and indicate you will not be doing any more work on it. Do you want to work on bugs whenever you feel like it? Nothing wrong with that, it's your work, but again, please just put it somewhere in writing so that any developer or PM who comes across your library knows exactly what to expect. You painstakingly supported a library for years, got burned out and want to quit? At least try to pass it to another maintainer. IMO these are just some very, very basic things that open-source authors can do that would alleviate a LOT of the friction that occurs in this space between them and those who decide to rely on their work. Be kind, be clear, be upfront. That's it!

deleted 5y ago

[deleted]

qwertywert_ 5y ago

I read Joe Elden Ring.

brunoborges 5y ago

Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's code, whether they had discussed about it or not. Back in the days of SourceForge, open source software would be simply put for download. Anyone willing to collaborate, often times would first engage in the mailing lists or forums. That is not what GH Pull Requests do though, but quite the opposite. It builds on the idea that it is easier to discuss by showing code than by exchanging words. But that's just not how it works for anything beyond trivial/typo fixes. And that just frustrates everyone. This is the flow I'd like to see GitHub allowing maintainers to choose, in addition to leaving today's flow as default: - Allow maintainer to disable Pull Requests just like they can disable Issues/Discussions - Allow maintainer to "Open Issue for Pull Requests" This basically means that Pull Requests are on a per-issue basis, not per-repo. And only if the maintainers open said issue for accepting Pull Requests. This would push the contributors to first dialogue and discuss the enhancements/bugs before wasting any time writing code thay may never be accepted. This flow would be much better for setting the right expectations, in my opinion.

duskwuff 5y ago
There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.
- brunoborges 5y ago
  What I described is what I believe GitHub should support. Not that they support it today.
  - duskwuff 5y ago
    Right, I mean that there is a (caveat-ridden) workaround as it stands. I agree that repository maintainers should have the option to restrict or disable pull requests, just like they can disable other features.

erwincoumans 5y ago

Indeed, love this article. Especially after receiving this tweet, getting public attention for a bug: https://mobile.twitter.com/araffin2/status/1501314248114413573 https://mobile.twitter.com/araffin2/status/15013142481144135...

yblu 5y ago

I used to maintain several popular open-source projects and contribute to even more popular ones. It was always fun at the beginning, especially because I built them for my own needs. But I kept getting asked to fix bugs or improve things even long after my needs had expired. I tried the donation route for a little while but it didn't go anywhere - I received maybe a few hours worth of money (versus hundreds if not thousands of hours I had spent working on those projects). I also tried releasing a paid version for one of the projects and got buried with hate mails and, unfortunately, online abuse. That was when I stopped working on open-source and I'm happier than ever. I'm very happy for people who make it from doing serious open-source work. I think they deserve it. But at the same time I feel bad for those who build or maintain no less serious or popular work and yet couldn't make enough to worth even a portion of the time they'd spend.

mwattsun 5y ago
The reality is: most companies are taking economic advantage of the generous spirit of open source developers. That needs to stop. SPONSORING OPEN SOURCE DEVELOPERS Rich Hickey - December 15, 2020 https://cognitect.com/blog/2020/12/15/sponsoring-open-source-developers https://cognitect.com/blog/2020/12/15/sponsoring-open-source... HN Thread here: https://news.ycombinator.com/item?id=25436335 https://news.ycombinator.com/item?id=25436335
- smashah 5y ago
  Sponsorship is not a panacea unfortunately as corporate use of a project is not proportional to the maintainership burden. Hopefully the industry can fix this one day.
  - hawkesnest 5y ago
    If you could even get it! Think about all the millions of dollars dealing with the Log4J issues last December. How much has that prompted sponsorship of any logging libraries by the affected companies? Not much, from what I've seen.
mikepurvis 5y ago

graderjs 5y ago

Exactly. I talked about this in my 22120 interview[0] a couple years ago. You have to learn to say no. Self-management taking care of yourself and setting boundaries, protecting your space to ensure you can continue making contribution on something you care about. People can be so demanding you have to push back. Use the block feature on GitHub if they're real trouble. I don't have a ton of experience but in my experience of this somehow by pushing back and setting boundaries and saying no it seems you change the expectation or culture and it's a persistent thing. Then the "little community" you have seems to behave better. [0]: https://console.substack.com/p/console-28?utm_source=url https://console.substack.com/p/console-28?utm_source=url

wly_cdgr 5y ago

Always good to see an open source dev standing up for themselves, if only a little, against all the entitled freeloaders and techbros who are all too happy to exploit them and to encourage them to continue exploiting themselves If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat

orangecat 5y ago
you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. As an author of open source projects with thousands of users: no. You should abide by the terms of the license, which I voluntarily chose and which does not have a secret passive-aggressive clause of "you're a piece of shit if you don't pay". (Separately, the tipping model is awful and something we should be moving away from rather than expanding).

mholt 5y ago

Good on him. I wrote fairly comprehensively about boundaries in open source recently: https://matt.life/writing/the-asymmetry-of-open-source https://matt.life/writing/the-asymmetry-of-open-source A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.

jurassic 5y ago

A few years back I was in a role where it was my job to maintain a small but non-trivial open source project (~1500 github stars, 5 core contributors). I burned out after about two years in that role. People repeatedly demanding help in the github issues without even providing repro steps. Hate mail to the project email list from users angry we didn't implement the feature they want in the latest release. We had people second-guessing all the time if we didn't ship the things they wanted or they disagreed with the decisions we made. Some people just like to get in touch to let you know your work sucks. The worst was the CEO of a small competitor company repeatedly hassling me over slack DMs and in github issues threads shamelessly trying to get me to prioritize free work that he wanted for his clients. Separately, over a period of several weeks, this same person asked me a ton of support questions and then compiled my answers without edits or attribution into a "white paper" he used as a resource to get people into the marketing funnel for his consulting shop. I came to hate that guy, such an asshole, but I couldn't totally block him because his company was a member of the open source foundation governing the ecosystem of tools my project was under. Honestly, it was hell. The most stress and irritation I've ever had in any job. When I started the job I thought it was a dream getting paid to do open source, but now I consider that an anti-goal for any future role.

wintermutestwin 5y ago
Sounds like OS developers would benefit from Product Managers who could shield them from the users (among other PM tasks). Do many OS projects have PMs? Are there any "standards" around non dev roles in OS projects?
- morgante 5y ago
  Unfortunately my experience is that most PMs are not sufficiently technical. They will often add more work by injecting useless processes and try to "demonstrate value" by coming up with new ideas without actually understanding the problem domain. The best approach I have found is simply to add more automated gates/bots. If people have not done what the bot asks, there's no need to waste time/energy on them.

neilv 5y ago

I appreciate that an open source developer is likely to be burned out on some people's expectations or unthinking requests, but that page was too long for me to even skim. Usability-wise, one could lead with a terse bulleted list of "use cases" for which people should contact you, and how. Then state you can't handle all the other usual reasons people want to interact with an open source developer, maybe giving examples. Then follow it with explanation of why.

zzzeek 5y ago

This is a good read. just to get a sense of some of the OSS maintainer experience. As far as a practical guide, it's my experience that the vast majority of users of OSS software libraries "get" these things already and therefore you don't hear from them. However, just 1% of users who don't "get" it at all, and do all the direct messaging / manipulative stuff are still there, and that's who ruins your day. Which then leads to, those people are absolutely not going to read a blog post like this, they can't even read GIANT LETTERS IN BOLDFACE at the top of a github template telling them to please provide a test case / stack trace / etc. After doing this for 16 years I have realized that while you need to put up guidelines, instructions for interacting, issue templates, etc., at some point you can't keep putting up signs to PLEASE DONT DO THIS - because the people for whom the ALL CAPS is intended for are the last people to read/ care about any of this, and the stern messaging otherwise brings the mood down for that vast majority of users who aren't going to be bothersome in any case. You have to just have a pre-packaged response for the various things you get: 1. "hi" on IRC in private message from someone you don't know (obviously looking for help) - ignore. there's no response you can have for this person in this setting that will make the situation better (keep in mind, there are many forums / chats/ systems this person can use to get help, and they are well documented. these people ignored all that and are trying to go right to the main dev to get private help. they most certainly know how to find things because they found your nickname on an irc network. so this is overall a pretty rude move, but even then, some people just arent aware of what they're doing or how to act) 2. email asking for help - this is probably not too different from the "hi" in private message thing but I tend to give folks like this a short answer and point them to github discussions / irc, mentioning "there's some folks there who can help us further" (note the word "us", to soften the blow a bit). the emailers tend to be completely bewildered and generally lean heavily towards overall beginner types so I do try to gently guide them into the wider community for help. 3. recruiters - geezus, they just don't stop. I pretty much ignore them, which they have all caught onto these days so they email you over and over again...I will send back a one liner about 50% of the time after they've pinged me three times 4. weird link-sharing emails who want to put some kind of endorsement for some programming tool on my site that makes absolutely no sense to be in the context they are proposing - I usually just ignore these. Hard to tell if those are spam robots or what but they can be persistent with fairly emotionally charged "can you at least tell me what you'd be interested in?" kinds of replies...I mean these folks I'm sure are sending thousands of these emails out, are they sending out hundreds of frustrated third-requests to everyone who doesn't reply also? I do feel for this developer since producing a JS web-development oriented library is going to generate lots more attention from a lot of users with relatively low levels of technical sophistication. I'm thankful that the Python world still attracts high quality people with reasonably good manners about things.

SavageBeast 5y ago

Open Source Software promulgated by GitHub is made commonly available in the form of actual source code. If this code does not suit your needs, change it such that it does. We're all engineers/developers/coders/hackers with Top Notch Skills right? Make a fix thats well thought out and well integrated, commit, pull request and hope the maintainer finds value in integrating your code into the next release. Should you come across a maintainer that doesn't share your view of the issue and depending on licensing constraints simply maintain the code you were given for free on your own. That or ... I dunno... Maybe pay someone? Venmo is a thing? Do you even Crypto bruh? * I spent 5 years working for a company that successfully took this approach. Pre-GitHub of course. * OP is totally on target.

andrew_ 5y ago

https://liberamanifesto.com/ https://liberamanifesto.com/

travisgriggs 5y ago

Is this kind of burnout perhaps in part due to the level of mechanization provided by the defacto platform for open source projects now: GitHub? It seems like it’s more frequent, but maybe that’s just me. It’s great that GitHub exists and lowers the barrier for anyone to develop and share open source efforts. But you also become a slave to its various very well automated processes. As a creative altruistic agent, that can actually take a lot of the fun out of it. And make one feel trapped by the process machine. It seems in old days, when things were less standardized, maintainers had more creative control over not only the code, but the process/community around it. I’m not advocating for a demise of GitHub. Just kind of wondering if this is the price we pay.

TAForObvReasons 5y ago
Cultural norms around Slack / Discord (compared to the IRC of old) are also to blame. With email, people understand that there is a reply and that process takes time. Discord and Slack encourage people to keep the apps running, continually sapping time and energy. The best thing a project can do to address burnout is to eliminate any sort of messaging option. Keep all discussions to the issue tracker and email.
outsomnia 5y ago
Yes, many issues are simply users deciding that it is quicker to abuse maintainer time to get and answer than find out themselves, github does facilitate that. What causes the most teeth grinding is when it is questions about their proprietary code. I don't care if their garbage never works! It's not going to help me or anyone else either way.

awill88 5y ago

I wonder if there could be a way to just turn off issues and only accept PRs. Contribution-driven feature requests. That would be a boundary that I think would protect the maintainer from the potential outcome that the article about boundaries does absolutely nothing. Open is open, people are relentless and unforgiving, that’s why I don’t have the stomach for it. But if I see something I’d like to do with a project, I will take a whack at implementing it and giving back. I can imagine gaining a distaste for seeing companies benefit without being rewarded in return. With that, perhaps it’s time to seek out other maintainers? If we’re talking open source here, shouldn’t successful projects become co-owned (ie maintained) by the community? While a single maintainer who creates a successful open sourced software certainly earns the discretion to choose to share their invention(s) or not, holding tightly onto the projects as opposed to donating them seems as unproductive as a random person demanding features. But I am not the maintainer so I don’t mean to convey apathy, my completely naive, lizard brain would just want to troll the worst of them with “open a PR and we’ll talk”

mhils 5y ago
FWIW, you can disable the Issues tab on GitHub, there's a setting for it.
vaylian 5y ago
> I wonder if there could be a way to just turn off issues and only accept PRs That would create the problem, that people won't able to ask if a feature is desired by the maintainer. New contributors would spend time on a PR and then learn that the original developer considers that feature to be out of scope and therefore the development effort would be wasted. I understand your wish for removing the issue tab. But there is a downside to it.
hbx 5y ago
Since Nov 2021, you can allow some people to bypass pull requests requirements. https://github.blog/changelog/2021-11-19-allow-bypassing-required-pull-requests/ https://github.blog/changelog/2021-11-19-allow-bypassing-req...

lukaseder 5y ago

How about charging money for work?

stdbrouw 5y ago

Most of the comments here remind me of the famous Neil Gaiman quote, "George R.R. Martin is not your bitch." [1] But I don't think that's the right framing. People buy the first book because they hope there will be a second, even though they haven't paid for that second book and hence are not entitled to it. People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. That's not about a false sense of entitlement or callousness on the part of your users at all. It's also not about freeloading, because a lot of those pull requests and issues on Github will be coming from people who publish their own open-source software. Instead, it's about managing expectations, like the post does. Put a big "this project is not maintained" warning on top, and nobody will bother you. Although I do understand that for larger active projects, it can be hard to explain to users exactly where on the spectrum between "don't bother me" and "I'll fix your problem yesterday" you are, and the bigger a project gets, the more likely you'll be to encounter people who enjoy exploiting your free labor. [1] https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...

otikik 5y ago
It's funny, because I think I have pretty much the opposite expectation. When I encounter a new open source project it means that I can make it better by providing pull requests with new features, or fixing bugs. And then everyone benefits. If they choose to listen to me that's fine, but that's the icing on the cake, not the main course.
- jcbrand 5y ago
  There are people like that, and they're usually great to have on an OSS project, but they're a minority.
uranusjr 5y ago
> People use your open-source project because you said, hey, here's this exciting new thing, try it out, so they assume you'd also want to listen when it doesn't quite work as it should. > Put a big "this project is not maintained" warning on top, and nobody will bother you. I think this is exactly the problem. The author never promises they would maintain the software, nor expect their definition of “this works” to match the users’. Why do they need to put up a sign in the first place for people to not assume? “Expecting things that were never promised” is pretty much the definition of self-entitlement. IMO this should be entirely the other way around. People should not expect anything unless the authors say they are willing to maintain.

CR007 5y ago

Does it works? I also have issues with users and in my case they don't read this kind of instructions.

pengwing 5y ago

In refusing to accept that any contribution you make to society is in fact a business, you will be doomed to build a bad business. You will talk about the emotional turmoil a feature request puts you through instead of being proud of your streamlined business processes and your ever increasing MRR.

wink 5y ago

I have only one problem with this: > In Slack or Github, it’s usually not necessary to mention me. That's kinda how it has always worked in these forms of communication though - if I want X to see something, I mention. It's not that I personally would be keen on to be mentioned all the time, but I've been on open source project IRC for 20 years and it is like it is. People need to configure their client to not spam them, or not use [medium] if they can't do that. It's unreasonable to have the general populace have rules of whom to mention and whom not to mention. We all should be sparingly using it, it's async after all.

specialist 5y ago

If my OSS projects ever get traction, I'll probably forward support to a public listserv or web bbs thing. Extra credit for wiring that up to some kind of ticketing and bug tracking thing. Automate the FIFO queue. Biggest benefit to me will be transparency. Everyone can see exactly where they are in my priority queue. Huh. Could lead to some fun incentive structures. Want my attention? Then pay me. Like charge $1 per slot. So moving from 100th to 5th place would cost $95. Maybe increase the price-to-slot logarithmically. Any way. It's nice to dream. A small inhibitor to me working on my OSS fulltime and exclusively is figuring out how to pay for food and rent and insurance while saving humanity (from itself).

iiroj 5y ago

I originally set out to fix a performance problem in lint-staged that was preventing my then-company from using it in their large git repo (related to long histories, git read/write tree, and clearing index caches). Here I am, many years later, still maintaining it and overally enjoying the work. I just chose to never take on any implied responsibility like described in the article. This means it's ok to ignore or close tickets, or simply not be active for some months if there was better things to do. So far the interest has kept up, and I'm improving it on our own terms.

zivkovicp 5y ago

> noticing people cozying up to me so that they can exploit our acquaintanceship later Unfortunately this is common in many other parts of life as well; setting boundaries is important.