> 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.

I await the first LLM generated PR to my JS canvas library with eager anticipation.

I can't wait to ask them if they've run the PR branch against all of the test demos, so they can prove that the PR doesn't break existing functionality. Currently there's just under 200 test demos, each of which needs to be tested manually (because: hell = canvas library + animation) across the three main browsers to make sure nothing breaks. Bonus points for going the extra mile for testing on mobile device browsers.

Over the last 6 months this has been my experience with new engineers at work, absolutely awful. I wish people didn't feel the need to throw out SDLC once the LLMs came along.

It's not rare for me to ask if they tested it. They can lie, but if they say they did and it crashes on me right when I start it, then I may never trust this contributor ever again.

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.

Requiring an issue per PR makes sense for significant bugs and features, but taken to the extreme it feels arbitrary and pedantic.

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.

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 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 have worked at a company that required an issue for every PR. It was dumb though. It just meant you made the PR, got shouted at by some checker for not having an issue, create an issue, copy & paste the PR title into the issue, submit the PR, and then the issue gets closer again.

Totally pointless.

> Discussion about a feature or bug is done before writing any code.

Not always. Not all PRs are significant enough to warrant discussion. For example I fixed a copy/paste bug recently where they had `foo_a = foo_b + i;` where it should have been `foo_b = foo_b + i;`. Obvious mistake. One character fix. Why on earth would I bother creating an issue and discussing how to fix it?

> 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 wastes a day or week writing it.

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.

I made a lot of PR for Chez Scheme (and indirectly Racket). For me it's easier to write the code, perhaps because I'm not an English native speaker, but my Spanish is bad too.

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 don't want to pay someone to write a feature we don't agree we need

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 think the stereotypical open source way is that you modify the code in private to what you want it to be and then upstream that in case it might be useful for others.

I think it's fine. Open source does not mean at all that it has to be open development. Doesn't mean it cannot be, of course.

I strongly disagree. I don't find it rude at all. In fact I find the idea that you have to get permission to offer code much more rude.

You are free to say "sorry I don't want to do it like this; you've wasted your time". That's totally fine.

> 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.

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".

Or build a proper plugin system, or other means of composition.

I like the "core" plus "contrib" model myself, but it does require a lot of upkeep which is often the reason to say "no" in the first place.

You are free to fork and make whatever mess of features you wish for!

Anything that falls outside the intended scope of the project.

"What if we allowed posting GIFs to hacker news posts and comments?"

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

> No. We could not assume that contributors would engage in such discussion, in the past; nor has this been inverted today.

If the author experience a shift in the nature of PR and discussions, then at the very least it's been inverted in the projects they maintain. Even if there were contributors that did so in the past, if the ratio increased it's an issue worth discussing.

> Code "discusses itself" with you as write it

Perhaps (though i lean towards disagreement), but that discussion is not with the maintainer or rest of the team. "I thought about it and this is the best approach trust me bro" is not a great push request. All those questions the contributor answered and "discussed" are un-resolved for everyone else, and the burden of proof should be on the contributor.

If you have to think it through in front of an IDE to think about it properly, script it out in some quick python and return to the issue thread to discuss the approach. Perhaps post the python prototype even.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

I think its quite easy to find examples by thinking of the extremes.

- Why don't git add a native UI? (out of scope)

- Why don't excel add lua scripting? (already has visual basic)

- Why don't neofetch add a built-in ascii art editor so people can more easily customize their logo display? (Bloat)

- Why don't pandas and numpy just merge? (confusing user experience)

They can be amazingly written, with impeccable docs and test suite. But they're out of scope, deviate from the project philosophy, confuse the user, add maintenance for the future, or could could be their own projects.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

More features means more code to maintain. More code to maintain means more time consumed. Time is finite. Time is the only resource you really meaningfully have in life.

I’m prioritising watching my kids take their first steps over expanding the scope of my open source python package.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software

In my experience, there is a subset of open source projects where contributions are theoretically accepted, but in practice the maintainer doesn’t actually want to accept anything from anyone else unless it’s something they’ve asked for. They view contributors as assistants who are willing to volunteer their time to handle tasks that have been delegated, but they prefer to keep it as their own project.

That’s fine, of course, if that’s what they want from their project. It’s their project. Where it starts to get frustrating is if they throw a fit when someone forks their open source project, or when they start rejecting PRs from other people but then lightly rewriting the code and resubmitting it as their own work. Both of these have happened to me in recent years. In one case I spent a long time writing a new feature that the maintainer had created an issue for and marked as open for contributions. Yet no amount of responding to his PR reviews made him happy about the structure of my solution. Eventually I didn’t respond for 30 days because I was busy and he closed it as stale.

Then a few months later I saw the release notes included the feature he claimed he didn’t want. I looked at the commit history and saw he had committed something strikingly similar to the exact PR I had been working on, with only minimal changes to function names and locations of code blocks.

That’s life, of course, but at the same time it’s getting a little frustrating to read all of the writing holding open source maintainers up on a pedestal simply because they’re holding that position. Over the years many of the projects I use have had to fork off and take new leadership and names because the old maintainer was getting in the way of progress. Again, they are within their rights to do so, but that doesn’t mean we need to praise any and every move they make.

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

Ooh! Ooh! I know this one!

Very often, folks want to modify a shared system, to optimize for their own application.

However, the modifications could do things that would negatively impact other users of the system, or make it difficult to customize for specific implementations.

They can also add maintenance overhead, which can impact quality and release cadence.

it may not have technical flaws, but it can be scope creep, doesn't align with the vision for a project, or just additional complexity the project doesn't want to take on.

remember that people will often drive by contribute features they want, but then it's up the maintainers to keep it working forever (until they remove it, if they even can).

> Why? If it is well-designed, useful, and has no obvious technical flaws, why shouldn't it be included in open source software.

If you have a vision and boundaries for what the software does, then you wouldn't want to take a feature that makes it do more than that. The project owner still has to keep the scope where they want it.

If it’s your project, it’s up to you to decide where the focus of the project should be. There’s lots of good ideas on the boundary of every project, and you can’t include them all. Even useful features can be a distraction.

Say you're making a music player and someone opens a PR to add PDF support. Suppose the implementation is immaculate.

I used to think the same way. Why does xyz developer refuse to do this? Don't they know that feature will be of great use to people like me?

Then I made something for myself. It took a lot of time and iterations because my needs were evolving. After it was perfectly tuned for me, I put it out there so someone else can find it useful directly or indirectly.

I started receiving feature requests and changes. I accepted a few, but rejected a a lot. This is mine. I made it for myself. I didn't step out there to build something for the world, I made it for myself and it was perfect for myself. If someone wants my stuff to do things their way and not mine, they're completely free to do so, that's why I shared it.

If I put my paintings out there and the steps I took to draw it, people are free to follow those steps and recreate mine or do it in their own way. You don't demand changes on my original painting.

> A typical maintainer is going to say "wait, what; my accounting system is all about finance, none of this is relevant!"; but they miss out on what users really want in many cases: interoperability or data portability.

I think you are the one missing the point.

Users can want whatever they want to want. They're receiving, generally, et gratis et libre software which depends on someone else's time and effort. If they aren't getting what they want from the project, they are free to fork that project — and when they do, they're still getting more than they would otherwise be entitled to (i.e. the ability to start from scratch).

Further, a maintainer by definition is normally someone not charged with implementing new functionality (that's a "developer"), but simply with bugfixes.