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?

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.