This has been discussed before and it has been true for me as well. I don't have a large, super-popular package I maintain, but several lesser known ones, some of which I wrote, and several of which I just adopted and passively became a maintainer over time.
At some point the pressure from the community made me pass the magical threshold between fun/useful/rewarding and downright chore.
It has permanently changed my perception of OSS management, to the point that I stopped releasing further projects, no matter how small, simply due to the work that these entail.
Just look at the discussions you find here monthly about being "a good author/maintainer/leader", where most expect full documentation, professional landing pages, useless code of conduct, and so on... BESIDES the project itself. You'll be criticized irregardless.
I have deep respect for the maintainers of popular OSS projects because of the amount of s*it they must take. I know I wouldn't do it for free at these scales. I also wouldn't do it besides another job since it is so demanding.
This is not a community project. This is my project. I know that will disappoint some people, but I do this for fun in my own spare time. If it stops being fun, I will stop working on it, which will pretty much kill the project. There are millions of projects in the world and the only reason they continue (if they actually do) is because the maintainers stubbornly stick at it.
With that in mind, here is the code of conduct: If it is fun for me then it is good. If it is not fun for me, then it is not good.
Things I find fun include: Bug reports that explain what you saw and what you expected to see. Suggestions for features that would make your life better. Stories of how the software so far has already made your life better. Entertaining stories of how you used the software (bonus points if it includes pictures of cats). Offers to volunteer to improve something (super bonus points if you actually improve it). Questions about how the software works. Offers to write documentation (super, executive class bonus points if you actually write some). Answering questions that other people ask (bonus points if you get the answers right).
Things I don't find fun: Drama. That is all.
To some extent, I will accept drama in exchange for money. But it has to be a lot of money. Think FANG level money. If you don't have FANG level money that you are willing to give me in exchange for drama, just don't do it -- even if you think it is the most important thing in the world.
There is no other code of conduct. I may arbitrarily declare some things fun for me and some things not fun. Please pay attention when I declare one way or the other and act accordingly.
Feel free :-) I warn you that the only way I had the courage to write it was that I drank a considerable amount of nihonshu (Japanese sake). It was pink. The label said that the pink colour was a natural result of the kouji (aspergillus oryzae). I'm skeptical :-)
But, in all seriousness, I've been thinking about it a lot and really the main thing, I think, is for everyone (even the maintainer) to avoid drama. If you find yourself in a dramatic situation that seems to have been caused by your actions, simply apologise for the drama that you have unintentionally invoked. I think that's all that is necessary.
But if it isn't about me, somebody else has to do the project management and the code commits.
That's just the way it is. When OSS goes further than the "my itch to scratch" scenario, it gets complicated and there needs to be a way to motivate people to scratch other people's itches.
> Ownership is essentially the main problem of OSS here.
I'm not sure I see the problem. Care to elaborate on just how ownership is a problem for OSS projects?
> Makes me think of Hickey's "Open source is not about you" rant and I can't prevent myself from hearing "It's about me".
Hickey's and the parent's CoC both express that, as far as people go, the OSS project is about the project owner(s) and not about "you" as a user of that project. It seems you are implying that this stance is bad and narcissistic instead of a healthy approach to working with OSS (which seems to be the more general interpretation).
I don't see a problem: any given author / contributor has their own reasons for providing something... and you and I are most likely not one of them. We can choose to tag along for the ride or not. If it is of value and we have issues or need missing features, we can contribute to the project to make it better. For many people, that is often one of the reasons they even bothered to open source it to begin with: to get help.
If one lacks the skills to or time & interest in helping, the two most productive courses of action are either to move along or throw money at the problem. Now maybe your issue is the developer/maintainer themselves. i.e. the project has value but you don't want to deal with the author(s)/maintainer(s). That's fine: fork the project. If enough people feel like you do, the original project will likely die due to these open source 'market' forces. That's a risk any author takes making the project open source to begin with.
I have absolutely no problem with a developer saying 'this is my project' or 'I'm not interested in your problem' as a default answer. It is their project/time and my problem after all. Assuming I don't have the time/skills and really want their help, I can offer to throw money at them and many will develop an interest in solving my problem. If that doesn't work, I can offer to throw money at someone who will.
Note that none of these issues are unique to open source: try to get Apple/Microsoft/Google to fix a longstanding bug or add a feature that you really want or need. Odds are, you don't have the order of magnitude of money to get them to care. And you usually don't have the source either, so you're out of luck.
When I do eventually write a COC for my project (i.e. when more than 0 people have seen it :-) ), this is an important section that I want to write. I choose free software licenses because I want my users to be as free as I am in their choices.
I thought long and hard about why I write free software. It's not for an altruistic reason. I do it because it is something important to me. If I allow others to dictate what I should be doing, then I lose my reason to write free software. The free software license is their guarantee that no matter what crazy thing I decide to do, or say, they can carry on without me. That's as fair as I want to get.
If only there was a system that aligned user goals with producer goals. Some way that the users can get the product “customized” to their needs through an incentive.
Like it or not, volunteer software is not meant to be about users. If you want it to be about you, you have to pay money.
I'm responding to my own comment to respond to the sister comments:
It seems most people who have responded seem to think I defend the kind of guy who joins an open source project, get some importance and then starts to act like a jerk (or in other words, starts challenging the power status of the main maintainer which is a natural thing once an individual invests a certain amount of time in a project).
No wonder so many people react against this kind of guy. There is resentment on both sides. Now let me tell you about another kind of "maintainer", the casual one. He just goes by, fixes a bug or broadens the interface of a function and he's gone. You'll most likely never have resentment against this kind of maintainer even though he might, because you're not engaged in a power struggle against him. Why ? Because you have already won it. You just can ignore/forget about his PR he won't harass you about it anyway. For what he knows you might be dead and have carried that holy merging power with you in the afterlife. He has invested work in this, because working for the benefit of community brings him joy, only to have his work briefly considered and discarded. And most of the time when this happens, the real reason behind this is never explicitly told "This is my project and I am in power – firmly kicks the ground" but this is paraphrased with words like "this does not fit the community needs". There are also maintainers who truely are dedicated to the community and if in power only for this greater good with no personal gains. They are sincere. If so why not let the community express itself, for instance through voting, instead of making decisions in its name ?
Now let's consider some points for an alternative take on what "code" and it's management could be.
- A library is not just a pack of implementations for a given solution (a categoria) it's also the public place on top of which such implementations can be enunciated (an agora). Version tags hint at this reality (code is a Becoming) but we prefer to play it down and hide it in a Changelog because the listed changes are seen as mere incidents on a road that leads to an idealized, objective and optimal state of code in front of which personal preference have almost nothing to say.
- To generalize what versions are variants are introduced. A code variant can be defined at any granularity level, small or large and there is ways to state a certain variant must be used, from global to more local scales.
- Each user can push variants in its own namespace (e.g: the-lib.public.the-user).
- A team of maintainers only curates such variants and its goal is to provide a comprehensive default perspective on the implementation space of the library. A library can have competing team of maintainers.
- There is no fork. Either your library is totally different and there is no point in starting it as a fork, or only parts of the library change and this is the wrong variant granularity. Plus a fork is a way to push unwanted changes "out of sight, out of mind", both for the irritated chief maintainer and for the library users that may be interested in what the fork has to offer.
- There is no ideal community to please, only a standard/reference set of implementations and multiple variants at multiple scales. Each variant has its own community, i.e. users/projects that use such variants.
- Variants are not just code fragments but are places where they can be proposed, discussed, versioned, tested, measured, etc. Want to collect data on the way a function is used in order to bootstrap some machine learning model ? It's the place where this data is stored and can be reached.
Think FANG level money. If you don't have FANG level money that you are willing to give me in exchange for drama, just don't do it -- even if you think it is the most important thing in the world.
The poster is talking about a level of money, not the exact companies. The whole point of the line is that you should feel excluded from bringing drama if you don't have that level of money to give the developer.
For me this is one of our flaws as society. When we like something we just continue with our lives. When there is something that we do not like we stop to say so.
One of the best learnings I got as a manager is to give positive feedback. So, employees know how much we appreciate their job, and that we see their value. And just that one time that it does not work out, I will give them feedback to improve.
But, I realize how little I have applied this with OSS and on-line in general. I rarely stop to say thank your for your comment, it was informative. Even, that I may donate some money I never stop to say thank you to the maintainers of OSS.
So, that's probably why you mainly hear complains and comments from seemly entitled people.
Thank you for sharing your experience it gave me a perspective to think about.
in the United States, the development of the Code of Conduct appears to be a mechanism, refined by lawyers, to make a legal case to -> kick someone out <- of an 'open' system
The code of conduct uses words to describe desired outcomes of cooperation, but actually, it defines boundaries such that there is a specific reason to require a person with some behavior pattern, to leave, be blocked and removed from the project.
Legally, if the project is declared 'open' then there was no way to require someone to leave, legally. IANAL
Who told you that? The word "open" is one of the most overused words in American marketing, and has never been an implicit grant of rights to anyone. People were routinely banned from project mailing lists long before codes of conduct became common, and corporate projects labeled "open" were often completely closed.
I think that require to leave legally refers to situation where that person comes back again and again and again. So that you may use your lawyer to threaten him or his layer.
Friendly heads-up that 'irregardless' is not a real word, rather a mashup between 'irrespective' and 'regardless', either of which alone will do. It's particularly one to avoid because it's probably in the top five of "words that irritate sticklers", who will judge you for it.
I think a good policy to have would be to tell everyone: "if you have a feature request or if you find a bug, make a pull request implementing it (or fixing the bug)".
For feature requests, perhaps it'll be good to encourage people to discuss it first, before they start implementing it.
But make it very clear that you're not doing free work for anyone simply because they ask. (And that this is open-source project, and everyone is expected to contribute.)
I do some work in a project with this rule, and I hate it because the end effect is no one place to track bugs and known issues. Not every bug needs to be fixed, and they certainly don't need to be fixed immediately. But it's useful to know that they are there!
> You will be told that you need to develop a thick skin.
It's the equivalent of a bully taunting with "stop crying!"
I have been doing open source for about 10 years. A couple of my projects have 1000+ stars on gh for what it's worth.
Most people are chill. Some people disagree without being disagreeable. Then there's others who are completely toxic. A guy who was cto of a company and wanted to use one of my libraries made me absolutely miserable for weeks. Wrote about the experience here:
Chiming in to add that I've definitely had my ups and downs with open source. When it's going well it feels incredibly rewarding but when it's not, it absolutely sucks and I've gotten to the point where I avoid GitHub and try to take a break. It's part of the reason I've avoided taking donations for any project I work on. I'd feel a lot worse about taking a break if people were paying for higher expectations.
In 10 years, really the only negative experience that in any way affected my well-being was the incident I wrote about in the linked blog post. That covers probably a couple thousand GitHub issues. So really overwhelmingly positive stuff. Amazing how much I let one guy fuck up my day, in retrospect.
This has not been my experience. I maintain various popular and not-so-popular projects (although maybe not to the level of gnome calendar) and I just work as much as I want. If I don't feel like handling an issue right then, I say I won't have time soon and that PRs are appreciated.
The vast majority of people are understanding, I don't remember anyone making a fuss about it.
Some times I am wrangling internally and that has an emotional cost. I find that being super crystal clear on where I stand is absolutely necessary to be able to say no.
Yes, exactly. Saying 'no' is a very important skill you should have. Of course you can learn it too (like I did :))
Also it is very important to reverse the emotional costs. I mean, usually people come to your repo and demand/ask for a feature. Instead of feeling overwhelmed from this request, say that you welcome contributions and without this this feature won't happen and the feature request will be closed (after 1/2 a year). Or if it is a bug report, ask for a reproduce with the latest master and so on ... so: try to reverse the demand to offload your maintaining work if it is no longer fun to you :)
I usually say something like "I find this very useful and will work on it", "I think this is good but will probably not have time, so feel free to issue a PR for me to review if you want it", "I will accept a PR but not really expend effort to make this myself", or "I will not accept PRs for this as I don't think it's in scope, but feel free to import my library into your extension if you want".
It's often hard to tell the difference between doing this honestly, and just stonewalling.
Even when I'm completely honest about it and would like to see the fix happen, there is a level of my mind where I'm all, "great, now they won't respond and I can forget about this."
I never have a problem saying no. I have a problem saying no in a way that will make the other person happy, but I'm working on it and I think I manage well enough lately, but the "no" gets said regardless.
It's a very important skill, as people are donating their time to helping you out, even if they're complaining about something. Especially for collaborators, I want them to feel like I listened to them and that I have concrete reasons for rejecting their proposal, even if the reason is "I don't believe this is in scope for this project, but maybe it could be implemented a layer above or as a plug-in".
You aren't doing anyone any favors if you say yes to everything.
Developers tend to be worse in my experience. I picked up maintaining a few projects awhile back (django-haystack, pysolr) which are in that unfortunate position of having been popular enough to get used a lot but never getting much corporate support. The issue trackers regularly get requests which are important to someone’s business but not enough to actually do any work. Sometimes that gets as far as a pull request but that much less commonly gets to the point of passing tests or support for more of the support matrix than they need, although that often doesn’t rule out requests to just merge it anyway.
Why would you imply that "normies" are worse than "techies"?
Just look at some places where you get couple of guys that think they are next Linus Torvalds. Other thing to search for, are holy crusaders for something like tabs or spaces.
Where I would say real "normies" would not care and be "oh it just does not work, meh". There is probably the same amount of crazy people that would go full length to find you to fix their problem and do it for free.
The way I have learned to deal with it is switching to a mostly read-only software publishing. The default of my answers to issues is some sort of "No", which might be "good idea, but not now", "good, but not planned, PR open", "not within the project's objectives", "bad idea, there's a better way", etc.
This is not great, I'd love to be able to do OSS fulltime and help hundreds of people out there. But the reality is that, with a fulltime job, it is either not helping 90+% individuals or risking burning out, which would be even worse (especially for me). Also, the fact that my software is used by millions of people per year (directly and indirectly) and I've received $10 in donations in total (~5 years of OSS) hints me that it's a very non-sustainable market.
Are there any benefits to being a free software maintainer beyond the obvious pride and satisfaction that comes with the role? For example, is this something that people mention on their resumes? Does getting a job become easier and when you do, can you negotiate higher salaries?
Our world is incredibly indebted to Free Software Maintainers and I wonder how we can pay them back in our little ways.
When I interview someone who is a free software maintainer then it's a really big plus because this shows me that they can handle maintainer ship which infers a lot of good qualities, from small facts like that they probably know git well and write good commit messages, to the fact that they know how to handle people in difficult situations when a inexperienced maintainer would let bad code slip in but a experienced one will fight for good solutions.
In my limited experience, I'm not sure it's an advantage.
You do get to break the ice faster during interviews and contacting new clients. But it can easily backfire as well: people will ask why "project X" is not up to their coding standards, why you didn't contribute to "X" and/or why "X" has not been fixed yet.
Not everybody seem to grasp this notion that these might not be professional products.
I often discuss with my friends that do not have any public projects to show off during interviews. It really doesn't seem to affect the outcome, unless the company in itself is interested in one of your projects (which is pretty rare considering the breadth of OSS).
I have a page dedicated to my Open Source projects in my CV pointing to GitHub repos. I got hired to my last job without doing any homework or whiteboard programming because I had enough code to show.
People can use sites like Open Collective, Patreon or the likes to directly pay open source projects or people involved with them. There's a lot of different platforms for this and I don't even know half of them. If there's a project you'd like to support, check if they take monetary contributions somewhere and if not, maybe suggest it to them and start donating :)
English has a serious problem with ambiguity around the word "free". In the closely related Scandinavian languages, there is a difference between "fri" (as in freedom) and "gratis" (as in free of charge). Unlike in English, the Latin borrowing "gratis" is the common everyday word for things that are free of charge. Free software is known as "fri programvare", whereas free-of-charge software (a.k.a. freeware) is "gratis programvare".
In German there are at least 3 words that describe these somewhat related concepts. The word "Frei" is mostly meant as in freedom but can also describe absence of something. The latter form is usually used in compound words like "kostenfrei" which means "free of charge" however, most of those words can also be compound with "los" like in "kostenlos" which means the same thing and is used more often in this case. We also use "gratis" but mostly if something is given complimentary in addition to something else. Something like "buy one get one free" for example. Then we also have "umsonst" which is actually not related but commonly used by people to mean the same thing as "kostenlos". However, it really means "for nothing" like in "ich habe vermutlich all das umsonst aufgeschrieben" or "i probably wrote all of this up for nothing". So the differentiation between getting something for free and something being free (as in freedom) is quite clear. However, there is no german word for freeware as far as i can tell and nobody i know says something like "Freie Software" instead of "free software" or "kostenlose software" instead of "freeware" but that might be caused by my circle and is more often used then i recognized :)
I would not be where I am without my involvement in OSS or other projects, mostly due to the gained experience. The "trick" about putting it on your resume is, if it's significant, to make it not sound or placed any less worthy than any other experience on there (possibly also avoiding terms like "free", "personal", etc)
I noted in another response, but will note it here as well:
I've had some challenging discussions that have made me rethink how I solve problems, and have resulted in deep dives that I would otherwise not have made. ultimately, that helps me, not just those using the software. so, there's a net positive that's sometimes overlooked.
I maintain a small library of additional classes for JUCE. I was paid to make some improvements to some of the classes that turned into a small consulting gig.
All my consulting work is JUCE based, so having a library of my work is helpful. But what I do is a very niche field. I don't know if this would apply in general.
One thing that helps is simply not engaging with tiresome people.
I ignore painful questions and let someone else on the mailing list answer.
I make requests once in code review, and then ignore that PR if there is tedious argumentation.
I kinda have a similar situation. I upload my hobby projects on GitHub. It has about 90 repos by now. Most of them are just garbage that no one looked at. One of them amassed about 3000+ stars over time. People keep sending me numerous pull requests, but I'm very picky about the coding style and I pretty much ignore all of them. I also ignore most issue reports and feature requests because I'm not interested. Some people asked to hand over the project to someone else, but even picking a good person is a huge hassle to me. So I just left the project pretty much dead as it is. Still, it somehow keeps getting more stars.
Am I a bad/irresponsible person? Since anyone can fork the project I don't think I'm doing disservice to the community (whatever it is). Also I'm frankly a little annoyed that I am getting this by just using my personal repo and mostly being passive (I've never promoted my project anywhere, except uploading it on PyPI).
Edit I can see that there would be a moral issue if I used my GitHub creds for my personal gain (such as applying for a job). But I've never done that. Again, I've never asked for this and I just want to play in my sandbox.
I maintain a few very different packages, and have had some good experiences and bad experiences. What I maintain ranges in size and complexity from Javascript libraries, database add-ons, and virtual synthesizer modules.
I've dealt with hostile users, and hostile packagers, but ultimately I've stuck with it due to some quite incredible challenges and communications I've received, ranging from very difficult problems that they've reached out for help solving, causing me to rethink some solutions, to very nice notes asking if it's ok to use software that I released as building-blocks (what it was designed and specifically licensed for). But, there are still those people that I dread hearing from, that make me want to just stop -- thankfully there are enough of the other kind, and interesting problems, to keep me going.
As for donations - I have only put donation links on the virtual synthesizer modules, and have received a grand total of $5, not exactly game changing, but worth a pint of beer.
So, I maintain for another day, maybe not as actively as some would like, but at least at a level that keeps me from burning out on it.
Having worked on commercial applications with freemium models, I’ve had the distinct impression that the free users are more demanding and pushy and rude than the paying users.
I’m not certain about that though, because there are always like 10x or more free users than paying users, so the volume of interaction with free users is simply much greater. It would be interesting to study and find out whether free users are more entitled than paying users, statistically. Anyone know if such research has already been done?
These "problems" are not specific to open source projects: Whenever you provide a service of some kind, very few people will thank you, most will just use it and another very few will be very vocal about where, how and why you are an incompetent idiot who is just waiting for their advice.
But the "problem" really does lie with you if you cannot tell people they got what they paid for (in case of pro bono work, like FOSS-development, even more).
Once upon a time I organized an annual pretty large demonstration for the legalization of Cannabis in Europe. After every event, at the first meeting, we had people show up who understood we desperately needed their advice. You can either let them hurt you or you sit back, light up and play ping-pong with them... Listen 10 minutes, then spend 10 seconds to confront them with reality (actual laws and regulations, the practicalities of your work or simply your experience of actually /doing/). It can be fun.
But wether it is fun or a dreadful experience is only defined by you.
I organise the yearly family Christmas gathering back in our village whenever I am in my home country. The deal is that every working adult is supposed to contribute a few dollars towards food and drinks. It really isn't much money. Everyone is supposed to chip in, in whatever way they are comfortable. No one is paid to attend and no one is forced to attend.
Back to your sentiments, the amount of nonsense I have to put up with from some family members is unbelievable. Luckily there are some good family members who usually step in and put them in their place. So yes people are a problem, even our own family members give us problems. I still organise get together and ignore the naysayers.
FOSS, in my experience, will not make you money, will not get you a job, and will gradually suck up more and more of your free time until you have none left.
In can also be tedious and frustrating, especially dealing with users.
Usually if any money is made off of your labor, it's made by other people, and they never contribute any of it back.
> It means you are trusted. It means you are trustworthy. It means you are skilled enough.
It means those things to the org that made you the maintainer. It means nothing in particular to the users, bug reporters, and people who offer up fixes and features who don't already know you.
> If you are open to review other people’s contributions, there is a high change you will find challengers disguised as contributors.
New devs making a first-time pull request typically do not yet trust a project's dev process. They also realize that the project has no way to trust their own skillset. To break the stalemate the new dev typically "oversells" their patch set and errs on the side of TMI to the point of being defensive.
Doesn't it fall to the maintainer to keep things positive, clear, and on-topic in such situations? If the org takes that as a necessary skill of a maintainer and mentors to it, it's at least possible to have a decent experience as a maintainer. If not, then I speculate any maintainer would interpret those skills as out of scope for project maintenance.
I also speculate they'll interpret each "challenge" as a distraction from their duties and steadily progress toward an increasing likelihood of burnout.
I am running a free job posting website (postjobfree.com).
Every day I receive about a hundred emails with various requests, questions and complaints (from recruiters, job seekers and operators of other job boards).
Some of these emails are negative or even rude.
But that negativity does not really bother me. I evaluate level of "Negativity" in the email to understand the nature of the request better (Is the request realistic? Is the request fair? Could our team realistically prevent that negativity in the first place?)
Requests like: “How dare you not (use your free time to) fix this ultra high priority bug that is affecting me?” -- I do not even consider negative. In fact, that is a positive comment to me, because it may indicate an opportunity (to make our job board better or to even add another revenue stream).
The complainer in such case already did some of the work for our job board: identified potential problem, described how to reproduce it, defined the use case explaining why fixing that problem is important.
If that is not helpful feedback, then what kind of feedback is more useful?
Even though bad faith criticism and complaints can be useful, I find there is a still an insurmountable problem sometimes: it can be too time- and energy-consuming to handle the sheer quantity and/or intensity.
Sometimes, especially at "political moments" (like elections in a project I was involved in recently - and I wasn't even a candidate), it can feel like being overwhelmed by a tidal wave.
If I only have 1 spare hour per day for a project, there is neither time nor emotional energy to handle emails that are so full of demanding questions that it would take 3 hours to process carefully and reply carefully. And if you don't reply carefully, they send you more, writing longer and getting more obsessive (and sometimes personal) as if they sense you'll engage them in a long conversation, so being careful in the first place is a net win.
Even if it only took 1 hour, that's still used up all the time I was going to use on other productive things, the "real work".
I am in awe of maintainers who seem to reply to an onslaught of demanding questioners, and somehow satisfy them.
> If I only have 1 spare hour per day for a project
... then your project is unlikely to become useful anyway. 5-7 hours per week is just too little in order to make a meaningful progress in a software project.
And if you are not getting critical feedback from customers, you are unlikely to know the right direction to develop your project.
According to Donnie Berkholz' definition - I do not communicate with assholes at all, because demanding and even rude feedback does not make me "feel oppressed, humiliated, de-energized, or belittled".
"FOSS maintainer" uses similar "fremium" model: basic product is free, but customization and support of that product typically requires to hire maintainer.
Alternatively, maintainers are getting hired by BigCo for brand recognition, improving hiring competitiveness of BigCo and other benefits that FOSS product brings.
""FOSS maintainer" uses similar "fremium" model: basic product is free, but customization and support of that product typically requires to hire maintainer."
Not really. With FOSS the whole product and especially the sourcecode, is free.
You can "maybe" hire the maintainer to do extra work and support for you, but you don't have to.
And the main point was, that this maintainer(and most others) did his work in his free time, not out of comercial interest, but altruism. You are doing your website out of altruism?
I doubt it.
I definitely appreciate every free software maintainer out there. Hats off for your hard work.
What I appreciate a bit less is a burnt out maintainers that does not ask for help and has his hands full. Hats off for your hard work, we use your library and we want to help. You are not alone.
What I dislike is a burnt out maintainer / not so great person of multiple important libraries of a popular language that randomly closes issues and PRs without explaining the reasons and then blocking people once asked why he did close an issue that was still relevant.
If it's a personal project open sourced, sure, you have the absolute freedom to do whatever you like. If it's a multi-maintainer project that has a huge piece of the market, then that's absolutely not okay - it causes a toxic environment that only damages the library and it's future.
My advice to other OSS project maintainers - unless you are paid to do so in a 9 to 5 job, just walk away. It's not worth the aggravation. I just woke up to the fact that the majority of my self-entitled users were working for multi-billion dollar firms and they were not contributing a line of code or stitch of documentation. With a handful of exceptions, you can't make a living off of open source alone. Patreon and OpenCollective is a great way to make coffee money.
>I just woke up to the fact that the majority of my self-entitled users were working for multi-billion dollar firms and they were not contributing a line of code or stitch of documentation. With a handful of exceptions, you can't make a living off of open source alone.
And those multi-billion dollar firms will show no greater willingness hire you, despite relying on your software, which they also won't pay for.
> There was sort of like this unwritten contract in open source that we had; the unwritten contract with corporations was if you wrote open source that they were using, you got some sort of job, or consulting fees, or at least some respect so that way you could find jobs.
> ... I started to realize that “No, that contract has completely been rewritten. It’s totally different now. If you write open source, you’re not gonna get a job”, and now what’s been happening - and part of my tweet storm and whatnot about open source - is that it’s gone the opposite direction, where what I see is sort of like almost direct action to prevent open source developers from making money…
Completely not proven yet, but I'm convinced: ask for it. Make it easy for people to pay you. Find a way (and reason) for people to invoice you for payment. Tell people that you expect payment even if they don't legally have to pay. Make it part of the "community ethos" that payment is a natural and good part of working with the community.
Free as in freedom, not beer. Ask for beer and give freedom in return.
I have this idea in the back of my head. Where I live in Japan, in the countryside they just put up these vegetable stalls. Nobody is there. There is a box and on it is say "100 yen" (about 1 dollar US). There are bags of fruit and vegetables. You take a bag and you put a 100 yen coin in the box. Not rocket science and nobody who isn't starving won't put the coin in (and if you are starving, take the damn fruit!)
You don't need leverage, you need it to be the norm that people pay for the software. That requires a cultural shift. Luckily, community cultures can be crafted (I think... maybe I'm wrong). People need to feel that if they pay for the software, you will make more (which they want). If they don't pay for the software, you will not make more (which they do not want). I think that's all it probably takes to earn money at this. I think... One day I'll test that theory.
While this is how it should be I find reality to be a lot different. The cultural shift required is so massive that I don’t think it will happen anytime soon, if at all. People have become accustomed to open source software. Critical infrastructure which is free. This is again drilled as a point, that software should be free, by the consumer software. Google and App Store have destroyed any resemblance of rationality in pricing software products. People expect stuff to be free (ads and stuff is fine, the really obnoxious people will block even those) or if not free, they expect a rock bottom price. People argue for software which costs 5 USD and some irrationally expect it to be cross platform, high polish and the dev should respond within minutes. Trying to sell software these days has become a harder argument especially if you are not able to quickly deflect these massive hoards of price-complainers.
This is the case for consumer software. I am not even trying to imagine how harsh it would be for an open source maintainer - who has absolutely no leverage given the source is already out there. What’s happening with docker, elasticsearch, Redis, MongoDB et al is not giving me hope either.
Open source projects are good at convincing their users (other developers) that they provide value, but developers are not yet very good at advocating for that value up the chain. I think the key to developer-driven enterprise SaaS is teaching developers to advocate for the value of their tools. Other departments do it very effectively, and it has the beneficial side effect of raising the employee’s status in the organization.
There's definitely a startup opportunity for this - making it super easy to receive payment as an OSS developer (either as a business or sole developer) and making it easy for businesses to pay.
If I saw a new issue on github and it came from a corporate "OSS gold account member" which potentially comes with $$$ attached I'd be much more inclined to implement it.
As it is my motivation drops off fairly quickly unless it's a serious bug or it's a relatively easy ask.
I think it would be much easier to get budget if the cost to get expedited OSS bugfixes were subscription based and accounts gets to deal with a professional billing department rather than "One Man and His Hat Inc. in Iowa".
This could be a part of GitHub. Imagine there was a '$' button beside the star button, and each time you clicked it you gave one dollar to the maintainer of the repo, with a counter beside it. The '$ counter' would only be visible to the user and the repo maintainers.
GitHub is the de facto hub of open source/free software, and if it was as easy to donate to a repo as it is to star it, I imagine more people would do it.
"Daniel Pink's new book, Drive, in which he highlights the rather stunning amount of counterintuitive research that suggests that money can actually make people less motivated to do creative works."
- Ask commercial users to pay a fee (still voluntarily though)
- Offer yourself as a consultant on the software, you can help businesses with implementation or migration.
Of course, there is a thin line. Having people to pay for your software raises expectations. Also, paying customers could steer you into a direction you (or the FOSS community) don't like.
In my experience, almost all businesses are perfectly willing to pay for the software that make their business possible. Businesses understand that FOSS is free speech, not free beer.
One serious problem with most of OSS libraries is that, no project will tell you, what's the upsides and downside of the project, or the things the project could do and couldn't do. So, most of the time, the user must spend serious efforts to evaluate if it's OK for them or not.
Of course, this is hard and often not reasonable to do. But at least, let's do things based on some assumption.
You need a thick skin to maintain free software, and that's not something that you can grow... either you have it or not. It's not for everybody.
The biggest mistake some software maintainers make is showing empathy for abusive and unreasonable users. Most of them simply deserve to have the door slammed in their faces. If you can't do that, then you'll lose your time and stress yourself.
Having empathy for people who are trying to engage with you constructively while denying it to those who are wasting your time is both very important and incredibly hard, in any circumstance.
> deserve to have the door slammed in their faces
Totally, but you need to (try to) be careful not to slam it in the potentially-helpful peoples' faces. There's one very popular open project that I've moved away from due to getting tired of seeing seemingly every single question/suggestion being met with "you don't like it, start writing some code".
Not to say that my decision not to use that project is significant in any way. I'm just one anonymous person. Just a point that it may be possible to be too aggressively self-defensive.
I totally get that I'm not entitled to anything, and you (maintainer) are entitled to do what you choose with your time. It's just that constantly, repeatedly pointing those facts out isn't going to win you much cooperation.
One of the things I've started to wrap my head around lately is the essential inhumanity of technology. It's a near-daily occurrence of mine to having to deal with something that's just plain dumb, and just have no way at all to fix it. I can't make the system better, I can't make any kind of suggestion to anyone so that my situation won't come up again.
There's nothing to do but to just accept it, put whatever workarounds I can come up with in place, hope I can remember what I did before the next time it comes up, and move on. It regularly moves me to anger, with nowhere to put it. It's not fair to unload it on your coworkers or your manager. So I'll vent a little bit, still trying to find the best way to do this, and just hope I'm not a raging alcoholic by the time I'm 40.
But I'm a skilled tech worker whose getting paid very well in order to deal with these things. If they're not just douchebags, I would guess that most people who get unreasonably angry at OSS maintainers are not getting paid very well to deal and are likely the target for generated externalities. They need a focus, someone to hold responsible.
But tech is inhuman and so there is no one to hold accountable. And if ever there was someone to hold accountable, by God get rid of that chink in the armor! The OSS maintainer thus becomes that chink.
I sometimes wonder if the brave new world that the West is building is not the great horn of plenty that we all believe it to be, but rather a monster that consumes the best parts of us and spits the rest out, too cruel to just put its victims out of their misery.
Then I remember that inhuman bureaucracy is nothing new, and pour another glass.
This reminds me of the author of libcurl saying that he gets a ton of emails from people asking about their cars infotainment system, because when they try to find an email address to contact for support, the closest thing they can find is his address in the libcurl license text:
This sort of thing seems to hit senior citizens harder because of their general unfamiliarity with technology. So they use the toolset they're familiar with, to find somebody to get on the phone to make them deal with the problem.
I'm tempted to take vicious glee in the notion that this is the comeuppance Baby Boomers are getting for selling future generations down the river to fund their own retirements. If they could have just shared the post-war wealth equally their children wouldn't have needed to destroy the world that made it.
Your comment brings to mind a passage I highlighted years ago in Robert Sapolsky's Why Zebras Don't Get Ulcers:
Stress-induced displacement of aggression: the practice works wonders at minimizing the stressfulness of a stressor. It’s a real primate specialty as well. A male baboon loses a fight. Frustrated, he spins around and attacks a subordinate male who was minding his own business. An extremely high percentage of primate aggression represents frustration displaced onto innocent bystanders.
I think you're right and what's tough is that the impulse to unload on someone seems to be hard-wired and even salutary. I have to catch myself from doing it and even then I'm sure I'm a regular source of microaggressions.
I think to a certain extent bureaucracy, humane bureaucracy, can be a corrective to the bite-your-subordinate instinct. But I agree there's nothing so effective at generating find-me-an-innocent-bystander-to-swipe-at fury as mindless ineffective bureaucracy where the architects of it are hidden and unaccountable. And, as you point out with technology, it's very easy to slip into regarding that third-party service your company signed up for or the open-source library you downloaded after glancing at the README -- when it doesn't work as expected or you promised yourself it would -- in just those terms.
Maybe someone could start a Punching-Bag-as-a-Service platform to collect and safely dispose of all this displaced aggression. Is there a good online screaming pillow where I could direct myself and others in these moment of impotent rage?
At my last workplace, I used to deal with it by simply getting up and taking a walk. A total context change is probably the best way to cope. Take a good half hour and get some physical activity. Ping pong was helpful too when I had access to a table.
A service is unlikely to work because anger requires immediate release when triggered otherwise it's repressed. Repressed anger builds up and makes the next outburst worse. I believe that the "lives of quiet desperation" described refer to anger that's continually repressed with no outlet.
There's a seeming epidemic of burnout in tech that I think is driven by this dynamic. I've seen people start jobs and almost immediately start exhibiting symptoms of burnout. The inhumanity of tech builds up and every little thing builds up.
I don't get burned out. I think this is because I'm skilled at managing my emotions. But as I get older my tolerance for repressing anger to release it in a controlled explosion later when nobody is watching grows less and less. And my jobs get more and more visible. I'm not sure how much longer I'll be able to stay in this career.
Now I'm curious about what you have read lately. The Technological Society by Ellul was a good start for me.
Yes, there's a lot of wishful thinking and religious zeal out there, helped by the modern "we can f* up your brain and you won't even notice it" techniques. It seems to me you can spend your whole life developing some free software which gets used, among other things, to create tons of money for other people. Makes you wonder (at least it makes me wonder), if this whole thing is not meant or at least supported by the good guys and girls who know how to make a buck and can convince even your granny to learn html because knowing how-to-web it's the new literacy while the purpose might be no other than "not even third-world countries want to work at boring websites, so we have no one to do the dirty work now. How can we convince some poor souls to do it, and freely too."
I'm really interested if you have something in the department. A nice article, a good book, something that can be used to wake one from it's slumber.
The Bible. Wish I could offer something more accessible. But a better read on the nature of hells, belief, faith, false gods, and how to find a true path to salvation can't be found. Haven't picked mine up in awhile. Should probably fix that.
I spend my time these days writing rather than reading. Chasing my own muse. Quora is my usual outlet, though I'll occasionally feel compelled to comment on HN.
You may find Om Swami's books interesting and accessible in modern time to understand the potential that each one of us carry for mystical enlightenment. For instance the book on kundalini: https://www.amazon.com/Kundalini-Untold-Story-Himalayan/dp/0...
>>> Kundalini is your polar opposite within you. When it awakens, you realize how immensely powerful you already are. You experience how there is a whole universe within you. It is your feminine energy if you are a man and your masculine energy if you are a woman. It is your passage, your path to eternal fulfillment within you.
>>> when you start meditating on the chakras, it is only from your experiences and newly gained abilities that you come to know that a transformation is taking place within you. The greatest transformation upon the awakening of the kundalini is not that you see blinding light (although, that can happen and has happened to me on numerous occasions) or you feel feather-light or you feel highly energetic. These are epiphenomena. This is not the real product; it’s more like buttermilk than the actual butter.
The real transformation upon the awakening of kundalini is that you shed your old tendencies and negativity like a snake sheds its
old skin. You no longer feel angry or flustered over trivial matters unlike the earlier times. Your emotions and thoughts don’t overpower and trample all over you anymore. You begin to gain control of yourself. ‘Supranormal’
streams of creativity and energy gush forth at the awakening, surprising even you with talents you never thought you had.
>>> Awakening of the kundalini is reaching your innermost state of bliss and joy. This state is covered with ten layers – desire, anger, greed, attachment, ego, passion, jealousy, hatred, fear and selfconcern.
As you elevate spiritually, you start shedding these layers. These avarana, layers, veil the true you. The real you that is beyond the duality of pain and grief, good and bad, moral and immoral. Awakening is a steady and gradual process on the path of kundalini sadhana. It is not an instant realization. It builds up, it grows on you. With each level of awakening, you discover bit more about the new you and you shed bit more of the old you.
>>> Awakening of the kundalini is realization of your pure abstract intelligence, the type that is not conditioned by your fears, emotions and worries. It is your pristine nature. When you are able to tap into this latent source of energy, you truly become the master of your universe. You can manifest whatever you wish in your life because your scale of consciousness is no longer limited to your body alone; it envelops the whole universe.
>>> What’s even more beautiful is that anyone who is willing to put in the effort can experience it.
Having wasted a significant portion of my youth on said book I would not recommend it. The whole thing boils down to devoting yourself to a (IMO) demanding, bigoted, homophobic, and imaginary being.
Whatever crumbs of truth (treat others like you want to be treated, life is short, etc.) included are better expressed elsewhere and without all the baggage.
That's why I said I wish I had something more accessible. Unless you already have the penchant for belief the Bible is just going to feel that way. It's an ancient text written for ancient peoples.
You need a map to the Bible in order to really understand it. I like YouTube videos, and the best ones I've seen on this topic are the ones by the Bible Project.
And they only feel like crumbs because we've spent the last 2000 years building a society based on those ideas. But they were new and shiny at one point in time. Just like tech is new and shiny now.
As an ex-Christian, I can still offer a more charitable view: just read the Golden Rule, love your neighbor as yourself, practice virtues of Galatians 5:22-23, and read Proverbs. That's the best parts of it that even a non-religious, utilitarian society might want to keep. The Christians I know that practice what they can of those values with less focus on judging people are among the best people I've ever met. They do more good and less harm than average person.
So, there's good takeaways even if there's lots of bad stuff in there. I'll throw in Buddhism and Confucianism given they have some good advice. As always, keep the good tossing out the bad or questionable stuff.
Having wasted a significant portion of my youth pursuing whatever I wanted only to later realize I was enslaved to the very things I thought I was pursuing freely, I can wholeheartedly recommend the Bible as that which gave me true freedom.
Many of it's teachings are certainly counter-cultural. And it does take time and effort to learn and interpret wisely. But I find much in the Bible that is very applicable to life today and, arguably more important, applicable to the life to come.
As for the imaginary part, there are plenty of rational reasons to consider the claims of the Bible. This isn't a bad start:
A lot of it boils down to your own personal presuppositions and worldview. For more advanced treatment that gets to the heart of how we know what we know and how our presuppositions affect what we think we know:
> A lot of it boils down to your own personal presuppositions and worldview.
Maybe. But my early worldview was shaped almost entirely by Bible believers. Now after thirty years my perspective has changed. And it's hard to see value in evaluating the world from ideas and testimonies that cannot be proven, especially those that condemn those born different.
Eh, this goes immediately into what parent is talking about. "Love one another" comes first only according to one of the four tellings of this scene (John's). The other three say that loving "the Lord your God" comes first.
It's a lot more than a hierarchy of "love God, then perhaps others if you have anything left". Here's the context showing the tight coupling between human love and divine love:
We love because he first loved us. Those who say, "I love God," and hate their brothers or sisters, are liars; for those who do not love a brother or sister whom they have seen, cannot love God whom they have not seen. The commandment we have from him is this: those who love God must love their brothers and sisters also.[1]
Elsewhere there's the commandment to "love as I loved you", i.e. love others to the point of dying for others. The standard set is incredibly high and hard—hence the Saints, whose lives & sacrifices are commemorated for their selflessness despite other struggles and failings.
The actual theology is pretty beside the point here. Really, you're just reinforcing the original observation that paulryanrogers made, which was that getting moral or ethical guidance from the Bible, as a non-religious, requires slogging through many layers that only apply to believers.
>You may not feel the joy of working on what you work anymore. You may want to move on. You may also not do that due to the sense of responsibility that you have to your code, your community, and the people who use your software.
I run a popular website, and I switched from selling books, to free content.
I make 6 figs at the day job, but put in 2-3 hours a night on figuring out new ways to save time or save money. The occasional email is nice, but its a very temporary feeling. I consider it my responsibility to society, so things will be free, but it also means only 1-2 people study this.
I use a lot of open source packages, and I’m immensely grateful to anyone who maintains one.
I also want to mention that I donate whenever the option is available.
However, here is my personal opinion that will most likely get downvoted to oblivion: if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it.
In my opinion, it is irresponsible to release something, anything, and then abandon it.
If you don’t want to be responsible for it, for example if it’s a hobby project or something, keep the repo private. If you release it with the intention of maintaining it, and your circumstances change later, do your best to find another maintainer.
If you want to charge money for it, do that.
But if your attitude is gonna be “I’ll work on this when I want, however much I want, and you should just be grateful for what you get and deal with it” then, well, that’s where my sympathy and respect for you ends.
I think I understand you completely, but I also think I know why you were downvoted. The problem is the implied promise of having a software project page on something like GitHub with descriptions, documentation, etc. This, in my mind, and probably yours too, implies a promise of future development, maintenance or at least security bug fixes. When such things are not forthcoming in a manner one might reasonably expect, we feel as though we have been cheated out of something we (rightly or wrongly) feel was promised to us.
Maybe what would be useful would be some standard (and required!) marking for all software projects on what the current level of maintenance is. Is it
Level 0. I wrote this in an afternoon and have no plans to ever look at it again — use at your own risk.
all through
Level X. This project is under active development and also has maintainers for a stable branch, which also receives security bug fixes in a timely manner.
In short, what I think is actually irresponsible is for projects to look like they are close to level X but then have maintainers behave like they are at a much lower level, and who think that any level of behavior is OK since they don't get paid and haven't personally promised anything. It would be better for all involved if the expected (approximate, of course) level of maintenance could be explicitly announced – this might make it clear to users what level they can expect, and make it clear to maintainers what level of involvment is expected of them to be able to call themselves “maintainers”.
> if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it.
I think there's also room for software that's dumped on the internet like a free couch left on the sidewalk, but it should be treated similarly: probably full of bugs and not worth your time. I agree that software maintainers shouldn't feel entitled to gratitude without obligation.
So the article writer became "maintainer" by virtue of being something like "the only person that currently cares". Should they have rejected access to the code and ceased contributions at that point, to not be irresponsible years later?
They might have taken over the role of maintainer, but if the level of involvment which the project required was too much for them, it would have been their duty as maintainer to declare the project moribund until a more active maintainer could be found. To keep the project active and looking alive is to mislead users and implicitly promise a level of support and development which they know they cannot uphold.
Sometimes I open source small libraries. When I get feature requests, I have replied that "if you have a budget, then I'm willing to talk about the price for this feature".
Does that fit the level of responsibility you require?
I don't understand the downvotes for this. I feel that by making something public and open source, there is an implicit assumption (unless otherwise stated) that the software is worth sharing.
The problem is that this puts what I consider the right amount of responsibility squarely in the middle of a continuum: library authors shouldn't be totally free of obligations to others, but the insane abuse that people level against open source maintainers is also obviously unacceptable.
I disagree with the idea that software is only worth sharing if it is updated. I've found plenty of value in code that hasn't seen a single commit after initial release. I'd consider it a bad thing if the people that made it available to me got shamed into not publishing it.
Was the value you found use-value (ie. the software did something useful) or was the value to you more along the lines of "instructional" (ie. you learned something useful from studying it)?
Because I've found that use-value often decays (or bit-rots) pretty quickly in unmaintained software, sometimes due to nothing more than changing packaging requirements.
Mixed. I guess most often library code that I integrated into my own projects, often by copy-paste instead of adding the entire project as a dependency. But I also have a folder full of random small utilities that I keep moving between my windows machines, and often is useful for years before it fails (Windows is probably more forgiving in that regard and provides a more long-term stable platform for existing binaries)
This rule accepted in general would mean that all students who put their homework on github are doing something wrong.
Or that all professionals who just play around technology or mini projects are required to keep them secret until they are totally sure they will maintain it forever.
That is just not workable and overly limited.
While owner can not expect gratitude, the "I’ll work on this when I want, however much I want, and you should just take it or leave it" is absolutely fine and should be fine. Just because it exists on the internet does not entitle the rest of the world to anything.
Unlike what you seem to indicate, projects do imply a level of expected support and continual development by their projected image as given by their web pages, documentation, etc. If a developer/maintainer does not uphold this implied promise, users have a right to feel bamboozled.
This really shouldn't be downvoted, as it is a valid stance (one I don't share, BTW, or not much).
Human social instincts strongly push toward this position, informed (largely) by metaphors and similies rooted in excludable goods even when nonrivalrous (eg. the prototypical Commons).
Software, though - and most especially Free Software - is part of another realm entirely, or at least verges on it: Things that largely grow, proliferate, and spread themselves, even if they do it through coopting human agency. Examples are stories, families, communities, ideologies, movements, hobbies, cultures, and most importantly, individual humans themselves.
"If you save a life you become responsible for it" is one of the few succinct ways this has been expressed, which of course doesn't do much to delineate the obligation or its limits. But the sentiment is clear.
To what extent can an author (of fiction or non-fiction) disclaim responsibility for their work if it takes on a quasi-life of its own? An artist for a work that is misappropriated?
How difficult is it to disavow a family that you have broken with? An embarrassing ancestor who accumulated the family fortune through unsavory means? A child that has grown to become a notorious public enemy?
Can a founder of a movement disavow its extremist fringes?
Does a celebrity actually have any responsibility at all toward their fans?
How difficult is it (or should it be) for a hobbyist to avoid being associated with those who share their hobby, but who also make the hobby unwelcoming to the Other?
By now you must have a dozen objections to this post, of all the ways writing software is not like these things I've mentioned, but there is also something deeply similar, though it is difficult to articulate exactly what that is.
An author of software, and more precisely a maintainer of software, is responsible in some sense for the nebulous thing that the group of people that software draws together is, even while also being a member of that same group.
That the responsibility does not necessarily create much of an attendant obligation is not necessarily clear, when so many social customs are predicated on such obligations being implicit (at least).
Even less clear is the extent to which such obligations, when voluntarily assumed, can then be discarded.
An analogy may be helpful here:
Having moved to a new city, and subsequent to joining some existing social group or club, you volunteered to take care of some aspect of a shared recreation (to bring the salad for a weekend picnic, for example), but you then discover that there are additional logistical and even financial costs involved that you didn't anticipate (the picnic starts much earlier than you're used to, the group includes many vegetarians and vegans who are used to having an extensive variety of salads at such occasions, etc.).
So, having voluntarily assumed this obligation, but not having given what could be objectively called fully informed consent, to what extent are you still responsible for addressing the expectations of this group (as a group, and also as individuals) you're now disappointing?
And how do the analogous obligations change (and grow) when you are (effectively) the founder of the group?
This morass of interpersonal relationships is the sort of thing that being a software maintainer requires navigating, and the situation isn't made simpler just because the central artefact the group revolves around is some non-excludable, non-rivalrous software that is being created and maintained, especially when the name attached to the software is just such a rivalrous good.
Disavowal of otherwise implicit responsibilities and obligations is something that seems to crop up more often in recent decades than previously, from IANAL and TINLA (or even IAAL, But Not Your Lawyer), to the increasingly commonplace "I Do Not Speak For My Employer".
Such disavowals being (apparently) necessary, authoring and maintaining software clearly also strongly implies at least some responsibilities and obligations, at least as a great many humans perceive things, and it is worth discussing just what those are, as well as when and how to effectively disavow them when not appropriate.
As I said at the outset, I personally feel the set of those obligations is smaller than the parent post states (neither software nor the community that forms around it is something that you are obliged to actively nurture), but my disagreement doesn't imply a downvote. It is a valid contribution to the debate on this topic.
At some point the pressure from the community made me pass the magical threshold between fun/useful/rewarding and downright chore.
It has permanently changed my perception of OSS management, to the point that I stopped releasing further projects, no matter how small, simply due to the work that these entail.
Just look at the discussions you find here monthly about being "a good author/maintainer/leader", where most expect full documentation, professional landing pages, useless code of conduct, and so on... BESIDES the project itself. You'll be criticized irregardless.
I have deep respect for the maintainers of popular OSS projects because of the amount of s*it they must take. I know I wouldn't do it for free at these scales. I also wouldn't do it besides another job since it is so demanding.