[HN Gopher] The burden of an Open Source maintainer
___________________________________________________________________
The burden of an Open Source maintainer
Author : geerlingguy
Score : 114 points
Date : 2022-01-10 15:52 UTC (7 hours ago)
(HTM) web link (www.jeffgeerling.com)
(TXT) w3m dump (www.jeffgeerling.com)
| clock99 wrote:
| BoysenberryPi wrote:
| I'm more interested in how Jeff manages to maintain 200 open
| source repos and still have time for all the other
| extracurricular he does like the graphics card RPi testing he has
| going on. Please tell me your time management secrets.
| geerlingguy wrote:
| Two things: saying no to the majority of time requests (it used
| to be very hard for me, but now I realize the power it gives me
| over my own time), and focusing on one task until it's done (I
| have a few Trello boards and have gotten more religious about
| 'WIP' during my working hours... though I probably hang out on
| HN and Reddit a bit too much still).
| 0xbadcafebee wrote:
| As a user, I feel pain when I use something free that seems like
| it should work, and I invest a lot of my time in making it work,
| and then I run into a bug, and report it, and the bug isn't fixed
| because there's no investment in it. I know it's my own fault for
| trying to use something without paying for support. But I get
| upset anyway, probably because I wasted my own time, and believed
| the unconscious lie that I told myself that using this thing
| [without support] was a good idea. (And even paying for support
| isn't a guarantee a bug will be fixed!)
|
| I develop open source projects too, so I'm intimately familiar
| with both sides. It's a bizarre feeling when I realize I am
| acting (as a user) the same way other users act towards me (as a
| maintainer). I think being a maintainer is a healthy reminder
| that I should lower my expectations as a user of free stuff.
|
| The reason I create open source stuff is there was a problem I
| wanted to solve, and I want to share my solution with others so
| they don't struggle with the same problems. I try hard to make it
| easy for people to use my solution, and I hate the feeling that
| someone might be inconvenienced by using it. I really do want to
| fix all reported bugs. But at the end of the day I have a life
| (and a job) that gets in the way. I feel bad about any bugs, but
| I don't feel bad about taking a long time to fix them, because my
| quality of life is more important.
| geerlingguy wrote:
| I sometimes feel this too, especially if I spend a day or two
| working on a bugfix that feels (to me) simple and logical, and
| then it sits rotting in the PR queue for a few months.
|
| There's a feeling of indignation, but I constantly remind
| myself that on the other end of the PR is a maintainer like
| myself, so I try to remember to bite my tongue and be extra
| nice.
| Shish2k wrote:
| I wonder if we need a middle-class of open source contributor --
| I see a lot of over-worked maintainers, and I see a lot of drive-
| by contributors with interesting half-baked ideas or PRs that fix
| one bug but fail CI tests -- I wish somebody would do the time-
| consuming and boring-but-valuable work of polishing these
| contributions into something merge-worthy...
| pbowyer wrote:
| > I wonder if we need a middle-class of open source contributor
| [...] I wish somebody would do the time-consuming and boring-
| but-valuable work of polishing these contributions into
| something merge-worthy...
|
| We need a valuing of non-coding contributions, and a way of
| welcoming them into projects.
|
| I like building community and dealing with people. I like
| project management, planning, and thinking about funding
| opportunities. I even like (but am not good at) writing
| documentaiton - but only if the author of the code is willing
| to explain _why_ they wrote the code this way rather than get
| me to write how it works.
|
| I haven't come across a project that is open to welcoming
| people who bring these skills. People do these things have got
| to that place through long-term involvement, or because the
| role fell to them. Or no one does it.
|
| A decade ago there was a drive to get designers and UX people
| involved in open source projects [0]. It came to little, to the
| detriment of the entire open source community. Writing code
| isn't the only skill important in a project, and if we embrace
| that the whole experience of using the framework, library or
| software improves.
|
| 0. https://markboulton.co.uk/journal/design-in-open-source/
| alice-i-cecile wrote:
| I'm doing this role over at Bevy[0]. Docs, project
| management, and mentorship (plus my technical contributions).
| It's incredibly valuable for the project, and has allowed us
| to scale up to hundreds of active contributors in less than
| two years. We do our best to welcome and encourage other
| folks in the same sort of role; there's always more PR
| reviews, issue management and community building to be done.
|
| Incidentally, this work has led to an official role with the
| project, tons of professional experience and contacts, and
| some well-paid consulting gigs. I have a _very_ strange and
| spotty resume due to health issues, so it 's been frankly
| life-changing.
|
| [0]: https://github.com/bevyengine/bevy
| pc86 wrote:
| Not trying to be tongue in cheek but isn't it easier for
| everyone just to reject the bad PRs like that?
| webmaven wrote:
| _> Not trying to be tongue in cheek but isn 't it easier for
| everyone just to reject the bad PRs like that?_
|
| Sure, especially if your (meta) goal is minimizing individual
| maintainer effort. But if you want instead to maximize
| maintainer and contributor _return_ on effort (counting both
| the originator and the polisher as contributors), a different
| approach may be called for.
|
| Maintainers "just" need to figure out for themselves not just
| how much work they are willing to put in, but what sort of
| work, and what work (if any) they are able and willing to
| delegate or offload onto others.
|
| For a maintainer who isn't willing or able to do the work of
| polishing contributions or handholding potential
| contributors, and doesn't have anyone they trust that is
| willing or able to do that work, rejecting most PRs (and even
| issues, for that matter) outright can be an entirely valid
| approach.
|
| Open source success and sustainability don't look the same
| for every project or for every maintainer.
| indymike wrote:
| "I'll recommend they fork the project"
|
| This is really the right answer a lot of the time. The first few
| times I submitted a PR and got rejected or ignored, I took it
| personally. Then a maintainer explained it to me (ran into him at
| an in-person meetup), and it was very similar to Jeff's
| explanation here. Also, what makes it really hard for maintainers
| is that a lot of the requests they get are from people who don't
| have the ability or desire to fork the project (and even less
| ability/desire to maintain the fork).
| tomcam wrote:
| First off, my sympathies and awe go to someone with that much to
| give. Thank you, Jeff.
|
| Second... I desperately want a post describing how one person
| maintains 200 projects! Wow!
| geerlingguy wrote:
| The cynical take is that said maintainer doesn't really
| 'maintain', but rather 'lets rot'.
|
| The optimistic take (and what I prefer to believe) is that if a
| project works, and solves the problem the maintainer wants it
| to solve, it doesn't need to be changed unless/until it breaks.
| lostapathy wrote:
| I agree with your optimistic take here. A lot of people are
| reading the "200 projects" and assuming they are all big
| projects. On the contrary, a lot of your projects seem to
| keep a very narrow focus that allows them to get to a state
| of "done for now" even is nothing is truly ever finished due
| to upstream and downstream changes around the project.
| PragmaticPulp wrote:
| > I maintain over 200 open source projects
|
| That's just a little bit beyond what the average open source
| maintainer has on their plate.
|
| Regardless, the attitude of recommending that people fork a
| project if they really need something is the way to go. It's okay
| to say "no" to an influx of requests and demands. The maintainers
| who burn out the fastest are the ones who view every comment,
| suggestion, request, or piece of feedback as equally important.
| It's okay to let something be your personal project and not let
| the community take a sort of control over your time.
|
| Do it long enough and you will develop a thick skin, if only out
| of necessity. Open source will expose you to some of the nicest,
| smartest, most thoughtful people you've ever worked with. It will
| also expose you to some of the most demanding, manipulative
| people who will use every social pressure technique they know to
| try to make you feel _bad_ about not doing exactly what they
| want.
| duxup wrote:
| It seems like the Open Source ethos also could also use some
| additions like:
|
| 1. How to maintain a healthy approach to your popular code.
|
| 2. How / why to say no without looking like the jerk.
|
| 3. How to find / manage help when you need it.
|
| Handy skills for life too...
|
| Granted plenty of folks do it very well, but there's nothing
| about Open Source that necessarily provides any of that and
| some folks who love to help, share, and solve problems fall
| into bad places.
|
| That also leads me to wonder how much complexity for most
| projects is even needed. I kinda wonder if for most projects
| maybe 90% of the people using the code use it for a handful of
| tasks, and yet the vocal loud folks demanding more are a very
| small minority...
| latchkey wrote:
| After ~25 years of open source and regretting a lot of my
| earlier behaviors as a younger human, a couple years ago I
| created another open source project [0].
|
| I made a point of setting it up right from the beginning.
| Easy build system, fully unit tested, code of conduct,
| automated CLA signing, examples, good documentation and most
| importantly, I am excessively kind to anyone who comments or
| gives feedback. This took an inordinate amount of time up
| front, but was worth it.
|
| I'd say the result of this is that I've gotten a couple high
| quality contributions, zero stress and very very little
| feedback. It has been a pleasure to maintain this project
| because it causes me no pain at all.
|
| I'd say that maintaining 200+ projects is just insane really.
| You've overdone it. It is impossible to do any of them
| extremely well and of course you're just going to invite 200x
| more drama. Don't do that.
|
| [0] https://github.com/lookfirst/mui-rff
| duxup wrote:
| >I'd say that maintaining 200+ projects is just insane
| really.
|
| Yeah I don't want to call out the writer or anything
| because I don't know but that ... that number worries me.
|
| Unless we're talking about one off packages nobody uses,
| can only do so much well.
| j1elo wrote:
| > _Despite how much some people detest the stale bot [...]_
|
| I _detest_ the stale bot :-)
|
| And I really think it only is a disservice to the project, 99%
| times I see it used. If the code has a _genuine, real defect_ ,
| it will not "go away" magically just because nobody complained
| again, or the authors didn't have time to look on it.
|
| See, the issue _is there_. Don 't have time? Ok leave the issue
| open, it acts as a documentation about, well, that _there is an
| unsolved issue_.
|
| I really hate when googling about some problem and then finding a
| promising bug tracker conversation that then... got comments
| closed because of old age. That's literally swiping the problem
| under the rug.
|
| Now regarding burnout and burden of OSS maintainers, I might lack
| a bit of empathy here, but I just don't get it. Really the
| license text says it all: THIS PROJECT IS OFFERED AS-IS. Most if
| not all OSS licenses have a phrase like this. Just quote those
| words 100 times if it's needed. My mental health as an OSS
| maintainer is very well and I cannot see it being changed by
| some, even lots, of demanding users at any point. Every time
| someone takes my code and uses it, there is an implicit
| conversation where I go "hey, here you are take this work for
| free, I'm lending it to you AS-IS, do whatever you want with
| it!". Absolutely at no point in time I feel pressure about
| defects in the code, after having this imaginary conversation.
|
| I guess we need more spreading of the notion of "not giving a
| sh*t" so the idea gets extended to more and more OSS maintainers,
| helping them have a happy life not encumbered by the work they
| decided to release by sheer goodness. EDIT: with this last phrase
| I mean that one should have the mentality of contributing up to,
| and not more, what one is able to do within their own limits. The
| "not caring" I mention is for _after_ reaching this limit: it
| will help not pushing through the burnout line, and thus as a
| result being happier in the long term.
| skybrian wrote:
| A bug report is an observation about a particular version. If
| nobody bothers to test newer versions, _you don 't know if it's
| real._ The more the code changes, the less likely the behavior
| is still there.
|
| Now, granted, it's likely that if nobody did anything then it's
| still broken, but it's still the case that a bug database,
| considered as documentation, gradually becomes outdated and
| increasingly misleading if not maintained.
|
| Stale bugs are still in the database and you can still query
| them. Nothing is lost. The question is how relevant old history
| is when it comes up in search results?
|
| Maybe querying on open bugs only is the wrong default? Stale
| bugs should probably be included but with much decreased rank.
| j1elo wrote:
| I agree with this, too. Which opens up a nice point of
| discussion: closing stale bugs is bad because it sweeps the
| issue under the rug; but closing them is good in case the
| context and source code around the issue has changed a lot.
|
| In this case I'm not sure what's the best solution. I have
| suffered myself finding an open bug but so old that it didn't
| really apply any more. However in those cases, it has
| happened that attracting attention from a dev, or just
| testing by myself, has driven the conversation into quickly
| realizing that the issue didn't apply any more with current
| state of the source code...
|
| Maybe it's a good idea having the feature of specifying which
| version the bug was reported against. GitHub doesn't have
| this, but I've seen it in some other bug trackers.
| toast0 wrote:
| In an ideal world, someone would go over the open bugs on
| some timeline and mark them as no longer an issue, still an
| issue, don't know, or won't fix. An easy timeline to
| specify would be take a look 3 months after last activity
| and double the wait every time.
|
| Of course, that takes time and effort and some bugs are
| harder to evaluate than others.
| watwut wrote:
| Overwhelming majority of closw as stale bugs are existing
| bugs no one commented about last X months. They did not
| magically went away.
|
| They are still there, exactly as described.
| corndoge wrote:
| Your latter point doesn't make a lot of sense to me. I write
| and maintain open source software because I enjoy seeing people
| use it. For me, not giving a shit about it means not working on
| it at all. It seems like it's as easy as keeping "no FITNESS
| for a PARTICULAR PURPOSE" as a mental mantra but in reality
| that just doesn't work for me. And I bet I'm not so different
| from most foss maintainers.
| j1elo wrote:
| > _it 's as easy as keeping "no FITNESS for a PARTICULAR
| PURPOSE" as a mental mantra_
|
| It definitely is. Of course OSS authors and maintainers want
| to see people using and enjoying it, but nothing is black or
| white.
|
| What you really mean is that you want people using and
| enjoying your software _within the limits of time and
| abilities that you can employ on it without it affecting your
| mental health_.
|
| Some people are worse than others at finding out about this
| latter part, and as a consequence they suffer.
|
| My point of view is that if you don't care as default state,
| _then_ you put work into actually caring, when you get to
| your limit you 'll be able to very easily see that you cannot
| contribute any more hours today, because you're almost
| depleted how much you actually care. Thus avoid crossing that
| thin line that is burnout and all mental health issues that
| come with it.
|
| I.e., be in a defensive mental state. Ironically, it will
| make you work happier and over a longer period of time, which
| ends up being positive for the health of the project itself.
| corndoge wrote:
| > It definitely is
|
| I just told you that for me, it's not. Repeating your view
| isn't adding anything. Restating it doesn't make it so. I
| understood you the first time.
|
| > My point of view is that if you don't care as default
| state, then you put work into actually caring, when you get
| to your limit you'll be able to very easily see that you
| cannot contribute any more hours today, because you're
| almost depleted how much you actually care. Thus avoid
| crossing that thin line that is burnout and all mental
| health issues that come with it.
|
| I completely believe that's how the mental process works
| for you. That's not how it works for me. If I detach myself
| from the project enough to not let it affect my mental
| state then I do zero work on that project.
| j1elo wrote:
| I see. Not being able to detach your mental process from
| an overburdened project probably means that you are more
| prone to suffer the kind of issues discussed every time
| this topic is brought up. Caution is advised, I guess.
|
| You might be able to perfectly handle your OSS projects
| despite of this tendency, you probably have your own
| complementary techniques (like limiting the number of
| simultaneously accepted PRs at any given time? I'd be
| interested if you want to share any), or if a bad wave of
| burden arrives one day, you might end up burning out and
| either throwing the towel or growing a thicker skin.
| Hopefully the latter!
| pictur wrote:
| "See, the issue is there. Don't have time? Ok leave the issue
| open, it acts as a documentation about, well, that there is an
| unsolved issue."
|
| I think this is really important. In some projects, the number
| of open issues is always zero. Most people see this as a good
| thing. I think it is not. we need projects where there are
| hundreds of open issues and these issues are visible. it is
| important to solve problems if they want to be followed
| clearly. I think it is a very important issue to be able to
| follow up the problems clearly.
| b3morales wrote:
| Absolutely. If nothing else, the issue report establishes a
| findable, centralized location for users to share workarounds
| with each other.
| kibwen wrote:
| If you don't like how some open-source library is managed, then
| exercise your freedom to fork it. Anyone who then claims that
| they don't have the time or energy to maintain such a fork
| cannot also reasonably expect anyone else to spend their own
| time and energy maintaining it for them.
| Aethylia wrote:
| It isn't more work for the maintainer to _not_ close issues
| purely based on time. This argument has been repeated often.
| And with the prevalence of lazily-used stale bots, it's not
| feasible for anyone to make all the forks necessary.
|
| Discussion can eventually lead to a shift, repeating this
| argument can't.
| kibwen wrote:
| _> It isn 't more work for the maintainer to _not_ close
| issues purely based on time_
|
| This overlooks the emotional burden of having a large,
| unbounded backlog.
|
| When I see that I have a missed call, I feel an obligation
| to call that person back. When I see that I have a text, or
| a DM, or an email, I feel an obligation to respond.
| Individually these are all minor obligations, but in
| aggregate they eventually coalesce into anxiety. PRs, too,
| get thrown onto this pile.
|
| Burnout is a self-imposed "boiling the frog slowly"
| scenario caused by gradually taking on more responsibility
| than you can successfully deal with. Realistic ways to
| prevent burnout are by either aggressively preventing new
| obligations from being thrown onto the pile, or by
| periodically defaulting on obligations and resetting the
| pile entirely. It appears to me that the stale bot is an
| instance of the latter. An instance of the former would be
| to just outright forbid PRs entirely.
|
| And if anyone thinks that they have the mental fortitude to
| handle an ever-growing and unbounded pile of obligations,
| then that only reiterates the call for them to fork these
| projects and accept the burden personally.
| BeFlatXIII wrote:
| I've solved that problem by being one of those people who
| never calls back or checks voicemail. At some point, I've
| got 75 e-mails to mark as read and delete today.
| AnIdiotOnTheNet wrote:
| If I encounter a bug in a thread closed by a stalebot, my
| natural conclusion is that the developers have no intention or
| desire to ever fix the bug. This usually leads me to searching
| for alternatives rather than wasting my time re-reporting it.
| geerlingguy wrote:
| I mark bugs, security-related issues, and planned features with
| appropriate labels, and the stale bot ignores those:
| https://github.com/geerlingguy/ansible-role-docker/blob/mast...
|
| Not all maintainers do the same. And some even _lock issues_,
| which I hate, because even closed issues can have a very
| fruitful discussion long after the issue was originally posted.
| j1elo wrote:
| Then you are, in my humble opinion, doing it _exactly right_
| :-) (apart from going all-in and just never closing anything,
| but yours is a very good middle ground)
|
| > _even closed issues can have a very fruitful discussion
| long after the issue was originally posted_
|
| 100% agree! In some occasions I've learned a lot from reading
| long related conversations in a bug report that had been
| closed or resolved long since.
| cube00 wrote:
| While everyone is free to maintain their projects as they wish,
| you don't necessarily need to maintain this level of control.
|
| As the project gains traction you'll develop a community of
| trusted developers around you and you could consider granting
| commit access to some of them to help reduce your workload.
|
| It can also reduce the stress of feeling that you'll be blamed if
| something goes wrong and it becomes more of a community effort
| which is one of the benefits of open source.
| canyonero wrote:
| I really liked an article on the subject of sustainability in
| open source by Dave Rupert. See
| https://daverupert.com/2021/12/sustaining-maintaining/
|
| One of the of the points Rupert drives home is that open source
| with the goal of sustainability doesn't have a framework in place
| that doesn't lead to burnout. Everyone just learns lessons the
| hard way without any real manual for successful outcomes.
| ozim wrote:
| Why there should be sustainability built in?
|
| Not everyone should be publishing their code and definitely not
| everyone should be OSS maintainer.
|
| From what I see and how I look at things, people think it "fun"
| or "cool" and don't understand full picture of what it really
| is to be OSS maintainer.
|
| I also don't think that simply more OSS is better - while yes,
| corporations should share more, software written with taxpayers
| money should be open - but randoms from around the globe should
| keep their leftpads for themselves and their friends.
| janfoeh wrote:
| I wholeheartedly disagree with your underlying premise of
| what open source is or should be.
|
| It's not a job.
|
| It's not a resume.
|
| It's not a damn lifestyle or an in-group to define yourself
| through.
|
| It's a way of saying _" I wrote this. I allow you to look at
| it and use it for yourself, if you like"_. Nothing more,
| nothing less.
|
| > randoms from around the globe should keep their leftpads
| for themselves and their friends.
|
| That seems like a bizarre inversion of responsibility to me.
| Randoms can publish whatever they please; if you use their
| left-pad, that's on you and you alone.
| ozim wrote:
| If it is not a job then why people are getting burned out,
| why people nag about not getting compensated?
| canyonero wrote:
| > Why there should be sustainability built in?
|
| I don't think it should be built in by default to any
| software that is released open-source. But, I do think having
| guidelines for how software can be developed in such a way
| that doesn't lead to burnout.
|
| The linked article pertains to avoiding the path to burnout,
| which if you are sharing code that an author a.) expects to
| "own" and maintain and b.) hopes other people will use, then
| you need should educate yourself as to how this can be
| achieved. Good literature on the subject is limited IMO.
|
| > Not everyone should be publishing their code and definitely
| not everyone should be OSS maintainer.
|
| I partially agree with this. I do think not everyone is up
| for the task of OSS maintenance and development, some of
| which is likely stemming because they don't have a good
| framework for how to do so sustainably.
|
| I do think anyone should be able to freely publish their code
| if they like. Sometimes folks want to share things for fun or
| education or demonstration purposes, when they don't intend
| to accept or want PRs or contributions or downstream
| consumption or maintain it. There is value in OSS for many
| different reasons. I think GitHub in particular does a poor
| job of signaling to readers which software is sustainable and
| which is not.
| ozim wrote:
| > I do think anyone should be able to freely publish their
| code if they like. Sometimes folks want to share things for
| fun or education or demonstration purposes...
|
| I do agree that anyone should be able to publish, but then
| should also consider bigger picture when "stars", "likes",
| "downloads" are rolling in.
|
| As noted there are no materials that show what is it like
| when you have to work on something for years because you
| built expectations in others.
|
| Just like kids want to be youtubers and then youtubers were
| all "burned out" because yt algorithm will take away their
| likes if they are not on top of the things all the time.
| lol768 wrote:
| I honestly detest stalebot - if you don't want to keep on top of
| your projects' issues/PRs, fine - but don't artificially and
| automatically close issues that explain very real limitations in
| your project just because _you_ don 't have the time to look at
| them. If you do that, you rob the next _n_ visitors the ability
| to understand what works and more importantly what _doesn 't_
| work at a glance, from the open issues/PRs list.
|
| That security vulnerability or bug isn't going to vanish into the
| ether because a "helpful" bot closed the issue. It'll still be
| there - but it'll get lost in every other closed issue.
|
| I will happily just comment on the issue every single time the
| bot closes it out of spite to force it to be re-opened. Hell,
| it's probably overdue someone writing an anti-stale-bot that does
| exactly that.
|
| Related: https://drewdevault.com/2021/10/26/stalebot.html
| geerlingguy wrote:
| If there is a bug, I typically mark it with a `bug` label, and
| I configured stale bot to ignore those issues, so they do
| remain open: https://github.com/geerlingguy/ansible-role-
| docker/blob/mast...
| lostdog wrote:
| Really stalebot shouldn't close issues. It should put them into
| a "stale" state, where they still exist for users to read, but
| are filtered out when maintainers look at a list of issues with
| the project.
| blakesterz wrote:
| I just want to give a BIG thank you to geerlingguy. I use a
| couple of your Ansible roles and they're great! It's amazing how
| much work you put in and it's most appreciated!
| mrtksn wrote:
| A developer creates a work, gives it for free(in writing) and
| receives fame and applause by the terms of the social contract.
|
| When the products turns out to have problems, an issue arises
| between the supplier of the product and the supplier of the fame
| and praise.
|
| I think that's why people feel entitled to customer service. If
| the developer fails to provide a good customer service, the users
| demand refund, that's why it feels very similar to regular
| customer support.
|
| In fact, the users of the free software can often be much more
| demanding. Maybe they are rightfully so, since they paid with
| social capital that is limited, precious thing - unlike money
| that can be earned in by doing work for a bit.
|
| The pain as a result of the product failure is also the same, it
| doesn't matter if you paid for it by a monetary transaction or
| tapping the like button. Even if you haven't done anything
| directly, you inflated the developers stats - which are the main
| KPI anyway.
|
| IMHO, if someone wants to make money from their work they should
| explicitly charge for it. You can't expect to receive all the
| street cred for giving away your work for free and also receive
| money for your work. The maintenance is simply, street cred
| maintenance.
|
| Many years ago I learned my lesson for giving stuff away for
| free. It's tough to sell your stuff in exchange for a reputation,
| the demands of the customer never ends. Your part in the deal is
| also not clearly defined, you are expected to fulfil your
| obligation by working on every single request no matter what is
| the scope and if you fail to do that your free users will be mean
| as if you scammed them.
|
| edit: Sorry for not being able to reply to you all but my account
| seems to be rate limited. Unpopular opinions have consequences I
| guess. Shouldn't hold them.
| [deleted]
| White_Wolf wrote:
| I'm not sure about others but when I publish a piece of
| software or script it's because I needed it for something and
| I'm done working on it for my needs. If someone has different
| needs than mine they can DIY or pay someone to do it.
|
| If anyone else needs it, they are free to copy and use it. If
| they find a problem that I think needs fixing or my stuff will
| cause me problems, I'll fix it. Otherwise, they are free to fix
| it and(if kind enough) submit it.
|
| I have 0 obligation to fix anything that I don't personally
| need and anyone that copies it has 0 obligation to give me
| anything in return. I only published it to save someone else
| the time for the bulk of the work. I'm not doing it for money
| or cred. I do it because it's something I already finished(more
| or less) and it won't cost me anything to share. Anyone elses
| needs(family and friends exempt) are not my problem unless It's
| my (paid) job to make them my problem.
| mrtksn wrote:
| But why upload it to Github or somewhere similar, do the
| marketing(a README that often promises something like
| enterprise ready Atomic transactions) and licensing?
|
| If the work was to fulfil your own needs it would have been a
| private repo or a folder in your drive.
|
| The moment you publish it, a social contract is established
| similar to creators of other free work like youtube videos
| etc. You receive cudos and fame, they receive a tool,
| entertainment, knowledge etc. When you fail your part of the
| contract, people can be very mean as the are mean on a
| Youtube vide that they don't like.
| andrewzah wrote:
| No. No. No.
|
| There is no such thing as this "social contract".
|
| I publish software on github with MIT or (A)GPL licenses
| for various reasons:
|
| * In case someone else has the same issue I did
|
| * In case someone is working on something similar and wants
| to learn from my code
|
| * As an external backup in addition to my hard drive /
| private git repo / etc.
|
| * Because I can. (deal with it.)
|
| There is NO expectation or "contract" or anything. People
| can open issues or politely request things, but getting
| upset or pushy over F/OSS released on someone else's own
| terms is just entitlement.
| mrtksn wrote:
| I'm sorry but there's a social contract. It's implicit,
| the moment you participate in a society the expectations
| from you and obligations towards you begin.
|
| Even if someone asks you the directions to the gas
| station, you are expected not to deceive them and give
| them the best instructions to you your ability and they
| are expected to show some appreciation for helping out
| the society. You will face backslash if you don't help a
| fellow human or deceive them despite the fact that you
| are not receiving direct payment for your act.
|
| Imagine you put a sign that says "The mall is in this
| way" and the sign is not entirely correct. It was a free
| sign, no one contracted you to put that sign but if it
| happens that your sign wastes someones time you will
| receive negative feedback and probably requests to
| correct your sign.
| hyperman1 wrote:
| There is an assumption not to be an asshole. But that's
| where it ends. If an endless stream if cars likes your
| directions, they can't expect you to keep standing where
| you are, giving each of them directions.
|
| In the same way, if someone posts some code you can file
| a bug or give a patch, but that doesn't entitle you to
| anything from the original author. Maybe you helped him
| making the code better and you're scratching each other's
| back. Maybe the author is just extra nice to you. But
| just because you've received a gift, you're not entitled
| to more gifts.
| webmaven wrote:
| _> There is an assumption not to be an asshole._
|
| I think some of the disagreement in this thread is just
| over whether someone is being an asshole if they leave
| buggy code lying around with no warnings attached, and
| rejecting /ignoring requests to remedy the situation.
| andrewzah wrote:
| In my opinion, there is no expectation for someone to
| accept your requests or PRs. It's definitely not the
| norm, but I reserve the right to not do anything that I
| don't want to do. You don't know someone's life situation
| or current goals; that library or tool may work fine in
| their use case or they don't have the time/desire to
| implement a fix or review a PR.
|
| That's why forking exists.
|
| That's the risk of pulling in external libraries from
| random developers. Unless you're willing to put money
| where your mouth is, then all you reasonably can do is
| politely request a fix or for them to merge your PR.
| andrewzah wrote:
| I'm not talking about society in general. I'm talking
| about random F/OSS projects on github. There is zero
| expectation when looking at someone's project from afar.
| webmaven wrote:
| > There is zero expectation when looking at someone's
| project from afar.
|
| Let's say I release some code that is isn't fit for
| purpose. For example, it corrupts user data 5% of the
| time.
|
| The code has a README that doesn't mention the issue, and
| I close all issues that refer to the problem. I also
| reject any PRs that try to fix it, and so on. I don't,
| however, disable issues or say the code is unmaintained,
| so there is a steady stream of people whose data gets
| corrupted when they download and use my code.
|
| Since you don't seem to like the term "social contract",
| would you at least admit that I am violating a few norms
| and acting like an asshole?
| pjmlp wrote:
| You are free to fork it, fix the corruption issue and
| uphold the social contract of your fork.
| webmaven wrote:
| _> You are free to fork it, fix the corruption issue and
| uphold the social contract of your fork._
|
| The freedom to fork (for any reason) is orthogonal to the
| question of whether the maintainer is being an asshole or
| not.
|
| Of course, people are also free to be assholes (for any
| reason). But it shouldn't be controversial to say "don't
| be an asshole".
| echlebek wrote:
| No there isn't. The software is provided as is, without
| warranty, express or implied. This is critical to
| understand.
| Hasu wrote:
| You sure are reaching really far to claim that someone
| giving you something for free owes you even more.
| AnIdiotOnTheNet wrote:
| Maybe I am misreading them but I don't quite think that's
| what they're saying so much as "you can't market your
| free product to other people as something they can and
| should be using, and then turn around and tell them to
| fuck off when they come back with complaints that it
| doesn't live up to those claims".
|
| A _lot_ of open source projects seem to do this. If you
| make it clear your project is just something you found
| useful and others might too, then I don 't think anyone
| really has a complaint about that.
| [deleted]
| hitekker wrote:
| I agree. There's a kind of social-transactional element to Open
| Source that people don't like to talk about. Like, chasing
| clout instead of dollars. If you're a committed maintainer who
| writes a lot of packages and sacrifices a lot of your free
| time, chances are you have some self-interest in the mix.
|
| The illusion of universal altruism probably helps insulate
| people from thinking about the uncomfortable politics of Open
| Source.
|
| I'd like to read an article covering your insights.
| pure_simplicity wrote:
| I think this mindset is fundamentally wrong on multiple levels.
|
| 1. There is no contract, not even implicitly, that promises
| software maintenance in exchange for praise. The praise may be
| a motivating factor for the developer, but anyone who thinks
| they are entitled to anything just cuz they showed some
| appreciation has not read the Open source License, which almost
| always states the software is provided as is without
| warranties.
|
| 2. Genuine praise is not transactional. The only factor
| affecting praise or criticism should be merit. Any other quid
| pro quo makes praise into hollow lip service, meaningless
| fungible gibberish uttered for personal gain. Praise is more
| like a donation than a payment.
|
| 3. Even if praise/fame somehow could function as currency, then
| any individual is not providing enough of it to earn themselves
| any significant privileges. Maybe in aggregate the community
| would have a 'claim' (if the developer agreed to this
| contract), but even then the obligations incumbent on the
| developer would be limited and unclear, because no one person
| can speak on behalf of the community and for most projects
| their community does not organize itself in such a way as to
| permit concerted group action that can be recognized as the
| will of the community.
|
| 4. if you feel like you have been robbed of your praise, you
| simply withdraw it or voice criticism. Or you recognize that
| your praise was still applicable and valid to the parts of the
| project that you were aware of at the time of voicing your
| opinion, so therefore is still deserved. If you think you
| provided more praise than is merited by the project, then
| that's an error in judgment on your part. No one asked you to
| proclaim project [projectname] the best thing since sliced
| bread and the hope of humanity that is literally gonna change
| the world. Just be more careful with who you choose to praise.
| mrtksn wrote:
| See, no one is suing you when you don't help people or don't
| maintain your work. They simply say bad things about you and
| your work, the exact opposite of the "payment" your receive.
| It's practically a chargeback.
| ahelwer wrote:
| Not sure about this model. I write open source software because
| of the inherent human desire to create. Benefits from
| admiration I receive comes a distant second to the happiness of
| exploring a problem then crafting a nice solution, on my own
| time, in my own way. In a lot of ways, working without
| compensation then freely releasing the output is weirdly
| selfish. It is appealing because you are so free from the
| obligations to others brought by getting paid.
|
| Users might invest time in using your software, and it is this
| time they feel robbed of when things go awry. I have been on
| both sides of this. I used to become very angry when something
| doesn't work right out of the box after quickly skimming a
| setup tutorial. At the time I was working for salary. Any free
| time I had was very valuable and couldn't be sucked up doing
| the same thing I do at work - debugging config issues, retrying
| with different options or environmental changes, etc. It was
| only after becoming a part time independent contractor that I
| developed the patience to really deal with open source
| software. To feel I had enough mental energy to really read the
| documentation or look inside the source code and debug what's
| going on - totally different from the customer service
| experience of dealing with proprietary software.
|
| People become frustrated when the effort needed to understand
| or deal with something is beyond what they are willing to put
| in. I don't think open source can escape its problems until a
| substantial portion of users have the time and energy to really
| engage with it. We should be working far fewer hours than we
| actually do.
| mrtksn wrote:
| I agree, the work comes from desire to create but I think the
| public github repo and the promises you give to the potential
| users comes from the desire to receive praise and cred for
| your work.
|
| From the users perspective, the joy and the pain is the same
| as with the paid product. If you promised them something and
| underdeliver, they feel scammed.
| rockbruno wrote:
| >fame and applause >Maybe they are rightfully so, since they
| paid with social capital
|
| I'm sorry, but I think you're exaggerating a lot here about the
| worth of "fame" in something as niche as writing open source
| software. It's like when people try to pay artists with
| "exposure" -- flashy, but worthless in every imaginable way.
|
| Case in point: The creator of Homebrew who famously failed to
| get a job at Google despite having all "street cred"
| imaginable.
| BeetleB wrote:
| > A developer creates a work, gives it for free(in writing) and
| receives fame and applause by the terms of the social contract.
|
| There is no "the" social contract. There are many social
| contracts, and they are not all compatible with one another.
| The whole point of written, legal contracts is due to a
| recognition of this fact.
|
| I don't abide by that (or any) social contract when I put
| something on Github, and nor should I. When I say that I can't
| guarantee this code won't cause harm (e.g. destroy HW or files
| on your HD), I mean that. If you want to labor under unspoken,
| unwritten contracts, be my guest.
| webmaven wrote:
| _> When I say that I can 't guarantee this code won't cause
| harm (e.g. destroy HW or files on your HD), I mean that._
|
| Okay, but imagine for a moment that you _don 't_ say that.
| The README is silent on the issue of potential problems. Are
| you violating any social contract then?
|
| Or suppose an issue is reported to you. You don't feel like
| fixing it, close the issue, and even delete it, and don't add
| a mention of the problem to the README. Are you violating any
| social contract at that point?
|
| If you don't like the term "social contract", would you agree
| that you would be violating some norms?
| BeetleB wrote:
| Of course I'm violating _some_ contract /norm. I am also
| conforming to _some_ contract /norm. That was the whole
| point of:
|
| > There is no "the" social contract. There are many social
| contracts, and they are not all compatible with one
| another.
|
| Similarly, those expecting my code won't cause damage are
| also violating certain social norms.
|
| The code is there for anyone to do what they want with it.
| Do with it what you will, and own the consequences.
|
| > Or suppose an issue is reported to you. You don't feel
| like fixing it, close the issue, and even delete it, and
| don't add a mention of the problem to the README.
|
| My Github repositories are very low in importance on my
| list of important things in life. I reroute most
| notifications to a folder and will go through that folder
| only a few times a year, so I likely won't even know about
| any such issues for months.
|
| Now personally, I do put a disclaimer in the README stating
| that people should view the code as unsupported and
| unmaintained (even though I do update the code from time to
| time), but I do it merely as a courtesy, not as an
| expectation. I do not at all endorse that people _should_
| put such disclaimers.
| [deleted]
| flucivja wrote:
| I wonder if OSS world needs kind of Spotify/Netflix platform for
| OSS distribution. If I would put in analogy OSS Developers to
| Music authors and songs/albums to OSS projects then such
| distribution platform would be paying developers depending on how
| much their project is used and maybe some other criteria and
| everybody who would like to use some OSS would need to pay
| monthly subscription to that platform.
| lomereiter wrote:
| You are describing Tidelift (https://tidelift.com/) except the
| bit where the users would "need to pay" - although that could
| be addressed e.g. via regulations for enterprises but not
| individuals.
| pjmlp wrote:
| They had it back in the day with stuff like the Walnut Creek
| CD-ROM distributions.
|
| In the long run, the only monetary solution is to go back to
| some kind of PD/Shareware, which is what all those public core,
| commercial full solution end up being.
|
| 30 years ago we called those public core parts, playable demos.
___________________________________________________________________
(page generated 2022-01-10 23:02 UTC)