Posted by jlowin 11 hours ago
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 were ones that would optimize for a specific use case, but it was a generalist system, so it had to remain “imperfect.”
In the end, it all worked out well, if not “perfectly.” It’s now a worldwide system, being run by hundreds of organizations, and used daily, by thousands of people.
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.
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.
That is very different from being exploited or taken advantage of.
Finding that balance can be very hard.
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.
It is public.
Happy to share it one-on-one.
> thanks for a great project, in our org we have a requirement that we only write files, not read them. Can you please add —-write flag so this app works for us?
The fact that someone clones your repo or uses your software doesn’t mean that you owe them anything. Every person with open source code should realise this before they start responding to feature requests.
As if open-source maintainers don't have enough chores.
Also I don't hesitate to be frank in my review, it's okay to say "I won't merge your feature because I don't think I can maintain that, but you're free to keep your fork". Or "I can merge it if you change this and this", but in that case I need to actually merge if they do what I asked for.
If it’s obvious without a shadow of a doubt that someone has lied, either on an issue or a PR, I’m very much inclined to block them. I have a lot of patience for people who are still learning or make silly mistakes but are genuinely making an effort; but if someone doesn’t even help me help them, that’s disrespectful and such behaviour shouldn’t be rewarded.
I've not maintained or worked much with open source. But i would have assumed this was already common? It reflects how (from my experience) companies work internally with code. Discussion about a feature or a bug is done before writing any code (over lunch, or in a issue thread). We don't want to pay someone to write a feature we don't agree we need, or that collides with future maintenance.
Even before AI, i'd argue the vast majority of code is cheap and simple. But that is what makes it more important than ever to decide what code should exist before someone (well paid) wastes a day or week writing it.
I occasionally submit documentation fixes when I find broken docs (outdated commands in the docs, incorrect docs). I’ve had these rejected before because someone insisted I create an issue and have it go through some process first just to submit an obvious 1 line fix.
At the extremes it clouds the issue backlog. You try searching for something and find pages and pages of arbitrary issues that didn’t need to exist other than for someone to get past the gatekeeper.
However, writing docs as the starting point for someone’s entry to a project doesn’t produce good results much of the time. You need someone who is more familiar with the project to write the docs. Having the docs written by someone new to the project can lead to some really frustrating docs.
This is even more true now that projects attract junior devs who want to build their resumes and think that documenting can be done by pointing Claude Code at the codebase and demanding it write some docs.
It also encourages bad behavior from devs who think they’re doing a favor for new contributors by leaving the documentation as an exercise for someone else.
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 team properly vetted the request. Worst case scenario, the “order” came down to our team, and the managers push to the individual contributors and there is no room for discussion at this point anymore and an arbitrary (made up) deadline that is somehow always unrealistic.
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 open issue and test-case to get through.
At worst, a small 100 row code-change may require a 8000$ independent re-certification of the device before being fully pulled into master.
This 1000%. In my opinion, the biggest part of my job is figuring out what should be built at all, not building what we all eventually agree should be built - that's often pretty easy, AI or no AI.
Most of my PR are like 30-50 LOC (including comments and tests), with a few very related features, and I have probably a 90-95% merge rate. Sometimes writing the explanation takes a long time. Many times while writing the code I get a lot of small surprises and unexpected corner cases. So most of the time a previous discussion would be too generic to be useful for me and inteligible for the maintainers.
Anyway, my idea is to take only a few hours (4?), perhaps distributed in a few slow days. So if it's not merged it's not a big deal, not hard feelings. Also a short feature is easier to review and modify if necessary.
We're talking about open source here, and saying "no" to unpaid, external contributors.
The way I approach it as an external contributor is that if the project is useful to me, I fork it, make my changes, and then open a PR in case the maintainers want to adopt them upstream. They don't have to, it's fine. But I don't have to ask for their opinion in an issue because I will just do what I want in my fork anyway.
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.
This quote is becoming a cliche. Perhaps because it provides such helpful dramatic motivation to the act of maintaining creative quality through active negative selection. When have the freedom to create things we want, that can be hard.
[0] https://www.goodreads.com/quotes/79715-in-writing-you-must-k...
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.
I kindly disagree. If the project is open source, it means that I can fork it. If I find an open source project and want to add a feature to it, I will fork, implement my feature, and then open a PR to the original project. A couple things there:
1. I have no need to open a PR to upstream, it's totally right to keep my changes in my fork (as long as I honour the licence).
2. If the maintainers don't feel like merging my PR, they don't have to. It's their right. They may request changes, and I may choose not to implement them.
It's not the only way to do it: it's perfectly fine to open an issue and ask for guidance. But I don't see the problem in opening a PR saying "look what I did with your project: you can merge it if you want".
Especially when "burden of proof is on the contributor, never the repo" and the repo is hiding behind immeasurable principles such as "ultimate success of a project isn’t measured by the number of features it has, but by the coherence of its vision and whether it finds resonance with its users." with the perfect example
> This threat can take many forms. The most obvious is a feature that’s wildly out of scope, like a request to add a GUI to a CLI tool
Indeed, a threat to the project that can transform a niche tool into a widely used one of at least reduce the usability barriers for a wider user base. Shoo the "incoherent vision" of a drive by Trojan horse bearing gui contribution gifts!
> there is a significant transfer of responsibility when a PR is merged. ... maintainer who is suddenly on the hook for it.
> we’ve introduced and documented the contrib
Oh, so all you had to do to get off the hook was add a comment that you're not responsible?