
My FOSS Story - mfrw
https://blog.burntsushi.net/foss/
======
k4ch0w
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.

Anyways, thanks for just being you man.

~~~
Casperin
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.

Just thought you should know.

~~~
burntsushi
Wow, that is some heavy praise! Thank you very much for the kind words. I wish
you all the best with your return to university. :-)

~~~
kragen
There are probably dozens of people who have been similarly inspired by you,
but aren't reading HN this morning.

~~~
danieldk
...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.

Thanks for the awesome crates!

[1]
[https://github.com/stickeritis/wordpieces/blob/7abbfb893ec20...](https://github.com/stickeritis/wordpieces/blob/7abbfb893ec20dfcc3bdd0f4494c468e88b90739/src/word_pieces.rs#L28)

------
srik
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!

~~~
indemnity
I’m sure almost everyone doing web uses ripgrep daily without realising it, by
way of VS Code search or Atom Search.

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.

~~~
quindecagon
Retrain your muscle memory.

grep () {

    
    
      echo "Use rg"
    
      rg "$@"
    
    }

------
faitswulff
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.

~~~
Pfhreak
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.

~~~
macintux
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.

~~~
BLKNSLVR
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.

~~~
phreack
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.

~~~
cjslep
> Being right does not give a right to be condescending about it

I agree. It takes discipline to be right without being righteous.

------
axaxs
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.

------
StavrosK
When reading articles like these I am mostly surprised, because my experience
with FOSS has been largely different. I maintain a few semi-popular libraries
like shortuuid and catt, but users have always been helpful and courteous, the
pull requests have always had the best interests of the library in mind and
the users were open to feedback, and the worst I've gotten was users politely
asking for support with their particular setup, to which I politely reply that
I unfortunately don't have enough time to debug things outside the scope of
the code and that's that.

Has anyone else had this experience? Maybe the trouble comes with libraries as
popular as ripgrep, or maybe it comes more often to a specific type of person.
I'm generally not very patient, so I'd expect to have much more trouble than
other maintainers, but I'm also just not negatively affected by bugs and PRs
at all. People filing them have taken their time to do it, which means my code
is important enough to them to spend time improving it, and bugs happen, so I
take bug reports as compliments rather than as personal failures.

Hopefully someone else has the same experience as me, and maybe we can figure
out how to generalize that experience for others.

~~~
burntsushi
Yeah, not everyone is going to have the same experience. And I'm sure it's at
least partially related to your user base. For example, most of the things I
build are _mostly_ consumed by other programmers. But what if it was consumed
by mostly non-technical users? I'm sure anyone could guess how that might
impact your own experience with your users. (I do have some projects, like
nflgame, that were mostly targeted at folks who were beginning coders or even
sometimes folks who couldn't code at all. The experience was quite different,
but overall still positive.)

I think the other thing I'd like to re-iterate is that the vast majority of my
interaction with others in FOSS _is_ either neutral or positive. This is kind
of what I meant by the negativity overshadowing the positive and how, at least
for me personally, the negativity sticks in my memories more than anything
else.

~~~
StavrosK
> I think the other thing I'd like to re-iterate is that the vast majority of
> my interaction with others in FOSS is either neutral or positive.

I think this is the issue. I get maybe a few issues a month, so I don't get
enough volume to have very negative interactions.

By the way, thanks for ripgrep, it's one of the most-used and most useful
tools in my command line.

------
jasonkester
I think the author is on the right track with his section on Setting
Boundaries.

Personally, by the time I release something as open source, it is Finished.
That is, it's feature complete and working to my satisfaction, and as far as
I'm concerned probably won't need much in the way of improvement going
forward.

So while I do occasionally get feedback from people using it, there's never
any pressing need for me to do anything about it. There have been a handful of
genuine bugs over the years, but mostly it's requests for features that I
don't need, and therefore probably won't add.

Occasionally somebody will go as far as adding one of those features
themselves, including a patch or PR with the addition. Thus far, all of those
cases have been for stuff I hadn't personally seen as necessary, so my only
response is to politely decline and suggest the author forks off his own
version if he wants to publish that change.

My philosophy, in short, is that the code I release is out there to use if you
want. But it's not something that needs "maintenance". It's Finished.

~~~
blub
Yours is the only mentally healthy attitude one can have today in regards to
open source. The character and audience of OSS have changed and increased
respectively.

It was quite sad to read this post for me, because I can see that the author
has partly interwoven their sense of self-worth with their OSS work. The whole
blog is a painful balancing act between speaking their mind and being polite
which can only end in more grief for them until they let their displeasure
show.

This is not coincidentally the impression I also get from the larger online
Rust community. They repress their feelings, always trying to be prim and
proper in their interactions, but those normal(!) negative feeling are still
there and vent in bizarre ways, such as bothering random Rust developers the
other day because their code is not "safe enough".

~~~
burntsushi
> until they let their displeasure show.

That's exactly what setting boundaries is.

------
rectang
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.

ETA: How can we counter the _Bullshit Asymmetry Principle_?
[https://en.wikipedia.org/wiki/Bullshit#Bullshit_asymmetry_pr...](https://en.wikipedia.org/wiki/Bullshit#Bullshit_asymmetry_principle)

> _The amount of energy needed to refute bullshit is an order of magnitude
> bigger than to produce it._

~~~
ddevault
You can do this on SourceHut, just make a git.sr.ht repo and don't make
anything else (ticket tracking, mailing lists, etc, are opt-in).

On GitHub you can disable issues but not pull requests.

~~~
tejtm
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

[0]
[https://en.wikipedia.org/wiki/Useless_machine](https://en.wikipedia.org/wiki/Useless_machine)
[1]
[https://developer.github.com/v3/activity/events/types/#pullr...](https://developer.github.com/v3/activity/events/types/#pullrequestevent)

------
codetrotter
> 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.

~~~
specialist
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."

------
elyobo
This is a really good article.

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).

~~~
DarthGhandi
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.

~~~
elyobo
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.

------
dancek
This is a great article. I respect every FOSS maintainer for what they're
doing and am saddened by the bs I often see them deal with. The article is
balanced in describing different reasons for coming off rude--as a non-native
speaker of English I've been rude without meaning to, for example. But even if
the intentions weren't bad per se, these interactions are an unnecessary
burden to the maintainer.

So to reiterate: any bug report or pull request that isn't _good_ will waste
the maintainer's time and effort. I wonder if the community could address
that. I mean, most anyone could screen issues for tone and the effort taken.
We could have a group of volunteers that tag issues worthy of the maintainer's
time and explain to reporters how they should improve. That would be a
valuable contribution to FOSS.

Setting up the system to do this is not trivial, however. Ideally I'd love to
just tag my repos for _issue review_. I'd wish for the reviewers to be
trustworthy. And as a volunteer reviewer I'd want a queue of issues to review,
and I'd require some compensation (e.g. a profile page showing how helpful
I've been).

I guess the feasibility of this idea comes down to the availability of
volunteers. What do you people think?

PS. Burntsushi, if you're reading this, huge thanks for your great software.
You're one of the people whose contributions I appreciate the most in FOSS.

~~~
burntsushi
Thanks for the kind words!

You have an interesting idea, but it seems tricky to pull off in practice. To
be clear, I'm not necessarily trying to say that low effort issues _are_ a
waste of my time, but rather, that is sometimes how _I feel_. I think it would
be good to collectively reduce their occurrence---I'm not sure how---but
sometimes the choice isn't between "low effort issue" and "high quality
issue," but rather, "low effort issue" and "none at all." In the latter case,
I'm not sure which I would prefer. Certainly, sometimes low effort issues
really do lead to productive outcomes.

It's tough and it's not something that has an easy answer. Some part of it is
me overcoming how negatively I feel about them and another part is perhaps
others spending a bit more time filing good issues. At least, in my opinion
anyway!

~~~
dancek
I didn't mean to imply how you think or feel. Sorry if my comment came off
that way.

Maintainer burnout is a real problem and I personally would run a real risk if
I ever released something worthwhile.

I agree that the idea is raw and difficult to implement, but we should think
about these things as a community (ie. I don't have the energy to do anything
about it, but I'm hoping someone would).

------
AnIdiotOnTheNet
There's a reasonable amount of FOSS developers here, so let me ask a question.

Often times I'll run across a FOSS project that claims to solve a problem I
have, encounter a bug that makes the project useless for my purposes, and
discover that said bug has had an open entry in the issue tracker for _years_.
This even occurs in major FOSS software with paid developers working on it.

Clearly no one actually cares about the bug, and "chiming in" is apparently
considered rude. So I ignore your software and move on. Whatever, you don't
owe me anything.

Then some day I respond to a forum post by someone asking about experiences
with your software, and relate mine. Apparently this is also rude, and I
should have filed a bug report.

I guess my question is: is there any scenario under which one can actually
provide feedback other than praise that you will accept?

~~~
burntsushi
> Clearly no one actually cares about the bug, and "chiming in" is apparently
> considered rude.

I clarified this a bit more in my article.

> Then some day I respond to a forum post by someone asking about experiences
> with your software, and relate mine. Apparently this is also rude, and I
> should have filed a bug report.

... that is definitely not what I said. What I said was this:

> Unconstructively whining about software on [insert social medium here].

I'm not sure how this means you can't post constructive critical feedback.
That's certainly fair game.

~~~
dilap
I actually came to this HN thread specifically looking for the word “chime”
because it seemed so at odds w/ what I would personally consider rude.

I hope you don’t think this comment is also rude!

Anyway, let me say, ripgrep is an amazing fucking tool. Really love it. <3

------
oefrha
> 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”.

~~~
rrix2
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.

------
atoav
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.

------
lordleft
What a phenomenal article. It's shocking how entitled people get about 100%
free software. Some really emotionally intelligent insights here.

~~~
gitgud
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.

~~~
rectang
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.

~~~
thrwaway69
Then you would never recieve an issue from me. :(

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.

~~~
rectang
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.

~~~
thrwaway69
We should use more emojis. :D

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.

------
dunkelheit
I used to maintain a fairly popular and important open source project and I
can definitely empathize with lots of what Andrew has written.

What always fascinated me is just how much the _form_ of a request impacted
the probability that I would spend energy to help. Someone who submits a
polite and well thought-out bug report just makes you want to help them. OTOH
someone writing "Hey when will you fix your stupid bug? My startup has already
lost $XXX in revenue because of you" just fills you with schadenfreude and
makes you want to troll that person, even if the request is essentially the
same in both cases. Some users just don't understand how much they undermine
their requests. This kind of attitude may work if you are a boss or a
customer, but open source runs on common courtesy.

One bit of the article that I disagreed with is classifying "Just chiming in
to say that I would also really like this feature" as rude. Yes, it is passive
aggression, but it is better than active aggression and still provides a bit
of valuable information. Open source at its best is like a swarm of locusts
devouring the problem domain and for this to work information must flow from
users back to developers.

Oh, and thanks for your open source work, burntsushi!

~~~
JediWing
Yeah I agreed that this call-out seemed out of place. I wouldn't even
categorize it as passive aggressive. I see it as attempting to give input as
to what ought to be prioritized. The intent seems positive to me as long as
it's not pushy.

Now, maybe the maintainer doesn't want this form of input, or prefers to have
the input in the form of issue voting, etc. Overall though I don't see the
action as inherently rude.

Then again I'm not a major project maintainer.

~~~
burntsushi
"rude" is perhaps too strong of a word. I've added a clarification to the
article since a lot of folks seem to be getting hung up on this. I also
responded to this here:
[https://news.ycombinator.com/item?id=22098281](https://news.ycombinator.com/item?id=22098281)

------
lqs469
Just like the author of actix-web decides to exit from his popular Rust open
source project recently([https://github.com/actix/actix-
web](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.

~~~
xiaodai
Pay the maintainer!!! We need Software Institutes fund by the United Nations
for maintaining open software

------
xwowsersx
> 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.

------
einpoklum
> why didn't this person take the time to read and fill

> out the issue template?

Really? I'm thankful when people just report bugs, rather than ignoring them.
Assuming they're actual bugs. I can always ask them for details and wait until
they give them.

I feel like I've been saved the embarrassment of the bug continuing to live on
in the code.

> 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?

For me, I'm frustrated that the UI and documentation are not clear enough, or
not attractive enough, to ensure everybody reads them and abides by them. I
mean, for me it's an imperfection on my part, or perhaps "basic human nature".

What I'm most frustrated about is when people can invest the time and effort
to write long bug reports without realizing that the behavior they're seeing
is not a bug at all.

Another source of frustration is bugs which are not mine, but affect the
behavior of my software, and which I can mostly do nothing about.

------
floatingatoll
I think there might be value in creating a “Maintainer’s Cookbook” of socially
appropriate phrases that they can use to decline interest in feature requests,
technical support, pull requests, bug reports, etc.

“ _That looks like an excellent feature! Good work, thanks for showing it to
me :)_ ” [pull request closed]

“ _I’m sorry to hear that it’s not working out for you. If you’re able to work
out what went wrong, feel free to post an update._ ” [closes issue]

“ _That’s an unfortunate flaw to have encountered. It doesn’t come up in my
usage, but I agree with your diagnosis. If you end up fixing it in your own
fork, please do mention this issue._ ” [closes issue]

And an accompanying “Open source user guide” that covers the basics (much of
which I don’t know today)

“ _How to fork, repackage, and replace an upstream Node dependency when you’re
trying to fix a bug_ ”

“ _When is it appropriate to submit an issue /feature/pull request?_”

“ _How do I upvote something I want to see an open source author do for me?_ ”

etc.

------
swayson
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.

------
Andrew_nenakhov
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.

~~~
dTal
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).

~~~
Andrew_nenakhov
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.

~~~
dTal
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).

~~~
Andrew_nenakhov
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.

~~~
jlokier
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.

------
gwern
It's an unusual comparison, but this New Yorker story about a Buddhist monk
maintaining the equivalent of a suicide hotline in Japan struck me as one of
the best things I've read about the difficulty of being a maintainer:
[https://www.newyorker.com/magazine/2013/06/24/last-
call-3](https://www.newyorker.com/magazine/2013/06/24/last-call-3)

------
scoutt
I own a couple or FOSS repos myself, and after some years I tearnt to classify
my projects into two categories:

 _ego-boosting_ : projects I don't care much and that I give away just because
I enjoy making them and increment my selfish ego-feelings when someone uses
it.

 _work_ : a project that has a specific _work_ purpose or is the base or core
product and that I want the users to adopt it.

Now, I hope the following isn't too rude, but it's the way I developed a thick
skin, and also how I think about it when trolls and haters come around my
projects: being a repo maintainer gives you a (small) _position of power_
(take it easy, you are not Torvalds!). That is, when someone downloads or uses
your project, is that _someone_ that came to you and not the way around; when
shitposting in some forum happens, it's them talking about you and not the way
around. When there is a rude request of some type, it's them needing you and
not the way around.

When someone comes with "you should X...", my toughs are "yes, I should
because, instead of being completely useless about it, I'm the only one who
_can_ do something about it".

Of course, the above applies to the _ego-boosting_ kind of projects more than
to the _work_ ones (since I want adopters coming and staying around, I can be
more flexible).

If the request or critique comes from well educated, patient users, then
obviously the above doesn't apply and the support/request goes through
smoothly.

If the critique comes from a peer maintainer or someone you esteem, then the
situation could be different (and happened a few times to me, and I can't
remember how I felt).

------
Anthony-G
That’s a fabulously well-written article: very insightful and demonstrating
remarkable self-awareness. It inspired me to check out the README for
_ripgrep_ and I was equally impressed with the quality of its documentation.

Until now, I’ve always shied away from any of the modern `grep`-like programs
as I prefer to be comfortable with the standardised utilities as specified by
POSIX (`find` and `grep`). However, I often find myself using GNU extensions –
since they’re so useful and make certain tasks easier. I figured today would
be a good day to take it a step further and try out `ripgrep`. One feature
that immediately appeals to me is that `rg` automatically respects
`.gitignore` and skips hidden files/directories and binary files; When
searching recursively, I pretty much always use `-I` with GNU grep and often
use its `--exclude` and `--exclude-dir` options (features not specified by
POSIX). I’m looking forward to experimenting with _ripgrep_ and discovering
what other benefits it can offer.

So thanks, Burntsushi/Andrew.

------
sylvinus
Burntsushi, as part of the mostly silent crowd I also want to share, for once,
how much I learned from reading some of your code, mostly in the rust regex
crate. Amazing work, truly inspiring.

------
tony
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](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.

------
nojvek
I have mad respect for Andrew (burntsushi). I use ripgrep everyday. Thank you
for the awesome tool. Anyone who uses VSCode also uses it since it powers the
underlying search.

I made some issues asking for some enhancements and was kindly denied. I like
this. It tells me the project is focused. Well I liked it because I got a
proper response within 48 hours. Most projects just have things laying there
forever.

Andrew, if you’re reading this. How do you manage your time to get so much
time to write OS code? Also how do you make enough money to be sustainable ?

~~~
burntsushi
Thanks for the kind words! :-)

> How do you manage your time to get so much time to write OS code?

I don't think there's any secret to it. I just love it, so I wind up _making_
time for it. And my life circumstances allow for it.

> Also how do you make enough money to be sustainable?

I work in Cambridge, MA on stuff mostly unrelated to FOSS. I'm very fortunate
to live in a location where salaries for engineers are pretty good.

------
bla3
What a great article.

I'm a happy ripgrep user. I'm impressed by its speed, its ease of use, and the
positive vibe on the issue tracker. Naturally, I never reached out to
burntsushi -- I don't have anything to complain about!

> 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 wonder if this is in part related to getting older. When I was younger, I
was into being logical myself. But as best I can tell, that was true for
myself back then: I cared about work progressing effectively, and in my mind
the best to achieve that was through direct, blunt communication. When I was
on the receiving end of that, I was happy about it. Now that I'm older and
have kids, I do think a lot more about how to say things. It does make working
with people who are exactly like I was a bit slower, but it increases the pool
of people I can collaborate with. So it's worth it (...I tell myself).

> Rudeness, on the other hand, comes in all shapes and sizes: “Just chiming in
> to say that I would also really like this feature.”

This is a great example. From the side of the person leaving this comment, it
feels so innocuous! "I'm just saying I'd like this too. Ignore me if you want,
I'm just adding a harmless data point." But from the side of the person who's
getting tens of these messages, it feels so very draining.

------
photonios
Andrew, if you're reading this! I use ripgrep every single day and it has
never failed me. Thank you for all your hard work! It's nothing short of
incredible.

Regards, A very happy user

------
bojanz
Communicating expectations / setting boundaries feels key to avoiding
negativity on both sides.

I recently read an article titled "Healthy Open Source Maintenance"[1], which
proposed the introduction of a MAINTENANCE_MANIFESTO.md, meant to communicate
expectations.

Quoting the fun part:

"Even though this idea is still in early stages, for the sake of clarity, this
is what a selection of manifestos could look like:

\- The sponsor me to get priority on your bug fix manifesto.

\- The this is free goods and service, so you get what you get manifesto.

\- The micro-donations to keep the project alive, but I decide what to work on
manifesto.

\- The hire the agency I work for to sponsor features manifesto.

…

The presence of the Healthy Maintainer Manifesto will be a tool to deflect
social pressure. This will help maintainers that suffer from avoidance anxiety
because they are not obligated to pay the maintenance taxes. Their manifesto
says so! If any demanding user wants to pressure them into doing anything in
particular, they can point them to the manifesto. The manifesto replaces
complicated social interactions with a discharge form. The goal of this is to
protect the maintainer, because, after all, maintainers are the cornerstone of
open source—and thus all the software industry. And because we all prefer a
community where maintainers are happy, and not at the brink of burnout."

[1] [https://www.lullabot.com/articles/healthy-open-source-
mainte...](https://www.lullabot.com/articles/healthy-open-source-maintenance)

------
miguelmota
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.

------
lazyjones
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).

------
CodesInChaos
I think offering only a bug tracker and no forum can contribute to some of
these problems.

I only create an issue in a bug tracker for bugs or change request. The
interaction feels impersonal.

On the other hand with a forum you get more of a community feel. There might
be a subforum for writing about your experience with the software (so you get
positive feedback) and one where users help each other, with the maintainer
only chiming in occasionally.

------
Dowwie
Andrew (burntsushi) is a tech leader. He's got a huge heart and a whole lot of
grit. I see him enduring as a high-profile open source project author. How
many battles a day does one accept before reprioritizing life decisions? One
too many strained interactions takes a toll on anyone. No matter how much grit
someone has, everyone has a limit defining how much is worth enduring.

Andrew should not have to deflect burning arrows fired in his direction on a
regular basis, and when they are fired he needs be able to cut them down
before they make a mark. Further, while he has developed the required skills,
his counterparts haven't. I remember an interaction I had with Andrew where he
mistook something I said as a flaming arrow and acted accordingly. Realizing
this, I immediately considered how what I said could be misinterpreted and did
not take offense to his reaction. His situation is far different from mine and
he's fighting battles I can only imagine.

For his sake, and that of others, there needs to be a concerted effort to
address the difficulties that open source authors are dealing with. In an
organization, an employer facilitates various types of training to help
employees navigate challenging situations. Ethics and professional conduct are
learned, as well as conflict resolution. I've taken such training a number of
times and continue to learn from them. There is a huge chasm between knowing
and doing, though, so hands-on training is required to internalize these
skills.

I propose a concerted effort to provide "soft skill" training for the
technology community. Users and authors of open source will benefit. I realize
that this alone will be insufficient but it is one concrete step that can be
taken in the immediate future to begin to address challenges that many people
are having.

------
ericsanchez
@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!

------
zzo38computer
I see that ripgrep is dual license by MIT license and the Unlicense. I suppose
that might be a reasonable way to do it. All of my software is I release it as
public domain, but maybe the dual license might help. A variant I have seen is
a program that uses MIT license, but it also says that any Discordian pope
(which is anyone) is allowed to grant themself a license to use it by WTFPL
(which effectively makes it as public domain, even if it isn't).

Free time is unscheduled is I think reasonable and it make sense. But also you
might have nothing to change for some time, so until then there would not have
any next release.

I write many programs too, but rarely get any comments, whether positive or
negative or neutral. (One exception is my "bystand" NNTP client; I have
received a patch to make it work on BSD, and some bug fixes, which I have
accepted.)

And to write a FAQ document, I think you would need to know the questions.

~~~
samatman
If you want your code to be maximally useable, slap an MIT or BSD license on
it. Anything else is commentary; the Discordian pope one makes me smile, to be
sure.

But yeah, public domain isn't well-defined internationally, so MIT and public
domain is more permissive than just public domain, in practice.

------
justinclift
> But as anyone who has been a FOSS maintainer can attest, positive comments
> are almost always dwarfed by negative comments.

This sounds really weird to me. It's not the first time it's been said either,
but my experiences being a FOSS maintainer (for some reasonably popular
projects) aren't at all dwarfed by negative comments. In my experiences, the
comments are almost universally along the lines of "How do I do X?" and
"Thanks!".

Thinking it over, there have been 2 instances I'd consider rude in the last
few years. One was just... someone being overly demanding, the other was (I
think) just a young person not used to being told No. ;)

Nothing else negative comes to mind.

My point is that being an OSS maintainer isn't automatically something like
the author describes. Some Communities are nice, and the people help each
other out authentically. :)

------
Myrmornis
Thanks burntsushi for this and all your work on FOSS. There's one thing that
I'd be interested to hear about that's not in the blog post -- stuff to do
with how your FOSS involvement and your professional life impact each other.
Ultimately it's zero-sum: 24hrs in a day. Do you often find you much prefer
working on your side-projects than on your day job? Do you think you'd be a
more productive / more engaged / deeper contributor in your day job if it
weren't for the side projects? Or is it more that your love of software would
suffer if it weren't for the side projects and hence you'd actually be a worse
employee? Perhaps those three sentences are bit facile, but hopefully the
question is clear.

~~~
burntsushi
Good question. I don't want to dig too deep into it, but at this point in
time, I really enjoy the diversity. The stuff I do at work and the stuff I do
in FOSS are fairly different and exercise different portions of my brain. I
think I fundamentally enjoy having that difference, although it's hard to say
for sure.

Even just restricting in to FOSS, I will often oscillate between different
projects in order to keep things fresh and avoid burning out. For example,
almost a year ago, I started working on a rewrite of one of my Rust libraries.
I hit a thorny problem and my motivation waned, so I moved on to something
else. I've just recently moved back to continue my rewrite, now almost a year
later, with renewed vigor.

------
sfifs
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.

~~~
axaxs
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.

~~~
Chris2048
You don't think forking would be considered rude?

~~~
justinclift
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.

------
wolframhempel
Could I use this opportunity to ask a more general question: What are your
incentives and goals when creating and maintaining open source projects? I
appreciate this sounds a little disillusioned, but after creating a number of
reasonably succesful projects ([http://golden-layout.com/](http://golden-
layout.com/), [https://deepstream.io/](https://deepstream.io/), earlier
[https://wolframhempel.github.io/photobooth-
js/](https://wolframhempel.github.io/photobooth-js/)) and I still can't find a
fully satisfying answer.

------
C14L
It should be possible to block people on Gh in the same way blocking on
Twitter works. So they can't access your repos anymore when logged in. That
would help a lot of the rude people to learn.

------
nicky0
> But other projects begin to pile up with issues and pull requests. The inbox
> gets longer. Each day you see a new issue come in, and you say to yourself,
> “yes, I will really look at it this time once I get home from work.” But
> more just keep coming in. Eventually you work up the motivation to context
> switch back into that project because That User has pinged you once a month
> for four months and their pull request is probably Really Important.

That's my software development experience in a nutshell.

------
jopsen
In my experience the bug tracker is always full of reports that are ignored or
forgotten. Even a closed project with dedicated staff and limits on who can
file bugs, it's unlikely that all bugs get triaged much less resolved..

In big projects, it's less problematic because it's never your failure, it's
the entire teams failure :)

But this idea that you can respond to all issues won't scale very far.

As the author says we need to set boundaries. Maybe sometimes we're too nice
in trying to respond to all bugs...

------
matheusmoreira
> There is no legal relationship here. There is nothing in my licenses that
> say I ought or have to do this. At least for me, it's an implied agreement
> among humans acting in good faith.

It's important to remember this. Many developers maintain software because
they personally care about the projects, not because they have customers. They
can always just drop everything and let the community deal with it, no
questions asked.

------
justin_oaks
For awesome FOSS projects, like ripgrep, I wish there was a way to donate
praise or goodwill, in addition to donating money. In other words, people can
write in a special area dedicated to words of appreciation and gratitude. All
those FOSS maintainers need to know just how much positivity there is.

Obviously it won't fix the damage of those who are rude or entitled, but
perhaps it'll help provide a boost.

~~~
burntsushi
I appreciate the intent here! For positive vibes, I think emails or social
media is good. But for money, I'm not sure it would work for me. I'm just
going to copy what I wrote in r/rust[1]:

\---

I think the various things people are trying to do to fund open source
contributors and maintainers is a great thing. I love what GitHub is doing
with its sponsorships and encourage folks to use that if it helps them.

But for me, I do not want money to get involved with what is right now a
volunteer activity that I perform exclusively in my free time. If I accepted
money, then at least for me personally, it would magnify a lot of the problems
I struggle with in my blog post. I do not want that.

If folks insist, then I generally advocate donating it to a cause they find
important. The ones I like are Wikipedia, The Internet Archive and Rails
Girls.

\---

[1] -
[https://old.reddit.com/r/rust/comments/er4qrn/my_foss_story/...](https://old.reddit.com/r/rust/comments/er4qrn/my_foss_story/ff2vfs2/)

------
Chris2048
When a project reaches a certain level of activity, maybe the solution is to
find people to help with e.g. triaging issue. It seems a waste that the core
maintainer is having to back-and-forth with people to get them to fill out the
bug reports fully; and willing contributor could probably do that without
needing core-dev expertise.

------
alexellisuk
This post reminds me very much of my own writing last year where I covered
several of the same topics, [https://blog.alexellis.io/the-5-pressures-of-
leadership/](https://blog.alexellis.io/the-5-pressures-of-leadership/)

Hope this also resonates with you Andrew.

------
neilv
I appreciate the author's self-knowledge and honesty, as well as the quality
software.

My own motivations in open source have been a bit different (and sometimes
conflicted), and my experiences and perceptions also a bit different, but a
lot is the same.

------
leshow
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.

------
Joeboy
Just here to add the chorus of ripgrep fans. Was initially skeptical that it'd
be worth switching from the extremely available and basically functional find
/ xargs, but having switched I absolutely wouldn't want to be without rg.

------
est31
Being a maintainer means that you often have to deal with things when they go
wrong. This can lead to the wrong perception that everyone dislikes you and
your software while in fact it's the opposite.

------
coldtea
I, for one, when I read burtnshushi's blog on its design, I switched to rg and
never looked back (had used pt, ag, and grep in that order before).

And xsv has been a standard work tool.

------
michael_j_ward
In terms of a practical takeaway, how much would FOSS maintainer's lives be
improved if you could actually require a runnable example before filing a bug?

~~~
celeritascelery
How many bugs would never get reported? Not saying it is a bad idea, but not
all bugs are so clear.

------
TheGrassyKnoll
(wanna be, old man Rust hacker here)

    
    
      If I *EVER* write a piece of code that's .1% as good as RipGrep, I'll feel like a damned Superstar.

------
htns
I've never heard of an AGPL project being beset by entitled leechers...
granted the license doesn't really matter with end-user applications.

------
fernmyth
Your `xgb` and `xgbutil` libraries did exactly what I needed, and helped me
write a nifty little window management utility for myself. Thanks!

------
ChrisMarshallNY
It’s quite a tome, and I’m glad to see a lot of these topics covered. Not sure
how many folks will read it, though.

I too, tend towards “prolix” (you can see that in my HN comments), and have
often been told “TL;DR.”

I’ve been writing FOSS stuff for a couple of decades, and can relate to pretty
much all of it.

But I keep writing it. No intention to stop.

I tend to write for a pretty tough crowd. It’s helped me to get comfortable
with the fact that I only do this for my own reasons, and I’m glad to help
others, but I don’t need their approval.

I write Swift code, these days. Has some similarities to Rust.

------
sirtoffski
A great read, thanks!

I use ripgrep and xsv daily at work - thank you Andrew aka burntsushi for
sharing your code!

------
throwaway023421
Lesson (not?) learnt: choose your audience. Choose what crowd you want to hang
out with.

------
SirHound
> How much time did that user just waste because of the bug?

I've run my fair share of OSS over the years and had negative comments, rude
bug reports, unconstructive API complaints etc. At my feelings about this
specifically have evolved to: Fuck 'em it's free.

------
fnord77
A consummate professional.

------
ddevault
This resonates with me on every level. Great article.

------
tenant
the standard response to every unhelpful communication to a FOSS project
should be either silence or a "F __k Off ".

------
hvasilev
I don't really understand why anyone would do FOSS, beyond the ideological.
Most of the problems of this person come from the fact that he has no
financial incentive / means to quit his current job and focus on / grow his
project. I feel like I read this exact same story from different people each
month of HN.

~~~
hootbootscoot
shared QA, eyeballs on code, consultancy funnel, freemium software, simple ego
kicks, getting a proof-of-concept in front of a bunch of people interested in
that specific sort of thing, the list goes on...

FOSS, itself, is the necessary lego kit the entire web (and to a lesser extent
mobile and desktop etc) rns on... are you suggesting that everyone go buy
Coldfusion or ATG Dynamo? the 90's called and want their time machine back...

~~~
hvasilev
Steady revenue stream, financial incentives and unlimited initial ways to
monetize your venture beat your entire list, which are definitely not
necessary for a successful project, given by the numerous non-FOSS successes
in the real world.

I honestly don't care that people work for free, it just saddens me that it
takes so long for these people to realize how important financial incentives
are. It is clear as day that this model rarely produces any financial results
for the developer, even if people and companies are actively using and
profiting from your work. That stuff seriously makes me wanna puke.

The reason why it doesn't work is because it violates a very basic business
principle. You don't wait for someone to "give" you money for your product,
because noone is going to do that. As a manager it is incredibly painful for
me to go through the entire chain of command to give you money "for
maintenance". Instead you should "take" it by making me wanna buy it.

The strawman part of your argument i will avoid, since it is a clear
nonsensical trap.

