The open source paradox(antirez.com)
antirez.com
The open source paradox
http://antirez.com/news/134
238 comments
Is this really necessary?
If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed?
If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.
If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed?
If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.
It depends on the maintainer.
There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively. I hate this, because it makes the maintainer look like a cantankerous prick, and it also puts me off using what might be a great project (and of course others will read it to).
IME, if I'm not familiar with the maintainers' temperament, I'm most successful using something like this template:
"Hi! First let me say how much I appreciate this library, it really helps with X.
I've found what I believe is a bug, whereby X (provide logs, stack trace, whatever is relevant).
You can reproduce this by X (provide repro steps or code snippet as appropriate)."
For projects I'm familiar with, things can be more business-like and to the point, and I can also offer to send a PR.
There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively. I hate this, because it makes the maintainer look like a cantankerous prick, and it also puts me off using what might be a great project (and of course others will read it to).
IME, if I'm not familiar with the maintainers' temperament, I'm most successful using something like this template:
"Hi! First let me say how much I appreciate this library, it really helps with X.
I've found what I believe is a bug, whereby X (provide logs, stack trace, whatever is relevant).
You can reproduce this by X (provide repro steps or code snippet as appropriate)."
For projects I'm familiar with, things can be more business-like and to the point, and I can also offer to send a PR.
I like your approach. As a maintainer of small projects with very few users I'm not offended by business-like bug reports. But it's very nice to hear someone is actually grateful for my software. (You only need one arrogant asshole demanding support to feel like your software is shit and maintenance is a burden.) Of course you only need to make a good first impression once.
This approach will also help if another part of your message comes off as arrogant. That can happen when English is not your native language.
This approach will also help if another part of your message comes off as arrogant. That can happen when English is not your native language.
Meanwhile this kind of dancing around the issue will piss me off, though I don't usually respond so.
If there's a bug, tell me what happened, what you expected, what your config/environment looks like, and if it's a library a minimal code example that triggers the bug.
I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.
If there's a bug, tell me what happened, what you expected, what your config/environment looks like, and if it's a library a minimal code example that triggers the bug.
I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.
If you like using my software and it makes your life better in some way, I absolutely want to hear that - it will help keep me motivated the next time working on it feels like a chore.
We love hearing about that in the D forums. But in bug database submissions, just the facts, Ma'am.
P.S. I have several letters from Empire users who reported that the game caused them to flunk out of college and/or get divorced. I'm not sure if they were complimenting or complaining :-/
P.S. I have several letters from Empire users who reported that the game caused them to flunk out of college and/or get divorced. I'm not sure if they were complimenting or complaining :-/
I think the thank you messages could be separate from the bug reports (which should be sterile and 100% tonally neutral). One possible way to separate it is to have thank you messages on twitter. It will also help promote the project, where as these messages in bug reports will get buried and lost and no one else is gonna see it.
Thank you, if I had expressed it this way I don't think I'd have riled as many feathers but this is exactly my stance. (apart from specifically Twitter)
I take your point, and I wouldn't want to read through reams of frivolity either - but there really wasn't anything like that in my example; it's 1 or 2 like saying "thanks", and then my example included all of the stuff you asked for.
Yeah, there's a difference between sharing your life story and a quick thank you, and if I have to take into account people who get offended by being thanked, then I wouldn't be able to communicate at all anymore.
You can't please everyone, and erring on the side of being too polite on average has worked pretty well so far for me.
You can't please everyone, and erring on the side of being too polite on average has worked pretty well so far for me.
Yeah it was probably an unfair segway into a pet issue of mine, sorry.
Allegedly search engines rank the story higher than the recipe by itself. But that doesn't extend to bug reports.
> I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.
The template given was nothing like that, at all.
Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
I can give a pass to Linus Torvalds and those under time pressure. I doubt any of the devs here commenting on HN are able to make either of those claims.
The template given was nothing like that, at all.
Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
I can give a pass to Linus Torvalds and those under time pressure. I doubt any of the devs here commenting on HN are able to make either of those claims.
> The template given was nothing like that, at all.
That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.
> Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
Let's start with the part where I said "though I don't usually respond so." It irritates me, but I tolerate it because my goal is to help people.
As for not having space for stories/niceties driving away women, I don't walk into the emergency room and think "man, this is a sausage fest". Usually there are vastly more women working there than men. Yet from discussions I've had with people who work in that area this is a common frustration there as well.
"You're bleeding, I don't need to hear about how depressed you've been since your grades are poor, fast forward to the part where you slipped while drunk and fell onto a broken beer bottle so I know what kind of treatment to administer." That's a made up example but is actually less ridiculous than the actual examples I've heard.
I'm not saying to leave out relevant details, but when you're bleeding or have broken bones or your left side is going numb, just tell the doctor the facts, as concisely and as clearly as you can.
If you want to tell stories, go to your primary doctor when you're not facing an emergency. Or, and this is not dismissive so please don't interpret it as such, go to a therapist, or a councilor.
A bug report on an issue tracker is obviously not life threatening in the vast vast majority of cases, but it's the same idea. It's where you go when things are broken, so tell me what's broken and the relevant context.
If you want to give thanks or talk about what you like or how you get value from the project or whatever, there are other venues for that and I encourage you to use them. Or put it at the end of the issue thread after the problem is at least identified. I've never been upset at someone for clearly expressing the problem and then saying thanks when I fix or acknowledge it.
EDIT:
> I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
It takes some serious mental gymnastics to turn a focus on helping people as quickly as possible into "a display of dominance and self-importance". I'm specifically asking people to not kiss my ass about "how much this project helped them during a dark time in their life" or whatever so I can get to the root of the problem they're encountering and resolve it.
It's incredibly bad faith to claim that trying to be efficient with my volunteered time so I can help as many people as possible is an attempt to dominate the people I'm helping. Frankly this sentence makes me question your motives here. Had I taken this sentence in earlier I wouldn't have responded to your post at all.
That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.
> Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
Let's start with the part where I said "though I don't usually respond so." It irritates me, but I tolerate it because my goal is to help people.
As for not having space for stories/niceties driving away women, I don't walk into the emergency room and think "man, this is a sausage fest". Usually there are vastly more women working there than men. Yet from discussions I've had with people who work in that area this is a common frustration there as well.
"You're bleeding, I don't need to hear about how depressed you've been since your grades are poor, fast forward to the part where you slipped while drunk and fell onto a broken beer bottle so I know what kind of treatment to administer." That's a made up example but is actually less ridiculous than the actual examples I've heard.
I'm not saying to leave out relevant details, but when you're bleeding or have broken bones or your left side is going numb, just tell the doctor the facts, as concisely and as clearly as you can.
If you want to tell stories, go to your primary doctor when you're not facing an emergency. Or, and this is not dismissive so please don't interpret it as such, go to a therapist, or a councilor.
A bug report on an issue tracker is obviously not life threatening in the vast vast majority of cases, but it's the same idea. It's where you go when things are broken, so tell me what's broken and the relevant context.
If you want to give thanks or talk about what you like or how you get value from the project or whatever, there are other venues for that and I encourage you to use them. Or put it at the end of the issue thread after the problem is at least identified. I've never been upset at someone for clearly expressing the problem and then saying thanks when I fix or acknowledge it.
EDIT:
> I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.
It takes some serious mental gymnastics to turn a focus on helping people as quickly as possible into "a display of dominance and self-importance". I'm specifically asking people to not kiss my ass about "how much this project helped them during a dark time in their life" or whatever so I can get to the root of the problem they're encountering and resolve it.
It's incredibly bad faith to claim that trying to be efficient with my volunteered time so I can help as many people as possible is an attempt to dominate the people I'm helping. Frankly this sentence makes me question your motives here. Had I taken this sentence in earlier I wouldn't have responded to your post at all.
Yes, get rid of the niceties when you're under the kind of time pressure and situation you might find in an emergency room and you're bleeding.
Otherwise, use them. Does your development time resemble the conditions above, or is it more like you sitting at a keyboard in a nice room with a coffee reading comments on the internet?
As to an emergency room not looking like a sausage fest, the stats don't back you up. From [1]:
> The study's lead author, Remle P. Crowe, a research scientist at ESO – an emergency-medicine data company based in Austin, Texas – says she wasn't particularly surprised by the results, which culled data on graduates of EMS training courses as a proxy for likely diversity in the upcoming workforce. A former emergency medical technician, Crowe says the profession has long struggled to attract minorities and women, and previous studies have shown similar outcomes.
There are plenty of numbers given in the article that show low numbers of women among emergency room staff.
[1] https://www.usnews.com/news/healthiest-communities/articles/...
Otherwise, use them. Does your development time resemble the conditions above, or is it more like you sitting at a keyboard in a nice room with a coffee reading comments on the internet?
As to an emergency room not looking like a sausage fest, the stats don't back you up. From [1]:
> The study's lead author, Remle P. Crowe, a research scientist at ESO – an emergency-medicine data company based in Austin, Texas – says she wasn't particularly surprised by the results, which culled data on graduates of EMS training courses as a proxy for likely diversity in the upcoming workforce. A former emergency medical technician, Crowe says the profession has long struggled to attract minorities and women, and previous studies have shown similar outcomes.
There are plenty of numbers given in the article that show low numbers of women among emergency room staff.
[1] https://www.usnews.com/news/healthiest-communities/articles/...
> Yes, get rid of the niceties when you're under the kind of time pressure and situation you might find in an emergency room and you're bleeding.
Again it's my fault, I brought up storytelling and was complaining about that. I'm not upset at the word "please" or something. Your posts keep saying niceties and my posts keep saying stories, which makes me think either you're not hearing my repeated admissions of sidetracking or you're intentionally pushing an agenda.
> > That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.
Was my wording there.
> As to an emergency room not looking like a sausage fest, the stats don't back you up.
As I understand it emergency rooms work with EMS but most people in the emergency room are not EMS. If those stats do extend to the E.R. workers then I wonder whether my local E.R. does something different or if it's purely chance, but I'd estimate 70% female at least.
Either way the point was an analogy. Bug reports are for the bug details. There are other venues to talk about how much this leftPad library changed your life. That's all I'm trying to say.
It's very strange how in this thread maintainers who prefer ass kissing are egotistical and dominating, and maintainers who don't require ass kissing and would be more comfortable if you left it off are also egotistical and dominating. Is the message you want to convey simply that I should not volunteer my time to helping people?
Again it's my fault, I brought up storytelling and was complaining about that. I'm not upset at the word "please" or something. Your posts keep saying niceties and my posts keep saying stories, which makes me think either you're not hearing my repeated admissions of sidetracking or you're intentionally pushing an agenda.
> > That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.
Was my wording there.
> As to an emergency room not looking like a sausage fest, the stats don't back you up.
As I understand it emergency rooms work with EMS but most people in the emergency room are not EMS. If those stats do extend to the E.R. workers then I wonder whether my local E.R. does something different or if it's purely chance, but I'd estimate 70% female at least.
Either way the point was an analogy. Bug reports are for the bug details. There are other venues to talk about how much this leftPad library changed your life. That's all I'm trying to say.
It's very strange how in this thread maintainers who prefer ass kissing are egotistical and dominating, and maintainers who don't require ass kissing and would be more comfortable if you left it off are also egotistical and dominating. Is the message you want to convey simply that I should not volunteer my time to helping people?
This is what you responded to, this is what is being advocated.
> "Hi! First let me say how much I appreciate this library, it really helps with X.
When I, or anyone else in this thread advocates for adding a life story into a bug report or the like, then you can bring in your stories about stories and it'll be relevant.
> Is the message you want to convey simply that I should not volunteer my time to helping people?
Quite obviously not, it's that you should stop comparing yourself to those in life threatening, intensely time pressured situations and try to be more pleasant to those you're responding to, not trying to find excuses around doing so. You work in a pleasant environment, with low pressure, and are well rewarded, you definitely have the time to be well mannered.
> maintainers who prefer ass kissing are egotistical and dominating
It's not about "ass kissing" but basic respect, and if you wanted to provide an example of how not to exercise restraint and apply any semblance of etiquette, that would be a good one. Do you ever wonder why development is a "sausage fest" instead of the emergency room?
> "Hi! First let me say how much I appreciate this library, it really helps with X.
When I, or anyone else in this thread advocates for adding a life story into a bug report or the like, then you can bring in your stories about stories and it'll be relevant.
> Is the message you want to convey simply that I should not volunteer my time to helping people?
Quite obviously not, it's that you should stop comparing yourself to those in life threatening, intensely time pressured situations and try to be more pleasant to those you're responding to, not trying to find excuses around doing so. You work in a pleasant environment, with low pressure, and are well rewarded, you definitely have the time to be well mannered.
> maintainers who prefer ass kissing are egotistical and dominating
It's not about "ass kissing" but basic respect, and if you wanted to provide an example of how not to exercise restraint and apply any semblance of etiquette, that would be a good one. Do you ever wonder why development is a "sausage fest" instead of the emergency room?
Speaking of basic respect, when someone admits to a mistake several times in a conversation and says explicitly "I waded in" and "it wasn't fair [of me]", repeatedly focusing on berating them for that mistake is not very respectful.
It shows that you are not listening to understand, but to find argumentative points. If you're truly concerned about dominating behavior that drives people away, I suggest you start with your own communication. I've been there myself, and I slip up quite often, so don't take this as judgement, only advice.
It shows that you are not listening to understand, but to find argumentative points. If you're truly concerned about dominating behavior that drives people away, I suggest you start with your own communication. I've been there myself, and I slip up quite often, so don't take this as judgement, only advice.
> Speaking of basic respect, when someone admits to a mistake several times in a conversation and says explicitly "I waded in" and "it wasn't fair [of me]", repeatedly focusing on berating them for that mistake is not very respectful.
We go from a grandmother's chilli recipe in an issue and end up with a comparison using bleeding patients in an ER. That's not someone apologising for a mistake and correcting, that's someone trying to wriggle around easily challenged and fantastical statements used as excuses. What next - are we airline pilots trying to save a plane with 3 failed engines while children selfishly ask for a tour of the cockpit?
We go from a grandmother's chilli recipe in an issue and end up with a comparison using bleeding patients in an ER. That's not someone apologising for a mistake and correcting, that's someone trying to wriggle around easily challenged and fantastical statements used as excuses. What next - are we airline pilots trying to save a plane with 3 failed engines while children selfishly ask for a tour of the cockpit?
I want to add, as an OSS maintainer myself, I don't put the blame for attitude solely on the kind of maintainer I mentioned. It's very common to get get users using demanding, demeaning or ungrateful language, and that type of thing does wear on you.
> There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively.
You are only responsible for what you say and do, not how someone else chooses to react. If you provide a bug report in good faith, and don't act entitled or snotty, you've done your part, and have behaved within the terms of the implied social contract. If the maintainer chooses to react in an unwarranted manner, that's on them, and I think that sort of bad behavior should be exposed for others to see.
Personally, as a maintainer, I find that unnecessary fluffy language makes it harder to get to the meat of the problem, and it annoys me. If you're risking a bad reaction either way, why not choose the way that's objectively the most helpful?
You are only responsible for what you say and do, not how someone else chooses to react. If you provide a bug report in good faith, and don't act entitled or snotty, you've done your part, and have behaved within the terms of the implied social contract. If the maintainer chooses to react in an unwarranted manner, that's on them, and I think that sort of bad behavior should be exposed for others to see.
Personally, as a maintainer, I find that unnecessary fluffy language makes it harder to get to the meat of the problem, and it annoys me. If you're risking a bad reaction either way, why not choose the way that's objectively the most helpful?
I think stating a bug matter-of-fact-style is fine, personally. As long as there isn't a negative tone, I don't think you need the introduction. "Tried this, expected this, got this", with a title containing a clear summary.
I've created and maintained some libraries, and I think if a library maintainer takes issue with totally neutral, fact-stating bug reports, that's entirely on them. If you're stating nothing but the technical details, there's really no implied sense of entitlement or bitterness. Maybe it comes across as cold, but it's an issue tracker, and posting issues is the point. It fits the context.
I've created and maintained some libraries, and I think if a library maintainer takes issue with totally neutral, fact-stating bug reports, that's entirely on them. If you're stating nothing but the technical details, there's really no implied sense of entitlement or bitterness. Maybe it comes across as cold, but it's an issue tracker, and posting issues is the point. It fits the context.
For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.
Personally, I've long held the view that practically all code is buggy one way or another and that many things can mean throwing code away is the best way forward, so one just shouldn't be attached to a few bytes. One should rather feel attached to the project at hand, which then naturally results in one trying to improve it, which means bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.
Personally, I've long held the view that practically all code is buggy one way or another and that many things can mean throwing code away is the best way forward, so one just shouldn't be attached to a few bytes. One should rather feel attached to the project at hand, which then naturally results in one trying to improve it, which means bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.
I think it's also that people don't like feeling stupid, and most bugs are stupid mistakes, so having one pointed out can make you feel stupid.
If you've got tests then you've already seen how many stupid mistakes you make, long before release. To get that far and still not have learnt enough humility to accept there may be more is quite the achievement!
Catching a bug while testing is clever. You wrote a good test.
Getting a bug report is stupid. You made a mistake, didn't catch it while testing and actually published it for others to see how stupid you are.
Do you know of a single programmer who has written a program of any but the absolute lowest complexity that is entirely bug free upon release?
Yes, I'll claim that such programs do exist. But it's rather hard for a human to notice those; beware of survivorship bias.
Having said that, I still support the sentiment that most code is buggy. It's futile to expect pervasive perfection.
Having said that, I still support the sentiment that most code is buggy. It's futile to expect pervasive perfection.
I didn't mean imply that releasing buggy code was stupid. This happens, of course it does. And it not necessarily stupid
I was trying to give a reason why people, myself included, don't learn the humility you refer to.
I was trying to give a reason why people, myself included, don't learn the humility you refer to.
I see, thanks for the clarification and my apologies for assuming the worst - maybe I've come to expect the kind of hubris I thought you were displaying because, all too often, programmers actually do display it. Just the other day I had one comparing himself to a doctor in an emergency ward, heroically saving bleeding victims, because he deigns to contribute to open source. This justifies treating the writers of bug reports with disdain, of course.
Nice to know it's not endemic!
Nice to know it's not endemic!
> These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.
I got over that a few decades ago.
> bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.
Absolutely. And fixed bug reports go into the test suite so they never darken anyone's door again.
I got over that a few decades ago.
> bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.
Absolutely. And fixed bug reports go into the test suite so they never darken anyone's door again.
> For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.
Maintainers that have that attitude just shouldn't have public bug trackers that anyone can submit to. If they choose to do so anyway, and react poorly to legitimate bugs that are respectfully presented, that's on the maintainer, not the reporter.
Maintainers that have that attitude just shouldn't have public bug trackers that anyone can submit to. If they choose to do so anyway, and react poorly to legitimate bugs that are respectfully presented, that's on the maintainer, not the reporter.
It's "natural" to feel this way - that the product is "yours" somehow.
But it's smarter to realize you don't own the software; you own your skill at making software.
Viewed this way, every bug report is an opportunity to improve your skill.
But it's smarter to realize you don't own the software; you own your skill at making software.
Viewed this way, every bug report is an opportunity to improve your skill.
I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected).
Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it.
I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs.
Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it.
I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs.
Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
> Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions.
This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate:
a) In terms of organization, I need the issue list to be about things that are actionable in the repo.
b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.
I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions.
This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate:
a) In terms of organization, I need the issue list to be about things that are actionable in the repo.
b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.
Personally, I don't like Gitter or Slack as I find them much harder to search or find already answered questions. Stack Overflow works very well though, a question-answer format is perfect for support requests. Its also much easier to search or link to. I think that Github issues feel closer to that for many people.
Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.
Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.
I wonder if it would be beneficial if github added a support forum to each repo, though having to deal with spam may turn into a major overhead. It would give the opportunity to contribute to a project to those with less technical skills and all the information would be in one place. Gitlab and other products may already have this, I don't tend to use them.
GitHub has "Discussions" on the way[1] which seem like they will greatly help the situation. You can see one in action here[2], which is where I first saw it. Doesn't seem to be generally available yet though, but when it is, I think it will improve issues greatly.
[1] https://github.blog/2020-05-06-new-from-satellite-2020-githu...
[2] https://github.com/clap-rs/clap/discussions
[1] https://github.blog/2020-05-06-new-from-satellite-2020-githu...
[2] https://github.com/clap-rs/clap/discussions
Fantastic, thank you. Should have known better than to think it wasn't on the way eventually.
The worst is when project B is a closed source project. I have such an open-source project A that interacts with such a project B. That is the worst. Then I get a bug report, project B got a new version and your project A does not work anymore. Fix it! Then I ask what was changed in the new version of project B. Then they say, they do not know. Then I ask the company of project B. They do not respond. Then I get another email from a user, you need to fix it for the new project B version. Then I send 5 emails to the company of project B. Then they respond, "we do not support project A". And I do not have access to project B myself
Not me. I appreciate bug reports and the time the submitter took to post them. Even if they aren't clear enough for me to find the problem, someone else may run over the bug, too, and having multiple inadequate submissions often provides enough clues that we can fix the problem.
No need to stroke our egos, just the facts is just fine.
No need to stroke our egos, just the facts is just fine.
[deleted]
If that's actually what you wrote, I would be annoyed as a maintainer. There's an implied assumption here that "command X" was never tested and must therefore crash for everyone. In 99% of cases, "command X" runs without issue and has been tested on multiple configurations. If it turns out that "command X" crashes for you because your company's IT department misconfigured the certificate authorities on a particular Windows build image, you end up wasting massive amounts of everyone's time. After maintainers get burned by these kind of bug reports tens of times, they understandably get hostile to such low effort bug reporting.
If that's how you react, then you're a part of the problem. If someone opens a bug report that factually represents behavior they've seen, and provides supporting evidence and information, and you react that way, you should probably re-examine your world view and think hard about why you believe that everyone is out to unfairly criticize your work.
> If it turns out that "command X" crashes for you...
As a project maintainer, I hope you recognize that people will run your software on all sorts of hardware and software configurations that don't match how you've tested it. It's impossible for you to test all possible scenarios. Requiring that every potential bug reporter explicitly acknowledge that their issue might be unique to their particular setup in order to assuage your apparently-fragile ego is unreasonable and counter-productive.
> If it turns out that "command X" crashes for you...
As a project maintainer, I hope you recognize that people will run your software on all sorts of hardware and software configurations that don't match how you've tested it. It's impossible for you to test all possible scenarios. Requiring that every potential bug reporter explicitly acknowledge that their issue might be unique to their particular setup in order to assuage your apparently-fragile ego is unreasonable and counter-productive.
What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.
So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?
Sure, as long as you're polite about it (and it would be incumbent on the reporter to be polite as well). It's not your responsibility to help users debug. If you do that often, for issues that are actually more widely reproducible, your software might end up getting a reputation for instability. Whether you care about that or not is up to you.
That is up to you. Different people/projects have different standards for how much effort they put into a bug.
If you think the issue is unlikely to be an actual bug, that would seem like the correct course to take. If you suspect it might depend on other details and you're keen to investigate more, you could ask for more details.
One related thing that many projects do is to have a bug template that asks for details such as software versions, operating system, CPU, etc. This can help a lot in reproducing bugs.
If you think the issue is unlikely to be an actual bug, that would seem like the correct course to take. If you suspect it might depend on other details and you're keen to investigate more, you could ask for more details.
One related thing that many projects do is to have a bug template that asks for details such as software versions, operating system, CPU, etc. This can help a lot in reproducing bugs.
> So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?
Depends how you want your project to be perceived.
If you don't give a crap, and just want to close issues then sure. ;)
If you're interested in finding out why the bug is occurring in such a strange way, and potentially solving the problem... then working with the user to figure out the cause (whether it's their fault or not) is going to be more useful. :)
If you're the only maintainer of your project though, and it happens a lot then personally I'm not sure what the right approach is.
The projects I'm involved with do have it happen, but it's not that often. So we're not too burned out by those things.
Depends how you want your project to be perceived.
If you don't give a crap, and just want to close issues then sure. ;)
If you're interested in finding out why the bug is occurring in such a strange way, and potentially solving the problem... then working with the user to figure out the cause (whether it's their fault or not) is going to be more useful. :)
If you're the only maintainer of your project though, and it happens a lot then personally I'm not sure what the right approach is.
The projects I'm involved with do have it happen, but it's not that often. So we're not too burned out by those things.
As an open source maintainer, and from what I've seen in general, there's absolutely no problem with reporting a bug! Do you mind me asking why you feel like adding that disclaimer? Is it because you don't want to seem demanding? What is the goal of "just report that the bug exists"?
The main/only major problem I've seen with bug reports is when it's actually user code, so if you can show why you are certain that it's the library's code that is buggy that's best. If you can prove it with a code snippet, perfect. If you can point to a specific place of code and explain why it doesn't work, perfect. Or just explain exactly what happened. TBH, as long as you are just not be like "my code doesn't work fix it" you should be mostly fine.
> Note: exception if the package is marked as e.g. "unmaintained" or such
> Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR.
The main/only major problem I've seen with bug reports is when it's actually user code, so if you can show why you are certain that it's the library's code that is buggy that's best. If you can prove it with a code snippet, perfect. If you can point to a specific place of code and explain why it doesn't work, perfect. Or just explain exactly what happened. TBH, as long as you are just not be like "my code doesn't work fix it" you should be mostly fine.
> Note: exception if the package is marked as e.g. "unmaintained" or such
> Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR.
> Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR.
It's important to understand that this is a misrepresentation of Linus Torvalds' attitude, even "before adjustment". I have seen plenty examples of negative reactions by him, but they were never in reaction to helpful PRs.
They were always in reaction to bad code, unhelpful behavior, etc.
In some cases, they were in reaction to people who were genuinely trying but failing to be helpful. In that case, the kind of blow-up that he became famous for is usually not helpful[0]. That doesn't make him an awful maintainer, though, it just makes him a human being with large but finite amounts of patience.
[0] Though who knows -- perhaps there are cases where the blow-up was what finally got the point across to the person who thought they were being helpful but weren't really. In that case, the blow-up was perhaps a crude tool, but got the job done. Difficulties arise largely due to cultural differences, keeping in mind that "old-school kernel development" is a culture in itself that deserves to be treated with some respect.
It's important to understand that this is a misrepresentation of Linus Torvalds' attitude, even "before adjustment". I have seen plenty examples of negative reactions by him, but they were never in reaction to helpful PRs.
They were always in reaction to bad code, unhelpful behavior, etc.
In some cases, they were in reaction to people who were genuinely trying but failing to be helpful. In that case, the kind of blow-up that he became famous for is usually not helpful[0]. That doesn't make him an awful maintainer, though, it just makes him a human being with large but finite amounts of patience.
[0] Though who knows -- perhaps there are cases where the blow-up was what finally got the point across to the person who thought they were being helpful but weren't really. In that case, the blow-up was perhaps a crude tool, but got the job done. Difficulties arise largely due to cultural differences, keeping in mind that "old-school kernel development" is a culture in itself that deserves to be treated with some respect.
The thing about Torvalds for me is how long and explanatory his negative reactions were. He wouldn't just blow-up, he would explain in an abrasive manner exactly why he thought discussing this thing was a waste of his time. It was obviously a tactic (if subconscious) to get people to hesitate before proposing something he would think was obviously silly. I think it probably worked; the criticism of his responses were that they were unnecessarily personal and hurtful, not that they were wrong.
I can also see why he backed away from it. If you're going to hurt people's feelings, best to do it through intermediaries so you don't get stained.
I can also see why he backed away from it. If you're going to hurt people's feelings, best to do it through intermediaries so you don't get stained.
The goal of filing a bug is to help the project.
I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages disappear", and the maintainer has responded with "Why do you need both A and B? Could you use A and C instead?".
That's a waste of time for both of us. If I want to ask someone about the merits of B vs C I'll find somewhere better than a bug tracker.
I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages disappear", and the maintainer has responded with "Why do you need both A and B? Could you use A and C instead?".
That's a waste of time for both of us. If I want to ask someone about the merits of B vs C I'll find somewhere better than a bug tracker.
Sometimes developers simply want to learn more about how the users use their creation. It might look like a waste of time to you, but it only is if you don't cooperate. Obviously there is something unexpected about using both A and B, so maybe just fixing the bug the way you envision is not the best approach. Maybe developer knows something you don't, or vice versa.
A lot of the time people just don't know about some feature or work-around to the problem. That's likely what's happening there.
Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly.
Not filing bugs is easier than filing bugs. If someone stops to file a bug (as the original commenter wrote, "to help the project") and someone responds to the bug reporter as if they're trying to get help, then it's just going to annoy the bug reporter and make it clear that they wasted their time. That it's possible for the ambiguity to even exist is a consequence of mixing bug reports with other types of feedback. Bug trackers should be for tracking bugs.
Not filing bugs is easier than filing bugs. If someone stops to file a bug (as the original commenter wrote, "to help the project") and someone responds to the bug reporter as if they're trying to get help, then it's just going to annoy the bug reporter and make it clear that they wasted their time. That it's possible for the ambiguity to even exist is a consequence of mixing bug reports with other types of feedback. Bug trackers should be for tracking bugs.
Sometimes deciding what the bug is depends on knowing what people are doing.
For example, lets say the report is that a program crashes when a particular set of options is used together. The developers thought that there were no situations where it made sense for someone to use that particular set of options.
They need to decide if the bug is that the program accepts that combination of options rather than giving an error about an illegal option combination, or the bug is that the developers were wrong and that combination should be made to work.
For example, lets say the report is that a program crashes when a particular set of options is used together. The developers thought that there were no situations where it made sense for someone to use that particular set of options.
They need to decide if the bug is that the program accepts that combination of options rather than giving an error about an illegal option combination, or the bug is that the developers were wrong and that combination should be made to work.
[deleted]
I do not agree at all.
Bugs often require work around or alternatives while the bug is still active.
You always try to stop the bleeding first before you try to do anything else.
Bugs often require work around or alternatives while the bug is still active.
You always try to stop the bleeding first before you try to do anything else.
You're approaching this from a position that relies on a bunch of unsound assumptions. You're assuming that the person is bleeding. You're assuming they're trying to stop it.
If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use, and the project maintainer responds as if mjw1007 is trying to get something from the maintainer, then in addition to it becoming clear that having taken the time to file the bug was a waste, the maintainer's response is going to be infuriating. I can corroborate with firsthand experience, and you should be able to agree just by considering the circumstances—which differ from your assumptions, and that's the problem.
There's a fundamental disconnect here between how you understand the bugtracker to be used versus how others are actually using it and what any given person expects to get out of it. To repeat: that it's possible for the maintainer (or one of the project's fans) to give a response that gets mjw1007's intention wrong is only possible because people are freely mixing bug reports with other types of feedback. (The project doesn't actually have a bugtracker at that point!)
Side note: it's not useful to move from concrete to abstract by turning to a metaphor ("bleeding"); it makes it more difficult.
See also: https://news.ycombinator.com/item?id=24311700
If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use, and the project maintainer responds as if mjw1007 is trying to get something from the maintainer, then in addition to it becoming clear that having taken the time to file the bug was a waste, the maintainer's response is going to be infuriating. I can corroborate with firsthand experience, and you should be able to agree just by considering the circumstances—which differ from your assumptions, and that's the problem.
There's a fundamental disconnect here between how you understand the bugtracker to be used versus how others are actually using it and what any given person expects to get out of it. To repeat: that it's possible for the maintainer (or one of the project's fans) to give a response that gets mjw1007's intention wrong is only possible because people are freely mixing bug reports with other types of feedback. (The project doesn't actually have a bugtracker at that point!)
Side note: it's not useful to move from concrete to abstract by turning to a metaphor ("bleeding"); it makes it more difficult.
See also: https://news.ycombinator.com/item?id=24311700
> If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use
Given the burden on upstream maintainers, probably mjw1007 should have included a crucial bit of information in the bug report: That they are not using the software any more, this is just to report a known bug they encountered before.
I'd say at least half of my bug reports are for things where I've already found a workaround for my situation, or I'm not using the software any more.
Those bug reports are a burden to create, because I don't get anything directly useful from doing so, and I usually take care to show how to reproduce the bug, ideally with a minimal reproducer, which sometimes takes hours.
If the problem upstream gets solved, it's nice to know I contributed a little civic duty, but I won't likely need the fix.
But I know what it's like to be on the receiving end of reports. So as a reporter, it's on me to not waste the upstream maintainer's time, by making it clear this is just an informational bug report. After all it's more burdensome for them than it is for me.
If they report back, as many do, asking if can try X, Y and Z, I may have to apologise and politely say I'm not using it any more. Ideally I already mentioned that, but upstream might not have noticed the first time.
If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted. That's on me.
When I contribute a bug report freely as a sort of civic contribution, it's not reasonable to expect upstream to do anything in particular with it if I'm not willing to help as well. It has to be given freely with no expectation on my part, because they haven't promised anything.
If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them, which is to read my mind and magically guess what I do and don't want, or alternatively to avoid assuming, spend an extra round trip asking what I was too lazy to say up front.
Given the burden on upstream maintainers, probably mjw1007 should have included a crucial bit of information in the bug report: That they are not using the software any more, this is just to report a known bug they encountered before.
I'd say at least half of my bug reports are for things where I've already found a workaround for my situation, or I'm not using the software any more.
Those bug reports are a burden to create, because I don't get anything directly useful from doing so, and I usually take care to show how to reproduce the bug, ideally with a minimal reproducer, which sometimes takes hours.
If the problem upstream gets solved, it's nice to know I contributed a little civic duty, but I won't likely need the fix.
But I know what it's like to be on the receiving end of reports. So as a reporter, it's on me to not waste the upstream maintainer's time, by making it clear this is just an informational bug report. After all it's more burdensome for them than it is for me.
If they report back, as many do, asking if can try X, Y and Z, I may have to apologise and politely say I'm not using it any more. Ideally I already mentioned that, but upstream might not have noticed the first time.
If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted. That's on me.
When I contribute a bug report freely as a sort of civic contribution, it's not reasonable to expect upstream to do anything in particular with it if I'm not willing to help as well. It has to be given freely with no expectation on my part, because they haven't promised anything.
If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them, which is to read my mind and magically guess what I do and don't want, or alternatively to avoid assuming, spend an extra round trip asking what I was too lazy to say up front.
I don't recognize what it means for something to be "just an informational bug report". You either have a bugtracker or you don't. It's supposed to contain a list of known defects or it isn't.
> After all it's more burdensome for them than it is for me.
This is nuts. This can only be true if there are much, much bigger problems afoot. Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons is precisely why maintainers are burdened, burning out, and complaining about it—they've fostered a culture that encourages outsiders (and the developer's own process/practices) to "burden" them.
> If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted.
You're strawmanning. Your job here is not to postulate the most convenient[1] circumstances that could be true and which would make it easy for the fury to seem "silly". It's to deal with the concrete, non-hypothetical circumstances where people have responded in genuinely obnoxious ways to bug reports. Imagining counterfactuals is easy.
> If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them
Sure, but the expectation that people not be presumptuous and/or rude where it's unprovoked is an expectation that runs through everything. It should be regarded as axiomatic.
1. https://wiki.lesswrong.com/wiki/Least_convenient_possible_wo...
> After all it's more burdensome for them than it is for me.
This is nuts. This can only be true if there are much, much bigger problems afoot. Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons is precisely why maintainers are burdened, burning out, and complaining about it—they've fostered a culture that encourages outsiders (and the developer's own process/practices) to "burden" them.
> If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted.
You're strawmanning. Your job here is not to postulate the most convenient[1] circumstances that could be true and which would make it easy for the fury to seem "silly". It's to deal with the concrete, non-hypothetical circumstances where people have responded in genuinely obnoxious ways to bug reports. Imagining counterfactuals is easy.
> If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them
Sure, but the expectation that people not be presumptuous and/or rude where it's unprovoked is an expectation that runs through everything. It should be regarded as axiomatic.
1. https://wiki.lesswrong.com/wiki/Least_convenient_possible_wo...
> It's supposed to contain a list of known defects or it isn't.
If it were just a list of defects, this discussion wouldn't have started.
By "informational" I mean reporting that a bug exists. "When I do X, Y happens and Z should happen instead. You might like to know. Best wishes.".
By the other kind, I mean asking for a solution. "When I do X, Y happens, please make Z happen instead. Await your prompt reply, Kthx".
Often there's no way to tell which one is intended. A tick box to differentiate between "I'm just reporting this, I don't need the change" versus "I would find a solution useful" or even "can someone specifically help me find a solution" seems like it would be helpful.
These are different kinds of bug report, and they all land in a typical GitHub-style or Bugzilla-style public issue tracker.
The second kind are not defect reports, and we haven't even mentioned feature requests, which aren't defects at all. They land in the issue tracker as well.
> You're strawmanning
Hmm, maybe I should rephrase to clarify where the emphasis was intended: "If I submit a bug report and the maintainer replies thinking I wanted something from them, it would be silly for me to become infuriated because my effort seems wasted". That addresses the scenario in the comment I replied to, so not a straw man.
> where people have responded in genuinely obnoxious
Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something.
Are you sure you're not strawmanning and counterfactualising?
> This is nuts. This can only be true if there are much, much bigger problems afoot.
Well, it's true. Yes there are problems. That's why this discussion is taking place. Do you have solutions?
> Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons [...]
And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I was around when Netscape opened up. No solutions leap out to me arising from that, then or now. Netscape's own lessons appear to be about corporate management and control of projects.
The vast majority of open source projects, especially those where people report feeling burdened, are run by unpaid people in their spare time (or when they should be sleeping), as one-person projects. Netscape's corporate strategy doesn't seem relevant here. (And ESR's "Cathedral and the Bazaar", which was related to Netscape's changes, doesn't provide a solution either.)
If it were just a list of defects, this discussion wouldn't have started.
By "informational" I mean reporting that a bug exists. "When I do X, Y happens and Z should happen instead. You might like to know. Best wishes.".
By the other kind, I mean asking for a solution. "When I do X, Y happens, please make Z happen instead. Await your prompt reply, Kthx".
Often there's no way to tell which one is intended. A tick box to differentiate between "I'm just reporting this, I don't need the change" versus "I would find a solution useful" or even "can someone specifically help me find a solution" seems like it would be helpful.
These are different kinds of bug report, and they all land in a typical GitHub-style or Bugzilla-style public issue tracker.
The second kind are not defect reports, and we haven't even mentioned feature requests, which aren't defects at all. They land in the issue tracker as well.
> You're strawmanning
Hmm, maybe I should rephrase to clarify where the emphasis was intended: "If I submit a bug report and the maintainer replies thinking I wanted something from them, it would be silly for me to become infuriated because my effort seems wasted". That addresses the scenario in the comment I replied to, so not a straw man.
> where people have responded in genuinely obnoxious
Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something.
Are you sure you're not strawmanning and counterfactualising?
> This is nuts. This can only be true if there are much, much bigger problems afoot.
Well, it's true. Yes there are problems. That's why this discussion is taking place. Do you have solutions?
> Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons [...]
And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I was around when Netscape opened up. No solutions leap out to me arising from that, then or now. Netscape's own lessons appear to be about corporate management and control of projects.
The vast majority of open source projects, especially those where people report feeling burdened, are run by unpaid people in their spare time (or when they should be sleeping), as one-person projects. Netscape's corporate strategy doesn't seem relevant here. (And ESR's "Cathedral and the Bazaar", which was related to Netscape's changes, doesn't provide a solution either.)
> If it were just a list of defects, this discussion wouldn't have started.
This makes for the second time this week I've run into someone stating the obvious and thinking that it makes for a point in their favor and not one against their end of the argument.
> Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have been replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something. Are you sure you're not strawmanning and counterfactualising?
Yes, I'm sure, and I don't really have time or the wherewithal to explain in depth to someone who's dead set against not understanding. "The maintainer in that scenario may have been replied politely" is simply not a move that's available to you. There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals. (Even in the case of hypotheticals, it's a problem—counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".) There is only what did or did not occur (or what is or is not posed). To repeat: it is not your job to imagine the most convenient circumstances that would weaken the side that you're arguing against.
> And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I've offered them. Go back and read my comments in this thread and you'll see them. Read your own comments—it'll suffice to read just what you've written in this one—and the solution follows naturally from the problem you describe. If it's so hard to discriminate between "informational bug reports" and support requests, then stop mixing them. If you're going to run a bugtracker, then run a bugtracker[1].
> Netscape's corporate strategy doesn't seem relevant here.
You're right. So I don't know why you focused on it at length, as if you can talk your way into it being the thing that I was referring to. Once again, a move that's not available to you.
1. https://hyp.is/de25lAXAEeuhNEN0wan1Ww/news.ycombinator.com/i...
This makes for the second time this week I've run into someone stating the obvious and thinking that it makes for a point in their favor and not one against their end of the argument.
> Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have been replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something. Are you sure you're not strawmanning and counterfactualising?
Yes, I'm sure, and I don't really have time or the wherewithal to explain in depth to someone who's dead set against not understanding. "The maintainer in that scenario may have been replied politely" is simply not a move that's available to you. There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals. (Even in the case of hypotheticals, it's a problem—counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".) There is only what did or did not occur (or what is or is not posed). To repeat: it is not your job to imagine the most convenient circumstances that would weaken the side that you're arguing against.
> And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I've offered them. Go back and read my comments in this thread and you'll see them. Read your own comments—it'll suffice to read just what you've written in this one—and the solution follows naturally from the problem you describe. If it's so hard to discriminate between "informational bug reports" and support requests, then stop mixing them. If you're going to run a bugtracker, then run a bugtracker[1].
> Netscape's corporate strategy doesn't seem relevant here.
You're right. So I don't know why you focused on it at length, as if you can talk your way into it being the thing that I was referring to. Once again, a move that's not available to you.
1. https://hyp.is/de25lAXAEeuhNEN0wan1Ww/news.ycombinator.com/i...
I agree with some of your observations and ideas, btw. But I have to wipe the antagonism off my screen with a strong disinfectant to appreciate them.
This comes to mind: https://news.ycombinator.com/item?id=24674099
> There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals
We're not.
I replied to the comment I replied to, nothing else, and it describes a hypothetical, so the reply does too.
> counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".
:eye-roll: My job is with theorem-proving software. You can show off knowledge of quantifiers but it's unlikely to impress.
The specific comment I replied to (not the main discussion topic as you assumed) has the informal discourse equivalent of an implicit universal quantifier.
> Netscape's corporate stratgy [...] I don't know why you focused on it [...] as if you can talk your way into it being the thing that I was referring to.
You hand-waved vaguely about "Netscape" and "lessons", giving no direction as to what you meant while insinuating we should all know them. The lack of clue sounded like a communication choice, thus intentional shorthand for "you know what I mean".
That leads a good-faith correspondent naturally to a speculative reply, to which you could politely respond with "no that's not what I meant, sorry for the ambiguity". I think it's unlikely you'll see that as rational, but it's how informal language works, otherwise it's questions all the way down.
This comes to mind: https://news.ycombinator.com/item?id=24674099
> There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals
We're not.
I replied to the comment I replied to, nothing else, and it describes a hypothetical, so the reply does too.
> counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".
:eye-roll: My job is with theorem-proving software. You can show off knowledge of quantifiers but it's unlikely to impress.
The specific comment I replied to (not the main discussion topic as you assumed) has the informal discourse equivalent of an implicit universal quantifier.
> Netscape's corporate stratgy [...] I don't know why you focused on it [...] as if you can talk your way into it being the thing that I was referring to.
You hand-waved vaguely about "Netscape" and "lessons", giving no direction as to what you meant while insinuating we should all know them. The lack of clue sounded like a communication choice, thus intentional shorthand for "you know what I mean".
That leads a good-faith correspondent naturally to a speculative reply, to which you could politely respond with "no that's not what I meant, sorry for the ambiguity". I think it's unlikely you'll see that as rational, but it's how informal language works, otherwise it's questions all the way down.
Adding workaround if you know one is just good practice IMO. Out helps prioritization too.
Even if the original reporter doesn't care (side note, they usually do in my experience), other people also stumble onto the report.
There's a lot of assumptions being made here. A maintainer offering help is not a waste of time. The offer is not just for the original reporter.
There's a lot of assumptions being made here. A maintainer offering help is not a waste of time. The offer is not just for the original reporter.
"Usually" doesn't matter. If 100 people drop by to demand the project maintainer make a change or tell them how they can do something to best benefit their company and look good by doing it, and 1 person stops by with a high quality bug report, it follows that annoying the latter is how you guarantee that your future lies in dealing with 100 assholes, because person #101 is going to disappear.
> maintainer offering help
That's a generous way to put it.
> maintainer offering help
That's a generous way to put it.
Clearly you have had a bad experience. Sorry to hear that.
I will nearly always, unless explicitly asked not to, offer help to work around a bug if it is at all possible. I can't control if someone is upset by this nor can I tell if they will be unless they say as much... but not doing so would be significantly less helpful to a majority of people. So "usually" does matter.
I will nearly always, unless explicitly asked not to, offer help to work around a bug if it is at all possible. I can't control if someone is upset by this nor can I tell if they will be unless they say as much... but not doing so would be significantly less helpful to a majority of people. So "usually" does matter.
I think you just validated mjw1007's impulse to add the disclaimer.
And it's more than a bad experience. It's an entire culture, which leads to the point that mjw1007's comment here is the top voted one for this story, and I've written comments to explain why I stopped filing bugs for projects that host their trackers on GitHub.
And it's more than a bad experience. It's an entire culture, which leads to the point that mjw1007's comment here is the top voted one for this story, and I've written comments to explain why I stopped filing bugs for projects that host their trackers on GitHub.
There's nothing stopping anyone from acknowledging the bug _and_ offering a workaround. That's the best of both worlds. The complaint here seems to be about responses that dismiss the validity of the bug report based on the existence of a workaround.
It's totally valid for the maintainer of an open source project's response to a bug report to be "I don't care enough about this use case to fix this bug", but the courteous thing to do is to be upfront about that.
It's totally valid for the maintainer of an open source project's response to a bug report to be "I don't care enough about this use case to fix this bug", but the courteous thing to do is to be upfront about that.
>Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly.
Well, most users don't use the bugtracker correctly, so there's that...
Well, most users don't use the bugtracker correctly, so there's that...
Yep, or don't know how to use it, or messed up in combining api keys.
Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
The thing is, a developer also has a concept of his project. He doesn't necessarily want it to be all things to all people, and support all of A, B, and C together. He might even consider A+B distateful and avoid coding it for that alone...
Triage is not a waste of time. Developers usually have far less time than bugs or missing features.
If someone asks a question, it's because they would like an answer.
If someone asks a question, it's because they would like an answer.
Right, always answer the question, even if you don't think the answer will be helpful: you might be wrong, and if you're not then providing the answer is likely to be the quickest way for the asker to find out that they didn't need to know.
But also: don't ask "why do you X" if someone hasn't said they "X". On this occasion I didn't particularly want to enable both A and B, I just noticed the problem when I briefly did.
But also: don't ask "why do you X" if someone hasn't said they "X". On this occasion I didn't particularly want to enable both A and B, I just noticed the problem when I briefly did.
That's an interesting distinction. It's like simply documenting that a bug exists versus arguing that a bug exists and should be resolved.
The latter feels similar to making a feature request, which can also be done in Issue trackers like GitHub Issues. Maybe the fact that both the former and the latter are allowed/encouraged to exist within the same tracking systems somewhat contributes to the confusion/conflation of the former with the latter.
The latter feels similar to making a feature request, which can also be done in Issue trackers like GitHub Issues. Maybe the fact that both the former and the latter are allowed/encouraged to exist within the same tracking systems somewhat contributes to the confusion/conflation of the former with the latter.
As an OSS maintainer, for me it is not snotty, but also not necessary.
My biggest issue are people that come and leave comments like "why isn't this fixed yet?", or thumbs down my response that I'd appreciate some help fixing it, or adding the feature.
My biggest issue are people that come and leave comments like "why isn't this fixed yet?", or thumbs down my response that I'd appreciate some help fixing it, or adding the feature.
My preference is usually: ‘hi, thanks for creating this tool/library/whatever. It really makes a meaningful difference in my life. I’m encountering a problem with the blah blah module, which you can repro thusly.’
Don’t grovel, but also acknowledge that the only compensation the reader of the report is likely to get is in the form of these extremely rare moments of gratitude.
I should also mention that I maintain an open source app that gets used by the public, and is regularly confused by them with being a product of a group of paid individuals. In fact, they usually think the software is a result of their tax dollars at work. I’ve received a lot of really negative, shitty feedback from all sorts of people, including folks in the software industry (shout out to everyone who ever emailed me from their Amazon.com work addresses). Don’t be like these people. The ones who start by simply saying “thanks” not only get more from me, but also help keep my motivation up.
Don’t grovel, but also acknowledge that the only compensation the reader of the report is likely to get is in the form of these extremely rare moments of gratitude.
I should also mention that I maintain an open source app that gets used by the public, and is regularly confused by them with being a product of a group of paid individuals. In fact, they usually think the software is a result of their tax dollars at work. I’ve received a lot of really negative, shitty feedback from all sorts of people, including folks in the software industry (shout out to everyone who ever emailed me from their Amazon.com work addresses). Don’t be like these people. The ones who start by simply saying “thanks” not only get more from me, but also help keep my motivation up.
> Don’t grovel, but also acknowledge that the only compensation the reader of the report is likely to get is in the form of these extremely rare moments of gratitude.
As I write elsewhere, this is a fundamentally flawed mindset. A high quality bug report is the reader's compensation. It's a goddamned gift. The presumption that the reporter is a leech and the recipient is the one being leeched is exactly what's wrong in the culture.
Consider this: You post your project. I'm not in the target demographic. But because I come from the culture epitomized in Shirky's Here Comes Everybody, and not the fucked up culture of the GitHub generation, where 999 times out of 10 you only reach out to someone because you're trying to get something from them, I decide take the time and give it a look anyway. Going into this, I already have nothing to gain. So I do look at it, and I spot a bug. I file a bug report with steps to reproduce. This is a contribution to the project, its maintainer, and whoever uses it. Do something with it, or don't. But no matter how you respond, I will get nothing out of it. To flip things around in a Costanza-like attempt to grab the upper hand is... anti-social.
This isn't to say that leeches don't exist. But muggers also exist. And yet, the fact that muggers exist is not a good reason to go around socking people in the mouth when they approach you and start speaking.
As I write elsewhere, this is a fundamentally flawed mindset. A high quality bug report is the reader's compensation. It's a goddamned gift. The presumption that the reporter is a leech and the recipient is the one being leeched is exactly what's wrong in the culture.
Consider this: You post your project. I'm not in the target demographic. But because I come from the culture epitomized in Shirky's Here Comes Everybody, and not the fucked up culture of the GitHub generation, where 999 times out of 10 you only reach out to someone because you're trying to get something from them, I decide take the time and give it a look anyway. Going into this, I already have nothing to gain. So I do look at it, and I spot a bug. I file a bug report with steps to reproduce. This is a contribution to the project, its maintainer, and whoever uses it. Do something with it, or don't. But no matter how you respond, I will get nothing out of it. To flip things around in a Costanza-like attempt to grab the upper hand is... anti-social.
This isn't to say that leeches don't exist. But muggers also exist. And yet, the fact that muggers exist is not a good reason to go around socking people in the mouth when they approach you and start speaking.
OK, I'll say it differently, don't be an asshole.
Don't be an asshole submitting a high quality bug report.
Don't be an asshole submitting a low quality bug report.
Just don't be an asshole.
Don't be an asshole submitting a high quality bug report.
Don't be an asshole submitting a low quality bug report.
Just don't be an asshole.
> But no matter how you respond, I will get nothing out of it.
Well, you get a problem solved. One that was probably bothering you or stopping you from doing some work.
Otherwise I agree, though. Gratitude is nice, but a well-formulated and described bug reports are the best. (PRs are a mixed bag, because it's rare to have a full match with the current design).
Well, you get a problem solved. One that was probably bothering you or stopping you from doing some work.
Otherwise I agree, though. Gratitude is nice, but a well-formulated and described bug reports are the best. (PRs are a mixed bag, because it's rare to have a full match with the current design).
> Well, you get a problem solved. One that was probably bothering you or stopping you from doing some work.
You ignored the entire premise. Weird, because I repeated it multiple times. (And I don't understand how the comment can even make any sense unless you get the premise.)
To be clear: the scenario outlined above is one where I'm filing a bug report against a software project that I do not use and do not ever intend to use. There's no way a bug in the software can be showstopper for me if the software in question has no effect on the success or failure of whatever show I'm running.
You ignored the entire premise. Weird, because I repeated it multiple times. (And I don't understand how the comment can even make any sense unless you get the premise.)
To be clear: the scenario outlined above is one where I'm filing a bug report against a software project that I do not use and do not ever intend to use. There's no way a bug in the software can be showstopper for me if the software in question has no effect on the success or failure of whatever show I'm running.
To be clear: the scenario outlined above is one where I'm filing a bug report against a software project that I do not use and do not ever intend to use.
I think your premise is specious. Who files detailed bug reports on a piece of software that they have never and will never use?
What is the scenario where someone would bother doing this?
What is the scenario where they even have the knowledge to file this detailed bug report since they lack any context on the software in question?
I think your premise is specious. Who files detailed bug reports on a piece of software that they have never and will never use?
What is the scenario where someone would bother doing this?
What is the scenario where they even have the knowledge to file this detailed bug report since they lack any context on the software in question?
I do this all the time. Sometimes I even send in patches too.
I already answered this, but maybe you missed it:
https://hyp.is/cS034gX1EeutOzMchaO06A/news.ycombinator.com/i...
That you're here having trouble grappling with the suggestion that such a scenario is even plausible is evidence of the cynical depths we've reached. Even in the case that you're unable to understand why, does the "why" really matter? It happens, and that's what matters.
https://hyp.is/cS034gX1EeutOzMchaO06A/news.ycombinator.com/i...
That you're here having trouble grappling with the suggestion that such a scenario is even plausible is evidence of the cynical depths we've reached. Even in the case that you're unable to understand why, does the "why" really matter? It happens, and that's what matters.
That seems unnecessarily rude. Also, you still haven’t offered up a plausible scenario of why you would magnanimously look at my OSS project that you have no intention of ever using, find a bug, and submit a bug report, exhortations of circa 2008 Clay Shirky notwithstanding.
> That seems unnecessarily rude.
Am I supposed to refrain from being seen as unkind to someone tacitly accusing me of lying? I gave an answer before you ever even asked the question. I don't know what you want, I don't know why you think you deserve my time and energy in light of the incoming rudeness directed my way, and I don't know how you can't see that expecting it is in stark contradiction to the position you're taking.
Am I supposed to refrain from being seen as unkind to someone tacitly accusing me of lying? I gave an answer before you ever even asked the question. I don't know what you want, I don't know why you think you deserve my time and energy in light of the incoming rudeness directed my way, and I don't know how you can't see that expecting it is in stark contradiction to the position you're taking.
I don’t think I’d want to receive one of your magnanimous bug reports. Hope you have a good night.
"So I'm afraid that I am going to have to break up with you". Really seized the upper hand there, Costanza.
https://hyp.is/9rn9dhDOEeum9XvjucTYqw/news.ycombinator.com/i...
https://www.youtube.com/watch?v=887bIe0hXyc
> Hope you have a good night.
I somehow doubt your sincerity. Go fuck yourself.
Sincerely, from me to you.
https://hyp.is/9rn9dhDOEeum9XvjucTYqw/news.ycombinator.com/i...
https://www.youtube.com/watch?v=887bIe0hXyc
> Hope you have a good night.
I somehow doubt your sincerity. Go fuck yourself.
Sincerely, from me to you.
> You ignored the entire premise.
Yeah, seems so. I've re-read the original message now.
Here are two thoughts for your consideration:
- This is a discussion about FLOSS projects' lives and their maintainers' experiences. Given that your approach is an outlier, your observations don't have a lot of relevance to an average FLOSS project. Nor, as a consequence, does the opinion of "who owes who".
- Consider, in abstract, two projects. One has only bug reports from actual, motivated users. Another has 10% of bug reports from its users and 90% of "drive-by" bug reports. Starting with a certain size, I think you can imagine how the second project might have the maintainer overwhelmed, unmotivated, and/or spending a lot of time on code that is almost never run in production.
Software is not math; there are always parts that are more used, and always some bugs that are ignored because they're non-trivial to fix, and the tradeoffs are not worth the developer's time. Unless you're DJB, I guess.
Yeah, seems so. I've re-read the original message now.
Here are two thoughts for your consideration:
- This is a discussion about FLOSS projects' lives and their maintainers' experiences. Given that your approach is an outlier, your observations don't have a lot of relevance to an average FLOSS project. Nor, as a consequence, does the opinion of "who owes who".
- Consider, in abstract, two projects. One has only bug reports from actual, motivated users. Another has 10% of bug reports from its users and 90% of "drive-by" bug reports. Starting with a certain size, I think you can imagine how the second project might have the maintainer overwhelmed, unmotivated, and/or spending a lot of time on code that is almost never run in production.
Software is not math; there are always parts that are more used, and always some bugs that are ignored because they're non-trivial to fix, and the tradeoffs are not worth the developer's time. Unless you're DJB, I guess.
This comment is rewriting the premise again.
> This is a discussion about FLOSS projects' lives and their maintainers' experiences.
It's not. It's rooted at mjw1007's comment "When I file a bug report[…]" and, before that, the linked article where antirez deals with the same matter that I'm discussing.
https://news.ycombinator.com/item?id=24670700
A later comment—the one that I responded to—tries to convince us to focus on the maintainer and sell the appreciation-as-compensation, maintainers-get-nothing, and, implicitly, the bug-reports-have-negative-value perspective that is pushed in the circles I referenced above. And that's the problem. As I wrote elsewhere, filing bug reports takes more effort than not filing them. By myopically portraying the maintainer as if they're a protagonist in some Gary Stu fanfic about the world, we end up with a take that fails to consider all the relevant details, and that's the attitude that antirez admonishes. Please revisit both the article and the comment linked above.
(I'm not really interested in responding further to this conversation.)
> This is a discussion about FLOSS projects' lives and their maintainers' experiences.
It's not. It's rooted at mjw1007's comment "When I file a bug report[…]" and, before that, the linked article where antirez deals with the same matter that I'm discussing.
https://news.ycombinator.com/item?id=24670700
A later comment—the one that I responded to—tries to convince us to focus on the maintainer and sell the appreciation-as-compensation, maintainers-get-nothing, and, implicitly, the bug-reports-have-negative-value perspective that is pushed in the circles I referenced above. And that's the problem. As I wrote elsewhere, filing bug reports takes more effort than not filing them. By myopically portraying the maintainer as if they're a protagonist in some Gary Stu fanfic about the world, we end up with a take that fails to consider all the relevant details, and that's the attitude that antirez admonishes. Please revisit both the article and the comment linked above.
(I'm not really interested in responding further to this conversation.)
I usually flip this around -- report the bug as straightforwardly as possible, and then sign off with a statement of gratitude (usually paired with "let me know if I can provide any more information on this issue"). To me it feels more sincere and less likely to be perceived as trying to preemptively apologize for the bug report.
>In fact, they usually think the software is a result of their tax dollars at work
That's amazing. Perhaps it's reality that's wrong.
That's amazing. Perhaps it's reality that's wrong.
Woulda, shoulda, coulda.
Deciding how to phrase contributions is a surprisingly tricky problem, and in fact I think that the way a contribution is written can (to some degree) demonstrate the author's level of understanding and appreciation of the project and community's time commitments.
Some projects have extremely high issue volume, use their own automation/triage, and prefer very terse communication -- and in those cases it may make sense to include only the minimal details required.
In other cases a hobby or community-building project (for example) might prefer more informal and friendly communication.
Either way, the author's phrasing isn't the only factor that matters in each situation. The relationship also depends on the project/community responding effectively.
We're all human, we all make mistakes, and English is not everyone's first language, so a well-run project should afford for those (while also being cautious not to get completely sidetracked dealing with noise).
Some projects have extremely high issue volume, use their own automation/triage, and prefer very terse communication -- and in those cases it may make sense to include only the minimal details required.
In other cases a hobby or community-building project (for example) might prefer more informal and friendly communication.
Either way, the author's phrasing isn't the only factor that matters in each situation. The relationship also depends on the project/community responding effectively.
We're all human, we all make mistakes, and English is not everyone's first language, so a well-run project should afford for those (while also being cautious not to get completely sidetracked dealing with noise).
As an OSS maintainer (of small projects), I don't really care how someone words a bug report, as long as they aren't rude or demanding. In fact, I'm actually happy if someone takes their time to report a bug.
Your imaginary disclaimer would feel a bit weird indeed. But as other people have mentioned, a little “thank you for the project“ never hurts :-)
If you would mean it, I think it's nice to instead sign off the bug report with something like this "X is great, and thanks a lot for developing it" - when you're reporting something to a project where you are not previously known.
When I receive bug reports, I usually review it and tag it but won't come back to it until I have time. I won't bother spending time on fixing it if it's not something I'm actively using. If someone submits a PR with a fix then that's great and I'll most likely merge it in if there's no objections and tests still pass. I don't perceive the submissions as if the person thinks they're entitled to getting it fixed since majority of the time they're nice about it or they never come back to check on the status. When I submit bug reports and PRs to other projects, I have no expectations that it'll be fixed or merged since I understand what it's like to be on both ends.
Probably best to just have more articles about the topic -- like the one currently under discussion -- and more discussions of the sort happening right here. Create a culture where some fairly big percentage of people have a healthy attitude towards their open source stuff, understand they don't have to do anything if they don't want to, people talking at them about it is a form of engagement with a lot of positives, etc.
And then make peace with "You can't please all of the people all of the time. Some people can't ever be pleased. etc."
And then make peace with "You can't please all of the people all of the time. Some people can't ever be pleased. etc."
Seems to me the best thing is to make it as easy as possible for the maintainer (clear, with environment and steps to reproduce). The majority of maintainers want to iron out any bugs they have and the more of a checklist item the report is the happier they are going to be. It’s the GitHub ticket comment spew of “I have this bug too! fix this shit now!” that really wears people down.
Gauging demand can sometimes be useful in planning a project can it not? I mean, if the comments are phrased nicer than your example.
On several bug trackers there are structured ways to make it known without commenting. On GitHub, at least there's thumbs-up reactions.
I think this depends on the quality of the bug report or the following dialog.
Answers like this should have this disclaimer: https://i.imgur.com/p76JlUk.png
Answers like this should have this disclaimer: https://i.imgur.com/p76JlUk.png
Bug reporting should be about facts, cold hard ones and not about feelings or comments. Stay on topic, explain what you did and if you also link to a video showing the bug occurring don't comment during video. Just show the steps to reproduce it. Or if the bug happens on a particular architecture then also show that one as well and that should be the end of it. The developer needs info how to replicate it not reading a novel or entering a debate. I hate stuff like cheesy comments or mean ones. KISS is paramount in this case.
I think this is a wonderful idea, but you’re right that maybe it could be rephrased. How about a concise, straight-to-the-point bug report followed by this at the end:
> Thanks so much for this great project! I hope you don’t think I’m complaining, just thought you might want to know about this bug. Cheers.
> Thanks so much for this great project! I hope you don’t think I’m complaining, just thought you might want to know about this bug. Cheers.
I feel like the author is not the best spokesperson considering the overwhelming success he's had with open source on a personal and financial levels. It's like those startup success blog posts.
It's also quite idealistic.
For other people open source might start as a desire for better software or just a desire to help but then it doesn't play out the same way. The project doesn't have as much success, the effort is high and the positive feedback low, the user demands or costs unreasonable. Then you draw a line and realise you just created yourself a sort of unpaid internship position where the globe is your boss.
Having experienced something like this my conclusion is that open source in any continuous form is to be seriously avoided.
It's also quite idealistic.
For other people open source might start as a desire for better software or just a desire to help but then it doesn't play out the same way. The project doesn't have as much success, the effort is high and the positive feedback low, the user demands or costs unreasonable. Then you draw a line and realise you just created yourself a sort of unpaid internship position where the globe is your boss.
Having experienced something like this my conclusion is that open source in any continuous form is to be seriously avoided.
Generally agree except in some special cases like Django or Linux. They're both open source and continuous and seem (at least from the outside) to be successful at it. They also have foundations around them, though.
I think the better model for solo passion projects is generally to write your program and declare it "as-is". If people want changes to it, that's what forking is for. If you agree with their changes, you might arrange a pull request but that should be seen more as an exception rather than the rule (for this kind of project). This way the original code evolves in separate branches. Maybe one eventually becomes the de facto source, but being the original creator of the project should confer no automatic responsibility.
One very successful example of this in the wild is the open-source roguelike Cataclysm: Dark Days Ahead. Whales wrote the original Cataclysm but ended development of it in 2012, at which point the community forked it and kept development going for the past 8 years so far.
I think the better model for solo passion projects is generally to write your program and declare it "as-is". If people want changes to it, that's what forking is for. If you agree with their changes, you might arrange a pull request but that should be seen more as an exception rather than the rule (for this kind of project). This way the original code evolves in separate branches. Maybe one eventually becomes the de facto source, but being the original creator of the project should confer no automatic responsibility.
One very successful example of this in the wild is the open-source roguelike Cataclysm: Dark Days Ahead. Whales wrote the original Cataclysm but ended development of it in 2012, at which point the community forked it and kept development going for the past 8 years so far.
If the project is unfulfilling, you drop it and move on to something you care about.
It seems a lot of this recent commotion around OSS is coming from people who feel they are entitled to get paid for doing unfulfilling work, but they want to keep prestige that comes from having their name attached to it. Open source as a job is a privilege, not a career move. Commercial software hasn't gone away.
It felt really nice to have a sphere of software development not tied directly to capitalism for once, but welp, too late now. I guess that's the idealistic part.
It seems a lot of this recent commotion around OSS is coming from people who feel they are entitled to get paid for doing unfulfilling work, but they want to keep prestige that comes from having their name attached to it. Open source as a job is a privilege, not a career move. Commercial software hasn't gone away.
It felt really nice to have a sphere of software development not tied directly to capitalism for once, but welp, too late now. I guess that's the idealistic part.
His point is that if you end up like that it's because you don't recognize freedom when you see it. Its like that movie when the monkey does not go out of thee cage even if opened. Because its your project and you can do whatever you want. Its all in your head.
The again there is no reason any project has to go on forever. Some open source devs assume, often correctly, that money would ease the pain. In other cases just stoping open source work seems the logical choice. After all, there is no need for the world to witness your work.
PS: you do have a point that it's all in your head: in many ways open source work is addictive! Time for an Anonymous Open Source Developers group.
PS: you do have a point that it's all in your head: in many ways open source work is addictive! Time for an Anonymous Open Source Developers group.
I think it has to do with the idea of work. Some people associate work with discomfort and feel guilty if they have fun so they transform their projects on uncomfortable work like things.
Entirely disagree. This is not how a project is transformed but what a project is...
But indeed, maybe our common conclusion is that open source is not for everybody and it should have a warning on the box like cigarettes.
But indeed, maybe our common conclusion is that open source is not for everybody and it should have a warning on the box like cigarettes.
> Because its your project and you can do whatever you want. Its all in your head
Well yes, you can. But I think most people feel obliged to respond to feedback, and in fact probably want to respond.
Perhaps it's different for mature projects, but my personal projects are a source of perpetual disappointment.
Too much to do, not enough time.
Well yes, you can. But I think most people feel obliged to respond to feedback, and in fact probably want to respond.
Perhaps it's different for mature projects, but my personal projects are a source of perpetual disappointment.
Too much to do, not enough time.
You do that to yourself and of course the system around us is not made to acomodate such freedoms.
The beauty of it is that once you craate something and you share it you have already contributed something. I think that what you feel has more to do with your educaction. Like I said it is all in your head and you do that to yourself.
Contributing "something" isn't that satisfying or fulfilling to me, even though it can undoubtedly be helpful. Perhaps it's just my personality.
In some ways it has to do with the fact that people are educated to have a need for validation from an authority and several other ways of thinking that are completely counterproductive.
Validation from authority is not counterproductive. People who need zero external validation are at risk of psychotic behavior because they have no grounding.
Love, care and a nurturing social structure wihle developing as a child is what keeps a child healthy. What I meant was that self worth is tied with validation from authority. A sense of inadequacy is always fomented and all the other nonsense of the social experiments we call schools.And at some point you need to wake up to the fact that in a way its just a big theater. That's why you have theories like Rousseau's social contract. You need to answer to the question why are we doing this again?
I’ve had similar experiences but haven’t drawn the same conclusion. I haven’t given up on being able to change the norm where a lot of open source users act like they have an enterprise support plan while actually contributing nothing.
Funny thing: I had my email on a commercial support page for, you know, companies that wanted to pay money for custom work. 100% of the emails were from companies asking various questions; everybody took that page as priority free support for companies. I just removed my email in the end.
That’s a really common behavior. I’ve had people open issues stating that something is a production blocker but of course they can’t contribute time to fix it.
I seems to me that GitHub's "social coding" is slowly turning things inside-out and upside-down.
At the beginning, you have a problem and you try to solve it yourself. If you succeed in doing so, great! Job done. The project is already successful at this point.
Next, you can take the extra step of open-sourcing it, because it might be useful for others too, and you might maybe benefit from the improvements, bug fixes or bug reports of others.
But if you start spending more time on dealing with emails, PRs etc. and it's no fun, just say no. Ignore people calling you "unprofessional" and whatnot. You owe them nothing.
At the beginning, you have a problem and you try to solve it yourself. If you succeed in doing so, great! Job done. The project is already successful at this point.
Next, you can take the extra step of open-sourcing it, because it might be useful for others too, and you might maybe benefit from the improvements, bug fixes or bug reports of others.
But if you start spending more time on dealing with emails, PRs etc. and it's no fun, just say no. Ignore people calling you "unprofessional" and whatnot. You owe them nothing.
There's another step at the beginning: after you have a problem, you search for similar projects that might have already solved your problem.
And in fact this step seems to generate most of the bug reports - you get "please implement feature X" and "does this have feature Y?" and so on, from people who have used your software for all of 5 minutes (or not at all).
It's only after a lot of time is wasted that a new project is started. Alternatively, it could be that the people who try to use/reuse software and the people who write new software are completely separate, so that no amount of bug tracker work will lead to new source contributions.
And in fact this step seems to generate most of the bug reports - you get "please implement feature X" and "does this have feature Y?" and so on, from people who have used your software for all of 5 minutes (or not at all).
It's only after a lot of time is wasted that a new project is started. Alternatively, it could be that the people who try to use/reuse software and the people who write new software are completely separate, so that no amount of bug tracker work will lead to new source contributions.
[deleted]
[deleted]
> Open source is different
I believe the attributes given to open source here are wrong.
There is a ton of open source code that is crap where not even the author had any interest in making it actually good (the same is true for writing). There is code that is the result of what's alluded to be "copywriting work" that's open source.
For me, this reads like a strawman, or maybe super idealised version, of open source is like compared to a vague strawman of what working in a company is like. It feels like this is neither true nor are those the only options out there.
> So if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you.
I don't feel the users that are called "abusive" to maintainers and contributers are the ones because some of your code sucks and they want to make it better.
It's the ones that want you to pander to their use-case. That have unreasonable demands. But even the ones with bug reports and telling you your code sucks in some way, should have some basic civility while communicating. No power of refusing pull requests shields you from insults and the mental burden of being harassed because you refuse pull requests (or close an issue someone opened).
I personally expect other people to value my time, not necessarily in money though. This is a general rule of life, not a matter of open source.
I believe the attributes given to open source here are wrong.
There is a ton of open source code that is crap where not even the author had any interest in making it actually good (the same is true for writing). There is code that is the result of what's alluded to be "copywriting work" that's open source.
For me, this reads like a strawman, or maybe super idealised version, of open source is like compared to a vague strawman of what working in a company is like. It feels like this is neither true nor are those the only options out there.
> So if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you.
I don't feel the users that are called "abusive" to maintainers and contributers are the ones because some of your code sucks and they want to make it better.
It's the ones that want you to pander to their use-case. That have unreasonable demands. But even the ones with bug reports and telling you your code sucks in some way, should have some basic civility while communicating. No power of refusing pull requests shields you from insults and the mental burden of being harassed because you refuse pull requests (or close an issue someone opened).
I personally expect other people to value my time, not necessarily in money though. This is a general rule of life, not a matter of open source.
> There is a ton of open source code that is crap
The good thing of open source is that people pick the best available, or at least some that is "good enough" when there are many choices.
The bad thing of proprietary code is that you paid for that, so you are stuck with it. Throwing it again and redoing it has a high cost, staying with it has a (high?) cost. But if you want custom code or very specific code, it's going to be one-off.
So yes, in general you can say that open source has better quality, because the best rise to the top, while in proprietary code it is what it is.
The good thing of open source is that people pick the best available, or at least some that is "good enough" when there are many choices.
The bad thing of proprietary code is that you paid for that, so you are stuck with it. Throwing it again and redoing it has a high cost, staying with it has a (high?) cost. But if you want custom code or very specific code, it's going to be one-off.
So yes, in general you can say that open source has better quality, because the best rise to the top, while in proprietary code it is what it is.
I believe that you could easily turn around the argument:
To stay relevant with paid software you have to make something people will be willing to buy. If you produce bad software, people will not or at least stop buying it. You can dump everything into the open source domain without any restrictions. Therefore, commercial code is of better quality.
It's not that I believe this, I find neither of those convincing. There is great open source software and there is great commercial software. There is a huge amount of bad software on both seids either.
Is good open source software better than good proprietary software? Depends on what are the criteria for good, but I don't think that's something we could state as general as "open source is better."
Going back to the original article:
The distinction the article talks about seems to be personal motivation to make the code better. While there might be a shift to be more engaged in a personal project (which is likely) the licensing model of that personal project is fairly irrelevant for this. Futher, quite a lot of people are also engaged in their job and care about the product they are working on.
Are people that don't care about it on their job more or less likely to even start personal projects? To contribute to open source? I don't know, maybe there is some data on that.
To stay relevant with paid software you have to make something people will be willing to buy. If you produce bad software, people will not or at least stop buying it. You can dump everything into the open source domain without any restrictions. Therefore, commercial code is of better quality.
It's not that I believe this, I find neither of those convincing. There is great open source software and there is great commercial software. There is a huge amount of bad software on both seids either.
Is good open source software better than good proprietary software? Depends on what are the criteria for good, but I don't think that's something we could state as general as "open source is better."
Going back to the original article:
The distinction the article talks about seems to be personal motivation to make the code better. While there might be a shift to be more engaged in a personal project (which is likely) the licensing model of that personal project is fairly irrelevant for this. Futher, quite a lot of people are also engaged in their job and care about the product they are working on.
Are people that don't care about it on their job more or less likely to even start personal projects? To contribute to open source? I don't know, maybe there is some data on that.
> To stay relevant with paid software you have to make something people will be willing to buy.
This doesn't mean it has to be good, just that you convince people to pay you, which is IMHO "easy" with the high software developer demand right now and difficulty for non-devs to distinguish between high and low quality software.
I think though, that as you are saying, open source shines with generic libraries where there's competition and selection of the best, while proprietary software shines with end-products (which are normally a multi-discipline team effort).
This doesn't mean it has to be good, just that you convince people to pay you, which is IMHO "easy" with the high software developer demand right now and difficulty for non-devs to distinguish between high and low quality software.
I think though, that as you are saying, open source shines with generic libraries where there's competition and selection of the best, while proprietary software shines with end-products (which are normally a multi-discipline team effort).
> The good thing of open source is that people pick the best available
At least at the fringes, popularity can be anticorrelated with quality.
I can't count the number of times I've looked for a library to do some task, found an extremely popular repo with thousands of stars, tried it and had it fail in an obvious way, find that the bug was reported already (and ignored or closed or a pr was opened and ignored).
I then try some alternative, built by an unknown author, and find that it has reasonable tests (!) and good docs (!) and actually works. 12 GitHub stars.
At least at the fringes, popularity can be anticorrelated with quality.
I can't count the number of times I've looked for a library to do some task, found an extremely popular repo with thousands of stars, tried it and had it fail in an obvious way, find that the bug was reported already (and ignored or closed or a pr was opened and ignored).
I then try some alternative, built by an unknown author, and find that it has reasonable tests (!) and good docs (!) and actually works. 12 GitHub stars.
That is exactly what I mean. So you used the best available one! And so will many people. The case you are describing normally happens when the previous one has been there for a while, and the new one is, well, new.
Many people will do like you, and find the new one more useful, and add their stars, and write articles, so over time it'll also become popular.
Many people will do like you, and find the new one more useful, and add their stars, and write articles, so over time it'll also become popular.
If this were true, the better libraries would have more stars, especially when the age of the libraries are similar.
And this is generally true; for similarly age libraries, the one with better quality (accounting for docs as well!) is normally more popular. There are exceptions for sure, as recently popular dev's libraries become more popular because of how popular their author is, but I'd say in libraries that are 3-5+ years old this generally holds true
Not my experience with open source at all. I get very few bugs and PRs about actual defects. By and large they are feature requests that are very important to the submitter but not necessarily to me or other users of the project. And they do not care about quality at all - they only care about solving their own problem as expediently as possible and don't care if they introduce new bugs, break compatibility with existing users, or reduce maintainability of the code.
As for paid vs unpaid work - I care about quality in both cases. But I'm much more motivated to care about someone else's use case if I'm being paid.
As for paid vs unpaid work - I care about quality in both cases. But I'm much more motivated to care about someone else's use case if I'm being paid.
> and not when doing copyrighting work for a well known company
copywriting
> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money. You are doing work for free, they are risking their asses deploying what you wrote, you both care about quality.
In the end the fact you're there making time for any interaction requires some money to be entering the system somewhere, to pay the rent. If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
copywriting
> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money. You are doing work for free, they are risking their asses deploying what you wrote, you both care about quality.
In the end the fact you're there making time for any interaction requires some money to be entering the system somewhere, to pay the rent. If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
Signaling bugs is as much work as it is to send a patch. Sometimes is even better work. For instance a bug report that is the fruit of a deep investigation is worth a lot more than a weak patch that is fixing the problem in the wrong way, often because of lack of understanding of the system. I don't agree there is a clear distinction of patches and bug reports in which one is work donated to the project and the other is not.
Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
I think perhaps here you mean that "signaling bugs is work, just the same as sending a patch is work".
What you said reads like "it's the same amount of work to identify a bug as it is to fix it" and I doubt that's what you intended.
What you said reads like "it's the same amount of work to identify a bug as it is to fix it" and I doubt that's what you intended.
> Signaling bugs is as much work as it is to send a patch.
No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable.
Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable.
Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
It depend on the actual patch, and bug report.
I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working.
And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself.
Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals.
In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working.
And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself.
Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals.
In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer.
Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations.
If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable.
A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug.
All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable.
A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug.
All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
A quick fix is a great way to describe a bug for the person that understands the system.
On many projects the mantainers ask way to much of the submitter in following some guidelines. I feel they think they should not "steal" the submit from the submitter or something becouse fixing stuff for them would equal the work of commenting it.
On many projects the mantainers ask way to much of the submitter in following some guidelines. I feel they think they should not "steal" the submit from the submitter or something becouse fixing stuff for them would equal the work of commenting it.
Highly depends IMHO. A good bug report that doesn't just says "X happens sometimes" but figures out when and why, or provides in-depth reasoning for what the behavior should be, can be a lot more work than the code fix, or a new feature.
But you would want the "it doesn't work sometimes" bug reports too so you can keep your eyes open for it.
It might be a nice to have a place where people can file low-effort bug reports, or perhaps "symptom reports", where there's no expectation that a maintainer will respond or even look at them.
Then they could be treated rather like automated crash reports: you could mine them to see if a problem is common, or if someone reports a strange problem you might be able to see whether anyone else had seen it and look for common factors.
Seems hard to make it work in practice without it turning into a place where people would just rant. Maybe if you make the reports readable only by the project's maintainers?
Then they could be treated rather like automated crash reports: you could mine them to see if a problem is common, or if someone reports a strange problem you might be able to see whether anyone else had seen it and look for common factors.
Seems hard to make it work in practice without it turning into a place where people would just rant. Maybe if you make the reports readable only by the project's maintainers?
It's a bit of an unusual idea, but I'd suggest that making symptom reports more public would help -- as long as they are anonymized and opt-in.
That's a really tricky technical problem to achieve, since many bug reports depend on the user's local environment in order to reproduce the problem, and that could conflict with anonymization.
Making problems public creates incentives for the project to fix issues (since they can't hide their existence) and also provides opportunities and information for contributors to help resolve them (including for purely selfish reasons, to fix issues that affect their own systems too).
That's a really tricky technical problem to achieve, since many bug reports depend on the user's local environment in order to reproduce the problem, and that could conflict with anonymization.
Making problems public creates incentives for the project to fix issues (since they can't hide their existence) and also provides opportunities and information for contributors to help resolve them (including for purely selfish reasons, to fix issues that affect their own systems too).
That's what user forums are for, like uservoice or reddit.
I programmed quite a lot of C/C++/Java code in my life (looking back at it, close to 3 million lines), and I consider good, reproducible bug reports an important contribution. An app full of new features that the users want is still unusable if it crashes often or mutilates stored data.
At the risk of mirroring antirez's response, and on top of that I suspect I might be misreading you, but still:
> If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
A good bug-report isn't merely whining, it's a contribution to the quality of the project. It takes some amount of time and effort to file a decent bug-report, and it helps the project better achieve its goal. It's less valuable than a good quality pull-request to fix the issue, but it still counts. (The same is true of good quality feature-requests, but to a much lesser extent in my view.)
That's different from someone having a sense of entitlement. Unless you're on their payroll, you aren't obliged to prioritise their bug. More generally, you aren't obliged to continue your involvement in the project in any way.
> If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
A good bug-report isn't merely whining, it's a contribution to the quality of the project. It takes some amount of time and effort to file a decent bug-report, and it helps the project better achieve its goal. It's less valuable than a good quality pull-request to fix the issue, but it still counts. (The same is true of good quality feature-requests, but to a much lesser extent in my view.)
That's different from someone having a sense of entitlement. Unless you're on their payroll, you aren't obliged to prioritise their bug. More generally, you aren't obliged to continue your involvement in the project in any way.
I've come to view OSS as the software industry's inferior analog to waiting tables in the movie business. It's inferior because at least waiters are paid for their labor.
The OSS authors who are successful are also paid, of course: but at that point they've "made it" and no longer have the same concerns (e.g. paying bills) that the 99.999% of other OSS developers have.
The OSS authors who are successful are also paid, of course: but at that point they've "made it" and no longer have the same concerns (e.g. paying bills) that the 99.999% of other OSS developers have.
That's an interesting take; I view OSS as an act of generosity. It's a gift given by the author, without any expectation of reward.
Waiting tables in the movie business feels more like a hustle; people do it so they can live in LA or Vancouver while they seek fame and fortune.
I have seen a trend of fame/fortune-seeking in OSS recently, but it seems more like a toxic offshoot than the norm.
The best OSS projects are still made by people who are genuinely trying to share solutions to common problems. Maybe they "make it" financially, but that is orthogonal to OSS contribution.
Waiting tables in the movie business feels more like a hustle; people do it so they can live in LA or Vancouver while they seek fame and fortune.
I have seen a trend of fame/fortune-seeking in OSS recently, but it seems more like a toxic offshoot than the norm.
The best OSS projects are still made by people who are genuinely trying to share solutions to common problems. Maybe they "make it" financially, but that is orthogonal to OSS contribution.
Open source authors are annoyed, in descending order, by:
It leads to the same dynamics as Mao's cultural revolution, which was not really a success.
[1] Not in this case of course.
1) False bug reports, reporter has an attitude.
2) Minor bugs, reporter has an attitude.
3) Major bugs, reporter has an attitude.
4) Unresearched bugs.
It leads to the same dynamics as Mao's cultural revolution, which was not really a success.
[1] Not in this case of course.
Some open source authors are also annoyed by:
5) Reporters not spending hours getting familiar with the build system to verify the bug in origin/master, even though it's been there in the three last stable releases.
6) Not providing a patch.
7) Not using the appropriate jargon for everything.
Entitlement is very much a thing (on both sides of the fence), but these are going to be extremely off-putting for anyone who is only ever going to be an end user.
5) Reporters not spending hours getting familiar with the build system to verify the bug in origin/master, even though it's been there in the three last stable releases.
6) Not providing a patch.
7) Not using the appropriate jargon for everything.
Entitlement is very much a thing (on both sides of the fence), but these are going to be extremely off-putting for anyone who is only ever going to be an end user.
Maybe those OSS authors ought to document their software better.
A pithy README.md with a toy example nobody would ever actually learn anything from isn't documentation. Maintaining a proper changelog with links to relevant issues/tickets isn't that hard, but it's rarely employed.
A pithy README.md with a toy example nobody would ever actually learn anything from isn't documentation. Maintaining a proper changelog with links to relevant issues/tickets isn't that hard, but it's rarely employed.
> mostly by people who do little programming but take over OSS projects
You're voiding your whole argument by disqualifying any opposition like that. Anyone disagreeing with you will now fall into that bucket, and give you a reason to ignore them. Can we save that for politics please?
You're voiding your whole argument by disqualifying any opposition like that. Anyone disagreeing with you will now fall into that bucket, and give you a reason to ignore them. Can we save that for politics please?
I keep seeing these kind of threads popping up here on hacker news, where people are lamenting the pains and sufferings of open source maintainers.
I agree about the base problem: open source maintainers do lots of work and they are not getting paid. Sometimes people come to expect them to work for them for free! What entitlement, huh?
And this lack of concrete reward makes it easy to burn out unless you really care about what you do.
This is a real problem. Sure.
But here on Hacker news lately I’ve gotten the impression that everyone expects every open source maintainer to be burned out and suffering, and that we should always act as if they are.
People should tiptoe around and be afraid to interact, lest they disturb this poor and over-worked maintainer!
Needless to say, I think that’s wrong. Open-source thrives on positivity, on energy and a willingness to contribute.
We shouldn’t make people who wants to contribute afraid to do so, simply because some maintainers are burnt out.
I’d rather say the opposite: if you as a maintainer no longer see joy in what you do, you should step aside or at least take a break. We don’t need you as a force taking energy away from open-source.
We’re thankful for what you’ve contributed in the past, no doubt. But your legacy will probably do better if you let someone else carry the flame from now on, or at least for a while.
There’s no shame in taking a break.
Disclaimer: open-source enthusiast, contributor and maintainer.
I agree about the base problem: open source maintainers do lots of work and they are not getting paid. Sometimes people come to expect them to work for them for free! What entitlement, huh?
And this lack of concrete reward makes it easy to burn out unless you really care about what you do.
This is a real problem. Sure.
But here on Hacker news lately I’ve gotten the impression that everyone expects every open source maintainer to be burned out and suffering, and that we should always act as if they are.
People should tiptoe around and be afraid to interact, lest they disturb this poor and over-worked maintainer!
Needless to say, I think that’s wrong. Open-source thrives on positivity, on energy and a willingness to contribute.
We shouldn’t make people who wants to contribute afraid to do so, simply because some maintainers are burnt out.
I’d rather say the opposite: if you as a maintainer no longer see joy in what you do, you should step aside or at least take a break. We don’t need you as a force taking energy away from open-source.
We’re thankful for what you’ve contributed in the past, no doubt. But your legacy will probably do better if you let someone else carry the flame from now on, or at least for a while.
There’s no shame in taking a break.
Disclaimer: open-source enthusiast, contributor and maintainer.
> if you let someone else carry the flame from now on
Ha!
For a lot of open source maintainers and projects, that's not an option because there isn't someone else.
A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that.
It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't.
It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all.
That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself".
That's not maintainers being unwilling to step aside.
There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features.
Or more reasonably, which just clash with the design direction of the project.
The same happens in the real world (non-computer) non-profit volunteer projects.
A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.
Ha!
For a lot of open source maintainers and projects, that's not an option because there isn't someone else.
A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that.
It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't.
It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all.
That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself".
That's not maintainers being unwilling to step aside.
There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features.
Or more reasonably, which just clash with the design direction of the project.
The same happens in the real world (non-computer) non-profit volunteer projects.
A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.
> It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Then you step down. If you’re burnt out and the project no longer gives you joy, you have no obligation to fix bugs or even keep things working.
The project will be abandoned and dead... until evolution decides that it should be revived again (if it should), by someone not you, in a fork with a new maintainer who now has the drive you once had.
It may be hard for you, but it may be best for the project, and it’s probably good for your own health too.
I’ve done it to some of my projects. I’ve taken over projects who has been abandoned by others too.
If the code is useful, someone will pick it up and make use of it. No need burning out by convincing yourself of the falsehood that the person that does all the hard work has to be you, forever.
Then you step down. If you’re burnt out and the project no longer gives you joy, you have no obligation to fix bugs or even keep things working.
The project will be abandoned and dead... until evolution decides that it should be revived again (if it should), by someone not you, in a fork with a new maintainer who now has the drive you once had.
It may be hard for you, but it may be best for the project, and it’s probably good for your own health too.
I’ve done it to some of my projects. I’ve taken over projects who has been abandoned by others too.
If the code is useful, someone will pick it up and make use of it. No need burning out by convincing yourself of the falsehood that the person that does all the hard work has to be you, forever.
I think you've been downvoted because your reply is too dismissive of the motivations why people do open source projects in the first place, and of the way joy depends on how other people behave.
For myself, I have worked on projects where I continued long past where I felt joy in doing the project, because the goal of the project was still worth doing, and not just for myself but for other people's benefit.
I've done many things like that which you wouldn't call projects too. If I quit at the first sign of not enjoying them, I would have abandoned a lot of people by now!
There is also reputation. For better and worse, some people's reputation is bound up in how they handle their projects, and this has become stronger since "GitHub is the new résumé" for some. To step down from a project is to potentially drop a career-building opportunity.
To apply your principle to that sort of thing, we would need an expansive definition of joy that goes beyond feeling uplifted in the short term, and go deep into a pandora's box of why people choose things, intrinsic and extrinsic motivations.
We would also need to figure out how to apply the principle when joy isn't a passive result of whether you work on the project. It's affected by how things like bug reports are handled, on talking publicly about what we want from each other, about the importance of politeness and reasonable expectations, learning how to respond to people, and other things such as this discussion. Sometimes unpleasant experiences are needed to create more joy in future.
I think it's more fruitful to just let joy be good old simple joy, and when it comes to deciding whether to "step down", instead of a simple assessment of "am I enjoying this", talk about better ways to accomplish things we think are still worth doing, even when we're not currently enjoying it.
For myself, I have worked on projects where I continued long past where I felt joy in doing the project, because the goal of the project was still worth doing, and not just for myself but for other people's benefit.
I've done many things like that which you wouldn't call projects too. If I quit at the first sign of not enjoying them, I would have abandoned a lot of people by now!
There is also reputation. For better and worse, some people's reputation is bound up in how they handle their projects, and this has become stronger since "GitHub is the new résumé" for some. To step down from a project is to potentially drop a career-building opportunity.
To apply your principle to that sort of thing, we would need an expansive definition of joy that goes beyond feeling uplifted in the short term, and go deep into a pandora's box of why people choose things, intrinsic and extrinsic motivations.
We would also need to figure out how to apply the principle when joy isn't a passive result of whether you work on the project. It's affected by how things like bug reports are handled, on talking publicly about what we want from each other, about the importance of politeness and reasonable expectations, learning how to respond to people, and other things such as this discussion. Sometimes unpleasant experiences are needed to create more joy in future.
I think it's more fruitful to just let joy be good old simple joy, and when it comes to deciding whether to "step down", instead of a simple assessment of "am I enjoying this", talk about better ways to accomplish things we think are still worth doing, even when we're not currently enjoying it.
It isn't that easy. If your project is very high quality and you let others take over, you'll be forgotten in a couple of years and others take the credit. Often without doing much except responding to rude bug reports like a trained hotel receptionist.
But that is frequently the real goal of those who drive out high performers.
But that is frequently the real goal of those who drive out high performers.
There's many motivations and circumstances behind the maintainers of open-source projects, and I think this post works off a too simplified & idealized perspective on that. It seems to mostly assume that an open-source project exists because the maintainer wants to make the software the best it can be and is free to do so because they got a nice income from something else and no big challenges prioritizing it against other things in their life.
Well, that used to be the case for the majority of OSS. Even when funded by enterprise, the main reason to publish code has always been to share and advance a field, not to make more money out of it.
I noticed a missing feature in an OSS product I use. I pointed out the general mechanism of how it might be implemented. 3 hours later it was implemented, and the maintainer thanked me.
I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"
I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"
Because you kind of did Product Management for them!
“Hey, there’s this idea. I have at least one customer [me]. I think it’d be pretty easy to implement like this.”
It’s pretty rewarding to have a blueprint for “oh, I can deliver some value, easily”.
Got any more suggestions for them? :).
“Hey, there’s this idea. I have at least one customer [me]. I think it’d be pretty easy to implement like this.”
It’s pretty rewarding to have a blueprint for “oh, I can deliver some value, easily”.
Got any more suggestions for them? :).
I also had similar interactions, but I'm not sure of the outcome, because I don't know how much it aligned with the project's roadmap.
And this is exactly where I disagree with Antirez' post.
> You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality.
Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?"
If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself.
Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released.
So I would urge developers who opensource their code to establish what their users can expect.
And this is exactly where I disagree with Antirez' post.
> You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality.
Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?"
If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself.
Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released.
So I would urge developers who opensource their code to establish what their users can expect.
If you add any dependency to your project, you Am are taking a risk. It's partially mitigated by open source because you can make downstream changes, but you would be better off writing from scratch many times if you know ahead of time the project will be abandoned.
Sorry, I don't get it. I agree that there is a risk, but the risk is to need to do work at an unpleasant time you couldn't plan for as much as you wanted. "Risking your ass" risk is risk over which you could get fired.
Let's use an example: years ago someone built something in Python 2.6 and added some library because it provided functionality you needed. Now you are in charge and need to upgrade to Python 3.7 because of $REASONS and the library isn't compatible nor maintained.
How is this different from having written the library by yourself? You'll still need to do the transition. And yes, it probably would have been better if someone else did this for you or you knew before, but so is life. Years ago someone made a decision to postpone writing it from scratch and you inherited this somehow.
There is a serious risk it will come like this, but this is not "you risk your ass" risk. No one will get fired over something like this.
If someone is stupid enough to accept changes from upstream without reviews and an attacker added a backdoor to $AUTHENTICATION_LIB and you download version 0.9.1_hacked without checking if this is a legit update, that might be "risking your ass" risk. And someone might get fired for it. But probably is't.
Let's use an example: years ago someone built something in Python 2.6 and added some library because it provided functionality you needed. Now you are in charge and need to upgrade to Python 3.7 because of $REASONS and the library isn't compatible nor maintained.
How is this different from having written the library by yourself? You'll still need to do the transition. And yes, it probably would have been better if someone else did this for you or you knew before, but so is life. Years ago someone made a decision to postpone writing it from scratch and you inherited this somehow.
There is a serious risk it will come like this, but this is not "you risk your ass" risk. No one will get fired over something like this.
If someone is stupid enough to accept changes from upstream without reviews and an attacker added a backdoor to $AUTHENTICATION_LIB and you download version 0.9.1_hacked without checking if this is a legit update, that might be "risking your ass" risk. And someone might get fired for it. But probably is't.
That's because your wish happened to align well with the maintainer's understanding on how they want to spend their time. Think of it as hitchhiking, if you're both going the same way, it's a win-win: a free ride for you and a free chat for them. But if they need to take a 100-mile detour to get where you're headed, it makes full sense for them to simply say no.
I think most people forget that when you (or anyone) puts something out there in the public domain, there is no obligation / entitlement on either sides.
The user is not obliged to make a payment to the creator, nor is the creator obliged to respond to every need (question/bug report/contribution)
Any warranty or service request must come with some form of contract between the user and creator.
We as a community must help in people understand this. Open source is not a contract. No one is entitled to anything.
The user is not obliged to make a payment to the creator, nor is the creator obliged to respond to every need (question/bug report/contribution)
Any warranty or service request must come with some form of contract between the user and creator.
We as a community must help in people understand this. Open source is not a contract. No one is entitled to anything.
> Open source is different, it's an artifact, it's a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding.
Open Source does not always mean hobby project. Plenty of people make a living writing Linux kernel code, for instance.
edit: ketzu beat me to it.
Open Source does not always mean hobby project. Plenty of people make a living writing Linux kernel code, for instance.
edit: ketzu beat me to it.
When employed by big companies to do so, because their main business is selling something else unrelated to the software itself.
Doing open source where software is actually the real product usually ends up in hobby project level as donations, consulting or books aren't enough to keep the ball rolling.
Doing open source where software is actually the real product usually ends up in hobby project level as donations, consulting or books aren't enough to keep the ball rolling.
antirez himself made his living writing open source code for redis, until July 2020.
Some context for readers: This is Antirez, the creator of Redis. Dude's insanely smart (saying this not yet having read the article).
EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.
EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.
And the creator of dump1090! When I was a student receiving Mode-S transponder was so expensive, we had a shared receiver/decoder for the whole eng. school. Now that I lecture there I show the students a $6 RTL-SDR with dump1090 to show how far open tech goes, plus some MATLAB code to store/plot the aircraft data: https://github.com/JorgeGT/PlotRTL1090
NP and thanks for the nice words.
Not all open-source is created equal. There are many open-source projects where all the key contributors are employed by a big corporation. And their performance review depends on the work they do on the open source project. like Go language, AOSP, Chromium, VSCode, dotnet, Zstd. Most Linux contributors are also doing what their employers tell them to do.
Maybe we need to distinguish “altruistic open source” from “corporate open source”?
Yes, we need. I call it "indie OSS" vs "Company OSS".
GPL contra the rest of OSS licenses seems to map to this divide fairly well, don't you think? My impression is that Corporate legal seems to not like GPL, at all. So next one, make it GPL.
There are probably some parallels here with music; some people produce (and may collaborate on) music for pure enjoyment and the craft, and at the same time there are large businesses that have industrialized music creation.
> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money.
If an open-source project grows to the point where time is insufficient to maintain it alongside your day-to-day job, then the matter of money becomes inevitable. And I'm not talking about allocating one's entire free time to the project, but just the time one assesses to be reasonable for this hobby, which can be rather short because of other occupations (rest, family, other hobbies, etc).
If an open-source project grows to the point where time is insufficient to maintain it alongside your day-to-day job, then the matter of money becomes inevitable. And I'm not talking about allocating one's entire free time to the project, but just the time one assesses to be reasonable for this hobby, which can be rather short because of other occupations (rest, family, other hobbies, etc).
This makes me think I should take emails/comments less important. These are not customers, they are fans.
If it's my project,I should just enjoy it for myself.
While it sounds great to personally respond and research what people tell me, it's a major distraction and time waste when I could be doing research.
If it's my project,I should just enjoy it for myself.
While it sounds great to personally respond and research what people tell me, it's a major distraction and time waste when I could be doing research.
>Open source is different, it’s an artifact, it’s a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding. And you want it to rock, to be perfect, and you can’t sleep at night if there is a fucking heisenbug.
Not necessarily. For paid contributors (often among the most important ones in "open source" projects with corporate involvement) it can be just another job. And for casual open source creators, it can be just a small hobby, not some obsession with it being perfect. Heck, a big number of open source codebases are left to rot as soon as the dev moves to something more shiny...
So when he says "if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you. It’s not about money. You can ignore bugs if you want, and ignore their complains, you can do that since you don’t have a contract to do otherwise, but they are helping you, they care about the same thing you care: your software quality, grandiosity, perfection." that might be true for Redis, or Sqlite etc, but not for all FOSS projects, including many otherwise succesful ones...
Not necessarily. For paid contributors (often among the most important ones in "open source" projects with corporate involvement) it can be just another job. And for casual open source creators, it can be just a small hobby, not some obsession with it being perfect. Heck, a big number of open source codebases are left to rot as soon as the dev moves to something more shiny...
So when he says "if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you. It’s not about money. You can ignore bugs if you want, and ignore their complains, you can do that since you don’t have a contract to do otherwise, but they are helping you, they care about the same thing you care: your software quality, grandiosity, perfection." that might be true for Redis, or Sqlite etc, but not for all FOSS projects, including many otherwise succesful ones...
> Open source is different, it’s an artifact, it’s a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding. And you want it to rock, to be perfect, and you can’t sleep at night if there is a fucking heisenbug.
This has been my experience.
I have refined my development skills, as a direct result of my OSS work (I've been writing open-source for over twenty years). During this time, I was a manager, at my "day job," and the company I worked for actively discouraged managers from being engineers. I wasn't having that, so I did OSS on the side, to keep my chops up.
Also, I worked for a company that insisted on a rigid, waterfall-based development methodology, that I thought resulted in sub-par software. It worked great on hardware; not so great on software.
Through my OSS work, I was able to prototype and refine a methodology that is a great deal more flexible than that used by my corporation. I feel that it results in far better software.
I have not experienced a whole lot of the troubles that Antirez encounters; mostly because I haven't authored anything of the scale of Redis. I have, however, authored another project that has become a worldwide standard framework (for a much smaller demographic), and the best thing that I did for it (and for myself), was to get the hell away from it. It's being maintained by a team of fairly brilliant and energetic folks that have taken it to the next level.
I really feel that if I had remained "in the mix," I would have stunted it.
As Twain once put it: "I cannot help but notice that there is no problem between us that cannot be solved by your departure."
This has been my experience.
I have refined my development skills, as a direct result of my OSS work (I've been writing open-source for over twenty years). During this time, I was a manager, at my "day job," and the company I worked for actively discouraged managers from being engineers. I wasn't having that, so I did OSS on the side, to keep my chops up.
Also, I worked for a company that insisted on a rigid, waterfall-based development methodology, that I thought resulted in sub-par software. It worked great on hardware; not so great on software.
Through my OSS work, I was able to prototype and refine a methodology that is a great deal more flexible than that used by my corporation. I feel that it results in far better software.
I have not experienced a whole lot of the troubles that Antirez encounters; mostly because I haven't authored anything of the scale of Redis. I have, however, authored another project that has become a worldwide standard framework (for a much smaller demographic), and the best thing that I did for it (and for myself), was to get the hell away from it. It's being maintained by a team of fairly brilliant and energetic folks that have taken it to the next level.
I really feel that if I had remained "in the mix," I would have stunted it.
As Twain once put it: "I cannot help but notice that there is no problem between us that cannot be solved by your departure."
> they care about the same thing you care: your software quality, grandiosity, perfection.
Nope, I don't care about this at all.
I don't like writing software in of itself. I like trying to find eutectic points of different molecules in software because it cheaper than doing it in a lab, I like being able to explore whats running on my router because I'd like to know what security holes could lie there. I like c and c++ because its way faster at run time and uses less way resources when trying to find low dimensional space projections of energy matrices than doing it in python. The code itself? I don't care about it at all to the extent that I can get what I want from it.
Not everyone who writes open source software cares about the same thing, but its good that the author found something they like to do as with I.
Nope, I don't care about this at all.
I don't like writing software in of itself. I like trying to find eutectic points of different molecules in software because it cheaper than doing it in a lab, I like being able to explore whats running on my router because I'd like to know what security holes could lie there. I like c and c++ because its way faster at run time and uses less way resources when trying to find low dimensional space projections of energy matrices than doing it in python. The code itself? I don't care about it at all to the extent that I can get what I want from it.
Not everyone who writes open source software cares about the same thing, but its good that the author found something they like to do as with I.
You haven't realized you're actually agreeing with him. If someone sends a bug report to your router firmware project, what do they really care about?
I wont care (unless im curious enough to explore it), if they want to write a fix themselves they can do it. And if they write a fix, I wont care about it's quality, perfection or grandiosity… and I won't assume that they do either.
I don't agree because I'm not making an assumption for others motivations of writing software (or submitting bug reports), nor do I want to.
If you and the author want to assume that these are the only motivations can exist in open source software, then that's on you both, I don't have to assume such things.
I don't agree because I'm not making an assumption for others motivations of writing software (or submitting bug reports), nor do I want to.
If you and the author want to assume that these are the only motivations can exist in open source software, then that's on you both, I don't have to assume such things.
Perfection and grandiosity are a thing apart, but certainly you care about quality... Otherwise you'd play video games with fake chemistry instead of study real chemistry, no?
Quality is something that seems much more useful than perfection and grandiosity (to me at least), but I won't care about it more than necessary to get something done: if a desired reaction can be done with 80% concentration of the compounds… I wont strive for 99.9%, esp if the costs (time/money/etc) of achieving the latter are an order of magnitude higher unless it is needed (and rarely it is).
Generalizing a complex concept is never easy and in doing so we often make mistakes. This happens also in this post.
At the same time, finding counterexamples is easy and it is even easier when the matter is related to personal motivation or choices.
At the same time, I greatly resonate with this need of quality and this brings to my mind this book [https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...]. In an environment obsessed with growth (more customers, more downloads, etc.) it is often difficult to make long-term choices which gives to quality the right level of importance.
At the same time, I greatly resonate with this need of quality and this brings to my mind this book [https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...]. In an environment obsessed with growth (more customers, more downloads, etc.) it is often difficult to make long-term choices which gives to quality the right level of importance.
I don't think "most" people produce their best work while working on something in their spare time. That simply doesn't make sense. Your work is something you're paid to care about and do well with all your attention, while most open-source projects are like hobbies that you practice semi-randomly in your spare time. For every open source project that's polished and well-tested and well-maintained there are 1000 which are hastily written, simply without any tests, abandoned, etc.
I don't doubt there are people who put their soul into fantastic open-source projects instead of any code at their work. But then it's a question why they're still in their day job in the first place, if they don't like the job or don't want to care about their job. Sooner or later the best course of action would be to quit and either work on their own project full-time and try to monetize it, or find a job they're actually passionate about or at least OK with caring about. I understand that the author himself made redis big, but then it also pretty much became his full-time job and I doubt his understanding reflects that of most other developers out there.
I don't doubt there are people who put their soul into fantastic open-source projects instead of any code at their work. But then it's a question why they're still in their day job in the first place, if they don't like the job or don't want to care about their job. Sooner or later the best course of action would be to quit and either work on their own project full-time and try to monetize it, or find a job they're actually passionate about or at least OK with caring about. I understand that the author himself made redis big, but then it also pretty much became his full-time job and I doubt his understanding reflects that of most other developers out there.
Open bug reports, I can't see that as a problem. If it doesn't seem well researched, you can leave it be or ask for better confirmation. Otherwise it helps you write better software.
Pull requests and patches are even better. Someone has researched the problem and attempted a solution. You can review that and see how it fits into your bigger picture.
There's two little diseases in OSS.
1. Loud, bullying complainers who attempt to monopolize the communication channels, spamming mailing lists and chat rooms about their problems and refusing help with workarounds, etc. These people are usually mediocre programmers or non-programmers.
2. Apathetic maintainers who may be working on little features they care about and not worrying about the quality of the project as a whole. I remember the experience of patching an upstream project to the one I was working on and I could not, for the life of me, get the upstream project to care that they had a bug that made their software look bad. They were actively maintaining the project but I suppose they weren't focusing on that area. That's a real turn-off to helping them out in the future and leads to forks.
Pull requests and patches are even better. Someone has researched the problem and attempted a solution. You can review that and see how it fits into your bigger picture.
There's two little diseases in OSS.
1. Loud, bullying complainers who attempt to monopolize the communication channels, spamming mailing lists and chat rooms about their problems and refusing help with workarounds, etc. These people are usually mediocre programmers or non-programmers.
2. Apathetic maintainers who may be working on little features they care about and not worrying about the quality of the project as a whole. I remember the experience of patching an upstream project to the one I was working on and I could not, for the life of me, get the upstream project to care that they had a bug that made their software look bad. They were actively maintaining the project but I suppose they weren't focusing on that area. That's a real turn-off to helping them out in the future and leads to forks.
That's so true. I still work and put a lot of energy and work into a project I began to love during my time at the university: https://github.com/sirixdb/sirix
I've spent so much of my spare time working on the project with some gaps since 2012 (and before under a different name at the university since 2006 or 2007). Last year during Hacktoberfest I got first contributions and since then at least another guy, Moshe works constantly on clients for Python and TypeScript and a frontend using Svelte: https://github.com/sirixdb/sirix-svelte-front-end
I've got a lot of great contributions since october last year and it's such a good feeling, despite spending money for the domain https://sirix.io and stuff like a logo and so on :-)
I've spent so much of my spare time working on the project with some gaps since 2012 (and before under a different name at the university since 2006 or 2007). Last year during Hacktoberfest I got first contributions and since then at least another guy, Moshe works constantly on clients for Python and TypeScript and a frontend using Svelte: https://github.com/sirixdb/sirix-svelte-front-end
I've got a lot of great contributions since october last year and it's such a good feeling, despite spending money for the domain https://sirix.io and stuff like a logo and so on :-)
In his book "The workmanship of risk", the industrial design philosopher David Pye said that the best work of the century will be done by amateurs. The reason being that a professional's work will always be held back from perfection by the fact that one has to balance the quality of the paid work relative to what one can reasonably charge for the work.
The amateur's work held back by what one can reasonably spend without funding.
I think that a lot of people here are forgetting that a project is whatever you make a project to be. It does not need to be operated like a bureaucratic profit seeking corporation. The problem is that the corporate world leaks their madness into our private lives. Just do whatever you want and have fun. Remember that you can choose any type of societal model to structure your project. And most importantly you are free to walk away at any time. But there exist two things here the real project and the social avatar of the project and how the people on the project interact with each other. What belongs to whom? and does it matter? Sub specie aeternitatis this whole thing feels like an effing Herzog movie. Please don't let yourselves get carried away by this nonsense. Like whats the effing point here Fitzcarraldo? I mean seriously people, as a humanity, where are we going so fast that we can't wait to get there and why don't get there with joy?
Quote: "As somebody said, the best code is written when you are supposed to do something else."
Not for me, my best code is when I write stuff for myself. None of them are open source and they tend to have better code than stuff I work for clients. Which usually means I borrow my code from my pet projects a lot when solving client's problems.
That also leads to a nice side effect that over years I have a huge collection of personal code that I just copy/paste and I know it works. When I do a live session of creating a PoC the client even if himself is a developer gets lost in my fast switching of pages, copy/paste, my fast way of talking and throwing overwhelming information at him that in the end they just get lost. And one hour later a final "it's done, here take it" usually gets a "holly shit, that's awesome". When I hear that I know the client is mine.
Not for me, my best code is when I write stuff for myself. None of them are open source and they tend to have better code than stuff I work for clients. Which usually means I borrow my code from my pet projects a lot when solving client's problems.
That also leads to a nice side effect that over years I have a huge collection of personal code that I just copy/paste and I know it works. When I do a live session of creating a PoC the client even if himself is a developer gets lost in my fast switching of pages, copy/paste, my fast way of talking and throwing overwhelming information at him that in the end they just get lost. And one hour later a final "it's done, here take it" usually gets a "holly shit, that's awesome". When I hear that I know the client is mine.
>don’t do the error of reducing the interaction to a vile matter of money
The most important thing I've learned from reading antirez's blog posts is a certain way of thinking about the labor market that I'm guessing is much more common in Italy (and maybe in France and Spain) than where I live (namely, the US).
The most important thing I've learned from reading antirez's blog posts is a certain way of thinking about the labor market that I'm guessing is much more common in Italy (and maybe in France and Spain) than where I live (namely, the US).
It's not "the Italian labor market". Antirez's open source work is financed by his corporate employers, so of course he has no need to take payment for bug fixes in his project.
You didn't catch my point, but never mind. (I probably should've written "a certain way of thinking about the morality of work and of money".)
I sometimes wonder how much of a pain it really is? I've seen a few impolite complaints here and there on GitHub, but not as much as posts like this (or some comments here) imply. Am I missing something? Is it one of those loud minority things or do you fell that OSS disrespect is prevalent?
It's both a loud minority thing (that's still quite draining to be exposed to) and very unevenly distributed between projects/maintainers. E.g. projects aiming at non-/not-so-technical users often have problems with it, especially if they at the same time are in areas where regular breakage is to be expected (e.g. software to scrape/download from popular websites, 3D printing tools would be my guess for good examples). Some projects with corporate users but no corporate backing can run into the same. But at the same time for other projects it might never happen.
While I understand some of the sentiment, I disagree with most of the opening. When it comes to the open projects I want to do, often it's either a library that I break off from something I am working on that I actively need. At other times, those projects languish because of a lack of motivation, time or both.
Some of my best work comes out of when I'm getting paid to do the work directly. I take some level of craftsmanship/pride in what I do. Those are the things I finish and more than one has seen production use for over a decade. Not everyone has pride in the craft for their paid work, but that's kind of the point, not everyone is the same. I do wish more people took care in their craft though.
Some of my best work comes out of when I'm getting paid to do the work directly. I take some level of craftsmanship/pride in what I do. Those are the things I finish and more than one has seen production use for over a decade. Not everyone has pride in the craft for their paid work, but that's kind of the point, not everyone is the same. I do wish more people took care in their craft though.
> As somebody said, the best code is written when you are supposed to do something else
Offer not good for user interfaces. :)
At least in the Gnu-slash-linux world it's like this. I once fixed a volume slider widget where the lowest value was almost zero. I can't be sure, but it's quite possible that when I realized the stupidity of that bug I took a break and went back to my regular job.
Nearly every open source UI I've ever seen looks as if it were designed as a gift for the in-laws on Christmas eve.
The exceptions generally leverage the web (or borrow large parts from it). That's why people are revving their Electron monster trucks in your craggy-ass Gnu-slash-linux parking lot.
Offer not good for user interfaces. :)
At least in the Gnu-slash-linux world it's like this. I once fixed a volume slider widget where the lowest value was almost zero. I can't be sure, but it's quite possible that when I realized the stupidity of that bug I took a break and went back to my regular job.
Nearly every open source UI I've ever seen looks as if it were designed as a gift for the in-laws on Christmas eve.
The exceptions generally leverage the web (or borrow large parts from it). That's why people are revving their Electron monster trucks in your craggy-ass Gnu-slash-linux parking lot.
> > As somebody said, the best code is written when you are supposed to do something else
> Offer not good for user interfaces. :)
Actually, it's still the best; it's just that that's a very, very low bar, since the competition is actively user-hostile, and looks like it was designed in Photoshop by a graphic designer who never wrote a line of code in their life (often because it was).
> Offer not good for user interfaces. :)
Actually, it's still the best; it's just that that's a very, very low bar, since the competition is actively user-hostile, and looks like it was designed in Photoshop by a graphic designer who never wrote a line of code in their life (often because it was).
Please don't post flamebait here.
"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian.
This is missing one important variable -- the age of the project. Sure, if I have to fix a bug at work, in some crufty old software, that I probably didn't write, that's a lot less appealing than writing brand new, clean, perfect code on my own project.
On the other hand, if my new project gets to be a few years old, and develops some cruft of its own, and I have to fix a bug in it, that might look a lot less appealing than a brand new work project, in which I am writing new, clean, perfect code.
This is missing one important variable -- the age of the project. Sure, if I have to fix a bug at work, in some crufty old software, that I probably didn't write, that's a lot less appealing than writing brand new, clean, perfect code on my own project.
On the other hand, if my new project gets to be a few years old, and develops some cruft of its own, and I have to fix a bug in it, that might look a lot less appealing than a brand new work project, in which I am writing new, clean, perfect code.
[deleted]
*YMMV
Maybe engineers who have some basic self-guiding work ethic are able to product high quality code also in the job that allows them to put a roof over their head and feed their kids.
Maybe engineers who have some basic self-guiding work ethic are able to product high quality code also in the job that allows them to put a roof over their head and feed their kids.
This doesn't seem like a paradox at all - isn't it a well known fact that intrinsic motivation trumps extrinsic motivation?
The main problem with open source issue reports is so frequently nothing to do with the way something is said (though that is often a problem), but the actual content of what is being said. 90% of the issues I end up with on GitHub aren't requests for support on the project, they are requests for tutoring of basic programming and IT issues.
This reminds me a bit of artists that complain that they can't live from it. IMO OSS is very similar to this, the salary for doing something you like is by definition pleasure or even fulfillment. But you have to play by the rules of the system. Hence my often frustrating consulting work pays for my hobby OSS. Plain ying and yang.
About the quote at the bottom, I see a parallel on how responsibility/obligation can backfire. Very often it removes the initial drive / intrisic motivation which weighs high in the outcome quality.
Just yesterday I was called no less than fascist on GitHub. Because some years ago we have removed an obsolete and insecure authentication method from our opensource app.
>Like a writer will do her best when writing that novel that, maybe, nobody will pay a single cent for
No problem, it's just about woman's who write...not the job of writing.
No problem, it's just about woman's who write...not the job of writing.
The real underlying issue is
a) how to deal with public goods especially networked public goods.
b) The production cost vs use cost.
c) we act on margin always not on total as my mind may think but our act is temporal.
a) how to deal with public goods especially networked public goods.
b) The production cost vs use cost.
c) we act on margin always not on total as my mind may think but our act is temporal.
Anyone who derives dopamine from their work to the point of being willing to obsessively work for free is treating their “work” like a drug and in essence is no different from a drug addict. In this arrangement the users supplying bug reports and extracting value from the author is the drug dealer.
This isn’t a healthy arrangement and often leads to burnout and depression. You cannot blindly indulge in your passions. You must apply some level of discipline and long term meaning to what you are doing or you will destroy yourself.
This isn’t a healthy arrangement and often leads to burnout and depression. You cannot blindly indulge in your passions. You must apply some level of discipline and long term meaning to what you are doing or you will destroy yourself.
Anything anyone enjoys doing is no better than drug addiction?
I never made such a claim, explicitly or implicitly. I think you’re projecting an argument.
What is the paradox? I don't see it.
That the OSS writer cares and is often willing to fix code she writes for free, more than the other paid work she does.
In economics it’s known as the subscription equilibrium.
Conflict of interests. Also it's in the interests of maintainers to understate the value of their users.
Money isn't vile. What a toxic way to think about work.
The HTTPS cert for this website points to redis.io . Don't know what's up with that...
The author wrote Redis.
« I'm filing this bug report because I found a bug. This isn't a complaint that the bug exists, or a suggestion that you prioritise fixing it, or a support request asking for workarounds. It's just a report that the bug exists. »
But I think actually writing that would come over as rather snotty. Maybe the right thing is to write a post somewhere on what I think is the right attitude for filing bug reports, and discreetly link to it.