Crashlytics Enterprise Is Now Free | Hacker News Reader

Crashlytics Enterprise Is Now Free

crashlytics.com

30 pointsjohns20 comments

Boy does this look like the beginnings of an ad network.

If everything is free and unlimited... How are they gonna make money?

How does google analytics make money? they just want our data.

SLAs? Support? Consulting? Tangental services? Same way Google Analytics does, they're getting their foot in the door with a lot of enterprises.

volume

This must be an enterprise product, because I can't tell exactly what it does from the blog post or the home page. Is it like Errorception? What languages does it support? No need to explain in a comment here, just point me to the page on their site that I can't find -- but must be there -- that explains in simple terms.

It's a SDK for mobile apps (Android/iOS). There doesn't seem to be a page with every product on it, but the product link at the top leads you to explanations like: http://try.crashlytics.com/reports/

I don't understand why anyone would use this now. It was one thing when Google bought Urchin, which was already incredibly pervasive.

But Crashlytics is a relatively mediocre solution that doesn't already have market dominance. I guess that probably made them cheaper to acquire, but now that we know that Twitter wants them to spy on everyone's mobile apps, why would anyone use them?

There are other crash reporting solutions, and we're not already locked in. It seems like a bad tactical move for Twitter to have telegraphed why they wanted Crashlytics so clearly.

I'm curious to know how you think Crashalytics is a mediocre solution.

I run AppBlade (a tangentially competitive service which offers open-source [PLCrashReporter based] crash reporting for enterprises) I have customers that opt to use Crashalytics when closed-source isn't a show stopper and have huge respect for Wayne and the team.

From what I understand they use Mach Exceptions which are the hairy/scary holy grail for exception reporting in Darwin. Mediocre is using signal handlers which the rest of us mortals do.

Mach exceptions aren't the "holy grail", they're private API on iOS. That is why nobody is using them. If you want Mach exception handling, it should only take a couple days (if that) for a qualified engineer to implement, of which there are quite a few available from the Mac OS X olden days.

Mach exception handling was explained in _2001_ on the OmniGroup's macosx-dev mailing list: http://www.omnigroup.com/mailman/archive/macosx-dev/2000-Jun...

Crashlytics is big on marketing (your use of the phrase "holy grail" came straight from their press release), but they're possibly less than forthcoming when it comes to explaining the realities of their technical solutions. Due to this fact alone, I can't share your respect for Crashlytics' management.

Thank you for a detailed response, we're mostly an iOS shop (little OSX experience) few here will touch a private API out of fear of Apple's wrath and Boston based, so it's hard to not get caught by the marketing wake. You've demonstrated knowledge and I'm satisfied with your belief that they are a mediocre solution.

Since you seem to have some knowledge in the field and an alternative opinion to engineers here, what is your preference for iOS crash reporting? We're currently reevaluating PLCrashReporter in our SDK but need things to be open-source.

I would suggest also reviewing Google Breakpad. They've added iOS support, and while I haven't reviewed it first-hand, the I do know that the Google Breakpad developers don't fool around.

I do not wish to steal the OP's thunder, in that I wouldn't call Crashlytics mediocre myself. They're essentially on par with the other solutions technologically, minus the issue of private API and a tendency to overstate their marketing case.

Agreed, by mediocre I meant "ordinary." My original question being, if it's basically the same as other solutions, why would anyone use it now that we know what Twitter is doing with it.

Hi pifflesnort,

Wayne here. We're extremely proud of the work that the team here at Crashlytics has put into our crash reporting solution. There are many flaws in PLCR that we've addressed -- our customers, like Twitter, Vine, Square, Yelp, OpenTable, Hipmunk, Delta, Kayak, and others, enjoy the increased visibility as well as the wider net to catch issues that other solutions cannot.

We look forward to improving our solution even further - stay tuned ;-)

> Wayne here. We're extremely proud of the work that the team here at Crashlytics has put into our crash reporting solution.

Can you explain why you're using headers for private data structures from the Mac SDK on iOS, while also stating the following?

"At Crashlytics, one of our founding principals has been an extreme (some would say, absurd) attention to detail. Crash detection and reporting, particularly on iOS, is a complex and esoteric problem to solve, with arcane restrictions that throw modern programming practices out the window."

Copying in private headers from the Mac SDK for use on iOS isn't something you can do accidentally.

> There are many flaws in PLCR that we've addressed -- our customers,like Twitter, Vine, Square, Yelp, OpenTable, Hipmunk, Delta, Kayak, and others, enjoy the increased visibility as well as the wider net to catch issues that other solutions cannot.

We're discussing systems software engineering on the level of compilers and operating systems. Without concrete information, you are not providing what an actual engineer requires to evaluate your solution.

This topic is deep, broad, and complicated. This deserves honest engineering discourse.

A specific example. In a blog post, you state:

"Need to allocate memory at crash-time? Revisit your approach. Thinking of calling an Objective-C method? Dream on."

Those things are not possible because of the requirement that signal and exception handlers be async-safe. Ironically, while Crashlytics does not use Objective-C, it still includes code that is not async-safe.

These kinds of mistakes are a fact of engineering, which is why good engineers are humble engineers. Your unequivocal boastful marketing -- and evaluation of other solutions -- is perhaps not entirely forthcoming.

If you consider Crashlytics to be a valuable service that is a step above others, I'm curious to know why you sold it as a data spy play to Twitter? Doesn't that kind of compromise the integrity of your vision? Or was it not clear to you what Twitter was going to do with it before the acquisition?

I wonder if this is good or bad news: After the twitter acquisition, the expensive product becomes free. I rather have a free product, but as a customer I would be worried shutdown is next.

Wayne from Crashlytics here. Don't worry, a shut down is not next :-)

Nah, seems like a volume play a la Urchin/Google Analytics. See point #3 here: http://news.ycombinator.com/item?id=5132089

I really liked the sound of Crashlytics. Then Twitter bought it. Now it's free. I don't trust Twitter and I don't trust free, so I'm less likely to use this.

If I don't understand why something is free, I grow suspicious. I want to know how a company plans to make money before I sign up for its services.

Reply on news.ycombinator.com