This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly entitled users that saps whatever morale and energy you have left. Probably best he did not include that though as that is what all discussion would be about.
I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them.
Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.
Following up on my previous comment, I managed to never become fully burned out, but it required changes to myself, not the project. I had to become less emotionally invested in the project, realize I could not solve everything and step back a bit and do some other things. I guess it would be great if the project were reinforcing these ideas to its contributors to prevent burnout, but that also does not seem realistic. And "the project" is made up of others going through the same problems.
The large OSS project I contributed to thankfully had other contributors that were good role models for these behaviors and it helped seeing them disengage to do other things for a while.
this is a wonderful comment, thank you for writing it <3
i am trying to model these behaviors; this post was primarily intended for other people working in the project. i feel pretty strongly that this is a cultural issue moreso than an individual one. i have seen too many of my friends burn out to say it was all their fault individually.
> This is a good description of what life is like working on almost any significant open source project.
Open contributions project.
An open source project does not necessarily have to accept random contributions, issues or hatemail from the general public. [1] They just need to make the source available with a permissive licence, period.
I believe that Linux with its idiosyncrasies in its communication model (mailing list vs the ease of Github, strong dictator running the show) works as a great filter from entitled users, and that's an underrated feature in open source. See also sqlite.
---
1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.
- Source available or not
- Open source or not (a subset of source available)
- Open contributions or not (also a subset of source available)
- BDFL or community driven
That's a lot of variation and may explain why so many conversations about open source sound like people are talking past each other-- they're talking about different kinds of projects!
PS: Regarding:
> 1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.
I wish there was a standardized way of declaring this, I always feel so awkward writing the "no PRs" disclaimer on my toy projects.
> That's a lot of variation and may explain why so many conversations about open source sound like people are talking past each other
Most of the discussion is people suffering through GitHub-style social networks. I don't see a lot of people talking through each other, as much as I see people assuming this is the way, and others pointing out it's just one option.
At some point we have to acknowledge that GitHub is a toxic social network. The toxicity is way more hidden than Facebook and others like it, but it's there too. Every universalist social network is toxic.
GitHub is absolutely toxic which is why we develop on GitLab instead. The reduction in the slowly creeping "social features" and non-existence of drive-by activism is great.
Gitlab's approach to the problem is making every UI redesign even worse than the one before, so people have to click through 3 menus just to file an issue.
The latest redesign is egregious to say the least.
I strongly believe GitHub has the same dynamics as most "big tech social media". Where anything that drives "engagement" gets prioritized. From algorithms that make alt-right/neo-nazi's more visible because the controversy drives "eyeballs" to features that are removed or never implemented because they would lower engagement.
I'm confident that GitHub has a good prediction on what will happen if they roll out features that lower the burden of maintaining a FLOSS repo. And am rather certain that several of these features also lower the engagement. And therefore will not be implemented. In other words: the needs and goals of GitHub/MSFT and those of Open Source maintainers don't align perfectly. Yet the power balance is way off, so open Source maintainers will experience pain to a level that they almost walk away in great numbers.
It would be a baffling decision for GitHub to make any product decisions based on engagement. They don’t even serve ads, what benefit do they have to an engaged user?
Engagement isn't just driving ads. It's driving engagement: The "toothbrush"-factor we called that in app-development: do you have an app that people pick up like their toothbrush: without much thought, several times a day?
Engagement means people have you in their workflow, on their radar. I would love it if Github is something that I don't have to think of, that is invisible and out of my mind. I'd love it if it's something I never have to visit, open, see or interact with; as as little as possible. I'd love it if it were preconfigured to take work from me rather than impose yet another inbox, timeline, bookmarks, "likes" and so on.
And if you consider "advertisements" very liberal, that's exactly what Github is: a place for companies to attract eyeballs and engagement on their software.
Because the known system effect means that the more arbitrary developers engage with them, the more likely it is that at least some of them will drive corporate adoption and, by extension, sales.
Why is it a given that GitHub slowing me down by making me engaged with the site more, will make me spread more word of mouth/etc? Everyone in this thread is just assuming a link here, but I don’t see it at all.
GH annoys the shit of me by making me click more shit to get my job done, it “increases engagement”, and then… what exactly? My annoyance is supposed to lead to me… thinking about GitHub more? And thus I’ll pressure my org to use it?
This makes no sense. I hate engagement-based metrics as much as the next person but I’m not sure MS is as brain dead as to intentionally make the UX worse, to make engagement higher, and assuming that will somehow increase sales. There’s no link here.
I'm not saying MSFT is intentionally frustrating you to increase sales.
But that, where engagement drives sales, your frustrations are disregarded.
They are different links.
MSFT could easily build a toggle to disable PRs (default, enable PRs). They have these toggles for all other features already.
They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.
I merely take that a step further: there are quite certainly many features disregarded or not even conceived that would save a (small) group immense effort. Simply because MSFT has done the excel-thingies and knows that features that make people visit GitHub less often, are not positive to their sales.
> They don' build this, because, as many other commentors point out, the few people that would benefit from such a toggle, don't outweigh the amount of engagement, data, and usage it generates.
That makes no sense. Say I'm an open source project maintainer who doesn't want PR's in my repo. I have to continually log in to GitHub to check the PR tab and close all active PR's (or as others have pointed out, use a bot to do this, but that's beside the point: The discussion is about why this isn't a built-in feature.)
What value does Microsoft get out of the "data" generated by me having to continually log in and close PR's? "Yup, people who don't want PR's on github log in a lot to close them". Why is that valuable? We keep talking about engagement as a thing but nobody's explaining why it matters at all for MS. "Engaging" me by forcing me to open up the website to do mundane stuff doesn't move any of MS's needles. "Usage" goes up only because I have to keep doing this mundane shit.
Here's a VASTLY more likely reason why MS doesn't want to make it easy to disable PR's: Lock-in. Microsoft wants to encourage users to use GitHub for everything involved in software engineering, end-to-end. Because if you do so, leaving GitHub becomes a lot harder, because GitHub has your PR history, your issue history, and is hosting your wiki, etc etc. This is not the same thing as "engagement", it already has a term, and that term is "lock-in". (Apropos: I consider PR discussions to be indispensably valuable in finding out why some particular line of code looks like it does: Finding the PR that introduced it and looking at the discussion is a great way to find out the motivation of the original author.)
MS does not like users that purely use GitHub as a mirror and don't use any of the GH-specific features, because those users can trivially migrate their code to another hosting provider if MS ever decides to do something silly like charge them.
Engagement makes no sense whatsoever as a motivation to not let users disable PR's. Lock-in makes perfect sense.
It means they keep position as dominant Git forge, mindshare: people are most familiar with them, then think of them first for Enterprise contracts, are interested in other paid product/feature (Copilot e.g.).
Side benefit to overwhelming mindshare many people expect/require the other forge to have the Github feature: being different counts as negative. This reinforces.
It's enshittification. The same way LinkedIn is being turned into ...generic social media, GitHub is slowly being eaten away into serving some executive's delusions.
I would assume, in the context of Microsoft encouraging engagement (specifically the PR feature of GitHub), the more engagement they have the more code is put into their system, thereby allowing them more data to train Copilot and other ML models.
What makes it “obvious”? They tried to kill Linux and Open Source. I will never forgive them, and I sure as hell would never trust them not to try again.
This is a frankly ridiculous assertion given LKML's notoriously toxic history. Part of the problem is that overly-entitled maintainers can be as equally dangerous to actual progress in the project by stonewalling useful code on invented reasons that have never been applied to previous PRs and that the maintainer does not apply to their own commits.
Github marketplace has a close pull request action[1].
You also need to close issues after a set amount of inactivity[2].
If there is a bug without a CVE, or a feature someone wants fixed that users don't want to submit a fix for themselves AFTER it has been discussed with the maintainer in an issue with a replication or strawman proposal and the owner has created a draft pr and asked you to work on it, it probably needs to come with a Patreon donation[3]. This can help alleviate maintainer burnout by allowing the maintainer to hire someone to make the contribution.
A software shop wouldn't operate without some kind of iterative plan. Large open source projects with single maintainers shouldn't either. Scheduling 1 or 2 hours a week for issue triage, hosted in an online meeting, and limiting WIP in terms of open PRs to be discussed during this triage meeting should allow for both community interaction and strong governance for the project and prevent burnout for the maintainer.
All of this can be placed into the Readme or Contributor guide and a CLA that contributors have to sign.
Otherwise, people can fork and maintain the project themselves.
If you want to prevent flame wars, or demotivating comments, something like a comment sentiment analysis app[4] might even be a good idea to add to your project. There are plenty of models available that you can delegate to for this in the wild, and it's worth automating moderation to prevent burnout.
Finally, really toxic users can and should be banned[5]. It's not worth it to deal with anonymous negative contributors all the time.
The point is Close Pull Request shouldnt be an action. It's should only be a bool in some database column for project settings that turns off the entire functionality.
> Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.
Glad some said it. When things are too organised or categorised it just becomes another business/todo list.
The problem *is not the organization/categorization*. Any larger project is completely unsustainable if it is a disorganized chaos, with issues falling through the cracks because they can't be kept track of as the scope and team grows. These tools are a great help there.
The problem is this tooling is used for the wrong job.
If the only "discussion" about an issue is the bug report/pull request, that's wrong. That should be only the first/last step. Unfortunately, for many projects there is no other communication channel anymore.
So then people use what exists and is available - PRs and issues on Github. Which are both very poorly adapted to any sort of discussion. But if all you have is a hammer ...
It used to be that the first things a new project got set up was a mailing list, then maybe an IRC channel, perhaps a shared code repository (likely CVS or Subversion) and only then an issue/bug tracker (usually Bugzilla, Track) when the project grew large enough to need it. In that order.
This culture of project community discussion has been largely lost with the younger generation of contributors that don't use e-mail and many don't even have an e-mail account (or don't use it except for signing up for services). Mailing lists have been seen as "old school" and poor UX, so have been largely replaced first by silos in the form of web forums and then later by Discord, Reddit, etc.
All that makes it great and easy for anyone to come in and post something there (the signal to noise ratio is usually not great) - and absolutely terrible to find anything, to actually coordinate work of a distributed team or to track multiple busy projects. E-mail comes to you and can be automated - forums, Reddit, Discord, etc. you have to actively seek out, follow and manage. Poor project maintainer having to deal with that ...
There are good reasons why projects like Linux kernel still use mailing lists for coordination or even sending patches (!), despite the huge size of the project - it simply makes the life of the maintainers (i.e. the people doing most of the actual work!) easier.
Well said, this is what I was getting at as well. I think the barrier to contribution was too high in the old days, and that is where GitHub brought improvements, but it came with the loss of community. Everything becomes about PR's and Issues and Discussion was just lost. In the Apache community, the expectation used to be that everything had to happen on the mailing list. Even if someone created an issue, there was an expectation it had to come out of a mailing list thread.
I am not saying this was perfect or even better. Just that the side effects were different. Probably a lot of people did not bother contributing because the barrier was too high, but overall I think it created healthier community dynamics and it was not uncommon to see people begin as users asking questions, and evolve into users answering questions and eventually contributing to the development.
This generalises to any idealism. You would not think veterinarians to be at elevated risk of suicide, but they are [0], and I think the reasons are similar: a moral dilemma caused by the mismatch between expectation and grim reality which ultimately leads to burnout and desperation.
The other extreme is a "bullshit job", work that you don't enjoy and which serves no meaningful purpose.
I 100% understand why veterinarians are in a crisis.
We had to let our pupper go a few weeks ago. The vet had to basically sit there and watch us while we processed the fact that we were about to pay her to kill our best friend.
For us, it was the worst day we had experienced in years. For her, it was Tuesday. She had other people waiting in the room next door, and had to go from solemn to bright and cheery over the span of ten footsteps, and she has to do that every day.
Her job is often to put a very real price tag on the life of a beloved companion. "I'm sorry, but keeping him alive will be $10,000... or we can humanely put him down for much, much less."
veterinarians are the most realists people in the medical field. While you put cost as the main factor my experience it is not simply a math problem, it is often a quality of life issue. Spending the $10,000 to extended a pets life for a another year is rarely about making the pet better, it is emotional support for the human companion of the pet while the pet will end up suffering for the year and die anyway.
So yes it is often cheaper to humanely put a pet down, it is often also the most ethical thing do to even if money was not a factor.
I call them realists because the face the inevitability of death head on in a way that we do not do in Human Medicine where we believe maximization of chronological age is the singular goal to be achieved at all costs with no regard to cost, pain, suffering or quality of life.
This is why you need to bring your joy & love of the dog to your vet when things are going well, when you're there for routine things. It really improves their day.
We finally found the right medications for my 10-year old loyal potato (she's had low thyroid function, immune system trouble caused by the low thyroid function, a rattlesnake bite on the nose, arthritis, and so on) -- she's now acting half her age and happily jumping on rocks to pose for treats, and it's so nice to share her story with the vet.
Everyone at the vet visibly brightens up when they interact with a happy well behaved dog.
The original dog would still die, no? Having a puppy with technically the same genes but none of the behaviors or memories of the original seems like a very poor substitute.
I think, from observation, that the Rust project has worse burnout problems than most other similarly-sized open source projects.
I'm not sure whether it's more to do with the way the project is organised, the state of the codebase, or the sort of person that's attracted to working on Rust in the first place.
Maybe it's because Rust is new and well designed. People who have adopted it probably care about this and want to maintain it and that's hard. Maybe it's my perfectionism, my desire to build and live in an ivory tower, but I feel this as a Rust user, a fear that they might break some perceived perfection that I care about. I've commented before that "at least C++ developers are free from the burden of using a perfect language", which was me projecting this feeling.
Rust is far from "perfect" in my opinion as any other language. It tackles couple of particular and important problems but since it can not completely solve it for general case it bends people to think in a certain "perfect" way. Not sure it is ok when one has to jump hoops on what should be perfectly valid and logical code just because compiler can't figure out that it is actually safe.
Also as a generic tool I think it ought to support multiple paradigms and it does not. Just because they (language designers) believe that doing thing their way is superior to what others might find more appropriate does not make them right.
Personally - I would use Rust if clients insists which so far has never been the case, otherwise I would take a subset of C++ any time over.
I was thinking something along the lines of people who tend to set unusually high standards for themselves.
Rust has something of a self-image of always being best-of-breed in everything it attempts, so I could believe that it might be particularly attractive to those sorts.
Other possibilities might be that Rust developers skew younger than average (I don't know whether that's true), or that its six-week release cycle attracts people who think that a year is a long time.
> people who tend to set unusually high standards for themselves
I would agree, at least I am like that when using Rust (though I don't contribute).
And it's true that this is a shortcut to burnout.
> or that its six-week release cycle attracts people who think that a year is a long time
I don't speak for the Rust project but to me this always sounded like a measure to avoid stagnation. Having six week slices helps remind people that this is not only a labor of love; many people out there are counting on you to get your stuff right.
Obviously Rust isn't governed like a commercial project (and thank the gods for that) and obviously many things still take years to complete but for me at least the six weeks release cycle would serve as a periodical poking a la "Hey, is your stuff progressing even a little?".
Don't know though, could be just my interpretation.
rust definitely skews younger than average. i don't have statistics on hand, but almost all people i know working on the project are younger than 35, and a surprising number are 17-25
Not only open source. Also anyone taking ownership in companies end up like that. The difference is: The person gets paid and is ideally not emotional involved.
Unfortunately, people who take ownership and accountability are often the same people that take pride in their work, which means they aren’t emotionally detached. As long as you're emotionally attached to your work, burnout is a real risk whether you get paid or not.
Ironically, the solution from my perspective is the opposite of most advice. It’s not for everyone to become drudging zombies apathetic about their work and just kicking the can, it’s that more people take pride, ownership, and accountability in all aspects of their lives.
Having gone through burnout and a lot of therapy, my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world. There are far too many people who surround all of us who are apathetic and/or incompetent, yet are entrenched, and being “forced” to carry their burden has an amplified effect on the misery we feel when doing that work. When you work with a team that only has accountable, competent, engaged people it becomes energizing rather than draining.
Realistically even if I am entirely correct above, this isn’t a solution. This is just a confirmation that in my experience the old adage “hell is other people” is true and the primary driver of burnout.
> my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world
Yikes! That hits way too close to home. You didn't have to attack me like that.
In seriousness, this is a very astute and correct observation. Noticed it in myself and several others as well. It really pays off to correct your level of caring with what you see from your superiors and colleagues (and peers, in non-commercial activities).
A problem I have is I don't know how to work if I don't care. At my last job I tried to not care and succeeded, but then got fired for poor performance.
Are there sufficiently productive people who don't care? Or does everyone care, but some hold themselves to impossibly high standards?
I don't know how to separate "lower standards" and "stop caring". They are the same to me, because lowering my standards requires not caring about the things that comprise my high standard.
>Or does everyone care, but some hold themselves to impossibly high standards?
That's your answer right there.
Do you know the age old saying "That is above my paygrade."? It means you shouldn't care more than what you are paid to do, which in turn will hopefully prevent you from burning out.
>I don't know how to separate "lower standards" and "stop caring".
You need to remember that your personal satisfaction ("I did good work!") is independent from your peers' satisfaction ("He did good work!"), and that correlation is not causation.
Life is short, draw a clear line between your personal and professional lives and budget your limited capacity for passion appropriately.
That explains how to set time boundaries, that's easy, set a timer, use the clock, etc. It's a mechanical process to adhere to time limits.
I'm thinking about things like finding millions of real user passwords in the test database. I complain and push and eventually we delete all the passwords from the database which breaks everyone's test build and in the end I don't make any friends. Did I care to much? I harmed my career because I cared.
Early in the project we agreed to organize our code into modules a certain way, but that fell apart and the code was not organized. I never knew where my code should go, the existing code was not organized, it bothered me a lot. How do I stop caring about that?
Shortly before I was fired a unit test I had written was passing even though it shouldn't have. The code was something like "assert(x == 1); assert(x == 2);" and the test was passing, it was impossible. It was some custom TypeScript stack and I got on the phone with the guy who created the tech stack and he agreed something was off, but none of us had time to look into what's up. I was fired before we ever got to the bottom of it.
These are the most recent examples, but I've had similar issues at other jobs. Imperfections, big or small often bother me more than other, and, again, I don't know how to lower my standards without also stopping caring, but without caring I have a hard time working.
Again, you need to consider what you are paid to do.
Are you paid to care about "finding millions of real user passwords in the test database"? About caring how or whether your code is organized? About what should be happening in a unit test?
If you are paid to care about it, absolutely do so because that's your job. If you aren't, though, at most you should inform someone who is paid to care about it and then forget about it because it's not your concern.
Life is short and there is only so many waking hours in a day, so we need to budget them accordingly. If you can't bring yourself to be less passionate about your work even though you realize it's actually causing you and your coworkers problems, perhaps it's a sign you need to change professions entirely.
They say I'm paid to deliver working software, but I'm not able to do that with confidence until lots of things with the system are fixed.
Their actions, though, say that they want someone who hustles and creates bugs and then puts on a good show fixing the bugs they themselves created.
Saying it like that, I guess the solution is to just get out, but it's hard to accept "just find another job" as the solution when I'm not even employed right now.
i think this is partially true, but i hesitate to call people zombies. the vast majority of people in the rust project are competent and engaged. the problem is they have different priorities and collaboration is hard when everything is bottom up. i have some more thoughts on this here: https://tech.lgbt/@jyn/111771440884089084
> i think this is partially true, but i hesitate to call people zombies.
To clarify, I was more responding from the perspective of the workplace rather than the Rust project. That said, I have been an open source contributor off and on since 2003 and my observation has been the situation isn’t much different.
In a project, rather than apathetic coworkers, you deal with users of the project that have complaints and expectations but without the ability or motivation to contribute themselves. I imagine Rust has slightly less of this than the consumer-focused projects I have worked on, but people are people at the end of the day. Contributing to any large project is largely thankless because there will always be one more complaint/demand issue, or one more PR from someone that didn’t read the contribution guidelines.
It can turn what you’re passionate about into a slog, and while the form may differ, it’s not meaningfully different from having apathetic or incompetent coworkers dragging you down.
To be honest, dealing with open source slog is slightly worse, because it takes much longer for the hope to die. Somebody that submits a bad PR seems to care somewhat, it’s not total apathy. Somebody that submits a whiny issue at least demonstrates that they used the project and cared enough to write. But both demand your attention without demonstrating competent contribution in and of themselves. It’s somehow worse than the coworkers that are on an in-office vacation.
i agree! i hadn't realized you were talking about people who weren't already team members. they're usually well-meaning, but it's true that some drain a lot of contributor time on things that aren't important.
rust has a conflict avoidance problem. i think rust could be much more effective at saying no, and saying it more quickly. i want to talk about that in my next blog post.
It is a fair point, but I think your last sentence hits on the problem. People that contribute regularly to OSS projects are nearly always emotionally invested. It brings a lot of pleasure initially which I think also contributes to the eventual burnout.
Ah yes. I wonder if an OSS project should set forth a time budget in some way? Hard to “enforce” though. And goes counter to wanting contributors to feel free to contribute on their terms.
The best I’ve seen is have additional contributors (often who just like the project but aren’t coders themselves) who run interference for the dev team. They can triage feature requests, filter out the spam and repeat issues, etc.
Also, and this can be the hard part, is sometimes you have to have someone who (even politely!) can be a bit of a dick when necessary. People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear.
Also having a defined procedure for “hiatus” helps quite a bit - make it easy for a dev to say “I’m off” and it can be indeterminate - this allows them to easily come back later. Encourage devs to use it liberally.
> People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear.
As an Eastern European I always found fascinating how many Westerners are struggling hard with this. To me and many of my peers (and apparently to Linus Torvalds and a good chunk of the entire Nordic culture, probably?) it's the easiest thing in the world to say something like:
"Listen up dickhead, I do this in my free time. If you don't like the direction of the project or the urgency with which your issues are [not] being addressed, you are free to not use it, and it also costs you nothing to not comment at all. I got better things to do than to reply to entitled cunts, now piss off."
It's very amusing what a huge drama many Westerners make out of just... being direct. Honest. Straight to the point.
"But he won't ever contribute and he might infect others with the opinion that the project leaderships is toxic!"
OK. That's a price I am willing to pay. My mental health > the second-hand opinion of people who were only 0.1% likely to contribute anyway. The math is very easy yet so many Westerners struggle so much with these [to me and many] mega obvious solutions, like "be a bit of a dick when necessary".
This is really very similar to the discussions I had with a lot of women long time ago. It goes like this: they tell me:
"I have to go tell X and Y about event A because otherwise Z will tell them lies and they'll think something wrong about me."
To which I reply with a cold expression: "Then you don't need X and Y in your life, if they can be so easily influenced by lies and won't even ask you about what truly happened."
Their expressions were priceless. The cognitive dissonance can hit us all VERY hard.
Back to the topic at hand, yes, I firmly believe all open-contribution projects need a Linus type of person. It's also a fact that many devs are introverted and can be chased away by entitled and insolent loud people. So somebody must put a shield in front of the devs.
I did not, but I have my doubts as to whether he was made to do it or if he truly meant it. I tend to believe in the former because it's always accompanied by "stepping back for a while" and "get help on how to behave better". Seems like a standard procedure after somebody manages to overpower you (in whatever hierarchy they have there).
Were cursing and expletives necessary? Absolutely no. They don't drive any point forward.
But: is showing people the door when they are entitled or unprofessional necessary? Very, very much yes.
Feel free to read into the article as your beliefs incline you to. I've known many people like Linus and they don't get "change of hearts". They simply get sick and tired of being misunderstood and just remove themselves from the situations that cause it.
There's more to the Linus-style jerk phenomenon than just telling entitled people to piss off (I would be reluctant to call that being a jerk if that's all it was). See https://news.ycombinator.com/item?id=33058906 for an example thread and associated comments. If you're just ranting or passing off subjective POVs as truth and obvious and those disagreeing with you as doing so out of incompetence or malfeasance, that isn't being direct, honest, or straight to the point. It's being a dick.
I've seen brilliant colleagues for whom I have the utmost technical admiration completely fail to improve bad designs implemented by others, because the brilliant person was so dickish about how they communicated to others.
> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus.
It's an exaggeration. Means that he disagrees with people who blindly repeat something that, on the level Linus operates, is objectively not true.
I have no context on the broader discussion but it seems both sides haven't equalized the plane on which they discuss. In that context I'll agree Linus was a dick.
But, consider what was said upthread: many high-profile open source contributors hear the same crap every day. No matter how gracious you start off, you'll start rolling your eyes and ultimately resort to sarcasm. And some go even further: start insulting. Ask anyone who works in retail.
So again, to me Linus' statement basically uses an exaggeration to illustrate a point: "Stop repeating something as if it's unequivocally true. It's true only in your context (userland application development). It's not true in kernel context."
That people get offended by that says more about them than about Linus.
Finally, I'll agree it can and should be toned down. Not disputing that. But it's also not so difficult to extract out the true point in such a rant and move on.
We probably won't get much further going back and forth on this. For what it's worth, you seem very reasonable, I've appreciated your comments for a long time, and I'm sure we'd get along fine if we were to work together.
I think you could let Linus off the hook by trying to find the kernel of truth as you suggest, and that seems to be the way key Rust team members work. There's been plenty of needless rancor in HN comments about Rust and you can see people like @pcwalton just not engage with the emotional content while still continuing to engage with the technical points. I'm personally impressed by this, but wouldn't be surprised if it contributed to the burnout.
Should we all aspire to be like that? Doing so seems like the human communication equivalent of Postel's Robustness Principle, which sounds great but in practice leads to shitty implementations getting away with being shitty because of the "robustness" on the other side. Maybe the better play here, especially with asynchronous communication, is to expect people come back to their message draft when they are not so pissed/emotionally triggered and then snip out tangential emotional crap. Especially the ragey condescending stuff.
> I'm personally impressed by this, but wouldn't be surprised if it contributed to the burnout.
I think that people who contribute to languages are of a certain psychological type. They are generous, nice, kind, they want to contribute and are not interested in the social and people drama. They are a special breed of people whom I admire.
At the same time, and as you point out, that makes them more vulnerable to burnout because the social / people drama always creeps in, and they seem less well equipped to deal with it (though I've known of very impressive exceptions).
Personally I found out that bottling up negative emotions is futile; they inevitably erupt and the longer you have bottled them up, the more violent the explosion and the worse the ramifications for your mental health.
That's my main reason for not mincing words anymore. I prioritize my mental health. I am OK if that means I part ways with people and companies. I was a victim of FOMO for most of my conscious life; I want to live my remaining years being more at peace.
> Maybe the better play here, especially with asynchronous communication, is to expect people come back to their message draft when they are not so pissed/emotionally triggered and then snip out tangential emotional crap.
Obviously that's best but I can bet each and every one of us has been in a situation where they knew they had to do that and still didn't. :D Myself included, not proud of some of my comments on HN during Corona time...
But expecting most people to be like that? Super tall order, turns out. :(
--
> We probably won't get much further going back and forth on this.
Likely not, but I am grateful that you entertained it as much as you did. :)
> For what it's worth, you seem very reasonable, I've appreciated your comments for a long time, and I'm sure we'd get along fine if we were to work together.
That's an extremely surprising and very warm message that I couldn't predict if I lived for 1000 years. Thank you! Still very surprised and your message is definitely the highlight of my day now.
> "Westerners are struggling hard with this [...] it's the easiest thing in the world"
But why pride yourself on taking the easy way out?
It isn't being honest and direct and straight to the point, it's a power move being deliberately rude/offensive/cruel hiding behind "just being honest and direct". Which only works as long as you have the power behind the powerslam putdown (in a personal project you do) and can deal with the consequences of cutting people off (which you say you are willing to). For everyone who doesn't have that power, and needs to work with others, it's not an option. Compare a physically large man saying "I find it funny that people don't just stare others down and threaten them like I do" and thinking that will work for everyone in every situation.
If that's your project selection criteria - "don't be thin skinned, man up, grow a pair!" - it's not-meritocratic; like a selection based on wealth or social class or accent or nationality isn't. If you want X and Y's skills (public project) or contacts or signoff (professional work) then you will have to face their susceptibility to Z's manipulations and deal with it. If you need help to do more work than you can do alone, you will have to work with other people's issues. "If you want to go fast, go alone. If you want to go a long way, go together".
> To which I reply with a cold expression:
> Their expressions were priceless.
That story shape is a perfect fit for "everybody clapped" meme, you feel superior to the stupid women who didn't even think of this power move, and wait for your applause. Were their priceless expressions "you solved my problem, my hero!" or were they "you have no clue that my life is different to yours and with no attempt to empathise or understand, you expect the first thing you thought of will solve my problems and want me to be impressed?" Women generally have less power in society, in companies, far less physical intimidation, less respect, fewer options, and need to depend more on social networks and support and building consensus to get along in life or get things done. Cutting off the network and getting a reputation as difficult to be friends/work with risks a lot more for women than it does for you.
That "I'm colder, more vicious, than you so I win. Empathy and emotions are weakness." is so ... last season.
> "It's also a fact that many devs are introverted and can be chased away by entitled and insolent loud people. So somebody must put a shield in front of the devs."
It isn't a shield, it's a counter-offensive. Many devs don't want their workplace turned into a battlezone by people trying to shout the loudest. Again, fine for your personal project, but having a shouty vicious bouncer is turning away the porentially useful contributions of unknown people who don't want to fight their way into that kind of workplace. Consider @dang here at HN doesn't take the easy way out of shouting people down, swearing at them, putting them in their place; instead he patiently links the HN rules and politely explains what he's doing and why (your account is doing A, against the rules here, will be banned in this time, please do this or that specific thing), over and over and over.
Trying to build a community of disparate people is much harder than being a dictator who can tell disagreeable people to piss off. Is it any wonder people who are trying to do that, are struggling with it?
> But why pride yourself on taking the easy way out?
Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain? You only lose mental health. Having to grind my teeth and not telling someone they're being an arse is bad for me.
> It isn't being honest and direct and straight to the point, it's a power move being deliberately rude/offensive/cruel hiding behind "just being honest and direct".
No. That's your interpretation because you are offended. I am in "the Linus camp" and knew many others like me and him and I am telling you that this absolutely is about cutting to the chase and solving the problem at hand on the spot.
I have no motive to lie to you or anybody, nor any face to save.
If you don't believe me and keep arguing that it's "a power move" then you're arguing with fictional people and not the real ones standing in front of you. ¯\_(ツ)_/¯
> For everyone who doesn't have that power, and needs to work with others, it's not an option.
Obviously yes, what's your point here? I don't get angry at work (where I don't have the power to tell people off) which is a double win. I got stuff to do, sometimes others get in the way, sometimes I make bad calls. Oh well, I made my peace with the fact that things can't happen as quickly as I want them to. And it's not even about "thick skin", it's more "giving up on perfectionism".
> If that's your project selection criteria - "don't be thin skinned, man up, grow a pair!" - it's not-meritocratic; like a selection based on wealth or social class or accent or nationality isn't.
The hell are you even talking about, and even bringing class / accent / nationality to the picture? It seems you just wanted to get stuff off of your chest and I was a convenient target. You're not even talking to me, again, you are talking to some fictional guy who does not exist.
> That story shape is a perfect fit for "everybody clapped" meme, you feel superior to the stupid women who didn't even think of this power move, and wait for your applause.
Your snark does not change the undeniable fact that I gave them advice that would have helped them with their mental health. Whether they accept it or not is on them. Those who didn't accept it also taught me a good lesson: to mind my own business and only give advice if I am asked to. It was a valuable life lesson that I am utilizing often (though definitely not always).
And yes, some people were mind blown... though they did not clap. :D You got one thing right at least.
> Cutting off the network and getting a reputation as difficult to be friends/work with risks a lot more for women than it does for you.
Context matters a lot here. I was talking about completely optional interactions where zero work / money / influence was involved. They were "buddies" for 10+ years and their main goal was to basically outdo each other. Extremely toxic and I pointed that out to them. Some of them listened and said it felt very liberating to just stop. The rest I was not interested in communicating further with because they had a tendency to bring the same drama to our extremely casual communications, which naturally led to them fading away with time.
> That "I'm colder, more vicious, than you so I win. Empathy and emotions are weakness." is so ... last season.
For the third time: you are not even talking about me. I am not cold at all, I simply learned to pick my battles. Seriously no idea what made you explode with so many assumptions, it must be somebody in your past and I probably reminded you of them. You should probably go talk to them though, not me.
> Again, fine for your personal project, but having a shouty vicious bouncer is turning away the porentially useful contributions of unknown people who don't want to fight their way into that kind of workplace.
Nowhere did I even implied I want a "bouncer" or that he/she must be "shouty". Stop projecting (4th time now).
Also that phrase of yours reeks of FOMO. I am sick and tired of being a victim of FOMO. Somebody doesn't like that I called them out for being entitled and spamming my OSS project's issue tracker and as a result they go away and won't contribute anything ever? Cool! Win for everyone.
You conflate a very classic case of "fear of missing out" with "showing rude a-holes the door".
> Consider @dang here at HN doesn't take the easy way out of shouting people down
I have considered him and other moderators a long time ago and found that I don't have what it takes to be a moderator, I don't want to have it and I am very fine with that. I am impressed by people who manage to keep the peace without alienating anyone except the biggest detractors but this is a non-goal for me, especially in the open-source contributing scene. I don't moderate forums and don't want to, and I'd be terrible at it. Again, I pick my battles.
> Trying to build a community of disparate people is much harder than being a dictator who can tell disagreeable people to piss off.
Another non-goal for me. When I start doing more open-source I'll be looking for people who contribute astute observations ("You made mistake X in file Y") or code. If somebody politely asks "is this feature on the roadmap?" I'll also politely say "yes but it's a low priority for me, what's your use-case?" and we can continue the interaction from there.
But, somebody doing a drive-by saying "I tried your project and it couldn't do X, your project sucks lol" then I have zero qualms blocking them and removing whatever they posted.
Did they have the worst day this year? I don't care. I had days after which I wondered if I even want to continue living, and nobody around me was none the wiser. They only saw a very tired guy who wasn't chatty, nothing else.
I can protect people from my bad moods and bad days. I expect all people I interact with to do the same. And I am very fine with cutting off those that can't do it.
---
No idea why you fixated on me as some sort of an enemy but you have aimed wrongly. Severely so.
What I was saying is that I don't feel the need to smile politely at a-holes and use a soft language. And I don't. The rest is a plethora of projections from your side.
That's one side of the coin. The other side is: if you are Linus, you have heard the same dumb questions or obviously wrong assertions, thousands of times. It's absolutely normal to start telling people to go RTFM and stop talking without thinking things through and without doing the proper due diligence. Ask anyone working in retail.
> "Nowhere did I even implied I want a "bouncer" or that he/she must be "shouty". Stop projecting (4th time now)."
You gave an example of calling someone a dickhead and telling them to piss off, then said "I firmly believe all open-contribution projects need a Linus type of person", someone who will "be a bit of a dick when necessary"; if that isn't describing a "bouncer" role ... what is?
I'm not against showing people the door, I'm against the needlessly provocative and rude Linus style of doing that. You say "Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain?" then you say "I can protect people from my bad moods and bad days. I expect all people I interact with to do the same" - so I can ask the same question back - why choose the harder path when doing that? What is to gain? Obviously you can see it when it suits you, the intangibles of higher standards, trying to build something which is better than dog-eat-dog, might-makes-right, rudest-wins, flamewars everywhere world.
> "No idea why you fixated on me as some sort of an enemy but you have aimed wrongly. Severely so."
As I said repeatedly, you can run your personal project however you like, but you are here in a Rust discussion arguing that Rust shouldn't have problems of coordinating with people because you find it easy to swear at people and get rid of them, and all projects should be run like that. I am arguing against that.
> "The hell are you even talking about, and even bringing class / accent / nationality to the picture? It seems you just wanted to get stuff off of your chest and I was a convenient target. You're not even talking to me, again, you are talking to some fictional guy who does not exist."
I'm talking about the programmy world culture of "piss off dickhead, RTFM noob, I can say that because Linus did!" which permeates too much software development world. It's mistakes of correlation and causation thinking "Linus is clever and that excuses his bad behaviours, I'm clever so that excuses me behaving the same way" or "If Linus is successful and rude, if I'm rude I will be successful" or "If he can get away with it, I should be able to". Those patterns drive a kind of filter which is not meaningfully different from any other filter based on or only "the right people" can be involved - race, class, wealth, etc. being the traditional ones, and rude/smart/technical male being the common one in this scope.
Encouraging projects to be run that way, saying all projects should have someone being rude to people, is objectionable for similar reasons that the others are objectionable.
> "You conflate a very classic case of "fear of missing out" with "showing rude a-holes the door"."
And you conflate a case of "showing rude people the door" with "here's a place I can abuse people and get away with it, which is a good thing". This is showing a rude person the door without invoking flamewars (@dang): https://news.ycombinator.com/item?id=39037519
I'm not saying you have to behave like dang, I'm saying nobody is going to be quoting dang's epic flame putdown win over THIS asshole like people do with Linus' newsgroup posts, and that's a good thing.
> if that isn't describing a "bouncer" role ... what is?
I still wouldn't call it a bouncer; I'd call it a moderator who is not afraid to tell people off.
> I'm not against showing people the door, I'm against the needlessly provocative and rude Linus style of doing that.
If you read my other sibling comments you'll see that I partially agree. To me swearing is unnecessary; if somebody is crossing lines I'll just try and quickly chase them away. I guess for others cursing is one vehicle through which to achieve that.
> As I said repeatedly, you can run your personal project however you like, but you are here in a Rust discussion arguing that Rust shouldn't have problems of coordinating with people because you find it easy to swear at people and get rid of them, and all projects should be run like that.
I see where the disconnect lies now. I haven't argued about how should the Rust project be ran at all. I got off on a tangent that was borne out of my disdain for the "being too nice" thing I am noticing in many Westerners. As a former bullied kid I understand better than many that never retaliating even a little encourages bullies. So in my eyes not showing some teeth just furthers the having a-holes problem.
> I'm talking about the programmy world culture of "piss off dickhead, RTFM noob, I can say that because Linus did!" which permeates too much software development world.
An assumption on your part is that I am imitating / emulating Linus. I don't. I simply understand what it is to have to read and listen to the same BS every day which is taking away from your time, energy and motivation to do what you truly love (in his case: kernel development).
If Linus did not exist I'd be 100% the same person in open-source contribution discussions.
> Those patterns drive a kind of filter...
Yes and that's a good thing. I don't subscribe under the "inclusivity at all costs" ideology. Are you?
> Encouraging projects to be run that way, saying all projects should have someone being rude to people, is objectionable for similar reasons that the others are objectionable.
Why are you so polarizing? I didn't "encourage" any project be run this way. Blindly doing stuff always, no matter the circumstances, is a bad idea regardless on which end of the spectrum you are. I preach for people on the receiving end of toxic (or stupid) posts to NOT shrivel away and strike back whenever necessary.
> I'm not saying you have to behave like dang
Are you not really? I already addressed this. I don't aim to be like him and I already said that I admire people like him. At the same time, I know that having to bottle up certain reactions is destroying my mental health so I simply don't put myself in situations where I have to do it. But I also have plans to start open-sourcing things. And there I know for a fact that I'll just be super cold (not emotional, and won't curse) but would still quickly stop any toxic discourse.
--
Is that the best policy for high-profile stuff like Rust? I can't say. I have witnessed language maintainers engaging in forums and I noticed how some people were EXTREMELY sensitive even to the mildest of "no" answers, very quickly escalating them to "you don't care and your community is full of a-holes" which made me facepalm hard.
I understand they don't want the bad PR. I get that. But I would never want to be in that position. So when I start my open-source projects I'll be like "OK, if you feel that I don't care and I am an a-hole, there's nothing I can do about that. Have a nice life." and will block the person if they keep escalating.
Even if that gives me bad reputation, I absolutely don't care. I get how language maintainers don't want such bad reputation but again and again, I think they overdo do the "be passively polite to the point of being taken for a doormat" behavior.
I ain't telling anyone how to run their projects. But I do have the right to think they're wrong in certain aspects.
> I think they also encourage drive-by contributions
I realize I am in minority, but for me, if project uses a mailing list I am more likely to do a drive-by contribution (compared to no contribution at all). Just doing git send-email is much easier compared to figuring out how to create whatever pull request is called in whatever forge the specific project is using.
> There's no clear notion of status, remaining concerns, priority, etc. in an email thread.
Which, for drive-by contributions, does not really matter. It is a problem for long term contributions and project managements in general, true, but there often is some tracking system present (patchwork, debbugs, ...).
None of this is unique to open source. Something that would be readily apparent to people who do volunteer work on things besides software. Which is essentially moonlighting on doing your day job.
All volunteer organizations have to fight burnout. Any time you start feeling like things won’t get “done” unless you do them, you’re on that road.
Amen. Especially on open source projects where just enough people use it to have an active user base, but not enough where you have a good stable of contributors.
I’ve burned myself out on a handful of projects like this and also why I haven’t started any new ones lately. It’s very tiring (doubly so if maintaining open source isn’t part of your paid job, so you’re doing it on your free time).
Yes. Usually there's either two lists, one for discussion and one for patch submission and review; or users use filters to divide them out (if $h_Subject contains "PATCH" -> send mail to "patches" dir). For large projects, you can use deeper filters to entirely drop mails in areas of the project that you don't care about.
Yes. The way to make it work is to use fiters in your mailclient. All mail to dev@ goes to its own folder, all mail to discussion@ to its own folder, all mail to support@ to its own folder. You only look there when you feel like it. Your inbox is not having all this noise.
> the best way to help the project is to keep contributing for it for years. to do that, you have to avoid burning out, which means you have to treat yourself well.
When I was a schoolteacher, the way I expressed this is that you have to do the job in such a way today that you're capable of doing it again tomorrow. This did not go down well and I am no longer a teacher.
I have a teacher friend who I've been pushing to adopt this mindset. She had a burnout last year because she kept putting off taking care of her health problems because she didn't want to miss a single day.
The fact that you are in pain every day is obviously a tragedy, and I hope your situation improves. Mocking your peers for taking care of themselves is still not acceptable, and does nothing to improve the situation for anyone.
I accept that this is a spectrum, and that some level of discomfort in life is unavoidable—people stay up late and skip exercise from time to time. The unpleasant consequences of these actions doesn't justify not contributing to society, and there are no doubt freeloaders in any reasonably sized company.
However, no workplace, including yours, should expect their employees to sacrifice their health.
Personally, I don't think it is natural to sit in the same role for more than a few years. And that's not just the primary tasks of the job -- the same people, the same administration, the same bureaucracy. I do feel that virtually no jobs will allow you to grow as a person and enjoy life.
Here, by "job" I mean the traditional kind at a corporation or medium-sized organization. After seven years of working in such organizations I realized the only thing that was fulfilling was quitting and doing a bunch of random things like contracting, content-creation, and other passive income streams.
Of course, that may not be for everyone but I still think (after talking to hundreds of colleagues in various places) that after a while, most jobs suck. Sure, some of them pay well but then again, I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things. And, if the money IS good enough, it makes sense just to work for a decade and then retire early...
> I personally feel that no amount of money is worth spending the best part of your youth doing mostly meaningless things
It depends on why you’re doing it. Supporting a family, and contributing money and spare time to your community, are very meaningful. I’m building <yet another API> for <Company> in order to do my real job which is being a parent and citizen.
If you like the people you work with, why change things? I've been on the same team for 6 years and my org has had minimal churn in that time period. It's not quite like a second family (that would leave me too heartbroken if I ended up moving on), but I don't really think I'll have an easy time finding another group I work so well with, so I don't feel motivated to find another opportunity.
I used to move around a lot, but I've since put down roots. There is something you miss out by constantly upheaving your life. Nothing is permanent, but letting flowers blossom over long time periods can be rewarding.
> letting flowers blossom over long time periods can be rewarding
There can be rewarding ways to live your life that don't allow this, e.g. serving your country, doctors without borders etc, but the nomadic life is a sacrifice so in order to be happy long term most people need to eventually set down roots as you did. The digital nomad lifestyle was sold for years as the ultimate life hack, and perhaps for a minority it is, but for most of us it sours.
I agree with a lot of this. The software industry has so few lasting projects, and almost no lasting projects that pay the bills. It just doesn't provide value to the paying consumers in a way that encourages long term building. Which, no surprise, the name is software after all, the benefit being computations can be easily changed without re-wiring circuits.
Unfortunately some professions work like meat grinders. If you're not tough enough to take the grinder's teeth you get chewed out and spat out the other end, and replaced by someone else, of which there is an inexhaustible supply. Suggesting to use softer teeth just gets you replaced before you're ground out.
Do other people react as strongly as I did to the lack of capitalisation at the start of sentences? The post is generally "well" written with good grammar and punctuation so I find it strange - it feels like a style choice. But the style choice just instinctively makes part of my brain feel like it's written by a child.
Wow a lot of people have very strong feelings about this. Parent comment is fine but some of the replies are quite out there, calling this "arrogant" and "dumb". Let me provide my own opinion.
IMO content over style. Nobody owes you adherence to a particular set of rules, nor do they owe you their thoughts at all. If the writer's style is a bridge too far for you, kindly just close the tab, don't complain about it. Certainly don't use hateful words to describe them.
Remember, the same English teachers who taught you to capitalize also taught you that there is no singular "they" and that you should use "he/she" instead.
I think that while authors are obviously free to make whatever stylistic choices they want, it's also valid for readers to point it out when those choices are so distracting that it interferes with the intended message of the writing (as long as it's done civilly). It reminds me of another recent-ish article that was posted to HN that used uncommon ligatures looping between certain letters, where a large part of that discussion was centered around how distracting that was.
As an author, if you notice that your style choices are generating more interest and discussion than the actual content of your writing, it's probably worth considering whether the reasons that led you to those choices are really worth taking away from the messages you're trying to convey. Seeing as how the author of this post chimed in here to call their use of lowercase an "asshole filter," I suppose it's clear where they stand on that question.
I can see a future where we'll have browser extensions that use generative AI to "correct" style and grammar of articles to match the preferences of the reader, at which point stylistic choices may cease to matter as much.
> Nobody owes you adherence to a particular set of rules, nor do they owe you their thoughts at all.
What the hell? English has rules. If those rules aren't followed, it makes communication needlessly more difficult.
This isn't just a typo we're talking about. This is someone making a deliberate choice to be harder to understand because they see it as quirky and cool.
It seems to be something new generations are increasingly doing. I remember someone saying that he was texting with his gen-z child, and the child felt like properly capitalized sentences sound like they are formally chiding you. I've learnt to mirror whomever I'm talking to (e.g. on Slack at work).
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
No capitalization is not a tangential annoyance, it is a major complain akin to complaining about a text written in one block (without anything distinguishing sentences and paragraphs from each other).
i said sentences and paragraphs not words not having punctuation is absolutely akin to not capitalizing after all new lines and dots are designed and are working together and in unison to when combined convey the important information information of separation of pieces of information ways of compartmentalization if anything capitalized words are more visible than dots
>> Remember, the same English teachers who taught you to capitalize also taught you that there is no singular "they" and that you should use "he/she" instead.
That is a completely different story. Using "they" is about respect. Using a standard form of writing is about making reading easier.
This was the big realization to me why spelling, grammar, etc are important. It’s not that people can’t understand various modifications and incorrect writing, it’s that it is harder for them, so you’re basically asking your readers to give more of their time to save you a bit of yours.
And it’s especially bad in a blog or similar, where there is one writer and multiple readers. I spent maybe a few seconds on this post, but it will be read five, ten, fifty times. If I wrote the whole thing in text-message shorthand, it’d be stealing time from each of those readers.
It also helps people who do not have English as their first language if you avoid abbreviations and incorrect usage.
In a comment on another Rust-related post, the author noted that, "rust definitely skews younger than average. i don't have statistics on hand, but almost all people i know working on the project are younger than 35, and a surprising number are 17-25."
I've messed with Rust a bit and I like it. I like the ideas and lack of compromise. But good ideas and a lack of compromises are what you get from youth, along with the arrogance of style choices that make things harder to understand. Will Rust stick around once these folks have bigger responsibilities?
My brain tends to self-correct what it's reading these kinds of posts, and considering the author of the post has replied to the comments here in the same style, I see two options for the style. It's either done for speed, or the shift key is mapped to something else, making typing one-off capitals harder.
That might equally be a stylistic choice, but I my gut says it's not.
If we could beam our thoughts directly into each other's head, we would. It would be the easiest way to convey information. Alas, we don't have that ability, so we resort to the written word. If your goal is to spread something interesting don't make it more difficult for your readers by hiding your point behind a style choice that directly contradicts the readers' expectations.
Capitalization goes hand-in-hand with punctuation. A period is only part of the formula that tells a reader that a complete thought is done. Capitalizing the next letter is a signal that the next complete thought is starting. The reader doesn't have to continually guess whether the punctuation was incorrectly or accidentally placed.
I pushed through your style choice and read the article because what you had to say was interesting and important. But not all readers are going to grant you the same courtesy. If you really want the widest distribution possible do your readers a favor and capitalize things according to the rules.
You used paragraphs and correct spelling, as well as avoiding things like run-on sentences and sentence fragments. It's obvious you want people to your read your work. Whatever reasons you have for choosing to not use capitalization, those reasons are not as important as the message you are trying to spread.
OP might be a non-English language speaker. Many languages don't use capitalization at all. Some languages don't even bother to put spaces between words, it's all driven by context.
But if you're writing in English, or really any language, you should attempt to follow the rules of that language, especially if you want wide readership. Grammar rules might be arbitrary, but readers learn those rules and expect what they read to follow those rules.
Oh, hey! Thanks for chiming in. It's rare to see rejection of grammar rules on longer forms of writing, so it looked interesting.
Any special reasons? Just because I like to know people through their choices and views. Didn't want to sound rude in the previous comment, so if I did, genuinely sorry (non-native speaker woes).
1. writing in lowercase is freeing. it reminds me that grammatical rules are arbitrary, and by extension other rules. "you can just do things."
2. people who are pedantic about this when it's clearly intentional are probably not people i want to interact with anyway, so it's a good anti-asshole filter (https://siderea.dreamwidth.org/1209794.html)
You're going to get some strong/rude reactions from "the other side," which is unfortunate. FWIW, as a reader I do find it genuinely more difficult to read. Capitalization serves a purpose for me, it's not arbitrary. It more clearly separates each sentence. I have to put in more work to read your thoughts without it. Anyway regardless, the rudeness sucks. Sorry on behalf of others who feel as I do.
frankly i don't want a larger audience, i didn't expect this to hit HN. i hadn't thought about it being harder to read for people in the project though, i'll do a poll on whether they find it distracting.
Then wouldn't dispensing with other rules of grammar be even more "freeing"? This is both a genuine and rhetorical question.
I guess it's like user interface design, where a cardinal rule is to be conservative, and not break user expectations unduly.
Of course UI patterns and language evolves, but the evolution of changes should probably be gradual, and done for a justifiable purpose. In this case, I'm not sure the stylistic choice actually adds anything to the clarity or beauty of the writing.
That's interesting take, thanks. I'd love to chat with you further on this issue, but this is neither the place, nor the time. Maybe I'll mail you about this in the soon-ish future if that's OK for you.
This is not an art exhibition. Conventions have a purpose. Capitalization is not a random spelling quirk, there’s a reason why we have it. The upvote balance on my comment confirms that it’s something to consider. The “fuck you” was in reference to the author’s comment, not just to his blog post.
This is a post in a personal blog that they wrote because they wanted to write it. Someone else came across it and pointed people outside of it's desired audience that it existed.
If I make a peanut butter and jelly sandwich and offer it to my friend next to me, and someone across the street yells "How rude of you! I'm allergic to peanuts", I will just close the window and continue sharing sandwiches with my friend, not spend time arguing with the yelling guy across the street.
If you think that the project makes "fuck you" decisions at every turn, I invite you to peruse our issue tracker and PR queue.
The burnout problems are because people care too much about making things better, and that is a neverending queue of tasks that seems to get longer and longer.
Someone looking at the tools and documentation and thinking "these people don't care about their users", just makes it evident to me that no matter how much tears, blood and sweat we put on improving things there will be people who think you're either not doing anything or that you're actively harmful to the project. So what's the point then?
HN guidelines has this to say about contents of your comment:
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Like many invocations of the HN guidelines: “interesting” is in the eye of the beholder and the amount of discussion prompted by this comment and upvotes it garnered would seem to indicate that this stylistic choice is in fact quite interesting.
The HN mod team may find it not to their taste, but they don’t get to decide what is or isn’t generally interesting.
You can group these kinds of "errors of personality" to help understand why they might or might not bug you.
First: actor intentionally disrespected someone. Speaking in a movie theater, especially after being shushed. Using the letter "u" to mean "you" in formal business communication.
Second: actor unintentionally disrespected someone. Clipping your fingernails in class. Badly misspelling someone's name in a critical business communication.
Third: actor unintentionally makes an inconsequential error. Native English speakers misusing "it's" or "your" and their respective homophones, or missing antecedents ("As an expert, it's important to do X and Y" rather than "As an expert, I think it's important to do X and Y").
Fourth: actor intentionally makes an inconsequential error. Wearing obviously mismatched socks. Consistently writing in all lowercase.
The key, for me, is evaluating intent and impact. Group #1 is asshole: they mean to hurt or annoy. Group #2 is incompetent: they make mistakes that matter. Group #3 is hapless: they make mistakes that don't matter. Group #4 is quirky or aloof: they're not hurting anyone, and they're OK if people draw negative inferences about them, so hey, it's a free country.
You might reach different conclusions about the groups, or subdivide the groups further.
(Anticipating critiques of my examples: yes, I really do think that misspelling the English pronoun "you" is disrespectful. Misspell your own name if you want to move from Group #1 to Group #4, but please don't misspell the word that you're using to represent me. And clipping your nails in class is such over-the-top behavior that I believe it's more about upbringing than intentional disrespect.)
I admit it annoys me more than it should. It's harder to read, but easier to write. So it's easily interpreted that the author cares more about their convenience than about others. I don't like this attitude.
This is close to how I feel about this sort of thing: the author can't be bothered to write properly, but still wants me to read it. But maybe that's a narrow minded view of the situation, due to my own biases.
I wrote the original comment because I wanted to get some view on how a (selection biased) part of the population viewed it. I was surprised by how emotional people got!
Maybe I'm in the minority, but I barely noticed. I thought so little of it that, after reading your comment, I had to first go back to the article and verify that it even was the case.
i didn't even notice there was no capitalisation when i read the article
idk about the author, but when i was younger, some people's pedantry and pettiness over grammar / capitalisation / more casual chatting got me to switch sides and deliberately stop using it as much. now it's also an aesthetic preference
i think there's potentially a valid point about accessibility concerns, but blog posts, chatrooms, and internet comments are also very informal modes of discourse
I was the original author of an open-source, server-based, federated, infrastructure system, that has become fairly ubiquitous, for the demographic that it Serves.
But it didn't start off that way. I shepherded it -almost entirely alone- for a decade, before I found a dedicated, motivated team that I trusted to take it over.
They have done wonders for it. Most of its explosive expansion has taken off, under their watch.
Walking away from it was the best thing that I could do for it. The last thing these folks need, is a "Benevolent Dictator," peering over their shoulders, and giving suggestions.
During the gestation decade, I had to be a not-so-benevolent dictator, many times, as people tried to take it over, change it to suit narrow sub-demographics (at the expense of everyone else), and even change its entire raison d'etre. I got a ton of pretty vicious hate mail and there are people that still hate me (I cry myself to sleep over that, every night), after a decade. In one instance, I had to wait until one nasty old bastard popped his clogs, before I could spread it to the entire Pacific Northwest.
During that time, I learned how not to behave. A lot of that hate, was because I'm actually pretty good at slapping back, but I really needed to learn diplomacy. Even when they are nasty, and we are right, we often need to just swallow our pride, and let the dervishes whirl.
I don't miss working on it, and I'm really glad the new team are doing so good with it. I suspect there's very little of my original code in it, but the team mindset is still very much what I established.
I am about to release a project that actually uses that infrastructure as a feeder to my backend.
> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed. this can be fun, for a time. what it’s teaching you is that you personally are responsible for catching mistakes.
Every team I've worked with that was feeling exhausted about code contributions actually needed to focus on better documenting guidelines but most importantly, improve CI. Catching silly mistakes is the textbook definition where automating stuff can help the most. This should improve reviewer's peace of mind and speed things up because people will work by themselves to fix things before asking for a review.
I don't know what's the CI situation in the Rust project but if it's anything like what I'm used to, it probably needs improvement. Adding more human-hours to reviewing things isn't sustainable.
CI is good. more tests are good. but there's a limit to how much they can catch.
here is an example: there is an internal type checking API called [`resolve_vars_if_possible`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/...). this needs to be called on the output of almost any call to `.normalize()`, or you will get an internal compiler error. the conditions under which you get an ICE are quite complicated; sometimes you need 6 or more items in the crate with `impl Trait` or type_alias_impl_trait or const generics involved. but it's very easy to see there's a bug just by looking at the code and seeing the missing `resolve_vars()` call.
how can we automate this? well, rustc has a mechanism for "internal lints", but they're somewhat annoying to write - you're basically writing a new compiler pass, and it needs to not have false positives. it's much easier to just catch this one instance. so the reviewer, who's already burned out, does this quick manual review instead.
yes, it's possible! that list doesn't exist today but i would love to create it. i wrote a draft a few years ago before shifting to other work; someone recently expressed interest in reviving that project: https://github.com/rust-lang/rustc-dev-guide/pull/1463
At the same time lint tools sometimes move into the 'pedantic unhelpful' field because those things are the easiest to check (no, nobody likes pep8 and its brain-dead char limit - Black is much better)
But yes, if it can be automated it should be automated
I think this is true of most open source projects, and probably all of the bigs ones.
Software in general has a burnout problem. I am regularly stumbling around like a zombie by friday afternoon, and that's just for my actual, paid job. If you added maintenance of a large open-source project like Rust ... I don't see how I would manage it, at least without letting my health -- and probably my family -- suffer for it.
I know that some people are fortunate enough to be paid for their open-source work, but that doesn't mitigate the burnout from software engineering itself. Add to that baseline stress the fact that your customer is "the internet" and feedback is often coming from "whoever is currently angriest," and it seems wildly unsustainable.
I've recently been contracted to do some open-source work in the Rust ecosystem, and this article feels like a warning from my future self to me. I'll make sure to heed it.
> “it won’t get done if i don’t do it” and “i need to review everything or stuff will slip through” is exactly the mindset of my own burnout from rust.
I've already caught myself getting into this mindset a few times.
For one particular issue, I got a bit mad because it felt like I was the only one trying to move a critical issue forward, and other people were treating it as a distant priority. In that case, what helped was moving away from the issue for a few days, and seeing other people pick up speed and make progress on it in the meantime. Having supportive colleagues is super helpful.
I don't know how much this will be a problem in the coming year. I'm hoping we can strike a healthy balance.
yes, there are lots of things you can do to get work done that don't involve you personally writing the code. i would like to write a post about that at some point but i have at least 3 blog ideas up in the air currently so it might take a while
Excuse the flippant tone, but isn't this just "I treated my hobby as an unpaid second job and I burned out because I was working two jobs"? It's worse than a job, actually; some of the stuff OP says I don't say about even my actual job. I have a set of responsibilities and I just make sure to fulfill them. If my coworkers don't fulfill theirs I'm not going to shoulder them. Am I going to give them a hand? Sure. But I'm not going to do their job for them, and I'm not going to avoid delegating because I don't trust their judgement. If they fuck up, they fuck up; maybe the business suffers, but how is that my problem? OP shouldn't be thinking the way they are even if they were being paid to work on Rust.
Brian Anderson (AKA brson, who as it happens used to head up the Rust project) wrote a good piece back in 2017 called "The Minimally-nice Open Source Software Maintainer" which has tips to reduce burnout/disillusionment in junior contributors. It's less geared toward preventing burnout at the top, but still well worth a read, and there's no reason much of it couldn't be applied in reverse.
It's not that unique or quirky when a considerable number of people are doing it. There are also other things like emojis, memes, etc, but all lowercase makes it simply harder to read.
I'm a game dev at a small studio. I have a discord full of gamers who all want me to do something or at least pay attention to them.
Every time I release something new, someone hates it.
It was hard for a bit, but I've been doing this for years.
Honestly you just gotta tune out the noise and prioritize what you want.
Open source project is a bit harder because you have to collaborate more than I have to collaborate with my gamer fans, but still, stop people pleasing and prioritize yourself.
I don't think it's in any way possible to please everyone, and even if you find the objectively-best solution, someone will hate it and be very vocal about it. Most of the folks will carry on and not say anything.
There's little I hate more than watching game devs engage with and respond to vitriolic fuming. Communities try so hard to tell people not to shit on devs, to be polite, to engage calmly and rationally, and then a certain subset of devs see a shitty, cranky post or comment getting attention and just can't help but weigh in to defend themselves.
I understand the temptation, but it's deeply frustrating to see.
I'm pretty hard on the gamers. I'm a dad now and most of the gamers are like 13 year old boys. So I try to teach them life lessons and I give them real consequences. I'm not very sensitive to negative feedback.
What's not clear to me from the post is, is the author talking about just the rust-lang projects?
Isn't this a characteristic of active contributors of many (or I daresay, most) large open source projects?
I am not an active contributor to any big OS project but whenever I stumble across the Github issues sections for one of them, they are full of "by when can we expect to see this fixed?" kind of questions.
I'm excited for the Rust project.
But to add a superficial observation: It seems that the Rust project is not very diverse.
Could that contribute to culture problems?
It seems to have a disproportionately high, relatively to society, percentage of white, male, strongly LGBT-oriented personalities, who usually have a female Japanese cartoon character, or maybe a furry, as their profile picture on GitHub.
Which is fine, whatever, but I worry that it suffers from groupthink and excludes different minds. Maybe it's hostile to plain people that just want to focus on programming? I suspect that people like Torvalds wouldn't survive long, and that's a shame.
And if you want to be really critical: Maybe the leadership is happy that specific people are leaving? Maybe burnout is a tool? Maybe it's a way of social control and censorship?
I personally hope that Rust finds more mainstream support and funding, because I'd love to work full-time in Rust for many years to come.
C++ is losing momentum as larger organizations lose interest in investing in it. Features standardized in c++20 are still not available in the most popular compilers, let alone features in c++23. The future is looking bleak.
Rust is a great alternative for greenfield projects but we really need a new kotlin-esque innovation to keep c++ alive imo.
> Or. That’s what I keep telling myself. Because it doesn’t feel like it was worth it. It feels like I wasted a lot of my life achieving something so ridiculously basic that it’s almost laughable. How utterly worthless I must consider myself, that hearing someone complain about putting data in C++ 5 years ago put me on the track to decide to try to put something in a programming language standard. That I had to fight this hard for table scraps off the Great C Standard’s table.
It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C.
Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs unwritable, like using a dangling pointer.
Why do you view that as an attack on C programmers? It's no more an attack on them than C was an attack on assembly programmers.
The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, different conventions, and complexity similar to C++. So in many ways, I find it inferior to C (although I agree that memory safety is good), but Rust people think it is superior in every way and behave like this.
It's true, not everyone has the same priorities, and Rust may not provide the right set of tradeoffs when one is deciding which language to use. I don't believe that C is strictly inferior to Rust. There are cases where it's not worth trying to use Rust instead of C.
Unsafe Rust is more complex to use than C in some ways. For example, an iterator for a slice, which contains two raw pointers, relies on the lifetime of the array it refers to lasting longer than the slice, and to encode this you need to use PhantomData [1]. Things like this make it look more arcane than plain C, simply because in C, this is implicit, and on the programmer to enforce.
> new contributors make PRs. they make silly simple mistakes due to lack of experience; you point them out and they get fixed
Sometimes the right answer is to immediately say "your PR is not up to project standards, it won't be reviewed, please revise it yourself if you want it accepted". It's not a job of a maintainer to educate every wannabe-contributor.
Thinking back to my earliest FLOSS contributions, I don't agree. Up to a point.
Some of the PRs I submitted were pretty dumb and a complete waste of someone's time to review/reject but they showed enough patience to help me get "over the hump" and to eventually get commit access to the repo -- which didn't really help with getting features implemented because I have an apparently unlimited supply of dodgy ideas and would get "why is this needed?" a lot. I also had a habit of getting code to about 80% there before doing a PR "for discussion" knowing full well the lead maintainer would fix up the remaining 20% if it were a valuable enough addition.
Probably also helped that the project has a history of working with GSoC students and the devs were a generally helpful bunch with getting new contributors up to speed on the codebase.
Honestly, if they weren't so welcoming I'd be half the halfassed-coder I am today.
* Do not allow questions on GitHub issues, it's a poor place for conversations. I find Discourse or some other forum (or mailing list) a better place to do that, which allows community participation (and you can automate moderation using something like https://github.com/pierotofy/issuewhiz)
* People owe you nothing, just as you owe them nothing; you don't have to fix an issue or merge a pull request because somebody opened one.
* Try review and merge contributions, but on your own timeframe. If people have urgency, kindly invite them to get a paid support agreement.
* Don't engage in quarrels; you always have the option to ignore or ban the offenders.
That might be, but then don't wonder if people look at you strange if you tell them you got burnout from a job where you never met any colleagues and didn't get paid either.
On top of the usual problems of a project becoming about maintenance and negativity, languages are destined to become diminishing returns and new languages always end up ruining themselves trying to add more to the foundations.
You can see with D, Rust, haskell, and whatever else, the transition to working on an ecosystem with easy to use and polished tools, IDEs, debuggers, autocompletion just never happens. The languages that get heavy use like C++, java and python solved the chicken and egg problem of having an ecosystem at some point where there was an actual workflow instead of just a hacked plugin and a command line.
The things that cause burnout like high expectations, pressure and endless bureaucratic project management slog sound like any software development job. Except the devs aren't getting paid which exacerbates the issue.
I'm surprised at how many people seem to focus so much on the effect of incoming PRs that require some mentoring to get them to a mergeable state or on "entitled users". I don't think those are significant contributors to burn out in the Rust project. Those you can ignore. More significant is "X is important, but I'm the only one that thinks so, so I have to carry X to completion single handedly". That causes a lot of the demoralization and heartache and guilt that contributes to burn out.
they both contribute a lot, although rereading my post i realized i dedicated more discussion to review burnout. i think it's a question of whether you feel more of an obligation to your users or to other people in the project, i've noticed you and i differ there.
for me particularly, reviews were bad because there was a time component, if i waited too long people would get frustrated and give up.
I enjoy helping people get up to speed, but after a while it becomes overwhelming for sure. It's just that if I'm not around for some reason I know that others will review things, eventually. PR reviews will continue if I get hit by a bus, pet features likely won't. I am happy that other people have taken some of my stances around DX and run with it, so at least on that one facet of the project I feel like I succeeded in becoming dispensable.
Not sure if this is Rust specific though; if anything Rust is easier to review because the compiler takes care of a large class of problems like use-after-free or race conditions. You let the compiler do the "review" on your behalf on most common issues and mainly focus on logic errors, which makes life much easier IMO for the reviewer.
> i’m not going to name names because either you know what i’m talking about…
Consider: this attitude of nod and a wink “can’t name names” strongly contributes to burnout in every community i’ve seen it in. Rust has it in absolute spades, but i’ve seen it eat other groups alive too. Maybe we can stop doing it.
this is mean-spirited. i am not talking about malfeasance in the project, i am talking about people who are trying their goddamn best and whose lives and jobs are at stake. what benefit do you think would come from announcing to the world "hey this person might shortly be unable to do the work that makes them a living"?
> if you are paid to work on rust, you likely started as an unpaid contributor and got the job later. treat it like a job now. do not work overtime; do not volunteer at every turn; do not work on things far outside your job description.
But if I don't work overtime how can I rewrite everything in Rust?
It felt like a depression. But only of the core development. Organisation and ecosystem are evolving. The layoffs by Mozilla in 2020 might play a role here. On the other hand, when withoutboats started writing about async again recently, it felt like the sun rises again.
I assume you say that be cause they don't capitalise the first letter of a sentence, which is fine since it's an informal blog post. This isn't a journal publication
I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them.
Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.