[HN Gopher] The open source paradox
___________________________________________________________________
The open source paradox
Author : stargrave
Score : 296 points
Date : 2020-10-03 09:14 UTC (13 hours ago)
(HTM) web link (antirez.com)
(TXT) w3m dump (antirez.com)
| sombremesa wrote:
| This doesn't seem like a paradox at all - isn't it a well known
| fact that intrinsic motivation trumps extrinsic motivation?
| outsomnia wrote:
| > 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.
| antirez wrote:
| 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.
| outsomnia wrote:
| > 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.
| inglor_cz wrote:
| 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.
| rbarrois wrote:
| 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.
| rightbyte wrote:
| 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.
| outsomnia wrote:
| 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.
| jka wrote:
| 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.
| detaro wrote:
| 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.
| rightbyte wrote:
| But you would want the "it doesn't work sometimes" bug
| reports too so you can keep your eyes open for it.
| mjw1007 wrote:
| 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?
| srtjstjsj wrote:
| That's what user forums are for, like uservoice or
| reddit.
| jka wrote:
| 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).
| MaxBarraclough wrote:
| 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.
| sidlls wrote:
| 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.
| 0SSawayyyy wrote:
| 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.
| detaro wrote:
| 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.
| ricardobeat wrote:
| 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.
| bobmalone123 wrote:
| OP could drop virtue signaling by stopping to write in 3rd
| "female" person ("she writes software"). Statistics talk.
| rushabh wrote:
| 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.
| agumonkey wrote:
| 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.
| geophile wrote:
| "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.
| mdoms wrote:
| Money isn't vile. What a toxic way to think about work.
| the-dude wrote:
| What is the paradox? I don't see it.
| mr_toad wrote:
| In economics it's known as the subscription equilibrium.
| antirez wrote:
| That the OSS writer cares and is often willing to fix code she
| writes for free, more than the other paid work she does.
| the-dude wrote:
| Ok, I do see that. Somehow the title does not work for me,
| but that is o.k. I guess.
|
| To get back to your point, I like to call it 'play' ( vs work
| ).
| antirez wrote:
| Yep, the title is not a perfect match with the text indeed.
| I documented our interaction in the post.
| gizeta wrote:
| 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/wi
| ki/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.
| aidenn0 wrote:
| 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"
| john_moscow wrote:
| 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.
| boulos wrote:
| 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? :).
| nakedrobot2 wrote:
| *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.
| pedro1976 wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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."_
| NewEntryHN wrote:
| > 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).
| logicOnly wrote:
| 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.
| nix23 wrote:
| >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.
| sally1620 wrote:
| 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.
| hjntmp wrote:
| 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?
| moron4hire wrote:
| 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.
| ketzu wrote:
| > 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.
| franciscop wrote:
| > 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.
| mceachen wrote:
| > 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.
| ketzu wrote:
| 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.
| franciscop wrote:
| > 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).
| HashingtheCode wrote:
| > A new idea is insinuating in social networks and programming
| communities. It's the proportionality between the money people
| give you for coding something, and the level of demand for
| quality they can claim to have about your work.
|
| This is amazing and revolutionary indeed. Imagine a world where
| people get paid try to produce the best code possible as opposed
| to hobbyists who slap together code just to get the thing
| working. Revolutionary indeed.
|
| Reminds me of this photo: https://i.imgur.com/R9rnmXv.jpg?2
|
| BTW, this is called humour. So downvote if you have none.
| junon wrote:
| 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.
| JorgeGT wrote:
| 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
| antirez wrote:
| NP and thanks for the nice words.
| MaxBarraclough wrote:
| > 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.
| srtjstjsj wrote:
| antirez himself made his living writing open source code for
| redis, until July 2020.
| pjmlp wrote:
| 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.
| nvlanders wrote:
| Open source authors are annoyed, in descending order, by:
| 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 all depends on how you report it. The current opinion, largely
| [1] pushed by people who do little programming but take over OSS
| projects, that bug reporters are oppressed by the bad, bad high
| performing developers is misguided.
|
| It leads to the same dynamics as Mao's cultural revolution, which
| was not really a success.
|
| [1] Not in this case of course.
| l0b0 wrote:
| _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.
| sidlls wrote:
| 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.
| ricardobeat wrote:
| > 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?
| mjw1007 wrote:
| When I file a bug report, I often feel I would like to add a
| disclaimer, along the lines of:
|
| << 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.
| jka wrote:
| 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).
| Gehinnn wrote:
| 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
| pixelrevision wrote:
| 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.
| bickeringyokel wrote:
| Gauging demand can sometimes be useful in planning a project
| can it not? I mean, if the comments are phrased nicer than
| your example.
| noisem4ker wrote:
| On several bug trackers there are structured ways to make
| it known without commenting. On GitHub, at least there's
| thumbs-up reactions.
| spacechild1 wrote:
| 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 :-)
| aaronbrethorst wrote:
| 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.
| dTal wrote:
| >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.
| aaronbrethorst wrote:
| Woulda, shoulda, coulda.
| cxr wrote:
| > 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.
| aaronbrethorst wrote:
| 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.
| hvis wrote:
| > 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).
| djur wrote:
| 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.
| cpuguy83 wrote:
| 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.
| unnouinceput wrote:
| 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.
| kzrdude wrote:
| 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.
| FartyMcFarter wrote:
| 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.
| [deleted]
| pydry wrote:
| 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.
| benibela wrote:
| 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
| sjrd wrote:
| > 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.
| dkersten wrote:
| 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.
| rmrfrmrf wrote:
| 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.
| FartyMcFarter wrote:
| What I had in mind was that "X" included all the relevant
| parameters. An actual runnable command, not just the name
| of a program.
| rmrfrmrf wrote:
| 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?
| djur wrote:
| 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.
| FartyMcFarter wrote:
| 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.
| GordonS wrote:
| 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.
| dancek wrote:
| 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.
| reificator wrote:
| 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.
| GordonS wrote:
| 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.
| eloff wrote:
| 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.
| brigandish wrote:
| > 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.
| GordonS wrote:
| 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.
| formerly_proven wrote:
| 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.
| aidenn0 wrote:
| 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.
| brigandish wrote:
| 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!
| apeace wrote:
| 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.
| franciscop wrote:
| 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.
| mjw1007 wrote:
| 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.
| srtjstjsj wrote:
| 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.
| mjw1007 wrote:
| 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.
| cpuguy83 wrote:
| 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.
| lmeyerov wrote:
| 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!
| cxr wrote:
| 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.
| tzs wrote:
| 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.
| [deleted]
| cpuguy83 wrote:
| 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.
| cxr wrote:
| 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
| cpuguy83 wrote:
| 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.
| cxr wrote:
| "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.
| cpuguy83 wrote:
| 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.
| cxr wrote:
| 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.
| jlokier wrote:
| > 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.
| cxr wrote:
| 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_possi
| ble_wo...
| jlokier wrote:
| > 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.)
| cxr wrote:
| > 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...
| djur wrote:
| 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.
| coldtea wrote:
| > _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...
| coldtea wrote:
| 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...
| Drdrdrq wrote:
| 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.
| atq2119 wrote:
| > 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.
| pessimizer wrote:
| 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.
| tenkabuto wrote:
| 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.
| cinquemb wrote:
| > 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.
| ricardobeat wrote:
| 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?
| cinquemb wrote:
| 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.
| srtjstjsj wrote:
| 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?
| Dean-DAGsHub wrote:
| 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?
| detaro wrote:
| 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.
| mcint wrote:
| Once we're fed, we can contribute to the gift economy, and
| homestead our own place in the gnoosphere.
| jlokier wrote:
| +1 for "gnoosphere". May it be named word of the year one of
| these years :-)
| [deleted]
| Ironlikebike wrote:
| 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.
| srtjstjsj wrote:
| The amateur's work held back by what one can reasonably spend
| without funding.
| frank2 wrote:
| >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).
| srtjstjsj wrote:
| 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.
| frank2 wrote:
| 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".)
| lichtenberger wrote:
| 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 :-)
| josteink wrote:
| 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.
| xfred wrote:
| 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.
| jlokier wrote:
| > 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, resume-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.
| josteink wrote:
| > 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.
| jlokier wrote:
| 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 resume" 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.
| jancsika wrote:
| > 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.
| a1369209993 wrote:
| > > 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).
| srtjstjsj wrote:
| Please don't post flamebait here.
| unnouinceput wrote:
| 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.
| agwa wrote:
| 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.
| coldtea wrote:
| > _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...
| bboreham wrote:
| Maybe we need to distinguish "altruistic open source" from
| "corporate open source"?
| antirez wrote:
| Yes, we need. I call it "indie OSS" vs "Company OSS".
| eternalban wrote:
| 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.
| jka wrote:
| 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.
| CyberRabbi wrote:
| 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.
| srtjstjsj wrote:
| Anything anyone enjoys doing is no better than drug addiction?
| CyberRabbi wrote:
| I never made such a claim, explicitly or implicitly. I think
| you're projecting an argument.
| tracker1 wrote:
| 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.
| fierarul wrote:
| 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.
| cryptica wrote:
| I think Antirez may be just another puppet of the financial and
| corporate elite. Which might explain why he gets so much
| coverage on HN and why his open source projects have such high
| degree of adoption from corporations... And receives such big
| contracts.
|
| He writes a lot of nice uplifting pro-social articles, but
| keeps dancing around the real issues and doesn't do enough to
| really help open source. From first-hand experience, he doesn't
| even bother to answer emails or messages from community members
| or from authors of other popular open source projects.
| ricardobeat wrote:
| 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.
| srtjstjsj wrote:
| Why would someone have to choose between pay and prestige?
| They are mostly independent. Most famous people are rich.
| fierarul wrote:
| Which is why I said stopping open source work is a valid
| option. It's quite hard to untangle yourself from that and
| sometime it seems like money would help.
| indigochill wrote:
| 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.
| astrobe_ wrote:
| 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_.
| Mathnerd314 wrote:
| 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.
| acdha wrote:
| 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.
| [deleted]
| [deleted]
| hjntmp wrote:
| 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.
| ZephyrBlu wrote:
| > 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.
| hjntmp wrote:
| 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.
| ZephyrBlu wrote:
| Contributing "something" isn't that satisfying or
| fulfilling to me, even though it can undoubtedly be
| helpful. Perhaps it's just my personality.
| hjntmp wrote:
| 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.
| srtjstjsj wrote:
| Validation from authority is not counterproductive.
| People who need zero external validation are at risk of
| psychotic behavior because they have no grounding.
| hjntmp wrote:
| 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?
| hjntmp wrote:
| You do that to yourself and of course the system around us
| is not made to acomodate such freedoms.
| fierarul wrote:
| 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.
| hjntmp wrote:
| 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.
| fierarul wrote:
| 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.
| projektfu wrote:
| 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.
| dustingetz wrote:
| Conflict of interests. Also it's in the interests of maintainers
| to understate the value of their users.
| LockAndLol wrote:
| The HTTPS cert for this website points to redis.io . Don't know
| what's up with that...
___________________________________________________________________
(page generated 2020-10-03 23:00 UTC)