I have definitely had this issue with Haraka (a highly scalable SMTP server). On the one hand we have Craigslist as a user, who have been incredibly open and contributed heavily to the project, and on the other we have had people post cryptic bug reports that it didn't work for them, but clearly they were trying to use it at an interesting scale, and we would love to have helped.<p>We pride ourselves on being one of the friendliest MTA communities out there, so to find people who give up and quit using it is always sad. Many times we've contributed custom code to companies for free to help them out, but we can't do that if you are silent. So speak up, companies, even if it's only in private messages.
What I'm seeing here is a customer support problem. And IMHO, PowerDNS isn't taking the correct steps to solve it.<p>It's funny, because the answer is right in the article. If your customer:<p>* is large and/or interesting
* has a legal/security/marketing/ team that's worried about sharing information publicly
* has an IT dept that doesn't know the whole company is depending on a single open source product
* feels they have to use gmail accounts and made-up names to talk to you<p>Then maybe a public forum really <i>isn't</i> the place to expect your customers to ask for help.<p>I would suggest creating a partnership program for businesses like Cloudflare - swap tech support for publicity (which will then help drive adoption)
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 <i>user</i> to approach the open source project in the correct manner.<p>It might be more productive to think about "How an open source project should talk to a large scale or interesting user".<p>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.<p>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.<p>These days, I think that a product manager is an essential part of any open source project team.<p>1: e.g. <a href="http://mail-archives.apache.org/mod_mbox/tomcat-users/200009.mbox/%3COFF2F061DD.C2B7EB05-ON00256960.004C94C4%40srv.uk.deuba.com%3E" rel="nofollow">http://mail-archives.apache.org/mod_mbox/tomcat-users/200009...</a><p>2: e.g. <a href="https://www.mail-archive.com/linux-raid@vger.rutgers.edu/msg00947.html" rel="nofollow">https://www.mail-archive.com/linux-raid@vger.rutgers.edu/msg...</a>
OFF-TOPIC FOR ENGLISH-AS-SECOND-LANGUAGE:<p>For HN'ers who are still learning the finer points of English this title shows one of the many weird inconsistencies of the language.<p>Normally, when trying to say 'a thing' where the thing starts with a vowel we change the 'a' into 'an' so 'a axe' becomes 'an axe', 'a umbrella' becomes 'an umbrella'.<p>However this is a notable exception: when pronouncing 'user' there is an unwritten 'y' e.g. it is said 'yoozer', thus we wouldn't normally add another consonant here so it should be 'a user' not 'an user'. If you say it out loud you can hear it (and hopefully feel the extra tongue work that, traditionally, we try to avoid).<p>Another common exception is 'Hotel'. It takes 'an' rather than the expected 'a' as for some reason we drop the 'H'. For me it rolls better off the tongue with 'an' but this may purely be due to conditioning.<p>'Herb' is a difficult one as in the US it's pronounced 'erb' while in the UK it has a hard 'H'. Thus in the UK we use 'A herb' — I assume the US says 'an Herb' — correct me if I'm wrong.<p>It's nonsense like this that makes me pity you brave fellows who attempt to master our pidgin of a language!<p>Edit: change 'pigeon' to 'pidgin' :)
This is one of the pitfalls of a public only support mailing list. I know I post using a gmail psuedonym to get support for various open source apps that I use for side projects.<p>I'd be looking to provide an extra private/internal support email address made available to the largest customers.
tangentially related: Thanks for once again pointing to PowerDNS. I've been using bind forever and I never really looked out for other alternatives ("it works - why should I bother learning something new?").<p>I had no idea what I was missing as from now on, I'll never again have to deal with forgotten serials or manually adding slave zones to the secondary DNS server.<p>Everybody still running with bind, thinking it's "good enough", ask yourself how many times you were inconvenienced by either of the two issues and decide whether it might be worth looking at alternatives.<p>The fact that PowerDNS apparently also is really performant doesn't matter for my mostly minimal use case, but it's good to know that if something great happens, I won't have to migrate again (not that migration is hard - powerdns comes with a helper tool to read your bind config and produce SQL for your zone files)
It is impossible to comment on this specific example without seeing the actual email exchange. What I can say, is that a user <i>chooses</i> how to disclose their identity and the identity of their company making the best analysis of an imperfect situation. Having worked for largely smaller companies (not in the business of protecting the global internet), I've been relatively lax in posting who I am and where I work. This transparency has been helpful on more than a few occasions.<p>If you are a "large and/or interesting" company, it would behoove you to disclose your identity in a safe and responsible way to projects (open source or otherwise) who represent any important part of your business. The trick is to do so in such a manner so as to derive the many benefits (increased responsiveness) without the many liabilities (spam, sales calls, etc).<p>By remaining mum about who you are, the signal to noise ratio of your requests do not stand out from the crowd. This is unfortunate for both sides. It does, however, reinforce the notion that companies and projects should aspire to provide excellent support to all users. You never know when you have a "secret shopper" in your midst.
Often when a company want's to "help" it means make a sale regardless of how poor the technical implementation is, waste your time with SE level support, and power point presentations. When instead they should be focusing on the product first. If your user is reporting a scaling issue and your product is all about scale, that should be your first priority.<p>Vendors also need to remember, your users change companies, a user could be at some small unknown company on day, and the next be in control of a large budget at a high profile company. Your reputation follows that user, and what they want to see is you're making a good product. If the smallest company is reporting an issue that would affect your customers, I'd want to see that you're addressing the issue with that company so I don't have to at my large/interesting company.
No sympathy. If your support for users is poor, then it is simply poor, and no excuses please. "We didn't know how big they were" doesn't cut the mustard.
To complain that the only reason you gave someone bad support was because you didn't know who they were is pretty tone deaf.<p>Would you want to dine somewhere that got panned by a restaurant critic and then wrote an essay saying, "Well, we'd have been a lot more careful with his food if we'd known he was an important critic!"?