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

When I was a teenager I submitted a random/unsolicited pull request to something in the spree ecosystem, got a very nice message from the maintainer/author saying that he appreciates it but it wasn't in the direction he wanted to take the library, but I could collaborate with him in some other way. Glad for the patience in that message, if it were spicy I might have been put off programming.

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

I'm not sure what I'm missing, but that sounds very similar to the idea that the parent comment says about reflection happening before, during, and after writing the code. It's not at all uncommon for me to explain some code I pushed for review with something like "Originally, I planned to use approach X, but then I ran into complication Y, so I switched to approach Z to handle that". At least to me, this fits the pattern of reflecting beforehand (selecting an initial approach), during (deciding on how to handle a complication during the process of development), and after (literally the explanation itself to describe how the final state was reached), but it doesn't sound anywhere close to "trust me bro".

I don't read the parent comment as arguing against these sorts of explanations, just against the idea that the explanation could be sufficiently written entirely up front before any of the code was written.

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 with the premise of the article and content being reiterated here by a number of commenters.

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?

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