It's interesting how the title "How to talk to an open source project as a large scale or interesting user" implies that the onus is on the user to approach the open source project in the correct manner.

It might be more productive to think about "How an open source project should talk to a large scale or interesting user".

I was deploying open source software in large corporations more than a decade ago[1] and I formed the impression that open source projects could do a LOT more to engage with and support their users. It sometimes felt like the developers just didn't care about users. Documentation was often sorely lacking[2] and "support" typically came in the form of mailing lists that were full of users trying to figure out how the software worked, and swapping advice and tips - often a case of the blind leading the blind.

The end result was that corporate users would sometimes choose commercial software, despite the cost, because it came with decent support and/or had functionality that the open source alternative lacked.

These days, I think that a product manager is an essential part of any open source project team.

1: e.g. http://mail-archives.apache.org/mod_mbox/tomcat-users/200009...

2: e.g. https://www.mail-archive.com/linux-raid@vger.rutgers.edu/msg...