My boundaries as an open source developer • Hacker News Board

Re: My boundaries as an open source developer

#131

Post by carapace » Thu, Mar 17, 2022, 12:12 AM UTC

lloydatkinson wrote: post #6

Is this person OK? Doesn't seem it. I use single-spa. I'm now worrying about it's future with the sentiments and apparent dislike of users expressed here.

I got the sense that Denning might have some sort of mild anxiety disorder, but I'm not any sort of expert on the subject. It doesn't sound to me like he dislikes users, rather he dislikes certain kinds of interactions. E.g.:

> When something feels like a demand (even a small demand such as “please respond to me” or “please review this pull request”), I often retreat. It is very common for me to take days, weeks, or even months off from open source because I get overwhelmed by the people asking me to do it. I experience a lot of initial anxiety due to the demand, followed by additional anxiety about me delaying my response.

Re: My boundaries as an open source developer

#132

Post by wly_cdgr » Thu, Mar 17, 2022, 12:19 AM UTC

Always good to see an open source dev standing up for themselves, if only a little, against all the entitled freeloaders and techbros who are all too happy to exploit them and to encourage them to continue exploiting themselves

If you build a product that uses open source libraries and you make money off that product, you should pay the people who created the open source libraries, even if they don't expect it or ask for it. Period. It's not a legal question, it's a basic middle-school-civics question of not being a piece of shit. If you can't afford to do that for all the open source libraries you use while still making a profit, you simply don't actually have a viable business model, much like how if you can't afford to tip your server you can't actually afford to go out to eat

Re: My boundaries as an open source developer

#133

Post by duskwuff » Thu, Mar 17, 2022, 12:22 AM UTC

brunoborges wrote: post #128

duskwuff wrote: post #126

Earlier quoted context omitted.

There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.

What I described is what I believe GitHub should support. Not that they support it today.

Right, I mean that there is a (caveat-ridden) workaround as it stands. I agree that repository maintainers should have the option to restrict or disable pull requests, just like they can disable other features.

Re: My boundaries as an open source developer

#134

Post by madeofpalk » Thu, Mar 17, 2022, 12:41 AM UTC

duskwuff wrote: post #126

brunoborges wrote: post #120

Open Source licenses are not about entitlement to contributions, engagement with the maintainers, or even community building. Open Source license is exclusively about the software. But the "Open Source Movement" is blending over, and that's what is burning out so many people on both sides: maintainers and contributors. GitHub's Pull Request feature creates an expectation that the maintainers will read a contributor's…

There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.

GitHub should have an option to disable PRs for a repo, however:

- Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t.

- you can include a readme which can include whatever discouragement you want.

- if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR.

- I’m sure you could trivially have a GitHub action that will auto close all PRs as soon as they’re submitted.

Re: My boundaries as an open source developer

#135

Post by mplanchard » Thu, Mar 17, 2022, 12:49 AM UTC

jeff-davis wrote: post #88

I suggest cultivating a sense of shared ownership. The author is trying to do that, which is great, but it seems like it's not there yet. That's true of open source as well as proprietary development. Do you want other engineers to constantly contact you because you're "the $feature guy"? Or customers to do so? No, you want a process and a team/community.

To be fair, this is really hard. Even finding other people willing to review PRs is difficult, much less people willing to spend the time understanding the entire codebase and being able to contribute to it in a meaningful way.

Re: My boundaries as an open source developer

#136

Post by passivate » Thu, Mar 17, 2022, 12:52 AM UTC

saagarjha wrote: post #102

FooBarWidget wrote: post #49

Earlier quoted context omitted.

> but it does make it sound like unsupported software Pretty much every open source license contains a section along the lines of "there is absolutely no warranty". Older projects make this crystal clear in their readme. Newer, hipper projects don't, but that's only because they don't state it as explicitly. Open source software is unsupported software unless you paid for a support contract. If you still get support…

There’s a difference between “please don’t ask for support” and “I’m happy to support you even though legally you can’t force me to support this”.

Indeed, there is a difference, but it is also quickly forgotten when your production system is down with the boss breathing down your neck.

Re: My boundaries as an open source developer

#137

Post by chii » Thu, Mar 17, 2022, 12:56 AM UTC

rectang wrote: post #90

jenscow wrote: post #87

Earlier quoted context omitted.

Perhaps the developer should have discussed their ideas before investing their time, if they're going to be upset about their unsolicited code being rejected.

The maintainer still has to deal with the negative interaction even if in some cosmic sense the contributor could have known better. A workflow design which ensures that such negative interactions take place is structurally flawed.

what's so negative about pressing the reject button of the PR? The maintainer doesn't have to even spend more than a second rejecting any contributions they get. They don't have to read any of the comments, nor reply to any concerns from the contributors.

The contributors aren't entitled to the time of the maintainers.

Re: My boundaries as an open source developer

#138

Post by brunoborges » Thu, Mar 17, 2022, 1:04 AM UTC

madeofpalk wrote: post #134

duskwuff wrote: post #126

Earlier quoted context omitted.

There is one way to disable pull requests on GitHub: enabling "interaction limits" on the repository. The gotchas are that it disables all interactions, not just pull requests, and it can only be enabled for 6 months at a time.

GitHub should have an option to disable PRs for a repo, however: - Owners are of no obligation to approve, close, merge, or interact with a PR in any way. If you don’t want to merge a PR, just don’t. - you can include a readme which can include whatever discouragement you want. - if you have a CONTRIBUTORS.md file, GitHub will show that to first time contributors when they submit a PR. - I’m sure you could trivially…

All of that imply that contributors will read things before hitting the Fork button.

Re: My boundaries as an open source developer

#139

Post by mholt » Thu, Mar 17, 2022, 1:18 AM UTC

Good on him. I wrote fairly comprehensively about boundaries in open source recently: https://matt.life/writing/the-asymmetry-of-open-source

A lot of principles are familiar here. Love to see it. Open source is no cakewalk, especially without boundaries.

Re: My boundaries as an open source developer

#140

Post by mikepurvis » Thu, Mar 17, 2022, 1:25 AM UTC

yblu wrote: post #124

I used to maintain several popular open-source projects and contribute to even more popular ones. It was always fun at the beginning, especially because I built them for my own needs. But I kept getting asked to fix bugs or improve things even long after my needs had expired. I tried the donation route for a little while but it didn't go anywhere - I received maybe a few hours worth of money (versus hundreds if not t…

I related pretty strongly to this. I've never tried to monetize, and the community I'm mostly working in (ROS) is populated almost exclusively with exactly the sort of kind, considerate people who will happily roll up their sleeves to take a crack at it themselves, given a little guidance.

Nonetheless, there are dozens of effectively abandonware ROS projects out there attached to my name— drivers for some sensor I shipped years ago and haven't touched since, interface libraries that aren't really relevant but don't have a clear alternative, stuff that was never out of the prototype phase and doesn't have anywhere close to the level of test coverage that would let me just merge much less release changes without extensive manual running of it.

I suppose I should go in and just mark them all as archived so that well-meaning people don't file issues (and even PRs) that will never be addressed or perhaps even acknowledged. And in some cases I've just granted PR authors write access and been like "there it's yours now." But none of these end states feel quite right; in all cases I end up feeling guilty and unsatisfied with how it turns out.