As someone who worked on a sizeable open source project, I sympathize with all of this. For me, part of growing as a person and making my own life easier were two things. First, to not hold everyone else to your own standards. That is, don't expect anything from anyone. Life gets a lot less disappointing that way. The other is to stop dwelling on what other people think. This one is hard, but if you can truly get there life gets a lot less stressing, programming included - you don't take such offense to the trolls. I think it's an unspoken part of aging and learning. You rarely see a shy old guy in the locker rooms.
All that said, as a complete aside, I have tremendous respect for Mr Gallant. Everything he writes is gold, and if you haven't yet, I'd recommend taking a look at his awesome open source projects.
By no means a summary of the article, but I liked these passages in particular:
On emotions:
> When I was a young adult, I'd pride myself on being “logical” and “free of emotional decision making.” Like all good lies we tell to ourselves, there's a kernel of truth to it. But for the most part, at least for me personally, I am a deeply emotional being.
> Emotions run deep and can be a really useful well to tap for intrinsic motivation. For example, for some time after ripgrep was released, I began to immediately hate touching the code that was responsible for printing search results. It was convoluted, buggy and difficult to change. While rewriting is a perfectly logical decision to make on purely technical grounds only, I was motivated to do it because I didn't like the way it made me feel. My emotion helped drive me to make things better for myself.
On communicating thoughtfully in order to communicate effectively:
> ...being thoughtful in one's communication is important to advance your cause. If you're thoughtless, even if you're correct, you risk working against your own ends because the person on the other end might not be able to look past your thoughtlessness.
On the fact that even the author can't and doesn't read every line of every dependency they pull in:
> ...As someone who uses FOSS and tries hard to be discriminating with the dependencies I use, it is just not possible for me to review every line of code I depend on. Even if I could somehow manage to read it all, I certainly wouldn't be able to understand it all in enough detail to be confident that it was doing what I thought it was doing.
This hit me hard too. Heading into college, I was so confident that it was not only possible, but correct to be an emotionless decision maker. That somehow you could navigate the rational path through every problem.
Turns out I was just an asshole who wasn't self aware enough to understand my own feelings and was making other people around me hurt.
This is an argument I could have every day with commenters on HN were I so inclined. Being polite, helpful, and correct is vastly more useful to the world than just being correct.
Going against your, and parents, commentary, this is a semi-accurate description of how I used to see myself:
"I'd rather be right than popular, and I usually am".
But I mostly wasn't convincing, whether I was right or wrong. And that's what I'm continually working on. Being convincing is arguably more important than being right in the first place. And to be convincing you need to know your topic from a number of angles, and you need to know the audience you're playing to. But you also need to know whose worthy of convincing, because there are some (plenty) that won't be convinced either way, so don't waste your time on them - know a lost cause so as to avoid committing self-denial-of-service.
To add to your very good insight, I believe that oftentimes it's not even a dichotomy. Being right does not give a right to be condescending about it, because it turns the conversation into emotional clashes by triggering a desire to oppose on the other.
But the very bad thing about that philosophy is that it makes one tend to default to thinking that it's others that are inferior and can't handle the facts you see so clearly... so if it turns out you were not right in the end, we've got the worst case scenario -- Now you're not just preventing yourself from learning and improving (which should always be the goal), you've become just like a troll, an asshole who's wrong.
> Being right does not give a right to be condescending
Not to disagree, but, quoting the article, I'd like to "underscore the asymmetry" between people that are right and condescending VS people that are wrong, think they are right (or don't care if they are, most of the times) and are condescending just because they can or because that's the way they think you advance your career.
They read somewhere that CEOs have a bad temper and imply that bad temper is necessary to become CEO.
Rightness comes in degrees. It can definitely be better to be _almost right_ but convincing than _completely right_ but unconvincing. In fact, all you need is to be _more right_ than people would be if you didn't convince them.
> Being polite, helpful, and correct is vastly more useful to the world than just being correct.
This is only true when being "correct" doesn't really matter very much (certainly true on the Internet). One of the hard earned pieces of wisdom from age is that the situations in which there IS a "correct" AND it matters are far fewer than you think. Most decisions are a wash so it's fine to concede.
In addition, "polite" is in the eye of the beholder. I can oppose something politely and people will still scream about how unreasonable I am being.
The problem is that "correct" sometimes matters a LOT and has opposition for non-"correct" reasons. Those same people that you deferred to so many times in the past now get very angry when you suddenly put a stick in the ground and go "No. This is correct and it matters and I'm not moving on it." In addition you will find that there is an entire class of social manipulators who just like to "play poker" and will go absolutely apoplectic when you will not budge a decision without new factual evidence.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”--George Bernard Shaw
As a general rule this is completely fine. However, sometimes being impolite and correct is desperately needed. As long as you are being impolite with great calm and forbearance.
Perhaps, but in most cases, people vastly overestimate how common that "sometimes" is, how desperately the "needed" is, and how great their own "forbearance" is. They bring this argument up as part of denying their own contribution to a conflict. It's so easy to deceive oneself about this that a better strategy is not to go there. Self-honesty about what one is actually feeling will mostly eliminate it anyhow.
I almost get the feeling that a lot of HN commenters actually pride themselves on writing terse comments devoid of emotion and sensitivity to the receiver/reader. Too often, I write such comments myself, as well. It seems to be part of a larger effectiveness trend, down to even keeping vocabulary as minimal as possible, and avoiding literature because it's too descriptive, a waste of time.
Is it tied to HN or hacker/startup culture, SV mentality? To pride oneself on being an effective robot? No care in the world except building the next great thing, damned be everything else? Maybe it's about the types of people attracted to computers? I hear the same kind of response daily at work, I mean, generally, we're not known to be the most socially intelligent group.
Thanks for your work BurntSushi, Andrew, ripgrep is great.
Perceptions about other people from their online comments are so susceptible to projection that it's important to practice suspending judgment. Tiny packets of text give us so little information about each other that they leave a lot of empty space for interpretation. We fill in those degrees of freedom from our imagination, based on our own prior experiences, which were in place long before that other person showed up.
Sometimes we fill the picture in favorably, but if there's anything in a comment that rubs us the wrong way—anything activating—then the picture we create is not a nice one. Since a forum like HN gets millions of posts a year, there are inevitably plenty of hooks to snag us in this way. If you stop and think about what that means experientially, it's sort of shocking: it means that we are surrounded by our own demons. Since everyone else is having the same experience, a forum like this is a community of people who feel surrounded by their own demons, not realizing that we are mostly creating them for ourselves. This is why disagreements degenerate so quickly, even though each party is sure that they're the one in good faith. It's also why you'll regularly see generalizations about how awful the community is, posted by users who participate in it every day. It's surprising that it can function at all.
By "demons" I just mean a composite of our own past painful experiences, which is the store we draw on when connecting the dots about someone else in a defensive way. This phenomenon isn't only online; it happens everywhere that people don't know each other well. But online, we know each other so little that there are more dots to connect.
> If you stop and think about what that means experientially, it's pretty shocking: it means that we are surrounded by our own demons. Since everyone else is having the same experience, a forum like this is a community of people who all feel surrounded by their own demons, not realizing that they are mostly creating them for ourselves.
I've been thinking about this all day since I read it. Thanks for this. It's a profound insight for me.
This along with BurntSushi's insight about emotional code smell makes this one of the best hn post ever for me.
Slightly tangential, but that former stance you describe partly is a consequence of the age-old dualism between emotions and reason, to which people quite frequently subscribe despite strong evidence in the last decades from neurosciences that this is just not an adequete model--that's not how our mind work. We are not some sort of judge in their cartesian theater deliberating between the good, rational-mind and the lively but childish emotional-mind.
> I was so confident that it was not only possible, but correct to be an emotionless decision maker. That somehow you could navigate the rational path through every problem.
You can.
And probably you should.
Just accept it is not the _only_ tool.
You have a life too, things come at different angles, from everywhere, and impact you and the people you love differently.
I've been working hard for the past 25 years to become an emotionless decision maker when it's about my primary job: writing software.
I don't keep code around because I'm attached to it, if there's a better way to execute the same thing.
I don't reject other people's code just because it's not the way I would write it.
I don't research pureness, I know that to be useful and, most importantly, correct, software has to solve a lot of edge cases and inevitably is going to be full of trade offs.
I don't only work on new software or features, I don't plan complete rewrites of legacy systems if I can work around the problem, I do maintainance, even of legacy systems, maybe nobody is gonna credit you for doing it, but it's what keeps the World spinning and rationally it's one of the most important tasks.
I used to care about "what will people think if I'll solve this with an 'if'?", now I know that it was my emotions blocking me from doing the right thing.
I don't take bug reports personally, although there are times I struggle with the usual "haven't read the documentation" or "it doesn't work it's not really helpful as a description of the problem", but I try to let my emotions out of it, I try to stay away from them as much as possible.
Emotionless doesn't mean rude or "acting like a killing machine" it means you're detached from emotions and when a problem arise you help to find the solution instead of blaming someone or something.
Emotionless is that alert on the plane that tells you to put your oxygen mask first, before helping your children. Because it's the most rational and logic thing to do, the opposite of what a parent would instinctively do out of love.
> Turns out I was just an asshole
Don't be an asshole is a good start too :)
But sometimes is hard when you're young and everyone older around you talks about tricking the system while you just want to fix it (at least that was my struggle with it when I was younger).
> > I was so confident that it was not only possible, but correct to be an emotionless decision maker. That somehow you could navigate the rational path through every problem.
> You can.
This is narrowly true in theory, noting particularly that it applies only after the problem is defined, because defining a problem is an application of values which ultimately are rooted not in rationality but in emotional preference.
In practice, people don't and probably practically cannot fully define problems in advance of approaching them, but feel out the parameters of the problem in the course of addressing it, so attempting an unemotional approach invaluable means accepting an incomplete understanding of the problem.
All you do by ignoring your emotions is that you become unaware of them. They don't go away. Psychology and neuroscience have again and again found how irrational and emotional we are even when we think we are rational.
> All you do by ignoring your emotions is that you become unaware of them
That's a bit silly to say.
It doesn't work like that, it's like saying that if you ignore your arm it stops working.
And nobody ever said you should ignore emotions, but that you are perfectly capable of behaving differently in different situations.
You're not always emotionally charged, you are not always made of steel, you can control what happens to you much more than you imagine.
> Psychology and neuroscience have again and again found how irrational and emotional
Irrational and hormonal, as in "driven by hormones", the layman term is emotional, but it isn't entirely correct.
Emotional is about emotions (nobody consider rage or sadness or loneliness or "I wanna be left alone" emotions, they are considered bad things, something to be removed), but being autistic is not being emotional, for example.
There are a lot of behaviours not caused by emotions, which, BTW, are located in our brain, our logic processing unit, not in our hearts. They are in its backend, the irrational brain, and they are perfectly rational: they are a tool humans used to survive and take life-saving decisions in the span of milliseconds.
They are the same thing as a fire alarm, they signal a change of state, possibly for the worse.
I'll go further and say that we all are at the mercy of our selfish genes, as R. Dawkins proved.
Ignore your arm and you won't learn how to use it. It won't go away. You'll just have an arm the is super uncoordinated and weak.
Ignore your emotions and you'll become emotionally immature and a person people won't like to interact with, because your emotions will come up when inappropriate.
The importance of learning to feel and label your emotions is one of the most basic findings in psychology.
I recommend reading about Non-Violent-Communication. It sounds like it is something completely different, but it is a practice for learning to labeling you emotions in different situations, and then being able to react more appropriately.
> Ignore your arm and you won't learn how to use it.
Sorry but no, it doesn't.
If you fall you stretch your arms forward, to protect your head, it's an automatism, your body works the way it is supposed to work even when you ignore it
Most of what it does it's independent from your will
It just works
The heart doesn't stop beating if you don't think about it
Looking back, I've written some regrettable github issues with a lack of respect for the maintainers.
What I've learnt is that if you want something done then ask politely, if you want something done now then try and do it yourself. That's the inherent beauty of open source.
What if we required that people leave videos instead of writing up issues? I'm not seriously proposing that, but it's harder to be a jackass when speaking than writing. Especially to someone's face.
True, it's not really a workable idea. My point is that text communication encourages jackassery, and many people don't think about that until they consider just how ridiculous or obnoxious their words sound when spoken aloud to somebody's face.
It helps convey some intent. Hm, that would actually be interesting. A browser plugin that automatically inserts emojis to convey your current emotions or feelings. You can set it yourself, it may learn from your interactions too.
Funnily enough I often have the opposite issue. I will sometimes start writing up a bug report, spend a couple of hours trying to get my thoughts down on paper, then give up because I have neither the time nor energy to finish. I kind of wish there was an option to submit a voice recording along with some code snippets :(
Video can be costly, especially in countries where data is still expensive. It can be a barrier to allowing more diverse communities to also contribute unfortunately.
If you want something done, do it yourself or hire someone to do it. There is no implicit reason for you to share your desire with the maintainer, unless you have a working agreement with them or would like to initiate one.
If you consider what you want and you think that it clearly aligns with the maintainer’s needs, then consider sharing your ‘want’ along with an explanation of why you think it’s valuable for their needs.
If you can’t figure out what their needs are, and you can’t provide an explanation for why this is important to them, then there’s no reason for you to bring it up to them at all.
(This will seem abrupt, but it’s not meant to be hurtful in any way - I’m just literal and sociology-ish. I did my best to be clear and kind about my view. No harm intended, apologies if any caused.)
Great post, just keep doing what you're doing! I, for one, have a ton of respect for the work that you do and the projects that you've created. I've never been the steward of a super popular project, but I can imagine it must be demanding.
I came across one of burntsushi's interactions on reddit that's still on my mind. A poster made an unfounded comment, based on their feelings, that a competing tool was faster than ripgrep and when the author rightfully called them out on the improper metrics of said claim and even took the time to explain the unfortunate effects of such claims, they simply responded that they would now flat out drop ripgrep completely. I can only imagine how exasperating multiple interactions of that "drive-by low-effort nature" must make one feel. How does one even respond to comments like that!
If you are reading this burntsushi, I'm really thankful for ripgrep, a tool I use tons of times almost everyday, as a backend for fzf etc. Definitely a happy user!
People are too quick to dismiss other's work when they don't know how hard it is or have done anything significant in the same field. Once dismissed, it becomes
a matter of what they feel about it at face value.
To everyone, it seems programmers write 500 words SEO spam posts so not worth much or hard. They can program the same if they wanted to.
(Note - SEO spam posts here refers to subjecive low quality code, duplicate of existing solutions or very similar to what you can do by combining two existing tools.)
Perception or feelings like above are quick to convey so they get conveyed.
Spitting out code is not the hard part of open source imo. It's dedication, commitment, building a community and sustaining feedback. If I am writing software to solve trivial problem, then it wouldn't take me much time but if I am writing software to solve trivial problems for others, It would take me tremendous time to write insignificant piece of code because it needs to be documented, accessible, thoughtful, clean, hosted, testable, branded (naming is one of the hard problems, after all.) and pass through many such criteria.
It doesn't need to but most people who love open source feel this way about their projects.
It's hidden. It's not visible to someone who just created an issue. Somehow we live in meritocratic ideals but forget that meritocratic solution on their own don't get much attention. Without a good readme, a lot of people simply ignore the project. We are actively optmized to go through ton of information that it de-empathizes us to human touch or mistakes. It's quick to notice a typo and make an insignificant comment about it because you can't focus on everything. Anything unexpected is a distraction and we get easily distracted, thus sometime vent on meaningless things.
> How does one even respond to comments like that!
Something I struggle with on other internet forums, too. I try to tell myself that I'm not just writing to change the low-effort antagonist's mind, but for everyone else reading the thread, too.
Just like the author of actix-web decides to exit from his popular Rust open source project recently(https://github.com/actix/actix-web). As a maintainer of large open source project is not a fun task. whatever mental or physical, it's really a hard job.
Respent for every maintainer and contributor, it's not easy. You can read some issues in the repository, the authors of some issues are just complaining or criticizing the idea or bug, it's unfair and rude. in the end, hurt maintainer's passions. Every developer should know it and respect it like the README or guideline before posting issues or comments.
It's a fantastic post about the analysis of OSS maintainer, Respect for Mr. Gallant.
As someone with a footprint in open source, I agree that giving labor for free sets an expectation.
That said, I never had the request to rewrite in a different programming language, yet. Downstream library users as well as package maintainers seem delighted with Python.
I think GitHub sponsors and patreon-like systems can be the way forward. If open source users said "hey, I'll give (10/20/50/whatevers affordable to me now) bucks a month toward open source projects" and then proportion them across projects they choose, that can go forward to things.
But open source is much bigger than projects themselves. One example would be package maintainers on Debian, Ubuntu, Fedora, Arch, BSD port systems, and so on. They put enough time into it they should be compensated.
I think with these new platforms like GH Sponsors, we're on a trajectory toward fixing this.
> I got a drive-by comment effectively telling me to use a “working” license instead, along with some (what felt like) condescending lecture on how licensing works.
I hope my many drive-by github issues on licenses over the years weren't taken as condescending. I want to avoid the headache in the future of a migration, an example of what it can entail: https://github.com/twbs/bootstrap/issues/2054
That's a lot of work.
Worse is the matter of ambiguity with certain licenses. Having something clear and simple that'll work across jurisdictions is a winner.
Wishful thinking or intent doesn't matter when the door is left open for a legal adversary different interpretation of the facts, then having to pay expenses to defend it. That's drama in and of itself, but could also really hurt a business, esp. in early phases.
I wish there was a well-understood convention to opt out of "social coding". A way to put up a project under an open source license (or CC0/public-domain) along with a notice that says effectively, "feel free to fork, but don't file issues or submit patches."
You can put that in a README, but people won't read it. Github won't let you disable i̶s̶s̶u̶e̶s̶ ̶l̶a̶s̶t̶ ̶I̶ ̶l̶o̶o̶k̶e̶d̶ pull requests, unless you archive the project (making it read-only). Is it possible on one of the other hosting services, like Gitlab?
We need better ways to draw boundaries around open source projects and contributors.
I have never tried but perhaps someone could come up with a useless_machine[0] type of webhook[1]
such that a pull request would do nothing but close itself
Assuming the author uses their own software, disabling the ability to hear about problems with it before you trip over it themselves is counterproductive. The minority of users would fix it and offer a PR in my experience, more would be willing to drop the author a note in an issue.
Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.
There are some projects like that on GH but they're marked as abandoned or clones of e.g. Linux. I understand where you're coming from but whatever it is you've open sourced won't be very popular, because open source software is less about technical excellence and more about popularity, market- and mindshare.
I mean I'm trying to pick an alternative to Ant Design (because Chinese) and there's a billion of them, but I'm having trouble deciding which one is the best option - Bootstrap, because most stars? Material UI because it shows up high in search results? And there's at least dozens more that will be objectively better (on a technical level) which I'll probably never see, and which I'll probably never use (because low popularity means low engagement and no guarantees that it'll still be around and maintained a few years down the line).
I would leave PRs available. Repo owner has no obligation to merge PRs however forks can still make use of upstream repo's PRs. That haplens usually when unmaintained repo accumulated a lot of popularity.
This is what we call "unmaintained" software. 'Unmaintained' may sound like a value judgment, but it's not - it's exactly what you're talking about; a project where any attempt to contact the putative maintainer is likely to be ignored altogether, and the "proper" channel for enhancement involves forking it and perhaps maintaining a version yourself.
(new) GitLab engineer here. This is correct, it can be set to allow merge requests from "Only Project Members", or disabled entirely. You can also disable pretty much everything else as well, if desired.
Disclaimer: nobody submits contributions to my hobby projects anyway.
Exactly – put that badge or the similar “Repo Status: Unsupported” badge (https://www.repostatus.org/#unsupported) in your README to succinctly communicate what users should expect from the project.
As somebody who works with data a lot, the need for analysing and transforming CSV files comes up and I recall, how I needed something fast. Then I discovered `xsv` about a year ago, and since then I still use it on a weekly basis. since then also discovered ripgrep.
It was also for me a gateway in the sense I see rust come up on HN, but only when I started using these tools I realised how fast and light those little apps can be. It made me want to learn Rust and seeing the community around it I realise, it is a very wonderful thing.
While I highly appreciate the contribution Burnt Sushi made, I've personally gone through a not so great experience contributing to one of Burnt Sushi's repositories.
I personally think a major issue is he may have over-stretched in terms of the repos he sought to create and support as a maintainer. He has 140 public repos many of them significant. As his interests, shifted I have experienced that the pace of reviewing and responding to comments and pull requests became really slow and ultimately led to frustration among contributors as well.
Might have been better to clearly prioritize and state which repositories he planned to support and which not and possibly either hand over ownership or mark the repo he didn't intend to support as orphaned.
Stop expecting that of him. He wrote the code, and open sourced it. He doesn't owe it to you or anyone to say that he doesn't care about it anymore, though doing so would be a nicety. It's open source. If you feel he isn't maintaining something, fork it and own it. Or pay him to.
The problem is not the "expectation" of ownership. The problem is in lack of clarity in communication. For whatever reason (usually because they're very good), a lot of Andrew's libraries became very popular in the Go world. If his interests have changed to Rust, all he needs to have done is say so.
I'm not faulting you for your expectations, please see my other comment for thought on that. The problem is that even expecting that is more free labor. Sure it's small, and courteous, but is labor. Speaking from experience, I go through weird phases where I want to hide from the world. I know things suffer for it, but it's me. And even writing a short note to let people know is not on my radar as something I care about.
I hope you don't take my comments as combative, I'm trying to speak from experience. I also learned of Mr. Gallant from being on the Go code review lists. I also noticed he seemed to "switch" to Rust. With that knowledge, anything I used heavily I would fork. If one day the two can reconcile, great. If not, congratulations, you own it until you get tired of it and someone else forks it. Such is the nature of open source!
Deciding that you don't intend to maintain a project is labor. This sort of decision is hard to make and extremely hard to undo. Much easier to keep thinking, "I'll get to it next month."
Going against the grain here, but, why so sensitive? A simple suggestion is not an insult, a sign of unthankfulness, or in itself denigrating the author's efforts.
I got the same vibe from the article TBH, a lot of what he considers rude just seems like well intentioned, if possibly misunderstood, suggestions.
Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template.
With the disclaimer that I have never maintained a highly popular GitHub repo, I get a lot of feedback for my projects that is unuseable, and some that is aggravating. I always have the option of simply ignoring it, and that's the end of that interaction. Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
> Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template
This was not the vibe I meant to express. I'm sorry it came across that way. I meant to express how it made me _feel_. The next paragraph goes on to say how such issues are eminently reasonable in a lot of cases, and my coming to terms with that is a struggle I face.
My goal was to explain my own perspective in the hope that it increases understanding of everyone involved.
> Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
I tried really hard to leave blame out of my article (for anyone other than myself). That is not how I feel. On the contrary, as I mentioned in my article, setting boundaries is exactly what has helped me so much.
Depends on whether the upstream project is still active, and whether your fork is targeting the same audience.
eg If you fork the code where the upstream project is obviously still active, and your changes target the same audience as the original (eg not taking in a new/experimental direction), then it could be rude.
However, if the upstream repo is no longer active the upstream authors may even happy to have someone picking up the leadership role for that particular project.
Buddy I made an actual contribution taking the trouble to understand the codebase and contributing a feature which was in the spec but not in his library. If Andrew didn't have time to address it as his interests were changing or whatever, he could have clearly stated it upfront in which case I probably would have picked a different library to invest in.
Characterizing this as "sense of entitlement" in a one liner is quite uncalled for.
A contribution to an open source project is a gift with a hundred strings attached.
In most cases it's a request for more of the maintainer's time to review, fix, and merge a change which they themselves likely don't need (otherwise they would have added it). In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself. It only becomes net-positive when a contributor has a long-lived interest in the project and turns out to be a capable maintainer with similar sensibilities; even then there is significant ramp-up time. 99% of the time this doesn't happen; most contributions are drive-bys.
> P.S. It so happens that that we previously interacted on that very PR thread:
Yup. I recognized your username and note that our interaction happened over a year after the original pull request discussion with no response from the repo owner.
> In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself
Sure but the general culture and expectation in open source is when people find bugs or create features, as good citizens they share the changes upstream. If what you want to do is "throw the code over" or you've lost interest in developing further, all you need to do is to say that as common courtesy to your fellow open source developer especially if like in this case a lot of people use it. Lots of repos do this and clearly stated deprecation.
Sort of. But, the most egregious form of entitlement is low-effort.
Whereas "the account has too many prominent repositories to accept contributions to in a reliable manner" lowers trust (which the burntsushi post also discusses).
It's as fair to say "I don't trust the project because it isn't maintained" as it is to say "the code is free, the maintainer's time is not". - I think this is exasperated by that "just fork it" works in a small sense for one or two patches; but there's a communal inertia that complicates it in a larger sense.
This should have been solved ages ago but it isn't. What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity?
The one contributing the most gets notified to accept or deny the request.
Security is the main issue: you can’t just give away control of a widely used tool without vetting the new maintainer because that would open all your users to malicious code.
You aren't giving control to unknown people here. You are giving it to good contributors who you have added personally. We can still have a system where core contributors can vote on someone accepting the request or author can disable this feature.
How many people vet the author before installing something from npm? If you trust someone because they have some code that looks good, then shouldn't you trust contributors who have good code in there too.
How many points of cracks are there in the dependencies of dependency?
If it's a widely used tool then author wouldn't go inactive for a year without doing something unless they are not getting paid or even acknowledged for their efforts.
If people like security, then pin and mirror your dependencies. Don't update without checking them.
My point was that the maintainer shouldn’t give up maintenance unless they trust the new maintainer, so we agree. (I did misread your original post, but I think it can’t be just any contributor)
> What is the problem with allowing repositories with specific licenses or label to be transferered to contributors after certain length of inactivity?
This is unworkable for a large number of reasons. But it's also largely beside the point. If the code is available under a permissive license and is not being maintained, fork it.
That was my thought about the "Dealing via Boundaries" section. The solution of "defer some maintainer responsibilities to someone else" never came up. When you insist that you have to do everything by yourself, you are creating that massive asymmetry between users and maintainers.
> "defer some maintainer responsibilities to someone else"
I have of course done this many times across different projects. Sometimes it works. Sometimes it doesn't. It isn't the silver bullet you portray it to be. Nevermind the risks involved due to supply chain attacks.
One thing that I found surprising was that the author considered comments along the lines of "Just chiming in to say that I would also really like this feature." to be rude. I would have thought it was helpful feedback; more people indicating the value of a feature seems helpful in assessing whether it's worth doing (if it's not obvious for other reasons).
I was mulling over that sentence too. While I’d probably not characterize them as rude per se, those little pings do intrude more than, say, adding another upvote on the issue. I already know there is a lot more that I’d like to do than have time for, and having these personal pleas add a little more guilt to the mix without providing any more substance are often a negative (especially when there are lots of them).
As an OSS author, unless I ask for that feedback, “me too” comments both add noise to my inbox and come off as entitled. It feels like the author of the comment expects me to implement a feature for them because they want it. I don’t maintain OSS as a product, I maintain it because it is code that I need for my personal use cases and I benefit by having others participate in QA and feature dev.
This probably does not apply to OSS projects that are products built by companies.
Thought the same... maybe what he finds rude is the comment itself in cases (like Github) where you can react to the comment with a thumbs up to say the same thing, instead of a new comment that sends a notification and maybe even an email. There needs to be a non-rude way to show support for a constructive idea.
Yeah, I didn't think of that, and several people have pointed it out in the responses :) Agreed completely, if the silent :+1: option is there then a content free "me too" is a bit rude.
I help with UX in a FOSS project. When it comes to comments of that kind, the problem is that they are usually quite low effort. The person thought: "X is a good idea" but never once considered giving proper reasons, exploring other possible solutions, thinking aboit how it should actually look like and so on.
In my opinion a good feature request does all that legwork. The goal (my goal) is to arm the maintainer with a action-plan that they can pull out of the drawer and start working on immidiately. If this doesn't work — seeing that the other side did the legwork can still be motivating and creates a good climate.
Just imagine we are not talking about code, but about cool Lego-towers for a moment. If you want the other kid to add a certain detail to the tower, the least you can do is explain it to them properly. Better is to inspire their creativity alltogether: who says your idea is the only/best way to solve the problem?
Yes, that's a fair point. Just "me too" doesn't convey a lot of extra information. Would "me to, because this would help solve my scenario xyz" be more helpful? What about "me too, because I also have the exact problem described" (which at least conveys that they've put more thought in to it than a totally light weight "me too")?
> Would "me to, because this would help solve my scenario xyz" be more helpful?
Quite definitly. But even more helpful would be if you listed all scenarios you can think of where this would be helpful, even ones that are not useful to you, but might be to others.
Then you think about how it would impact existing functionality (both positively and negatively), would it be the consistent thing to do? Where could be traps and pitfalls? Maybe even ad a mockup of hoe it would look.
If you did that, the maintainer sees that you didn't just demand a feature drive-by-shooting-style, but you did the actual legwork of fleshing the thing out. Don't marry your own ideas, others might be inspired by you and have a even better way of solving this.
If you are writing one sentence you are doing to little usually (in my eyes).
> But even more helpful would be if you listed all scenarios you can think of where this would be helpful, even ones that are not useful to you, but might be to others.
The danger with this is encouraging overengineering. It's easy, particularly if someone else is going to be doing the work, to say, "Maybe someone out there might someday want to do X, Y, or Z"; causing a maintainer to put a whole lot of effort and extra complexity into their code for use cases which nobody uses.
In fact, when only a single person wants a feature, there's a similar risk, that I'll put a whole lot of extra effort and complexity into the code for a use case which only one person thinks they want; and that after it's implemented, they decide they don't like it and go somewhere else anyway.
That's why I didn't understand why he considered "I would also use this feature" comments to be rude or unhelpful. I would think knowing that at least two (or three or four) people wanted a feature would be helpful feedback in knowing what kinds of things were worth adding extra complexity.
Perhaps in his mind they took the tone of, "Hey yeah, we're all waiting for you to do this work for us for free; what's the hold-up? Get cracking!" Which of course would be a bad attitude; but looking at the exact thing he quoted, I'd say that's more about what he's reading into it than what the commenter actually said.
The number of big projects with over a dozen identical comments saying "Same problem" is quite astounding. At what point does the maintainer turn off notifications? 5? 20?
Perhaps the point was that unless you have something useful to add to a GitHub issue then don't comment.
People don't want Reddit style pun threads here and yet to hear complaints about that being enforced, in fact the opposite. GitHub issues is similar in that sense. Everything has its place and time.
Yes, I think that adding the thumbs up feature (which people still use badly) was a good solution to that. It lets you give a "me too" response without cluttering up the comments, and without spamming the maintainers with notifications either - but if they do look they can see people expressing interest.
If the issue is a bug (as opposed to a feat request) maybe it's useful to know how common it is? It would imply its not just a one-off issue with a particular users setup.
It depends on the phrasing. If you’re just saying “me too” you’re just annoying the maintainer instead of adding a silent +1 reaction.
If you add one more use case that might help the maintainer reconsider the feature, then I’d find it acceptable. Sometimes the issue opener didn’t explain the utility that well or wrote some example that made it sound like it would be a niche feature and not worth it.
Yeah, I wasn't thinking of GH specifically, but if you have the silent thumbs up option, then a "me too" with no meaningful contribution is a bit rude.
I probably wouldn't call it rude, but I'd say it's definitely unwanted. It just adds annoying noise to my inbox. In my time working on FOSS, it's pretty rare that more "votes" would make me more likely or more interested in implementing a particular feature. I certainly would have been interested in knowing what features were most important to users, but I think a drive-by "me too" on a feature request is a poor sample of what users overall really want.
And regardless, for some projects, at some times, you just feel like working what you feel like working on, and more users clamoring for a particular feature just doesn't motivate you.
There are two unstated assumptions underlying “helpful feedback” that need to be considered and re-evaluated.
First, the assumption that ‘voting’ is an appropriate and helpful form of social interaction with someone who has not expressly invited that participation from others.
Second, the assumption that a group expression of a statement is emotionally equivalent to a single individual’s expression of the same statement.
These are not universally shared assumptions, especially in open source.
If one doesn't have proper additional reasons for their chiming, thats what the vote button is for. Otherwise the useless text is just taking up valuable screen estate and making people scroll un-necessarily.
I reckon that if you have to process a lot of communications about your project(s), and because you are the maintainer you HAVE to pay attention, comments like that are high noise, low signal, and while one of them is fine, dozens or hundreds of those a day just cost energy without bringing anything back.
> One thing that I found surprising was that the author considered comments along the lines of "Just chiming in to say that I would also really like this feature." to be rude.
I mentioned on r/rust that "rude" is perhaps too strong of a word. I was more or less thinking of things that annoyed or grated on me, and then just kind of lumped that in with "rude." To be sure, I do not get to lay claim to a universal definition of rudeness. :-)
But yeah, I think others responding to you pretty much summed up why it can be mildly annoying. And to be clear, I do think part of this is on me: I'm working on trying to let such minor things like this slide more. It's a process.
After thinking about it I agree with him. If you are going to stand up to speak in a community meeting, you should have something more thoughtful to say than "I agree with what that guy said".
> I taught myself to set boundaries: it's okay to say no to a feature solely on the grounds that you don't want the added maintenance that comes from it.
This makes perfect sense. The author seems to understand well that there's a balance to be struck when working on OSS; you can't always work only on the stuff you want to work on. On the other hand, being the one who initiates and maintains some FOSS has to mean something. If it doesn't mean you get to decide (within reason) on somewhat subjective calls such as "is this feature worth implementing when weighed against the maintenance burden?" then contributing and maintaining OSS ends up meaning nothing other than willingly doing work for free and letting everyone else in the world be your boss. Clearly that's an untenable situation.
> For me personally, this is an area where I struggle the most. My emotions get the best of me, because all I can think is: why didn't this person take the time to read and fill out the issue template? Or, in cases where bugs are user errors that could be resolved by just reading the documentation, all I can think of is: I spent this time gifting this user some software, but they can't even read the README before filing a bug report?
This resonates so much. Users who blatantly waste your time despite multiple cues steering them towards actionable bug reports are worse then trolls or haters IMO. (I use issue templates, with all caps and explosive emojis, and I even put specific actionable wiki links in error messages, but some people still insist on opening barebones “doesn’t work” bug reports. Or duplicates. People open duplicates when there are like three open issues in total and one is clearly the same issue as theirs. What the hell?)
With trolls or haters you can simply drop the ban hammer, easy. With this kind of high-maintenance users, it’s hard to decide whether you should waste time helping them, or simply refuse action until they get their act together.
> It can be maddening. But that's emotions for you. They certainly aren't always rational. The documentation could probably be clearer. Or the user could have just missed that part of the documentation. Or the user doesn't have experience maintaining FOSS projects or filing bug reports and maybe does not know how to provide an easy reproduction. These are all perfectly reasonable things to have happen, and it's why I do my best not to let my emotions get the best of me. While the way I feel is important, empathizing with the person on the other end of the wire is important too.
Honestly it’s hard to empathize with users who can’t follow “run command with --debug, post entire output” or who don’t bother to read anything when the error message clearly says “here’s a wiki article for your specific error, read it before reporting a bug”.
Until recently I was working for a large startup where I would see this kind of behavior constantly. Join a inter-team developer-support channel, send a "I'm seeing errors from your service" and wait for you to respond. One time I ended up chasing the error back to a deployment done by the person sitting next to the reporter.
We also had a helpdesk-style support chat for our developer tooling, complete with a bot that would respond to common error messages with links to solutions and people would STILL directly message engineers that supported the tools asking for help on trivial build issues or inability to use command line tools.
It was sort of baffling to see, its not like its any quicker than doing the right thing, it was simply people being lazy. Some of it's an Eternal September, too, I think.
@burntsushi I use ripgrep all the time. I was also able to learn how to go from 0 to release just by reading through your codebase and documentation to see what goes into a release. When I was writing my foss project I asked myself wwbsd (what would burntsushi do). Even stumbled onto how to create and maintain a homebrew tap thanks to you. I appreciate you and the work you put out, thanks!
I can fully sympathize with this. We have an open-source app on Google play, and the amount of dirt flying at us from users is astounding. What makes matters more funny, app is a client, so most of the problem are related to improperly configured servers. Also, since Google play allows users to leave ratings, every jerk feels entitled to award you 1/5 rating for every minor glitch he experiences.
We have learned to ignore this, and adopted a policy that we just don't care about ratings. If the user is asking for help in a polite way, we help him however we can, for free. If he is an entitled jerk, we just mock him for being entitled.
Of course, then some start ranting how immature our behavior is are and how we must learn to treat our 'customers' better. Of course, right.
I am curious if your open source app is on F-Droid, and if so do you find a better class of user there?
Slightly off topic - I can understand that people publish on Google Play to get reach, but it's upsetting when open source projects make it their sole binary distribution mechanism. It is strange to mandate that the user adopt the model of centralized control by Google, when 3rd party binary distribution is just as well supported on Android as any other platform. This goes for any app, of course, but open source apps in particular ought to know better (and with F-Droid, need not even host the files themselves).
The app is on F-droid as well, but the audience there is much smaller. Also, F-droid apps can't use push notifications from Google,and it severely limits their capabilities.
Getting way off topic now, but I've heard this about Google's "push notifications" before - what's the technical restriction? Surely whatever Google is doing, anyone else can do? Anecdotally, using K9 mail and a GMail account on a Google-free phone, my emails invariably arrive instantly (to my great surprise - I expected periodic polling).
The technical restriction is that you need to have google apps installed and have a valid app certificate to use FCM (the current name of Google's push notifications).
As for alternatives. FCM (or, for that matter, Apple's APNS) requires a persistent connection between a device and push servers to work. Curiously, both Google and Apple seem to be doing this via maintaining a modified XMPP protocol. And this just can't be replicated by any other party: to maintain a persistent connection an app must work all the time and be active in the background, and both Google and Apple heavily suppress background app activity (google has some workarounds, but they become more and more restricted with each OS update).
All in all, I believe that this policy is begging for some antitrust action, so device owners could legally subscribe to alternative app stores and push notification providers. From what I know about XMPP, replicating a server part of a push service should not be insanely hard to do.
It also omes down to power consumption and special mobile protocols.
Keeping a TCP connection open on a mobile link requires occasional keepalive package exchange. That wakes up the mobile radio, which is quite power hungry if the device isn't doing anything else.
That radio wakeup is needed for each independent TCP connection's keepalives, so to minimise the power consumption of multiple idle app/notifier connections, you want them multiplexed over a single TCP connection.
Another factor is the ability to send the underlying event over a lower-level mobile protocol. The mobile base station is regularly exchanging with the handset anyway, to maintain a link which can carry station-to-handset events already and to monitor the link. The whole thing is very well optimised for the radio. So an occasional application event can be sent over that link as well without needing any extra keepalives or radio wakeups. That's the most power efficient thing to do in principle, assuming application events aren't happening often.
Unfortunately, having lots of independent push notification providers being used by different apps at the same time would be quite power hungry.
I think it would be great if a user could direct all the subscriptions through one or two services of their choice though, including an option to provide their own service URL that they run themselves.
These issues aren't specific to FOSS, just ask Shareware authors or website maintainers. From personal experience and other such stories, I suspect they are also more frustrating if one's motives aren't exclusively altruistic or professional, i.e. if one craves the attention a little too much. The whole FOSS scene seems to me to be too much about other issues than quality software lately (10-15 years or so).
Burntsushi, Andrew. My man. You don't know me, we have never talked but bro I admire the shit out of you.
Trolls are much louder than lurkers. There are a silent majority of us that know how much time and sweat goes into building free tools. We appreciate what you do because you do it for love of being a hacker and showing everyone else how you did it.
I don't think people realize how hard it is having a day job and then building a huge project people want to use. It's mentally taxing. It sucks even more when it's only negative things. Life is already hard man, why do these people have to keep trolling you? It's enough to make you want to flip the desk and give it all up.
I love reading your Rust code, and seeing how active you are on reddit/hacker news. Going through how you built the Aho Corasick crate and comments on you trying to reverse hyperscans teddy algo. was amazing for me. I spent so many hours that day reading ripgrep source code. I was amazed and what you did and the comments everywhere about why, like why the printer was pull/push. The whole time, I was geeking over what you did so much that you started my love of Rust.
Burntsushi. Because of your blog post on ripgrep I found a love that I did not know I had (I am just a lowly self-taught frontend developer). I had no idea you could do magic like this with code, and that it could be that interesting. It made all the right wheels in my head spin and it was, and is, love.
I am going back to university (a place a swore never to return to) to learn about algorithms and algorithmic design, starting next Monday. Because of you.
Nobody has had this big an influence on my career, and every time I hit `rg` on my computer I do so with immense gratitude.
...or are using your work without you or them knowing. E.g., just the other day I added the fst crate as a dependency to do longest prefix searches on a set of word/continuation pieces [1]. Similarly, we use fst in a word lemmatization tool that is used to lemmatize billions of tokens.
As I've been learning Rust, I've seen ripgrep held up as one of the shining examples of how to use Rust to create useful, effective tools that new rustaceans should look at.
Same. The repo doesn’t disappoint. It’s thorough and very well documented. I am really glad I started reading through the codebase when I did. My only regret is not reading through earlier.
> When I was a young adult, I'd pride myself on being “logical” and “free of emotional decision making.” Like all good lies we tell to ourselves, there's a kernel of truth to it. But for the most part, at least for me personally, I am a deeply emotional being.
I’ve seen this in quite a few people, both online and in the real world – people that think they are all about logic and not about emotions. And in each and every case, I believe they are only fooling themselves in thinking so. Emotions are really powerful and they affect us all in far more ways than a lot of people like to admit.
Love, hate, jealousy, insecurity, and the list goes on.
People are really good at rationalizing their feelings though, so it is easy to get fooled into thinking that a decision or stance we took was based in some objective truth when in reality emotions were steering us.
Yet so many people refuse to accept that this is the case for them just like it is for everyone else. Even though it is blatantly clear to a lot of people around them when they are acting as they do because of emotions.
I think the world would be a better place if everyone admitted to themselves that emotions is a part of our nature. Then perhaps more people would be able to handle their own emotions better, and we would all, including themselves, be better off.
I certainly try to listen to my emotions and to understand how they effect me.
Values, esthetics, craft, experiences, priorities, and whatnot.
All the stuff that's neither logic or emotion. Which tend to be invisible to geeks.
I came up with gamers. Most very smart, in the high IQ and educational achievement departments. About half were very dismissive of other people's ideas, views. "I'm smart and logical. You're wrong. Meaning you're dumb, illogical, or worse, emotional."
Ripgrep is a work of art and like every work of art it will find critics that dislike it for not fitting their own mind.
burntsushi is one of these people in open source that we would need more of — both because of the quality of his work and the positive and grown way he interacts with the world.
If you read this: thank you for the incredible effort, switching to your software was a complete no-brainer as it is well documented and works — and before this creates pressure: it certainly will not get any worse. Work at your own pace.
Dear BurntSushi, thank you for your hard work and ripgrep which I use on a daily basis. Ignore the trolls and dismiss the people that take more than they give.
212 comments
[ 2.6 ms ] story [ 250 ms ] threadAll that said, as a complete aside, I have tremendous respect for Mr Gallant. Everything he writes is gold, and if you haven't yet, I'd recommend taking a look at his awesome open source projects.
On emotions:
> When I was a young adult, I'd pride myself on being “logical” and “free of emotional decision making.” Like all good lies we tell to ourselves, there's a kernel of truth to it. But for the most part, at least for me personally, I am a deeply emotional being.
> Emotions run deep and can be a really useful well to tap for intrinsic motivation. For example, for some time after ripgrep was released, I began to immediately hate touching the code that was responsible for printing search results. It was convoluted, buggy and difficult to change. While rewriting is a perfectly logical decision to make on purely technical grounds only, I was motivated to do it because I didn't like the way it made me feel. My emotion helped drive me to make things better for myself.
On communicating thoughtfully in order to communicate effectively:
> ...being thoughtful in one's communication is important to advance your cause. If you're thoughtless, even if you're correct, you risk working against your own ends because the person on the other end might not be able to look past your thoughtlessness.
On the fact that even the author can't and doesn't read every line of every dependency they pull in:
> ...As someone who uses FOSS and tries hard to be discriminating with the dependencies I use, it is just not possible for me to review every line of code I depend on. Even if I could somehow manage to read it all, I certainly wouldn't be able to understand it all in enough detail to be confident that it was doing what I thought it was doing.
Turns out I was just an asshole who wasn't self aware enough to understand my own feelings and was making other people around me hurt.
"I'd rather be right than popular, and I usually am".
But I mostly wasn't convincing, whether I was right or wrong. And that's what I'm continually working on. Being convincing is arguably more important than being right in the first place. And to be convincing you need to know your topic from a number of angles, and you need to know the audience you're playing to. But you also need to know whose worthy of convincing, because there are some (plenty) that won't be convinced either way, so don't waste your time on them - know a lost cause so as to avoid committing self-denial-of-service.
But the very bad thing about that philosophy is that it makes one tend to default to thinking that it's others that are inferior and can't handle the facts you see so clearly... so if it turns out you were not right in the end, we've got the worst case scenario -- Now you're not just preventing yourself from learning and improving (which should always be the goal), you've become just like a troll, an asshole who's wrong.
I agree. It takes discipline to be right without being righteous.
Not to disagree, but, quoting the article, I'd like to "underscore the asymmetry" between people that are right and condescending VS people that are wrong, think they are right (or don't care if they are, most of the times) and are condescending just because they can or because that's the way they think you advance your career.
They read somewhere that CEOs have a bad temper and imply that bad temper is necessary to become CEO.
Only from selfish point of view. If you are wrong and convince people to be wrong too, you just very likely made world less good place.
It is important to be right and double check yourself especially if you are able to be convincing.
This is only true when being "correct" doesn't really matter very much (certainly true on the Internet). One of the hard earned pieces of wisdom from age is that the situations in which there IS a "correct" AND it matters are far fewer than you think. Most decisions are a wash so it's fine to concede.
In addition, "polite" is in the eye of the beholder. I can oppose something politely and people will still scream about how unreasonable I am being.
The problem is that "correct" sometimes matters a LOT and has opposition for non-"correct" reasons. Those same people that you deferred to so many times in the past now get very angry when you suddenly put a stick in the ground and go "No. This is correct and it matters and I'm not moving on it." In addition you will find that there is an entire class of social manipulators who just like to "play poker" and will go absolutely apoplectic when you will not budge a decision without new factual evidence.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”--George Bernard Shaw
In short, be polite and understanding by default but don't be a pushover.
Is it tied to HN or hacker/startup culture, SV mentality? To pride oneself on being an effective robot? No care in the world except building the next great thing, damned be everything else? Maybe it's about the types of people attracted to computers? I hear the same kind of response daily at work, I mean, generally, we're not known to be the most socially intelligent group.
Thanks for your work BurntSushi, Andrew, ripgrep is great.
Sometimes we fill the picture in favorably, but if there's anything in a comment that rubs us the wrong way—anything activating—then the picture we create is not a nice one. Since a forum like HN gets millions of posts a year, there are inevitably plenty of hooks to snag us in this way. If you stop and think about what that means experientially, it's sort of shocking: it means that we are surrounded by our own demons. Since everyone else is having the same experience, a forum like this is a community of people who feel surrounded by their own demons, not realizing that we are mostly creating them for ourselves. This is why disagreements degenerate so quickly, even though each party is sure that they're the one in good faith. It's also why you'll regularly see generalizations about how awful the community is, posted by users who participate in it every day. It's surprising that it can function at all.
By "demons" I just mean a composite of our own past painful experiences, which is the store we draw on when connecting the dots about someone else in a defensive way. This phenomenon isn't only online; it happens everywhere that people don't know each other well. But online, we know each other so little that there are more dots to connect.
I've been thinking about this all day since I read it. Thanks for this. It's a profound insight for me.
This along with BurntSushi's insight about emotional code smell makes this one of the best hn post ever for me.
You can.
And probably you should.
Just accept it is not the _only_ tool.
You have a life too, things come at different angles, from everywhere, and impact you and the people you love differently.
I've been working hard for the past 25 years to become an emotionless decision maker when it's about my primary job: writing software.
I don't keep code around because I'm attached to it, if there's a better way to execute the same thing.
I don't reject other people's code just because it's not the way I would write it.
I don't research pureness, I know that to be useful and, most importantly, correct, software has to solve a lot of edge cases and inevitably is going to be full of trade offs.
I don't only work on new software or features, I don't plan complete rewrites of legacy systems if I can work around the problem, I do maintainance, even of legacy systems, maybe nobody is gonna credit you for doing it, but it's what keeps the World spinning and rationally it's one of the most important tasks.
I used to care about "what will people think if I'll solve this with an 'if'?", now I know that it was my emotions blocking me from doing the right thing.
I don't take bug reports personally, although there are times I struggle with the usual "haven't read the documentation" or "it doesn't work it's not really helpful as a description of the problem", but I try to let my emotions out of it, I try to stay away from them as much as possible.
Emotionless doesn't mean rude or "acting like a killing machine" it means you're detached from emotions and when a problem arise you help to find the solution instead of blaming someone or something.
Emotionless is that alert on the plane that tells you to put your oxygen mask first, before helping your children. Because it's the most rational and logic thing to do, the opposite of what a parent would instinctively do out of love.
> Turns out I was just an asshole
Don't be an asshole is a good start too :)
But sometimes is hard when you're young and everyone older around you talks about tricking the system while you just want to fix it (at least that was my struggle with it when I was younger).
> You can.
This is narrowly true in theory, noting particularly that it applies only after the problem is defined, because defining a problem is an application of values which ultimately are rooted not in rationality but in emotional preference.
In practice, people don't and probably practically cannot fully define problems in advance of approaching them, but feel out the parameters of the problem in the course of addressing it, so attempting an unemotional approach invaluable means accepting an incomplete understanding of the problem.
There is no switch that make it true just by flipping it.
That's why I said I've been trying for the past 25 years, it's a process.
On the other hand empathy doesn't work much better in practice.
People (we) are largely irrational.
> attempting an unemotional approach invaluable means accepting an incomplete understanding of the problem.
Of course!
That's a bit silly to say.
It doesn't work like that, it's like saying that if you ignore your arm it stops working.
And nobody ever said you should ignore emotions, but that you are perfectly capable of behaving differently in different situations.
You're not always emotionally charged, you are not always made of steel, you can control what happens to you much more than you imagine.
> Psychology and neuroscience have again and again found how irrational and emotional
Irrational and hormonal, as in "driven by hormones", the layman term is emotional, but it isn't entirely correct.
Emotional is about emotions (nobody consider rage or sadness or loneliness or "I wanna be left alone" emotions, they are considered bad things, something to be removed), but being autistic is not being emotional, for example.
There are a lot of behaviours not caused by emotions, which, BTW, are located in our brain, our logic processing unit, not in our hearts. They are in its backend, the irrational brain, and they are perfectly rational: they are a tool humans used to survive and take life-saving decisions in the span of milliseconds.
They are the same thing as a fire alarm, they signal a change of state, possibly for the worse.
I'll go further and say that we all are at the mercy of our selfish genes, as R. Dawkins proved.
Ignore your emotions and you'll become emotionally immature and a person people won't like to interact with, because your emotions will come up when inappropriate.
The importance of learning to feel and label your emotions is one of the most basic findings in psychology.
I recommend reading about Non-Violent-Communication. It sounds like it is something completely different, but it is a practice for learning to labeling you emotions in different situations, and then being able to react more appropriately.
https://en.wikipedia.org/wiki/Nonviolent_Communication https://www.youtube.com/watch?v=VT8KGgDo6TY
Sorry but no, it doesn't.
If you fall you stretch your arms forward, to protect your head, it's an automatism, your body works the way it is supposed to work even when you ignore it
Most of what it does it's independent from your will
It just works
The heart doesn't stop beating if you don't think about it
What I've learnt is that if you want something done then ask politely, if you want something done now then try and do it yourself. That's the inherent beauty of open source.
I have a hard time conveying my thoughts properly without writing them down. You would watch me blubber about the process rather than the problem.
Beside, it being a privacy issue and not comfortable sharing something that might get memed or used for political purposes.
It helps convey some intent. Hm, that would actually be interesting. A browser plugin that automatically inserts emojis to convey your current emotions or feelings. You can set it yourself, it may learn from your interactions too.
If you consider what you want and you think that it clearly aligns with the maintainer’s needs, then consider sharing your ‘want’ along with an explanation of why you think it’s valuable for their needs.
If you can’t figure out what their needs are, and you can’t provide an explanation for why this is important to them, then there’s no reason for you to bring it up to them at all.
(This will seem abrupt, but it’s not meant to be hurtful in any way - I’m just literal and sociology-ish. I did my best to be clear and kind about my view. No harm intended, apologies if any caused.)
If you are reading this burntsushi, I'm really thankful for ripgrep, a tool I use tons of times almost everyday, as a backend for fzf etc. Definitely a happy user!
To everyone, it seems programmers write 500 words SEO spam posts so not worth much or hard. They can program the same if they wanted to.
(Note - SEO spam posts here refers to subjecive low quality code, duplicate of existing solutions or very similar to what you can do by combining two existing tools.)
Perception or feelings like above are quick to convey so they get conveyed.
Spitting out code is not the hard part of open source imo. It's dedication, commitment, building a community and sustaining feedback. If I am writing software to solve trivial problem, then it wouldn't take me much time but if I am writing software to solve trivial problems for others, It would take me tremendous time to write insignificant piece of code because it needs to be documented, accessible, thoughtful, clean, hosted, testable, branded (naming is one of the hard problems, after all.) and pass through many such criteria.
It doesn't need to but most people who love open source feel this way about their projects.
It's hidden. It's not visible to someone who just created an issue. Somehow we live in meritocratic ideals but forget that meritocratic solution on their own don't get much attention. Without a good readme, a lot of people simply ignore the project. We are actively optmized to go through ton of information that it de-empathizes us to human touch or mistakes. It's quick to notice a typo and make an insignificant comment about it because you can't focus on everything. Anything unexpected is a distraction and we get easily distracted, thus sometime vent on meaningless things.
I’ve aliased grep to it so that I never have to suffer through slow searches if I type grep out of muscle memory.
Love reading his code too.
grep () {
I think a large part of it is (at least for me) the inability to believe that you cannot eventually make them see the light.
Sometimes that actually happens. Mostly it doesn’t.
Something I struggle with on other internet forums, too. I try to tell myself that I'm not just writing to change the low-effort antagonist's mind, but for everyone else reading the thread, too.
Respent for every maintainer and contributor, it's not easy. You can read some issues in the repository, the authors of some issues are just complaining or criticizing the idea or bug, it's unfair and rude. in the end, hurt maintainer's passions. Every developer should know it and respect it like the README or guideline before posting issues or comments.
It's a fantastic post about the analysis of OSS maintainer, Respect for Mr. Gallant.
That said, I never had the request to rewrite in a different programming language, yet. Downstream library users as well as package maintainers seem delighted with Python.
I think GitHub sponsors and patreon-like systems can be the way forward. If open source users said "hey, I'll give (10/20/50/whatevers affordable to me now) bucks a month toward open source projects" and then proportion them across projects they choose, that can go forward to things.
But open source is much bigger than projects themselves. One example would be package maintainers on Debian, Ubuntu, Fedora, Arch, BSD port systems, and so on. They put enough time into it they should be compensated.
I think with these new platforms like GH Sponsors, we're on a trajectory toward fixing this.
> I got a drive-by comment effectively telling me to use a “working” license instead, along with some (what felt like) condescending lecture on how licensing works.
I hope my many drive-by github issues on licenses over the years weren't taken as condescending. I want to avoid the headache in the future of a migration, an example of what it can entail: https://github.com/twbs/bootstrap/issues/2054
That's a lot of work.
Worse is the matter of ambiguity with certain licenses. Having something clear and simple that'll work across jurisdictions is a winner.
Wishful thinking or intent doesn't matter when the door is left open for a legal adversary different interpretation of the facts, then having to pay expenses to defend it. That's drama in and of itself, but could also really hurt a business, esp. in early phases.
You can put that in a README, but people won't read it. Github won't let you disable i̶s̶s̶u̶e̶s̶ ̶l̶a̶s̶t̶ ̶I̶ ̶l̶o̶o̶k̶e̶d̶ pull requests, unless you archive the project (making it read-only). Is it possible on one of the other hosting services, like Gitlab?
We need better ways to draw boundaries around open source projects and contributors.
ETA: How can we counter the Bullshit Asymmetry Principle? https://en.wikipedia.org/wiki/Bullshit#Bullshit_asymmetry_pr...
> The amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it.
On GitHub you can disable issues but not pull requests.
[0] https://en.wikipedia.org/wiki/Useless_machine [1] https://developer.github.com/v3/activity/events/types/#pullr...
Unfortunately that useful information comes mixed in with, eg, users who think the author's time is worth so much less than theirs (didn't the author demonstrate it was worth nothing by offering this work for free?) they want hand-holding for every little thing. The author can put it in README.md and point these guys at it when closing their issue.
I mean I'm trying to pick an alternative to Ant Design (because Chinese) and there's a billion of them, but I'm having trouble deciding which one is the best option - Bootstrap, because most stars? Material UI because it shows up high in search results? And there's at least dozens more that will be objectively better (on a technical level) which I'll probably never see, and which I'll probably never use (because low popularity means low engagement and no guarantees that it'll still be around and maintained a few years down the line).
Looks like you can on GitLab under "Settings" > "General" > "Visibility, project features, permissions".
Disclaimer: nobody submits contributions to my hobby projects anyway.
http://unmaintained.tech/
It was also for me a gateway in the sense I see rust come up on HN, but only when I started using these tools I realised how fast and light those little apps can be. It made me want to learn Rust and seeing the community around it I realise, it is a very wonderful thing.
I use ripgrep and xsv daily at work - thank you Andrew aka burntsushi for sharing your code!
I personally think a major issue is he may have over-stretched in terms of the repos he sought to create and support as a maintainer. He has 140 public repos many of them significant. As his interests, shifted I have experienced that the pace of reviewing and responding to comments and pull requests became really slow and ultimately led to frustration among contributors as well.
Might have been better to clearly prioritize and state which repositories he planned to support and which not and possibly either hand over ownership or mark the repo he didn't intend to support as orphaned.
I hope you don't take my comments as combative, I'm trying to speak from experience. I also learned of Mr. Gallant from being on the Go code review lists. I also noticed he seemed to "switch" to Rust. With that knowledge, anything I used heavily I would fork. If one day the two can reconcile, great. If not, congratulations, you own it until you get tired of it and someone else forks it. Such is the nature of open source!
Mentioning that you don't intend to maintain a project is not "labour".
If you don't look at any PR in the next 3/6 months, mark it unsupported.
I got the same vibe from the article TBH, a lot of what he considers rude just seems like well intentioned, if possibly misunderstood, suggestions.
Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template.
With the disclaimer that I have never maintained a highly popular GitHub repo, I get a lot of feedback for my projects that is unuseable, and some that is aggravating. I always have the option of simply ignoring it, and that's the end of that interaction. Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
This was not the vibe I meant to express. I'm sorry it came across that way. I meant to express how it made me _feel_. The next paragraph goes on to say how such issues are eminently reasonable in a lot of cases, and my coming to terms with that is a struggle I face.
My goal was to explain my own perspective in the hope that it increases understanding of everyone involved.
> Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
I tried really hard to leave blame out of my article (for anyone other than myself). That is not how I feel. On the contrary, as I mentioned in my article, setting boundaries is exactly what has helped me so much.
eg If you fork the code where the upstream project is obviously still active, and your changes target the same audience as the original (eg not taking in a new/experimental direction), then it could be rude.
However, if the upstream repo is no longer active the upstream authors may even happy to have someone picking up the leadership role for that particular project.
Characterizing this as "sense of entitlement" in a one liner is quite uncalled for.
In most cases it's a request for more of the maintainer's time to review, fix, and merge a change which they themselves likely don't need (otherwise they would have added it). In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself. It only becomes net-positive when a contributor has a long-lived interest in the project and turns out to be a capable maintainer with similar sensibilities; even then there is significant ramp-up time. 99% of the time this doesn't happen; most contributions are drive-bys.
P.S. It so happens that that we previously interacted on that very PR thread: https://github.com/BurntSushi/toml/pull/65#issuecomment-1919...
Yup. I recognized your username and note that our interaction happened over a year after the original pull request discussion with no response from the repo owner.
> In my experience, at least 80% of the time I end up spending more time and effort on accepting someone's change than I would have writing it myself
Sure but the general culture and expectation in open source is when people find bugs or create features, as good citizens they share the changes upstream. If what you want to do is "throw the code over" or you've lost interest in developing further, all you need to do is to say that as common courtesy to your fellow open source developer especially if like in this case a lot of people use it. Lots of repos do this and clearly stated deprecation.
Whereas "the account has too many prominent repositories to accept contributions to in a reliable manner" lowers trust (which the burntsushi post also discusses).
It's as fair to say "I don't trust the project because it isn't maintained" as it is to say "the code is free, the maintainer's time is not". - I think this is exasperated by that "just fork it" works in a small sense for one or two patches; but there's a communal inertia that complicates it in a larger sense.
The one contributing the most gets notified to accept or deny the request.
How many people vet the author before installing something from npm? If you trust someone because they have some code that looks good, then shouldn't you trust contributors who have good code in there too.
How many points of cracks are there in the dependencies of dependency?
If it's a widely used tool then author wouldn't go inactive for a year without doing something unless they are not getting paid or even acknowledged for their efforts.
If people like security, then pin and mirror your dependencies. Don't update without checking them.
This is unworkable for a large number of reasons. But it's also largely beside the point. If the code is available under a permissive license and is not being maintained, fork it.
I have of course done this many times across different projects. Sometimes it works. Sometimes it doesn't. It isn't the silver bullet you portray it to be. Nevermind the risks involved due to supply chain attacks.
One thing that I found surprising was that the author considered comments along the lines of "Just chiming in to say that I would also really like this feature." to be rude. I would have thought it was helpful feedback; more people indicating the value of a feature seems helpful in assessing whether it's worth doing (if it's not obvious for other reasons).
This probably does not apply to OSS projects that are products built by companies.
In my opinion a good feature request does all that legwork. The goal (my goal) is to arm the maintainer with a action-plan that they can pull out of the drawer and start working on immidiately. If this doesn't work — seeing that the other side did the legwork can still be motivating and creates a good climate.
Just imagine we are not talking about code, but about cool Lego-towers for a moment. If you want the other kid to add a certain detail to the tower, the least you can do is explain it to them properly. Better is to inspire their creativity alltogether: who says your idea is the only/best way to solve the problem?
Quite definitly. But even more helpful would be if you listed all scenarios you can think of where this would be helpful, even ones that are not useful to you, but might be to others.
Then you think about how it would impact existing functionality (both positively and negatively), would it be the consistent thing to do? Where could be traps and pitfalls? Maybe even ad a mockup of hoe it would look.
If you did that, the maintainer sees that you didn't just demand a feature drive-by-shooting-style, but you did the actual legwork of fleshing the thing out. Don't marry your own ideas, others might be inspired by you and have a even better way of solving this.
If you are writing one sentence you are doing to little usually (in my eyes).
The danger with this is encouraging overengineering. It's easy, particularly if someone else is going to be doing the work, to say, "Maybe someone out there might someday want to do X, Y, or Z"; causing a maintainer to put a whole lot of effort and extra complexity into their code for use cases which nobody uses.
In fact, when only a single person wants a feature, there's a similar risk, that I'll put a whole lot of extra effort and complexity into the code for a use case which only one person thinks they want; and that after it's implemented, they decide they don't like it and go somewhere else anyway.
That's why I didn't understand why he considered "I would also use this feature" comments to be rude or unhelpful. I would think knowing that at least two (or three or four) people wanted a feature would be helpful feedback in knowing what kinds of things were worth adding extra complexity.
Perhaps in his mind they took the tone of, "Hey yeah, we're all waiting for you to do this work for us for free; what's the hold-up? Get cracking!" Which of course would be a bad attitude; but looking at the exact thing he quoted, I'd say that's more about what he's reading into it than what the commenter actually said.
Perhaps the point was that unless you have something useful to add to a GitHub issue then don't comment.
People don't want Reddit style pun threads here and yet to hear complaints about that being enforced, in fact the opposite. GitHub issues is similar in that sense. Everything has its place and time.
That's an UI problem.
If a bug affects 100% of the users no matter what or just a few of them, in some weird condition and setup, is completely different.
There should be a way to be prioritize or sort bugs by popularity.
If you add one more use case that might help the maintainer reconsider the feature, then I’d find it acceptable. Sometimes the issue opener didn’t explain the utility that well or wrote some example that made it sound like it would be a niche feature and not worth it.
And regardless, for some projects, at some times, you just feel like working what you feel like working on, and more users clamoring for a particular feature just doesn't motivate you.
First, the assumption that ‘voting’ is an appropriate and helpful form of social interaction with someone who has not expressly invited that participation from others.
Second, the assumption that a group expression of a statement is emotionally equivalent to a single individual’s expression of the same statement.
These are not universally shared assumptions, especially in open source.
> One thing that I found surprising was that the author considered comments along the lines of "Just chiming in to say that I would also really like this feature." to be rude.
I mentioned on r/rust that "rude" is perhaps too strong of a word. I was more or less thinking of things that annoyed or grated on me, and then just kind of lumped that in with "rude." To be sure, I do not get to lay claim to a universal definition of rudeness. :-)
But yeah, I think others responding to you pretty much summed up why it can be mildly annoying. And to be clear, I do think part of this is on me: I'm working on trying to let such minor things like this slide more. It's a process.
This makes perfect sense. The author seems to understand well that there's a balance to be struck when working on OSS; you can't always work only on the stuff you want to work on. On the other hand, being the one who initiates and maintains some FOSS has to mean something. If it doesn't mean you get to decide (within reason) on somewhat subjective calls such as "is this feature worth implementing when weighed against the maintenance burden?" then contributing and maintaining OSS ends up meaning nothing other than willingly doing work for free and letting everyone else in the world be your boss. Clearly that's an untenable situation.
This resonates so much. Users who blatantly waste your time despite multiple cues steering them towards actionable bug reports are worse then trolls or haters IMO. (I use issue templates, with all caps and explosive emojis, and I even put specific actionable wiki links in error messages, but some people still insist on opening barebones “doesn’t work” bug reports. Or duplicates. People open duplicates when there are like three open issues in total and one is clearly the same issue as theirs. What the hell?)
With trolls or haters you can simply drop the ban hammer, easy. With this kind of high-maintenance users, it’s hard to decide whether you should waste time helping them, or simply refuse action until they get their act together.
> It can be maddening. But that's emotions for you. They certainly aren't always rational. The documentation could probably be clearer. Or the user could have just missed that part of the documentation. Or the user doesn't have experience maintaining FOSS projects or filing bug reports and maybe does not know how to provide an easy reproduction. These are all perfectly reasonable things to have happen, and it's why I do my best not to let my emotions get the best of me. While the way I feel is important, empathizing with the person on the other end of the wire is important too.
Honestly it’s hard to empathize with users who can’t follow “run command with --debug, post entire output” or who don’t bother to read anything when the error message clearly says “here’s a wiki article for your specific error, read it before reporting a bug”.
We also had a helpdesk-style support chat for our developer tooling, complete with a bot that would respond to common error messages with links to solutions and people would STILL directly message engineers that supported the tools asking for help on trivial build issues or inability to use command line tools.
It was sort of baffling to see, its not like its any quicker than doing the right thing, it was simply people being lazy. Some of it's an Eternal September, too, I think.
This is pretty much Rust Action Task Force now (which has no programmers)
We have learned to ignore this, and adopted a policy that we just don't care about ratings. If the user is asking for help in a polite way, we help him however we can, for free. If he is an entitled jerk, we just mock him for being entitled.
Of course, then some start ranting how immature our behavior is are and how we must learn to treat our 'customers' better. Of course, right.
Slightly off topic - I can understand that people publish on Google Play to get reach, but it's upsetting when open source projects make it their sole binary distribution mechanism. It is strange to mandate that the user adopt the model of centralized control by Google, when 3rd party binary distribution is just as well supported on Android as any other platform. This goes for any app, of course, but open source apps in particular ought to know better (and with F-Droid, need not even host the files themselves).
As for alternatives. FCM (or, for that matter, Apple's APNS) requires a persistent connection between a device and push servers to work. Curiously, both Google and Apple seem to be doing this via maintaining a modified XMPP protocol. And this just can't be replicated by any other party: to maintain a persistent connection an app must work all the time and be active in the background, and both Google and Apple heavily suppress background app activity (google has some workarounds, but they become more and more restricted with each OS update).
All in all, I believe that this policy is begging for some antitrust action, so device owners could legally subscribe to alternative app stores and push notification providers. From what I know about XMPP, replicating a server part of a push service should not be insanely hard to do.
Keeping a TCP connection open on a mobile link requires occasional keepalive package exchange. That wakes up the mobile radio, which is quite power hungry if the device isn't doing anything else.
That radio wakeup is needed for each independent TCP connection's keepalives, so to minimise the power consumption of multiple idle app/notifier connections, you want them multiplexed over a single TCP connection.
Another factor is the ability to send the underlying event over a lower-level mobile protocol. The mobile base station is regularly exchanging with the handset anyway, to maintain a link which can carry station-to-handset events already and to monitor the link. The whole thing is very well optimised for the radio. So an occasional application event can be sent over that link as well without needing any extra keepalives or radio wakeups. That's the most power efficient thing to do in principle, assuming application events aren't happening often.
Unfortunately, having lots of independent push notification providers being used by different apps at the same time would be quite power hungry.
I think it would be great if a user could direct all the subscriptions through one or two services of their choice though, including an option to provide their own service URL that they run themselves.
Trolls are much louder than lurkers. There are a silent majority of us that know how much time and sweat goes into building free tools. We appreciate what you do because you do it for love of being a hacker and showing everyone else how you did it.
I don't think people realize how hard it is having a day job and then building a huge project people want to use. It's mentally taxing. It sucks even more when it's only negative things. Life is already hard man, why do these people have to keep trolling you? It's enough to make you want to flip the desk and give it all up.
I love reading your Rust code, and seeing how active you are on reddit/hacker news. Going through how you built the Aho Corasick crate and comments on you trying to reverse hyperscans teddy algo. was amazing for me. I spent so many hours that day reading ripgrep source code. I was amazed and what you did and the comments everywhere about why, like why the printer was pull/push. The whole time, I was geeking over what you did so much that you started my love of Rust.
Anyways, thanks for just being you man.
Thank you Burntsushi. You rock my world!
I am going back to university (a place a swore never to return to) to learn about algorithms and algorithmic design, starting next Monday. Because of you.
Nobody has had this big an influence on my career, and every time I hit `rg` on my computer I do so with immense gratitude.
Just thought you should know.
Thanks for the awesome crates!
[1] https://github.com/stickeritis/wordpieces/blob/7abbfb893ec20...
I will second Kragen in saying that there surely are many others like me, that has been inspired by your work.
Oh and btw, it was the post on Automata, not ripgrep. This one https://blog.burntsushi.net/transducers/
I’ve seen this in quite a few people, both online and in the real world – people that think they are all about logic and not about emotions. And in each and every case, I believe they are only fooling themselves in thinking so. Emotions are really powerful and they affect us all in far more ways than a lot of people like to admit.
Love, hate, jealousy, insecurity, and the list goes on.
People are really good at rationalizing their feelings though, so it is easy to get fooled into thinking that a decision or stance we took was based in some objective truth when in reality emotions were steering us.
Yet so many people refuse to accept that this is the case for them just like it is for everyone else. Even though it is blatantly clear to a lot of people around them when they are acting as they do because of emotions.
I think the world would be a better place if everyone admitted to themselves that emotions is a part of our nature. Then perhaps more people would be able to handle their own emotions better, and we would all, including themselves, be better off.
I certainly try to listen to my emotions and to understand how they effect me.
All the stuff that's neither logic or emotion. Which tend to be invisible to geeks.
I came up with gamers. Most very smart, in the high IQ and educational achievement departments. About half were very dismissive of other people's ideas, views. "I'm smart and logical. You're wrong. Meaning you're dumb, illogical, or worse, emotional."
burntsushi is one of these people in open source that we would need more of — both because of the quality of his work and the positive and grown way he interacts with the world.
If you read this: thank you for the incredible effort, switching to your software was a complete no-brainer as it is well documented and works — and before this creates pressure: it certainly will not get any worse. Work at your own pace.