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.
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.
On paper I agree, from the other side of the fence, here is what the process looks like:
This looks good for what we want to do, let's test it out.
Cryptic error.
Google for 24h for a solution, can't find one.
Ask on official mailing list / forum / bug tracker.
Getting ignored as usual, or dismissed rudely.
Never use that product ever again.
I'm a CTO and I do that process more often that I would want to, sometimes I don't get that far because Install instruction sucks, and usually that's enough to deter me.
A concrete example: Since The Guardian opened Scribe (their CMS WYSIWYG editor) I had it in the back of my mind for weeks because it looked really interesting and close to what I had been looking for. We were doing CMS upgrades recently, so I wanted to take the occasion to plug in Scribe.
It took only 2h for me to put Scribe on my "never use ever again" list. It all look pretty neat at glance, quick install, nice plugin system, yadda yadda,... However, their one line install simply doesn't work, their is no list of dependencies anywhere, and simply no documentation. Logged an issue notifying them of the poor quality of their setup instructions. Got a reply 7 days later, which starts a discussion. But now it's too late, still have personal interest for Scribe, however my company has already moved on.
I'm all for OpenSource, have some myself (though, more of a "here is what I did recently" type of guy), however if you want to pretend to be a serious library/framework/piece of software, that includes decent documentation with clear install instruction for most common distributions.
Plus, dialogue is good, but most of the time I need it right now, or in a very short time frame, so more often that not I will simply drop back to another less interesting piece of library (or nasty one) that simply works, because that is what matters, it works when I need it. (Again with the Scribe example, no matter how much I dislike TinyMCE, I ended up using it, because one line of JavaScript is all it took for it to work).
I absolutely agree and this is a problem that a lot of open source projects face (Haraka is not alone in this). In part it comes down to the fact that most open source isn't worked on full-time, and so documentation often takes a back seat to getting your feature-du-jour working.
But absolutely we could all use some improvement in these areas.
Yeah, just to be clear I'm not bitching at maintainers, just giving the perspective of a potential company wanting to use a library. Though usually I do try to follow up if I think the software/lib is really nice, but it's often on a personal level, not for my company.
Documentation is pretty boring to write,and not as fun as feature-du-jour, but may be there could be some guidelines about what a basic documentation should have, specially with GitHub it could be straight forward to have a Markdown template for basic doc (Installation, FAQ, Requirements, Contact points, ...), I know I use one.
What I'm seeing here is a customer support problem. And IMHO, PowerDNS isn't taking the correct steps to solve it.
It's funny, because the answer is right in the article. If your customer:
* 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
Then maybe a public forum really isn't the place to expect your customers to ask for help.
I would suggest creating a partnership program for businesses like Cloudflare - swap tech support for publicity (which will then help drive adoption)
I think they should have a VIP program akin like WordPress. I think every serious Open Source project should have some kind of separated channel for Corporate/BigInstalls.
I would not entirely place the blame on PowerDNS here, it also points out that how our Corporate citizens can do better for the eco-system by being active partners with the Open Source projects they rely on, instead of hide and snipe mailing-listers.
Another reason why employees at big corporations are loath to contact
open source projects is that they assume they won’t get help, and need
to pay for support. And, while it is true that someone needs to pay the
bills here, we realise that for many users, a support agreement is just
not going to happen. Corporate IT might not even know the whole company
is relying on an open source project. Questions might be asked. For such
organisations, we are fine with providing free help on the public mailing
lists. But to give proper weight and context to your issue, it helps if
we know who you are.
I think corporate owners are in the best position to offer money for services. They are usually looking specifically for some sort of support contract they can pay for! (If Corporate IT doesn't know, that company has bigger problems anyway.) Something like a VIP program would be a great way to get these types of users in the door. Feed all that money back into your open source project - if you're big enough you probably have project support costs anyway (hosting, etc).
I agree with your second point as well, and I think it reinforces my point, because you can take those internal people that you are dedicating to the task and make them the active partners to the open source project.
Giving away a good portion of your infrastructure in a public forum and asking for configuration help, IS just asking for trouble.
The "large and interesting" deployment line was stated and reiterated several times as being "important" to the level of help that you'll receive from them. I fail to understand HOW this will garner more users to your service.
What I was referring to was using this service if you're NOT Google, Amazon or Facebook.
Nothing discourages me more from using a service if you differentiate the type of customer support you provide to a client based on their size or whether they have an "interesting" setup.
In the grand scheme of things, Google, Amazon and Facebook are less normal, so if you're tailoring your support model around those types of clients, then it's not for me...
My company has someone at Youtube they can call if they ever need help. Same with Facebook. Does that discourage you from using those services? Big companies give their big clients a support channel that doesn't exist for everyone. That's normal.
I guess the thing is, you don't want to make that too widely known. It's more of an optics thing.
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.
While I agree with you in general, after all, what's the point of building something if people can't use it, it misses the point of this article: if you have an interesting use case, particularly one that aligns very well with the goals of the project, you need to let the project know somehow. The developers are not psychic.
your comments are, bluntly, massively entitled. One of the open source tradeoffs is that they often come with slightly more install/configuration work; in trade for usage freedom, the ability to modify the source, and of course, zero required cash outlay. I share ml code on cran because I wrote it and I'm happy to have other people use it; that doesn't come with a requirement for me to spend more than zero time helping them do so and when I do, it's because I happen to feel like it. Telling me you're doing something interesting (to me!) will often help interest me in helping you. The massive wave of demanding users that want hand holding typically don't even get a reply from me.
Really? I see no entitlement, merely a very common annoyance that FOSS projects are traditionally very bad at support (and your frankly, shitty, attitude is part of that, and part of the reason many enterprises consider community open source projects to be absolute last resort)
If I had a penny for every time I had a question ignored in IRC or mailing list ghost towns, I'd be running my own Y Combinator by this point. Those that will actually take the time to help users out, or projects with sufficient and good enough documentation that the "hand holding" as you put it, isn't necessary, are like refreshing oases in a vast desert.
I would be okay with no support (explicitly mentioned) vs no support where that's not implied to be the case.
<rant>
There's nothing that sucks quite so bad as a link on a project page which says "Go here for help" - you do so, then find out you are in an IRC channel with 500 people, none of which ever speak, any questions are simply lost in the ether among the hundreds of join/quit messages per hour.
In other words, don't say you provide support if you don't intend on giving it. At least a message along the lines of:
This is provided as is, where is, if it breaks you get to keep both parts
..forewarns me to either not waste my time, or be prepared to waste quite a bit of time.
As it stands, now I've wasted time, and now I hate your project for being an unsupported piece of shit, and now I hate the developers for fucking lying about it.
This is a literal experience I'm fighting with right now.
</rant>
And worse, every time a user encounters this situation, it tars all of FOSS with the same brush. It's what leads to people joining companies and remembering their experience and telling people not to use X Y and Z due to that bad experience.
said the user unsatisfied with something for nothing and now demanding personal support!
a bargain (for you)
and ps -- just so we're clear, the package I've contributed includes the mandatory per-user function help (each with runnable code examples), plus a 10+ page vignette discussing common usage, implemented inference algorithms, and parameter setting suggestions.
The vast majority of email I get starts with the implicit sentence [I'm a lazy prick who can't be arsed to read any of the docs, runnable code examples, or surrounding discussion. So if you could answer questions from someone who couldn't do the briefest amount of research that would be fabulous.]
Those emails are closely followed in quantity by the emails best summarized as "I'm gonna be super vague here but something didn't work. I neither wish to share the exact invocation of your package nor data, and certainly neither of those without prompting, but something didn't meet my unknown expectations and I want you to fix it now!"
> the package I've contributed includes the mandatory per-user function help (each with runnable code examples), plus a 10+ page vignette discussing common usage, implemented inference algorithms, and parameter setting suggestions
That already puts this package at the 99.7th percentile, I'd guess, in level of documentation among open-source projects. x0x0 does not have a bad attitude. A bit of anger born of frustration, okay, but open source developers with bad attitudes do not write documentation at all.
And to answer your question, the primary purpose of the IRC channel and mailing list is to let the users support one another. Only when a question arises that even expert users don't know does the developer need to step in.
If you're willing to pay for support, an email to that effect would probably be welcome. Otherwise, you're already getting more than you paid for.
I sometimes have success on those IRC channels by asking the regulars what other resource or how-to would they use to solve my problem. This is an easy answer for them to give, and doesn't require them getting personally involved in my problem. A page full of search results might all look relevant to a newbie, but an experienced user's recommendation is more likely to hit the mark.
For HN'ers who are still learning the finer points of English this title shows one of the many weird inconsistencies of the language.
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'.
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).
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.
'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.
It's nonsense like this that makes me pity you brave fellows who attempt to master our pidgin of a language!
You're spot on about how we say "an herb" in the US. Interestingly, it seems "hotel" is the exact opposite... I've never heard someone in the US drop the "h" . We say "a hotel".
EDIT: Wow, five overlapping replies in two minutes, all correcting the "hotel" thing... Just goes to prove the aphorism that the best way to get help on the internet is to post an incorrect answer (perhaps Cloudflare should have tried that...)
Thanks. English is not my first language and I never heard it with the H dropped before, so I was afraid I was just chronically exposed to an error and copied it.
The neat thing is (to me), his rule still makes sense. If I were listening to someone who spoke a dialect of English different than mine, it would still sound natural if they chose their "a" vs "an" in the "right" way:
As you can see from the rest of this conversation (and the way my points for the article has swung violently from -1 to +6 and and is falling back again) I'm clearly no expert despite having been born to it! :)
I (northern UK based) find "an user" feels wrong as to me the "y" implied by the way "u" is pronounced is a consonant sound so it should be "a user" - though I pronounce the "a" in a softish manner (more towards "ey"), it might be different if you pronounce "a" harder or pronounce the "u" as more towards "oo" (reducing the y-like mouth movements).
Regarding herb: in written word it is "a herb" for correctness, though few in the north pronounce it exactly that way as the "h" is dropped to produce "an 'erb" or sometimes (though this makes you sound uneducated due to certain stereotypes) more like "a nerb" (this time with the harder "a" as in "an".
It's nonsense like this that makes me pity you brave fellows who attempt to master our pidgin of a language!
The fairly arbitrary set of incompatible rules and standards that make up the English language mean it is difficult to learn perfectly (especially as there are arguments as to that "perfectly" means in this context) but it makes the language easy to learn to the point where you can survive using it in the languages native land(s) easier than many others. We are so used to subconsciously processing all the different accents we have in the relatively small area that is the UK and the extra nuances that creep in from elsewhere (poor education, influences from other cultures mainly via TV/film & music, etc.), that unless we are feeling pedantic we also naturally screen out the mistakes non-native speakers make.
It is common to respond to people apologising for their bad English with something along the lines of "don't worry, I deal with worse from people who have been here for generations". We are not being patronising here (well, at least some of us aren't!): sometimes we genuinely do have to internally correct/translate more when talking to someone from 300 miles away than we do when talking to a Pole/Spaniard/what-ever who is not (yet) particularly fluent in English.
For "hotel" and some others, I believe the difference is whether or not the "h" is aspirated. That is, whether or not you take a short break at the word boundary. If you say it "in one breath", you get "an-(h)otel" with a very soft h and no or very little aspiration.
If you make the word boundary more pronounced, you get "a hotel" with a clearly noticeable air-burst, and a clearly distinct "h".
Same process as with "herb" etc. and some other words that can be pronounced both with and without aspiration in English.
This is much the same as in French, where if the preceding word end in a vowel (with certain exceptions) and the current word starts with a vowel sound, you can usually elide the last vowel in the preceding words except when the "h" is aspirated. My French teacher liked to say that the French "thinks" they are pronouncing the "h" in those few cases (aspiration usually refers to cases where there's a strong burst of air in pronouncing the sound, but in French "aspirated h" does not actually involve fully pronouncing an "h", though there may be some aspiration)
(I may confuse this - this is based on recollection of my French classes 20 years ago...)
There is a scene in Hot Fuzz where the police have to take along an 'interpreter' so they can talk to a West Country farmer who is speaking English, but with an amazingly strong accent. This scene was apparently based on a real event they saw during their research for the film.
(I think it's 'west country'... I'm not quite up-to-speed on my UK regional dialects)
I've generally used the Economist in my past writing and they say:
An
An should be used before a word beginning with a vowel sound
(an egg, an umbrella, an MP) or an h if, and only if, the h
is silent (an honorary degree). But a European, a university,
a U-turn, a hospital, a hotel. Historical is an exception:
it is preceded by an, the h remaining silent.
Which begs the question — what was my victorian-style, Scottish primary school teacher on about when she insisted on 'an hotel'?
Pronunciation is highly regional, an if you pronounce "hotel" without voicing/aspirating the "h", then "an" is appropriate. When newspapers use style-guides, they are after consistence as well as "emulate" a certain spoken voice consistent with their profile and target demographics.
Teachers can be wrong, but maybe some words are pronounced differently with a Scottish accent. And the "or an h..." part is redundant because "honorary" starts with the sound "on". I've never heard "historical" pronounced with a silent "h" though.
It might be a regional dialect. Growing up in the west coast, I have never heard "her-bal tea", but rather always heard "er-bull tea". Hearing the "h" sound in "herb" (as I do whenever I hear British (and Australian?) speakers speak) was always very jarring, until I realized that it was just that they pronounce that class of words differently than we do.
It's possible that in the eastern or southern US, they say the H in "herb".
I don't know that it's a regional variation, but about half of the people in my family pronounce the "h", including me most of the time. My sense is almost that dropping the "h" is an "educated" thing, and those who don't drop it are unconsciously tweaking the whole concept.
I never heard of anyone in the US using "an herb" and I've lived my entire life there. Also never heard the 'h' not being pronounced. I mostly lived in the East/Midwest, so perhaps the pronunciation differs elsewhere by region.
I feel bad upvoting you when you're hijacking the thread's potential relevant comments. But I really need comments like yours and you're awesome! I learned two things I didn't know thanks to you.
This off-topic digression was made possible by the submitter's rewritten title: "PowerDNS on losing Cloudflare as an user".
Since the article's title is neither linkbait nor misleading, we reverted to it, or rather to a shortened version of it that fits the 80 char limit.
I'm also demoting this subthread as obviously off-topic. It makes little sense for a bikeshed discussion like this to occupy the top slot of the top discussion on HN, but these things get reliably upvoted.
No need! It was a fine digression in and of itself, and I share your desire to help with the subtleties of English.
The trouble comes with the upvotes that make the digression into a top subthread. Bikeshedding is a collective creation that no one particularly intends.
It feels to me like there's a simple and elegant solution to this problem waiting to be discovered.
Originally it was a reaction to the in-built desire I (and I suspect most of us) have to immediately jump in and make a correction to someone else's English. It was an experiment in trying to say something useful and positive instead. It was an interesting result. I'm not sure I'd repeat it.
I wouldn't be so sure about the 'an' before hotel. That may be regional as well. I'm from the southern US and use 'a' there. However, 'an' would be used whenever the 'h' isn't voiced, which in my case would be words like honorable and honest.
> 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.
I'm not sure about the rest of the world, but in Australia I don't think I've ever heard 'an hotel'. It's always 'I'm going to a hotel'
Saying 'an Hotel' makes me pronounce 'Hotel' in a very uncomfortable way.
Yeah, this is a mostly American hyper correction. You see the same thing with "an herb". I'm guessing it's a relic from people who spoke French affecting the same pronunciation in English. You occasionally even see "an history"
May well be a regionalism an well. I say an herb and don't pronounce the H. But a hotel (or a history) and do pronounce the H--and hence use "a." There are a number of words that can go either way because the (acceptable) pronunciation covers both variations.
"historian" is a fairly long word. If you stop to create a word break, and then aspirate heavily on the "h", it can be uncomfortable to say. If you don't, then the "h" can get very soft if people try to say the whole word quickly and I imagine that some people drop the "h" entirely because of that, or make the "h" so soft it feels natural to contract
As a southern Englishman, i would say, and expect to hear, "a hotel". I associate "an hotel" with Northerners, Cockneys and speakers of Estuary English, and perhaps also posh people (although maybe that's Northerners or Cockneys trying to be posh, in the mode of Hyacinth Bucket).
I was taught 'an hotel' in Scotland by a very old-fashioned teacher. She could, of course, have just been plain wrong and I've been carrying this with me for decades repeating the mistake. Checking the UK newspaper style guides they seem to all insist on 'a hotel'.
"an hotel" is just wrong in my experience, which I think is where "people trying to sound posh" comes into it.
The south and the "posh" (there is quite some overlap there as there is a perception that the south is more posh and the north more rough) use "a hotel" which is also technically correct, as you move north the "h" gets dropped so "an" becomes correct, though if you are writing that you should have a apostrophe to indicate the dropped letter (an 'otel) - in fact the 'postrophe is sometimes even pronounced by way of a very small pause (this is often a clue when decided if someone has a particular accent or is just imitating it).
That would depend on how you pronounce "hysterically".
Do you voice the "h" or not?
If you pronounce it "iss-tear-ick-lee" then you'd use "an".
If you pronounce it "hiss-tear-ick-lee" then you'd use "a".
Personally I've never heard the word pronounced with a silent "h". I checked several dictionaries and they all list the word with voiced "h". None of them even list the silent "h" as an alternate pronunciation.
Therefore I would say that the voiced "h" is the correct pronunciation, and "an hysterically funny person" is wrong.
Given the "did you see" comment, it's a good example of a hypercorrection:
Easiest way to remember, if the sound of the word's first letter starts with a consonant sound, you use a. If it starts with a vowel sound, you use an.
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.
I'd be looking to provide an extra private/internal support email address made available to the largest customers.
Except that even the basic support [1] includes that:
> Support via private (email) ticketing system, with guaranteed 8 hour response time, during European office hours (9AM – 6PM, or 3AM – noon EST). Includes resolution of 5 incidents. Does not include DNSSEC support.
although CloudFlare should have probably bought the carrier grade support.
Exactly correct. This implies that Cloudflare was using PowerDNS and (as was their right) chose not to pay for even basic support.
I'm not sure what else PowerDNS could have done in this situation, and I can only imagine their teeth gnashing when they found they'd lost a lighthouse user.
Typically, lighthouse customers almost always also pay for support. Upon reflection, their post-mortem blog post was extremely well handled and written.
We in the computer business are well aware that some bug reports don't get fixed - such as because they require new features outside the scope of the project, or because fixing them is a huge hassle.
A "carrier grade" support contract sounds expensive.
If I'm going to my boss to ask for $x0,000 for a support contract because of a specific bug we're experiencing, I need to know the resolution won't be "WONTFIX"
Those are indeed common issues in our industry. However, in this specific case, PowerDNS specifically calls this out on their support section of their page: "Many (large) developments in PowerDNS have been funded by operators that wanted to expedite the authoring of the features they needed."[1]
Also, carrier grade support does indeed sound expensive for a small shop. Might even be deemed expensive for a medium-large shop (since they don't list pricing details). However, for an outfit as large as CloudFlare, I find it hard pressed to believe they couldn't afford Basic Support considering that one of their engineers on this thread stated that DNS is a critical part of CloudFlare's core service offering.
You don't ask for a support contract for a specific bug, but for a general class of support and current + future bugs. As part of the negotiation, your boss and organization can also leverage "lighthouse" status to influence PowerDNS to fix even minor bugs quickly as part of a negotiated Service Level Agreement ("SLA").
EDIT: To give CloudFlare the benefit of the doubt, it is possible that PowerDNS didn't make their support options clear to users before, and only updated their support pages after this post-mortem.
And no prices on that page at all, so you need to contact them, and then you are dealing with a salesperson who sees CloudFare as a whale who needs to buy the $$$ carrier-grade support and get them a big commission.
This is sadly such a common issue these days. Please give some idea of your pricing! Not providing any pricing information at all on your website is a massive disincentive to paying for your services.
I don't want to have to deal with sales people who will continually spam me with email and phone calls if I ask for pricing, and will want to have a 20 minute call to "understand my requirements".
By all means put an asterisk saying that the prices are guides only, or have large letters saying discounts may apply, or whatever, if you must. But not doing anything doesn't just aggravate your customers - it often means we go elsewhere or just use mailing lists for support.
If the customer would rather build their own system than risk talking to someone on the phone where money might be discussed, I'm not sure that the open-source vendor is the problem.
The contention was that Cloudfare could have just signed up for the cheap support plan if they wanted private problem reporting, and I don't think that would be as easy as was suggested.
It's not that hard to dig around and find someone you can email privately. For many open source projects, that can be kind of annoying, but if it's really, honestly, something that's kind of private, or if there's money involved, the developers are probably going to be more understanding.
This circumstance would be amusing to me if it wasn't way too common. People that are employed in or close to software development are well aware that when communication with user/clients/whatever is complicated. Incomplete and misinformed interpretation of requirements are the poster child of difficulty to discuss software. Then a developer turns around and fails to communicate with the people that develop the software they use.
For all the huffing and puffing I see people do about professionalism, very few of the "professional" mailing lists I'm subscribed to have adults that can say "I'm A at B, and am looking for a contact at C to email me off-list to discuss D."
I work on our DNS server, but I don't have a copy of the email that Matthew sent to the PowerDNS guys, but DNS is fundamental to what we do and so the ability to modify the DNS server was pretty important.
I think we got to the point where we just said "there are N features that we want" and decided to build our own. The result is that we've been able to do all sorts of stuff that's CloudFlare-specific: bear in mind that we handle two different sorts of DNS queries: external ones (that might or might not serve a CloudFlare IP that is proxying for a customer site) and internal ones (that need access to public, non-CloudFlare IPs). We also recently introduced a CNAME-flattening feature: http://blog.cloudflare.com/introducing-cname-flattening-rfc-...
There are other things we want to do to be fast in two ways: fast to respond (http://www.solvedns.com/dns-comparison/2014/04) and fast to update (which means integration with our replicated, global settings databases).
We also have all sorts of special things that we do to deal with attacks on our DNS infrastructure that include the DNS server talking directly to NICs for filtering and packet handling. We're also generating bpf bytecode directly for specific filtering activities.
Bottom line was that DNS is a core technology for CloudFlare; it made sense to totally own it. I don't think this says anything bad about PowerDNS. Note: HTTP serving is a core technology. If nginx weren't so configurable (especially through OpenResty) we could easily have been having this discussion about a web server. But equally agentzh (who wrote OpenResty) works for us.
> There were three main challenges. First, PowerDNS when under large in-bound DDoS loads would consume excessive resources and occasionally fall over. Second, and more insidious, because the version of PowerDNS we were using did not have abuse detection and rate limiting, we were increasingly seeing attempts at using CloudFlare authoritative DNS network to launch reflection attacks against others. And, third, it was very difficult to extend PowerDNS and add any sort of application logic which kept us from doing interesting things... like adding Easter Eggs.
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?").
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.
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.
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)
May I recommend LuaDNS [1] for simple uses? Write your DNS config in lua and deploy it with git push, I like it a lot for all my side projects and my homepage.
It is impossible to comment on this specific example without seeing the actual email exchange. What I can say, is that a user chooses 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.
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).
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.
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.
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!"?
Your analogy is flawed. This is like a restaurant critic saying the portions were far too small, but failing to reveal when they ordered that it wasn't just for one person, but actually a party of 12 people.
Hmmm, I'd agree if the issues were all performance-related, or if the author had said "make sure to let us know if you are a large deployment." What the author actually said was "large or impressive" and that point was reinforced several times. I don't know how you measure "impressive" but it sounds a lot like "special" to me.
I imagine if you were using their product in an HFT setup (somehow) with only a few servers, but with sub millisecond requirements they might also be interested.
I suggest actually _reading_ the post. It notes the tradeoff. It also notes we offer near infinite support for people asking politely and making their problems known. We also note that it isn't just a matter of scale.
To complain that the only reason you gave someone bad support was because you didn't know who they were is pretty tone deaf.
As a small end user of open source products, this is exactly what I expect and have assumed the case to be, even if I've never seen it spelt out like they did. I don't have any delusions that an open source product should cater to me.
I don't see how it's tone deaf, or more specifically I don't see how their statement could upset anyone other than those who expect open source to be a magical wellspring of doing their job for them.
Open source is a more like having another team at your company that isn't beholden to yours. You're getting access to the internals of the project and can communicate as if they're colleagues, but don't expect them to work on your project. If working together is mutually beatifical, or you pay, then things change.
I think that the analogy would be that the customer panned the restaurant because he had severe allergies and didn't tell the waiter. In order to serve special interests, the vendor needs to know constraints.
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.