Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
gist.github.com
gist.github.com
I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct.
This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You can't just call library functions from a multi-threaded context without understanding if they're thread safe or not, if they're reentrant, without using appropriate buffers or handling errno correctly.
Well, you can, of course. But then you have bugs, and crashes, and race conditions.
I don't mean to come off harsh but this is pretty bog standard stuff. Maybe the author is new to all of this, maybe not, but complaining about perfectionism when the issues being raised are almost entirely real actual issues really rubs me the wrong way.
Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years. The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping. The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. I don't think any project maintainer ever wants to accept contributions that make their life harder.
And I have a PR to fix problems in another Rust wrapper of the same libc functions: https://github.com/uutils/coreutils/pull/2653
It's hard to get right. Skimming the PR, the feedback looks reasonable.
Whether or not you are right on this issue is this really the way to generalise about current / potential contributors?
Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?
Edit: I’m making no point about quality or otherwise of contributions or whether maintainers should accept them. Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.
Perhaps this part explains all the commotion around rust... being a popular new language with strong opinions, but today there is a lot of entitlement going on in software communities, assuming that it makes sense to integrate inclusivity to such a degree that it's actually incompatible with what makes a cohesive opinionated project.
I'd generalise it: There is a lot of entitlement going on right now.
I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :)
The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try?
I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.
"90% of everything is crap." -- Sturgeon's law [0]
The problem is that once someone has put in the time to create a PR, declining it is never going to feel good for the contributor.
Yes, they can maintain their own fork with their changes. But to be told "this doesn't work for our project," no matter how politely, is often emotionally interpreted as a form of rejection.
Which is what spawns the kind of rant above in the original link.
I would also agree you are going to get some amount of crap no matter what. But, i would say if you want this to be different, it's not entirely on other people. Even with the best of intent, you can't expect contributors or teams or processes to behave magically just because they should. You usually need to motivate/incentivize or train the behaviors you want, and iterate the processes and your approach until you are getting what you want.
After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.
Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe.
IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tried anything specifically.
In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement.
Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;)
But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people.
There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people
That takes work, sometimes quite a lot of it, and there's no trick around getting the work done any easier.
A lot of contributions to open source are simply worth what you paid for them, which is nothing.
Early in a project it is possible to find areas of the codebase where easy things haven't yet been done because there just haven't been enough programmer-hours done yet to burn through the simple stuff. Late in a mature project the easy things have mostly gotten done and finding more easy stuff becomes difficult, and as you pull apart simple looking issues they start to look hard.
I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed.
And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.
I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there.
His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"
> expect to be treated kindly
Do you see why the first might make someone doubt the second?
If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage.
It takes time and patience to refine it into something good. It doesn't mean you shouldn't try.
If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best.
Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade.
If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved.
If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors.
But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions.
A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way.
Rust offers all of these.
Or an accurate depiction of reality.
You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.
I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good.
So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting.
The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor.
So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.
Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right.
Please remember, the bar has been set this high by successful projects.
One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.)
That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.
I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (scare quotes) to bad code.
So even though Linus Torvalds and his trusted lieutenants constantly complain about terrible buggy code that wastes their time, Linux still attracts new contributors (and this means more "bug ridden garbage").
EDIT add specific example... I think this 2014 Linus Torvalds complaint about programmer's bad code from has the "unwelcoming atmosphere" you probably wouldn't like : http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
... and yet people keep attempting to contribute to the Linux kernel project.
Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that atmosphere of harsh critique has been there from the beginning.
And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?"
Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.
Anyways, I'll ignore for the moment that your argument wasn't actually about linux in 1991, since you used an example from 2014 and said that people continue to contribute, implying that you think recent friction is relevant, because either way it doesn't hold water.
Even by 1995 Linux was already on its way to becoming a juggernaut, so the window of time in which Linux was "small" is pretty short in the grand scheme of things, and I think a convincing argument could be made that of the "free OS for x86 machines" projects that existed in the early 90s, linux was actually the easiest to contribute to for various reasons. I think it's actually likely to be an example of the opposite of what you're suggesting, which seems to be that "friction causes no harm". We might all be using something derived from 386BSD or Mach (perhaps even HURD!) if that were the case.
In other words, I don't think "Linux in 1991" is a substitute for an argument about "Alacritty in 2021". There is very little in common between these two projects or circumstances.
No, my argument was about the entire timeline of Linux kernel which was a continuation of gp's (xyzzy_plugh) example when he wrote: >Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years.
I just picked one random example from the last 20 years that happened to be from 2014. It could have been any of the hundreds of harsh messages in the USENET archives of 1990s of Linus and others berating people. Linus's tone was even more hostile before 2014.
> what you're suggesting, which seems to be that "friction causes no harm".
I'm not suggesting that at all. Instead, I'm pointing out that the gp's mental model of new & incompetent programmers not "attempting to contribute" because of an unwelcoming atmosphere is not correct. The Linux kernel has always had newbies attempt to contribute bad code even when it was a "toy project" compared to Alacritty.
To put it another way using a reverse perspective from gp (klelatti): A project that publicly advertises its dismissive attitude towards incompetent programmers also _attracts_ a certain subset of programmers who think they can meet the high bar to contribute. This counterintuitive reverse psychology does not seem to be included in his mental model.
I think you're really underestimating the rapidity with which linux grew, as well as the pure cachet that linux (or any project associated with Linus, like git) has and has had for most of its existence that makes it fundamentally different in terms of motivation and appeal from basically any other OSS project.
If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine.
Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?
This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
(In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they want in, and surely they'd see the problem, I don't think it looks like gate-keeping pedantry? (NB the repo was unmaintained, I was recently added as a collaborator, so older issues/PRs with no maintainer response aren't a counter-example, I'm just in the process of sorting through them.))
The author of that comment was talking to us about low quality PRs, not a specific one, to an author of one, nor in feedback comments on one.
It's not about PRs. Read it carefully. It's a comment about 'most programmers' who apparently don't have characteristics that mean they can do anything but produce 'bug ridden garbage'.
> The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping.
i.e. the context is reviewing (however that's done) contributed code.
But no, it's a comment on the characteristics of people contributing to projects.
It's saying that they are not capable of making a quality contribution.
Your reply here is some serious pedantry, you're essentially arguing that the output of most programmers is totally disconnected from the abilities of most programmers.
Really, what other relevant external indicators of the abilities of a given programmer does anyone have access to besides the code they output?
2. You don't have the patience, skills or experience to write anything other than bug ridden garbage.
Not pedantry at all so see a big distinction between these two statements.
In fact almost a textbook study of how to / how not to give feedback.
And regarding 2, the original was a general statement about the existence and prevalence of (low) skill; not an indictment against any specific author of 'garbage' who may (or may not) be capable of better.
But isn't that true? At least not right away, which is why the code gets reviewed. I'm pretty sure everyone writes bug ridden garbage, unless they're not already intimately familiar with the codebase already.
Or even because of it - as this kind of language can mean "I wont sugarcoat it, I'll say it like it is".
It's up to the receiver of that feedback to be able to see this.
The efforts are mostly irrelevant if the result has serious problems.
And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough.
So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.
Because they are adults with enough emotional maturity to not require constant encouragement in every aspect of life.
It's one thing to make negative, targeted statements against an individual contributor. It's another to make a likely true, slightly negative outlook about the quality of contributions on average. Potential contributors should be responsible for maintaining their own emotional equilibrium in such a case, in my opinion.
I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to.
I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.
Can you see the issue here?
I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright.
Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive.
Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.
If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.
I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required.
For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.
Because if they pass the bar knowing what it is then they also know that they're part of the club of developers who have the "patience, skill or experience to write half-decent code that isn't bug-ridden garbage."
People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said.
So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was.
Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that.
Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself.
I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.
Isn't the parent's whole point to discourage them from contributing?
Contributions are very often scratch-my-own-itch bugfixes that don't consider other users or the project at large.
It is easier in projects that are greenfield where there's few existing users and a more cowboy attitude toward getting any code accepted to move the project forward.
In mature projects that have lots of complicated requirements and external APIs that can't be broken it becomes extremely hard for external contributors to be successful because contributing becomes something that resembles actual $DAYJOB work that people get paid for. Which is a lot of sitting around for hours thinking of ways that the simple and obvious solution is poor and needs to get tweaked, then hours of sadness over breaking existing tests and refactoring the whole idea until you boil it down to something which is often quite a lot of work and may fix many problems outside of the initial scope of the issue, spread over multiple pull requests.
That is what software development in a mature codebase looks like, and its not something that is fun and something that people usually want to get paid to do.
Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions.
Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not a rocket ship.
I'm not suggesting you should just have totally bug ridden code, but if you are putting people through years of in-PR iteration on a thing to achieve "correctness", either 1. Close it because you won't get what you want 2. Accept it and improve it prior to release.
I'd point out: If it is really this hard for reasonable programmers to get it "correct", do you really think the people on the other side of the PR are so good at programming that they are getting it all right too?
I've watched plenty of really good software where the dev process amounts to:
1. Integrate code that is more experimental into the development trunk
2. Let people discover what is wrong with it
3. Fix and iterate it
4. Release.
The approach on some open source projects amount to:
1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process
2. Integrate code (or sometimes just give up and throw it away!)
3. Discover there were bugs in it anyway, because no code is perfect. Fix them.
4. Release
I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse.
One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc.
The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)
> 2. Let people discover what is wrong with it
> 3. Fix and iterate it
This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release.
In some cases, it can be acceptable to merge code that's clearly marked as experimental into the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.
So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :)
One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that.
I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).
I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.
I think you are not wrong in the limit, but it's a bit more complex than that:
1. You need to set expectations up front of what it means to contribute.
2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively).
But we often suck at training people at things they aren't used to. Training goes a long way. etc
Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :)
I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not.
I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"
The author made a number of comments on the PR about how they expected it was almost done while there were still outstanding concerns from maintainers. The author stopped responding to comments when their employer's priorities changed. Someone else volunteered to finish the author's incomplete work, then the author closed the PR, complaining about being tired of seeing it in their PR list.
The maintainers spent a fair amount of effort explaining many (basic Rust) things like the extremely unsound API design of dereferencing a user-supplied raw pointer. They were trying to help.
This just doesn't seem like an individual the maintainers have any reason to trust.
> The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code.
I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.).
To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.)
On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions.
Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.
Yes. But we are talking about a terminal emulator. And not even about one bundled with a DE (or OS). This _should_ be exactly the type of project where people can get their first OSS programming experience.
Generally speaking, these 2 things alone are basic errors when coding proper Rust. There were also many minor issues with the PRs that it seems the maintainers attempted to work through with OP.
Unfortunately learning the basics of a language like Rust is hard. Learning how to write correct Rust is even harder (and sometimes impossible without the right background knowledge). Learning how a project expects PRs to be designed and formatted is less technical, but takes dedication and time.
These PRs are riddled with things that are just straight incorrect.
Also, generally you are right about beginners starting with easier projects like this, but as many others in these comments have stated, the general bar is not low. Projects decide how to manage PRs. Nobody is stopping you from creating a terminal emulator in Rust that caters to beginners in Open Source. My guess is that the project would not be as good as Alacritty.
Also, the maintainers of any open source project don't owe you or anyone (including contributors) anything.
What I'm talking about that you can't expect the same contributors to a critical part of infrastructure as to a, well, more or less useless terminal emulator.
You can't do the 45327th copy of something (yes, yes, I get it, it's in Rust) and behave like your project is the Linux kernel or the Rust compiler.
Why not? A terminal emulator is probably one of the most-used apps for a lot of devs.
Plus, "useless things" can become great in time with a relentless focus on quality, understanding what their users need, and a vision for both the product and the implementation. There was a time when Linux wasn't regarded as a "real" OS, too.
Be careful of slamming unpopular projects for being unpopular. It's not a good look.
Yes, misleading claims about project importance would be a bad idea.
But decisions like
> This _should_ be exactly the type of project where people can get their first OSS programming
is up to maintainers, not up to random people not running this projects
It is 100% up to maintainer of a given project, they are not obligated to do this.
People are 100% free to pursue sky-high reliability and bugfreeness in their project, no matter what it is.
Of course they are. But they should not complain that the only people interested in their project are, well, not super-star programmers but beginners.
In other words: they can wait for the other programmer who is almost ;) as perfect as they are. But chances are these people are not interested in the 4535th copy of $TOOL (if they were, they would probably write that themselves - that's why there existed 4534 versions of $TOOL).
Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.
As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.
Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement."
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
I see no expectations, or demands in this post. Only disappointment at what OP sees as a missed opportunity.
OP is a pretty prolific contributor to open-source, and I get that ones purview doesn't extend past ones owns projects, but it certainly affords perspective. I hardly think any of the comments in this post are anything OP or any project maintainer should take personally or as undue pressure. It's simply well-trodden commentary [0].
[0] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
well, technically you are entitled to the source code
A gift of someone else's effort to contribute and push something forward.
A burden because once received, future maintainance of the gift is really on the one who received the gift.
It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other animals stacked up behind this one?
I don't think it's constructive to paint the approver as gatekeeping, or perfectionist. What does that achieve? Surely it's better to meet halfway on the gift exchange, thank you for the PR but it does need to be house-trained and socialised, etc.
(Earliest use I can find here – https://twitter.com/devbisme/status/1017520086096207874 – but perhaps goes back much further.)
Rejecting a gift is quite a rude gesture. Rejection a PR contribution until it receives further iteration after some thoughtful feedback is anything but a rude gesture.
I think this mindset that open source maintainers are obligated to accept PRs as gifts is the source of much of this frustration. The PR should be a starting point for further discussion, iteration, and collaboration, not a one-way gift that places a burden on the maintainer to satisfy the wants of the contributor.
If you disagree with maintainer priorities, just fork it! Merge whatever you want, advertise your fork in the unmerged PRs' comments, see what happens. Nobody will be offended; the license specifically encourages this.
Maybe you'll find you're just better at this maintainer thing and the world now contains better software, or maybe after a few years you'll find that you understand their perspective.
Also a lot of the delay was because you didn't have time to work on it as you mentioned in 2019 :)
I'm not a developer but I read through the thread to see what it's about. But I think most comments were constructive criticism or just non blocking suggestions even.
Though code quality seems to be a higher goal than in most projects I know, that's kinda admirable too. I can imagine your side too though, it's frustrating to be working on something and not seeing it go forward.
He only apologized for not removing the shooter's manifests. He didn't apologize for GamerGate, CP, racism, neo-nazism, and other terrible things. His words about the 8chan shutdown - “I was not even that upset about that” [1]. You can’t call it “fighting”.
[1] https://jacobinmag.com/2021/04/fredrick-brennan-8chan-intern...
Though like I said I don't agree and I think the devs merging it had justified concerns.
* The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various *nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. The author unfortunately chose a particularly messy and bug-prone corner of the POSIX APIs to wrap, and ran into a correspondingly intensive review process. I've merged simpler wrappers[1][2] with no fuss.
* Alacritty seems to work just fine. I switched to it about two months ago, after using nothing but (heavily customized) rxvt-unicode for a decade. Maybe it's because I don't use ligatures or images in my terminals (I thought we were talking about non-"toy" functionality!), but I haven't found myself wanting for anything beyond what Alacritty already does. And the scrollback seems to work nicely. To summarize: where's the tragedy?
IMO core maintainers call the shots on what to accept and what not to. As others have mentioned, if you don't like it- fork and build your own.
One thing I've learned from working with him a little bit was that there's a huge importance to both the medium and the timing of the message. Balancing even just IRC and GitHub PR comments is a tough game to play, but it must be played if you want to be successful. Treating PRs like IRC will get you in trouble, while reading IRC like a PR might leave you in the dust. Knowing when to move an argument from IRC to a longer form like a PR or Issue is a critical skill (one I never was very good at).
Chris and team, if you happen to read this. Thanks again for all that you do.
Please don't ever post things like this. If you're this frustrated that the people who make free things for you aren't donating their time to you in the way you'd prefer, grab a drink with a friend and vent to them in private instead.
> Please don't ever post things like this.
What the hell, is this against any HN policy? Or you think no one should post their point of view here if it's against yours?
EDIT: I think it's important to note that burnout is a result of you having an issue within yourself (at least in the context of voluntary projects), it's not something others do to you... you can choose to ignore all pull requests, for example, or say in your README that you won't accept any (I've done that myself to projects I wanted to keep in a certain "permanent" state for reasons). If you choose to engage in discussions, that's your call.
I think this is an oversimplification. You can be perfectly happy with yourself, but if your environment creates a neverending treadmill of situations that drains your soul, you will get burnout if you cannot find any mechanism to cope with it, to avoid it or to deal with it.
And in open source we are each others environment. If you have 100 well researched issues written in a friendly tone you will certainly feel a different motivation to tackle that backlog than if it are 100 toxic spitting well-researched issues. The same goes for how we talk about each other in public. If you think a PR should have been merged, just talk to the maintainers in a non-public setting (Chat or whatever) and explain why you want it merged, what you would be willing to do for it and how they could see this happen. If they still don't like to do it, just fork it and do it yourself.
I agree with you it's more complicated than that, but you seem to be supporting my point by saying this :)
... you will get burnout if --> *you* cannot find a way to cope... --> *you* cannot deal with it.
It's like offense... it must be taken to work... I know, I know... sometimes you cannot avoid taking it and bringing it with you because you care about others thinking you should be offended, or that they feel offended on your behalf even (with seems to be a common feeling today), but I find it great that the English language uses the term "take offense", as it is so accurate: if you don't take it, it simply evaporates, no one can offend you and force you to take offense if you choose to not do it.
Same with burnout.
In this case, requirements about code quality and even refusal of code likely to introduce bugs is being called "gatekeeping" which is complete nonsense.
If you refuse a merge request for good reason, you don't deserve to get shit on by some salty contributor who doesn't want to bring their PR up to your standards. This article seems to indicate that any PR intended to be helpful must be merged, whatever the cost in maintenance, because otherwise you're gatekeeping.
If you refuse a PR for bad reasons ("I don't accept contributions from Chile because I had a bad holiday there once" and more racist/sexist variants thereof) then you definitely deserve criticism. What's happening here isn't really criticism, though, it's childish ranting about other people not putting in enough free work for the author and how that is somehow damaging to the volunteers, disguised behind polite words.
I think the world owes maintainers no protection from real, useful negative feedback, but a lot of negative feedback is just people being angry that they don't get their way. In a civil internet, that kind of behaviour has no place being called "criticism" and being assumed to just be par for the course of open source.
I've decided I never want to be an open source maintainer exactly because of the entitled people who write these articles, and I don't think I'm the only one being pushed away from open source for this reason.
I strongly agree with you. I know gatekeeping has negative connotations and has become a sort of generalized boo word in some circles. But I'm glad maintainers act as gate keepers. Some code is crap and some coders aren't very good. Or, at least, their abilities don't match their ambitions. Someone has to keep low-quality work out of open source projects, and it's not a job I would want.
Nevertheless, quis custodiet ipsos custodes? The real problem with gate-keeping is when the gate-keepers aren't accountable. Criticism is one of the ways we can keep them accountable.
It's the same many areas. I want engineering schools and guilds to gate-keep so bridges don't fall down when I'm driving across them. I want news and book editors to gate-keep so I don't have to wade through acres of dross to find worthwhile content. And I want maintainers to gate-keep so open source software works when I need it.
Me too, it's kind of the whole point of being a maintainer :-)
Lack of contributors also causes maintainer burnout. The best way I know to have zero help is to treat a contributor poorly. Sometimes it cannot be helped, for example, when a contributor sends unusable code or a contribution forces a decision the maintainer isn't ready to make. Most scorned contributors will do exactly what Frederick did in this case, vent and then find a similar project to contribute to. In this case the similar project is Kitty, which is a fantastic piece of software.
> Please don't ever post things like this.
Asking people to shut up, not matter how politely you do it, rarely works. The problem will remain, and people will still complain about it.
Why do you think people should unconditionally accept code into their own codebase? Your wording also suggests that you think the maintainers are somehow leading you on to doing more work. Have you considered how much work doing proper review is?
The Rust community seems toxic, in the Wikipedian way of being unwelcoming and unfriendly without ever dropping into incivility.
This is why it is important for a channel of communication to be opened between all those interested in the project (a chat group) to grow rapport.
On the other hand it can be high because you’ll be the one on call when it blows up in production, or having to scramble with an emergency security fix.
When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which reduces the number of branches - if I see it as worth changing I'll do it myself after the merge. I'm not looking for all the reasons why it can't be merged, I'm looking for the minimum changes needed to make it comply with the codebase's existing standards.
This post also highlights one of the reasons I fell out of love with Rust. There's too many ways to do things.
It is like spending a ton of money on a big, bulky, but useless to a recipient present, giving it to someone and then complaining that they don’t take it - you had spent all this money!
The way out of this is to be more proactive and discuss first and then get to coding. Oh, and be prepared you would need to code an approach different from what you wanted.
And there is absolutely no shame in forking the repo, doing the changes you could not get merged, and keeping it around for your own/your org use.
It is all about tradeoffs.
I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.
I have been on both sides of this situation over the years, but it was never too extreme.
On the maintainer side: I have a small project that has picked up some pace recently, though is still rather small, and there has been only two situations where i said “this feature is not going in no matter what”. Because it will increase my burden as a maintainer and main author.
On the contributor side: If the maintainer in a timely fashion suggests some changes that seem reasonable, I am happy to spend the time doing them. Often they will give an “outside” view that will make a patch better.
Sometimes I saw them being quite selective about what they want to merge, whereas for me “just that bit” solves a real need and I see the request as too much work - then I just leave my fork as is and use that for what I needed. I see their rationale, and I am thankful for what they have done. And I leave my modifications in the fork in case someone needs them or wants to pick them up and improve.
The freedom with open source always should go both ways.
Some folks are insistent that their PR and their specific problem be addressed by your project, and the effort they put into writing code before discussing it just increases their attachment.
“But i paid a lot for it!”
100% agree! Someone unfamiliar with the code base takes the time to make a change that improves something, for free and without asking for anything in return... I always try to take it as it is, only asking for changes that are really necessary to avoid bugs or serious problems, then I normally go and do a post-merge cleanup to try to keep things organized in the way I want (which is hard for outsiders to do themselves).
> There's too many ways to do things.
Exactly! That's why Rust PR reviews are always dangerously close to descending into nit-pick shit shows - there's ALWAYS a 0.1% nicer way to write something, you can always change it to make it 2% more efficient, or to avoid allocating as much memory, or avoid using explicit lifetimes, or avoid dynamic dispatch.... the list goes on.
Well, it is your project or your team's project. It is entirely legitimate gatekeeping.
Questioning that is the bad side of the "social coding" touted by Github. IMO "social-anything" is like the Force in SW, it is easy to fall for its dark side if you don't keep your emotions in check.
An open-source maintainer should be gate-keeping the project.
Open source is great in that it enables many people to suggest improvements, but the PRs should be viewed as a proposal for collaboration.
Not all PRs are created equal. Far from it. They span a very wide range of quality. Letting every PR into the project will quickly accumulate a lot of technical debt and place even more burden on the maintainers to do further work to undo the backwards steps of the bad PRs.
When keeping quality high (or even just average), gatekeeping isn't inherently a bad thing.
Not saying this is the case here but there are two ways to look at it.
Btw the PR didn’t get merged yet because we need to fetch data using an api of another source which is poorly documented.
They state that reviews are not only meant to ensure good code, but also good coders. That means mentoring, but also merging the code if it's not perfect. Then, afterwards, when touching the affected part of the code again, cc the original author in a fixup PR. I have first-hand experience with this way of reviewing and I really like it.
They key, from what I've seen, is to facilitate useful conversation. Keep comments relevant and people will learn. Avoid politicking, while still providing evidence for your case. Typically, show your own work. The best review points clearly towards a better result.
Finally, acknowledge your own limitations as a reviewer. We're all human, to pretend otherwise does yourself and others a massive disservice.
(But what do I know. I've been out of the game for a while now.)
Sort of, yes. People develop confidence and expertise from repeated success at accomplishing things. Success creates confidence creates more success. You have to give people room to get that flywheel spinning for themselves.
This works just as well, and has the benefit of not introducing bugs and security problems: "Thanks! I can merge this if you fix A and B."
BTW - much better to get the flywheel turning in the right direction early. It is very hard to turn a gyro once it starts spinning.
I’m guessing this is about https://github.com/alacritty/alacritty/issues/3926.
I can well understand this being knocked back; as a non-user of macOS I would knock it back too. The main proposed option is frankly a fairly poor reimplementation of the logo and loses too much of the character of the original logo. A more conservative adjustment might stand a better chance. (chrisduerr also quibbles over the idea of maintaining different icon graphics for different platforms, but I suspect this may be more a further complaint about something that he’s otherwise already not happy with: that if the proposed icon was actually true to the Alacritty logo he wouldn’t object so much, though it’s still not an entirely unreasonable complaint—Apple are probably going to change their style in another year or two anyway.)
Admittedly the current icon isn’t great, because it’s taking the full width available to it, where native square icons look to go for 10% border on each side. I imagine you might have much more success just fixing the icon’s scaling (e.g. down to 90%—because it’s not square, 80% would probably be too far).
You could also try adjusting the aspect ratio just a bit, slightly squarer, but leaving everything else the same—that’d be about as conservative as you could get while still varying it for macOS. That’d make it a fair test of the idea whether chrisduerr is actively against having different source icons for different platforms.
As the designer of the original Alacrity icon[0], the icon proposed in your linked #3926 is close to how I would design the icon for macOS today (although I prefer semanser's version in #4726[1]).
I respect chrisduerr and the talent and monumental effort he's put into maintaining Alacrity over the past couple years, but shutting down the macOS icon proposals—which do not increase the maintenance burden of Alacritty and are obviously strongly desired by Alacrity's macOS users—is not reasonable.
[0]: https://github.com/alacritty/alacritty/issues/285#issuecomme...
[1]: https://github.com/alacritty/alacritty/pull/4726#issuecommen...
I simply made my own[0] and replaced it on my machine, easy enough and I fully respect the maintainer's position. It takes 30 seconds to replace the icon with an alternative, in fact you can probably automate it if you wish.
Finder, Slack: Squircle
Chrome, VS Code: Logo in a white squircle
Alacritty, IntelliJ, Firefox, Obsidian: Unusual shaped logos
VPN: Circle
Webex: Squircle, but scaled wrong (different border radius and aspect ratio)
So only about half are squircles, and one of them is not the OS X squircle.
This is the reason why FOSS survives the test of time so well. At least quite a bit longer than enterprise software, which commonly has to be rewritten next year.
The author is a "worse is better" programmer who finds themselves surrounded by "the right thing" people. I think the addendum the author adds a year later in the top comment is the right insight: fork away. This keeps the "the right thing" people happily obsessed with getting everything right, without the author being blocked on moving faster.
So for maintainers merging PRs with known issue is basically promising to fix everything not finished.
It's the users that give motivation to work on the project. Working on a PR is like working on spec. Working on the development branch gives you direct access to the "payment" of users using your code.
- creators are more likely to abandon or ignore projects that have low popularity or are completely unused - creators are more likely to be burned out when there are piles of demands, requests, complaints etc
No, it was just supposed to be one of the many projects with ambitious goals, that more often than not, go nowhere, and are abandoned a few years down the line...
If you've been on the scene long enough, you've seen thousands like Allacrity: editors, shells, terminals, DEs, new languages, etc.
What makes for a project's success then?
Is it the leadership? The raw motivation?
How do you facilitate interest?
Where are the developers and productive users coming together to talk?
I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust. When I look around and compare tools, mostly, I see nothing but the same song and dance.
I've seen a few factors play an important role:
(a) dev's persistence - many projects come with grandiose goals, go some of the way, but the dev loses interest after 1 year or so and abandons them.
(b) good marketing - many project are good and maintained well, but just don't market themselves nicely. A nice landing page, examples, documentation, screenshots, and even some superficial stuff like a nice logo and icon, all play quite a role in the success of one FOSS over another. It's not enough to welcome users/contributors, you also need to make yourself known well.
(c) solving a unique need (this is not necessary - e.g. you can be "just another editor" and do well - but it's a big bonus if you have that.
>I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust.
About Rust yes. It has proven itself, shipped code in major companies, got books, wide adoption, even interest from Microsoft, Facebook, and others.
Allacrity, I'm not so sure. A lot of big early claims, but still nothing special to write home about.
It's also that Rust solved a real problem (memory safe, close to the metal, modern language), whereas Allacrity is just one of many terminals.
And nobody really thought "what I need is a secure terminal" - as if terminals are a big security issue. A faster terminal sure, but there are several plenty fast terminals, with GPU support and everything.
Started with alacritty, but without tab support, was a deal-breaker for me.
I use tabs in kitty with tmux on each tab. Each tab is a context in my environment (dev/services/ansible/terraform/etc).
So now I'm just using st with a ligature patch. Not perfect and rather slow when dumping a lot of text to stdout, but it's otherwise snappy and does everything I need.
2 examples extrapolated to the whole community and language.
Is there any particular reason to resurrect it from 2020?
I'm the author of this post, I did not intend for it to receive wide circulation, and only have shared it in the past year with a few friends and MFEK users to explain my views on forking in Rust, why MFEK relies on so many vendorized crates etc.
I added some more recent commentary to the comments of the Gist: https://gist.github.com/ctrlcctrlv/978b3ee4f55d4b4ec415a985e...
I have also updated the Gist itself with a note:
> I did not submit this to Hacker News and did not intend that this post would have high circulation but have no real problem with it being there or with it having such. I have [more recent comments below](https://gist.github.com/ctrlcctrlv/978b3ee4f55d4b4ec415a985e...). This post is from January 2020 and predates the Modular Font Editor K (MFEK) project.
Cheers.
It was easier to start fresh than get PRs merged. This happened even for clean kill bug fixes.
For my own projects, my bar for merging is "Does this improve the project". If there's a code style issue I don't like, I'll merge, then make the change myself after. If it's an idea I don't like, or determine is out of scope, I'll state clearly that I have no intent to merge it.
Sometimes these are an issue of available maintainer time. Eg, the maintainer may be busy, and doesn't want to dedicate time to a project. So, you end up in code-style debates, where response take weeks etc. It's mismatched expectations between maintainers and users. Or if the maintainer doesn't have time to test or evaluate a change in all cases, a conservative call is to not take the risk of unforseen consequences.
Overall: I also agree with the points others here make about the owner-maintenance burden of PRs, no obligation to merge code you don't agree with, validity of safety concerns etc. It means you need to treat these on a case-by-case basis. In the case I outlined above, it would have been preferable not to fragment the embedded Rust OSS community by introducing a fresh HAL, but I had to to meet project requirements.
I admit I personally have never participated much in open-source development because, even as an experienced software engineer; I've never had many good experiences with merging code into public repositories, unless it's a very small project, where contributions are very welcome, because the level of perfectionism maintainers require from first time contributors kills any enthusiasm one might have even in the smallest of changes.
The main challenge in open-source is communication.
Of course, if it's too strict then people will stop contributing entirely. But if it isn't stright enough then the project can suffer from bloat and a lack of a unifying vision.
This becomes less of an issue if there's some level of expectation management involved. e.g. here is what we would like contributions for, here are things that we won't, and if you're unsure about any of it, open an issue about it before investing all your time and effort.
Not every occasional contributor will become a project member, so it makes no sense to impose too much burden on him. Maybe he only wants an interesting feature added.
Some of them will eventually become interested in becoming regular contributors, and that is even better, but every one should be left freedom of choice.
In my experience as Etherpad maintainer (1.6.5 through 1.8.4) this approach worked very well. For example https://github.com/ether/etherpad-lite/issues/3540 (and the related PR https://github.com/ether/etherpad-lite/pull/3559) where deep changes that went very smooth, not only code wise, but above all wrt the relation with the contributor, who was smart and collaborative.
But from sidelines, I find it ironic that a project whose name is a play on the word 'alacrity', meaning "cheerful readiness, promptness, or willingness", is earning criticism for its plodding perfectionism & willingness to say 'no'.
(Maybe users/contributors are subconsciously applying a higher standard via the connotations of its name?)
read more:
"Polite Technology
This is a book about the social interactions and situations that are the underpinnings of the open source world. It's about how humans collaboratively create software."
Edit: punctuation
We try to make our terminals do things no terminal (remember those boxes with a CRT that used to be in a room, then became ubiquitous enough to end up on our desks) ever did, or considered doing. Do I enjoy being able to partition a window without needing tmux? Yes. Do I like text reflowing when I resize the window? Sure. Do I find Tektronix mode useful? No. Do I find it fun? Of course!
We all are passionate about some thing or another (I, for instance, maintain an IBM 3278-2-like terminal font), but I have to agree that, when someone says my suggestion for adding smooth scrolling or double width/height attributes to VTE (I promised to add Tek support to it, but, like so many other side projects, I didn't have the time to start it) is niche or, worse, a Terrible Idea, they are not doing that out of cruelty, but from a position of "I'll have to maintain this idea only you like forever", and, in their place, I'd probably do the same (as I have in the past with `pip-chill` (another thing I maintain), when I think an idea is not great).
OTOH, from the other side, I'd love to see https://github.com/urwid/urwid/pull/434 merged :-(
And, of course, having https://github.com/htop-dev/htop/pull/736 shot down was disappointing, but understandable.
For what it's worth, I think this is an incredibly healthy attitude for a project maintainer to take. There are a lot of ways to go wrong managing a software project, and this attitude is a good way to avoid a big subset of common mistakes. It comes with downsides, of course, but it's important to think about the upsides too.
That said, I couldn't keep up with the arguments and decisions, while also balancing my own (disintegrating) life. I feel that we are all suffering from the effects of others far too heavily these days, so much so that good projects like this are labeled a "tragedy". That is completely unfair blame. The tragedy is not of Alacritty, it's of us. It's our fault we haven't fixed the issues. It's our fault all the comments and messages are loaded with unnecessary emotion. Well... it's at least partially our fault. Sometimes it's true that the squeaky wheel gets the grease. Sometimes it's also true that dark powers work against us. Still we must look at our own part in the equation.
Personally, reflecting on this post from the start of 2020, it's hard to think of anything but my own failings in the last years. But that too is not fair. It's something I must simply work to improve; like always. Leaving the world a better place than where I found it. I know there are amazing developers still working hard on important issues. It kills me that I'm not helping as I could be. It kills me that I'm often stuck, fixing bullshit issues and wasting time on things that are out of my control. But that's how it is now, and that's how it's been too, just perhaps to a lesser degree for a time, when everything clicked.
Perfection and correctness and idealism are lofty goals. But realism and practice are required while on the hunt. Maybe one day a new puzzle piece will be found, snuggling seamlessly into place. But until then, (we try and we fail)*.
Don't throw the baby out with the bath water. I beg you.
If it’s important enough of a feature people will adopt it and it will coexist with the original project.
If that convinces the original authors of the importance of a feature, you can merge and make the world beautiful again.
If something is important to me but I have requirements that differ from the maintainers I usually maintain a fork even if I’m the only user of it.
Sometimes it attracts people with similar needs and they build on top of my changes.
Discussions in open source are a lot more discursive and mutually respecting when you’re offering to donate your work to the project because it helped fulfill a need that you had yourself, not only because it gave you a reason to invest time into it but also because you don’t usually invest time into things without a clear reason you needed that feature.
From my observation, the causes tend to be:
- Maintainers spread thin, putting more of a burden on contributors
- Some projects being critical and needing more attention and some taking themselves too seriously (dealt with a project whose CI took a couple hours for ~60 jobs because they exhaustively tested every combination.
- Maintainers who haven't learned to distinguish the important from unimportant.
- Contributors who don't realize their PR is a white eleplant (burdensome gift)
- Contributors who jump in with a PR without first seeing if it aligns with the project.
Most of this happens everywhere. Probably the more unique aspects to Rust are being spread thin, precedence of high quality crates, and that Rust gives a level of control that is addictive and effects other parts of projects.
I'm tempted to move to fragments that a changelog is generated from to avoid conflicts. I just haven't gotten around to exploring what tooling is out there.
It's about learning from each other, so it's a win-win.
It's fine that your first PR doesn't get merged, just learn from other (reviews) and go on with next PRs. Just never give up.
If they don't, I'll call it a tragedy.
https://github.com/alacritty/alacritty/issues/4731
EDIT: I used it for a while in Windows before I switched to Linux where I use Kitty
Indeed, the two examples they mention are both related to Rust somehow, but is it enough to generalize to the whole Rust ecosystem?
[1]: https://github.com/kovidgoyal/kitty/blob/2350952d054bcaf945a...
if someday your own personal fork gets enough attention and the use case you implemented is solid enough, it'll pick up steam and will possibly get merged (or not) into upstream.
but still, you are free to change and peruse whatever you see fit. you got a lot of work done for yourself for no effort at all. time to put in your own.
When you combine that with perfectionists it can probably get annoying. It's sad this is common enough to drive people away, because I think Rust is a great language and using it "well enough" is the first step to learning how to do it better. Imho it's not realistic to expect everyone to really understand all aspects of traits, lifetimes etc. because those can get really tricky really quick and not every behaviour of the compiler is consistent in those areas.
This is like jwz’s interaction with the emacs team decades ago — the story was that the emacs team was being unreasonable about merging some changes jwz/Lucid wanted. If you actually read the correspondence, turns out jwz wasn’t listening to review feedback. The feedback was completely technically reasonable from a maintainer’s perspective and jwz/Lucid just wanted the code merged without consideration for the emacs team’s future plans.
It is like marriage. Everything is fine in the honeymoon, even when it is not, but after that, things start to get a little messy.