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.

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

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

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?

(Back in the day that's why I liked Firebird^H^H^H^Hfox -- you could bolt on extensions if you wish, but the core product was light.)

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

I totally disagree. I don't owe them anything at all. If anything, they're using my work, for free.

> After all, if you don’t want those interactions, keep your code to yourself!

Because I'm giving my code for free (generally under a copyleft licence) does not mean at all that I want interactions.

> The goal in open-source must always be to create a positive, compounding community.

Again, no. It may be one of your goals if you want to, but it's perfectly fine to open source your code without wanting to create a community at all.

I don't agree; some maintainers just want the code to be /used/ somewhere and possibly in modified form, but are nto interested in upstreaming anything.

For instance the SQLite project operates like this.

This is how open source was back in the day:

- Someone puts code out there

- You fork, then use code. Maybe you change it, put it out there

- Someone forks it back if they like the changes

That's it. No one owes anyone a single thing except following the terms of the license.

Want a change? Do it your self, pay up, or fuck off and wait for someone else to maybe do it, or not do it at all, depending on how they feel.

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

Let's start with the second point: Good code, that reflects, or even evolves, a project's philosophy - is "expensive". LLMs can't write it (will they ever? I don't know), so they have not made it less expensive.

As for the first point: The order of things has never been quite like that. Code "discusses itself" with you as write it, and once you've written a piece, your perspective on what you're writing and what you should be writing in the future - and even on what you had already written. Your own reflection happens before writing any code, during writing, as well as afterwards.

> A user proposes a new feature. It’s well-designed, useful, and has no obvious technical flaws. And yet, the answer is “no.”

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

> This work has gotten exponentially harder in the age of LLMs.

Maybe that is more of the problem. But that's probably not really "well-designed, useful, and has no obvious technical flaws" kind of stuff …

But since this is about an MCP tool, almost reads like LLM generated and the image above definitely is … maybe you're part of the problem!

An incredibly common pattern is a maintainer thinking they know better in an area they are inexperienced in, and rejecting change because they don't like the sound of something or are unable to see past their cultural biases.

We know this by another name - not invented here.

Common, practical areas this occurs in boring open source business CRUD applications:

- Address models aren't thought out. "Why would anyone want geocoding? What addresses don't fit the US style?"

- Phone numbers get modelled as plain strings and all of a suddenly "but changing them to be standardised is really hard"

- Company, brand, account structures rarely add URLs or links to external datasets. What possible use is a wikidata ID?

- Why would I put in vCard/CSV/Schema.org/any other import/export?

All of these areas are often ancillary to the primary purpose of whatever the application is, so get rejected out of hand.

But the use cases they enable for users - who don't use the application in isolation - are then completely blocked.

- Map, route or visualise spatial data mashed up with other datasets. Send people to remote locations without formal addresses.

- Hook up phone systems to make your system run for teams with centralisation, integrate SMS based messaging, etc.

- Join to public datasets to understand more about your customers (food safety, licencing registers, corporate entity registers, contract management systems, etc)

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.

The problem is the maintainer's frame is in their world view; and if they aren't dogfooding their project they aren't running into their users problems - how likely is it the maintainer is the BI analyst, or the low level data entry person, or from a country where QR code payment is the norm, or a million other considerations?

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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

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.

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.

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.