Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An open-source maintainer's guide to saying “no”

jlowin.dev

Post reply on HN
Print view View original

41–50 of 95 posts

Re: An open-source maintainer's guide to saying “no”

#41

Post by jddil »

ChrisMarshallNY wrote: post #13

I’ve had some experience developing an infrastructure-level system for use around the world. I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. One of the most important things I did, in that decade, was say “no” a lot. Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times. A lot of requests we…

> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away.

No you didn't.

Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you because you enjoy coding and don't understand how valuable your time is yet.

Re: An open-source maintainer's guide to saying “no”

#42

Post by jonorsi »

Struggling with this right now at my current job as one of four lead devs tasked with implementing our design system with using a React component library.

I am of the opinion that we only theme the components and provide snippets for how to use them for larger UI elements; the rest are of the mindset that we should be building more components in addition to the library for simple things like: a button that has a chevron in it for dropdown menus; a specific component for combining a tooltip with an info icon; a dialog with just an okay button, in addition to the dialog with both cancel and okay buttons; etc. etc.

Just the other day I got flak for saying no to accepting another version of a tooltip that had a different icon -- what's hard about using the tooltip with the icon you want...

Re: An open-source maintainer's guide to saying “no”

#43

Post by BobBagwill »

martinky24 wrote: post #31
ungreased0675 wrote: post #30

What would be an example of a well-designed, useful feature that doesn’t mesh with the philosophy of the project?

“What if we added a GUI based web browser to CURL?”

IMHO a better example is: "Can we make a teeny tiny change to CURL that would allow me to use it as a fetch engine for the GUI web browser I'm making? I can't think of anything else that might use that change, but pretty pretty please?"

Re: An open-source maintainer's guide to saying “no”

#44

Post by LtWorf »

aDyslecticCrow wrote: post #27
serial_dev wrote: post #23

Earlier quoted context omitted.

This was / is not my experience. I worked mainly on frontend code, web and mobile app. As a developer, I got the task, an “order” that something needs to be added. Best case scenario, my product owner / manager came up with it, because they talk to customers and noticed it would be helpful. Worse case scenario, someone else above them told them to do it because “we need it”, and I just hope the product person on my t…

Oof, ye i have heard about this kind of company culture. I think front-end and app development is particularly prone to cheap and dirty iteration. Bugs are cheap and non-consequential. New features are visible, fast to add, and make higher-ups happy. I work in industrial embedded C. So perhaps i have weird expectations about the level of pedantry. A 10 row code change may take week to discuss, and likely require an o…

Yeah frontend don't care about correctness. I've seen entire websites go entirely blank because I clicked somewhere and that triggered a js error and that means delete the whole DOM.

Re: An open-source maintainer's guide to saying “no”

#45

Post by ChrisMarshallNY »

jddil wrote: post #41
ChrisMarshallNY wrote: post #13

I’ve had some experience developing an infrastructure-level system for use around the world. I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. One of the most important things I did, in that decade, was say “no” a lot. Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times. A lot of requests we…

> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…

Sometimes, we do stuff for reasons that folks, these days, can't relate to. I'm truly sorry that you've never had a Cause to which you could dedicate that kind of effort.

No one ever "took advantage" of me. I'm actually kind of hard to hoodwink.

Yes, I did "have to."

If I have to explain, you wouldn't understand.

Re: An open-source maintainer's guide to saying “no”

#46

Post by Seattle3503 »

jddil wrote: post #41
ChrisMarshallNY wrote: post #13

I’ve had some experience developing an infrastructure-level system for use around the world. I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. One of the most important things I did, in that decade, was say “no” a lot. Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times. A lot of requests we…

> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…

Seems like you are saying the same thing as OP, but with a more cynical framing. He set boundaries because he did not in fact have to accept those PRs.

Re: An open-source maintainer's guide to saying “no”

#47

Post by brian_cunnie »

A year ago I changed my CONTRIBUTING document to say that I don't accept pull-requests on my very modest open source project (a special purpose DNS server)

I like coding, but am not fond of reviewing other people's code.

Also, the few PRs I received weren't up to snuff: for example, they included code changes but not tests. If they included tests, they weren't comprehensive. And they never included documentation changes.

Re: An open-source maintainer's guide to saying “no”

#48

Post by joshdavham »

> There is nothing more delightful than the drive-by PR that lands, fully formed and perfectly aligned, fixing a bug or adding a small, thoughtful feature.

I'm actually generally not a fan of "drive-by" PR's.

Unless the drive-by PR is fixing a simple bug in a simple way, then the contributor really should've opened an issue first. Doing otherwise is rude imo.

This is actually open source etiquette that I'd like to see encouraged more in the future. Something like "If you've never contributed to this project before, then open an issue first". I understand that this can be explicitly placed in a CONTRIBUTING.md file, but I think that this should just become common etiquette that we all follow and understand.

Re: An open-source maintainer's guide to saying “no”

#49

Post by NegativeK »

jddil wrote: post #41
ChrisMarshallNY wrote: post #13

I’ve had some experience developing an infrastructure-level system for use around the world. I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. One of the most important things I did, in that decade, was say “no” a lot. Some folks were not happy about it, and Godwin’s Law was invoked on my ass, multiple times. A lot of requests we…

> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…

I agree with the quoted commenter's point that sometimes shit matters enough to put up with the suck, but I also agree with your point that people need to understand that walking away might be the right thing to do.

Finding that balance can be very hard.

Re: An open-source maintainer's guide to saying “no”

#50

Post by ChrisMarshallNY »

NegativeK wrote: post #49
jddil wrote: post #41

Earlier quoted context omitted.

> I had to maintain it, almost completely alone, for ten years, before it was taken over by a competent team, and I could finally walk away. No you didn't. Younger folks reading this, you don't owe anyone free labor. If you want to donate your time to open source that's ok but just know there are thousands of people in this industry that don't care about your mental health and will continue to take advantage of you b…

I agree with the quoted commenter's point that sometimes shit matters enough to put up with the suck, but I also agree with your point that people need to understand that walking away might be the right thing to do. Finding that balance can be very hard.

This is true. I knew what I was getting into. I didn't expect it to be ten years, but I did expect at least five, before I could get folks to pitch in. I knew the character of the folks that would be trying to force the system into shapes that would not last, and how they would react to me.

In this case, it was for an organization that I've been involved in, for decades. I'm incredibly Grateful for what it's done for me, and I'm simply paying it back a bit.

The system was required to help them improve their discoverability, which could be life-saving.

It's not hyperbole to say that the system has probably saved many lives, and will continue to do so, for the foreseeable future.

It's also pretty much worthless, monetarily. No one would be willing to pony up a fraction of what it would have cost to build, if it were paid.

I'd do it all over again, if I had to. Fortunately, I don't have to. The team that took it over have done great things with it. It's a ship of Theseus type of thing. There's probably not much code I wrote, left. I write apps that now leverage it.

Post reply on HN