IMO, this acquisition could have been motivated by 1 or more of the following:
(1) Need them in house. Many larger companies have been contracting their app development to ISVs. Some ISVs have been quietly purchased by their largest customers, as mobile has become more "core". Crashlytics was a toolmaker that Twitter and some others used. Perhaps, Twitter thought these tools were "core", or too important to not have as part of their org.
I'd argue this isn't the primary motivator. Twitter could have benefited, and would arguably benefit more, if Crashlytics continued their mission external to Twitter as a straight crash diagnostic solution. If Twitter asked for something cool, Crashlytic would generally jump at the chance to deliver the functionality [w/ no acquistion]. From Crashlytic's perspective, assuming they ran a tight/"well attended" acquisition process, I would hypothesize a higher value from some one like Google (for dev tool for all their publishers + #3 upside + compliment to GA), and/or someone like NetDynamics/NewRelic/EMC. The APM people will eventually see the light, realizing they, too, can't afford NOT to have a mobile offering to their product offering (Facebook is to Instagram as …)
(2) Talent. Crashlytics has always had a competency in UI/UX + hardcore mobile engineering. Remember, they are toolmakers, the hard core of the hard core. These skills would be valuable to any company with a significant mobile presence. The UI/UX talent would benefit anyone.
Given the probable purchase price, anchored by their last round of funding (~$5-6M), pure talent motivations are unlikely due to investor return expectations driving high PP. If competitors had so drastically reduced Crashlytics ability to grow into a standalone business, then this might be a possibility. Even then, there are organizations who they could find to more highly value their particular skillets / current product *
(3) Re-purpose / Trojan horse. Since Crashlytics solution installs an agent inside someone's else app, you can begin delivering all types of services + collect all kinds of interesting info as part of a bundled offering:
- (3A) Event logging. Call this the Flurry/GoogleAnalytics play. Every time an instrumented app does something, speaks to the outside world, or most likely, a user takes a certain set of actions, the SDK can report to the mothership. This is particularly useful if you're looking to add tracking across Twitter properties (app, web, etc) and other apps.
- (3B) Social plumbing. Twitter might lost-lead this (give it a way for free) to make adding twitter functionality into any app very easy.
- (3C) Mobile infrastructure wedge. Secure a relationship with app developers, and do something more beneficial with those relationships than just selling them tooling. Burstly/Testflight is a good example, so is Flurry with advertising.
- (3D) Other. God only knows.
3A/3B/3C are a very likely. The "universal cookie" is the holly grail for advertising platforms, and no one has figured it out yet. I would argue Google is better situated to take this role (given control over ad network +leading mobile OS), but can't fault Twitter for trying. You could argue they are making the advertising platform move. If this is the move, they run the risk of alienating their relationships / running a cat/mouse game with the mobile OS platform owners
------------------------------------
So in summary, I'm going with mostly #3, with 1 & 2 as a secondary motivator. Whichever is the case, I'd keep a close eye on their ToS (the hips don't lie). #3 is scary every which way, for both consumers and app dev's. #3 is aggressive, and loaded with cat/mouse games from existing platforms. #3 is thinking big.
How does this play for the remaining players in the space? Either very good or very bad for Crittercism, uTest's Apphance, and Bugsense.
- Bad. There was always a high probability of mobile crash reporting becoming commoditized, and/or becoming a lost-leader for something else. I highly doubt Crashlyitcs is going to remain Twitter's gift to the mobile engineering organizations of the world (a 2nd Bootstrap of sorts)?
- Good. Competitors lost a very credible competitor today. The information and access Twitter would gain via an embedded monitoring agent inside lots of popular apps is very interesting. For example, Twitter would know coveted metrics like real-time MAU #'s for any app using Crashlytics SDK. There's a hypothesis that companies will pay for tooling, especially if they know and can control how the data will be used. This is only magnified, if the new owner has large incentives to misuse that information.
------------------------------------
[I was an early employee at a competitor. I left to join a new startup ~5 months ago]
I don't see how it works as a Trojan horse. I don't think it plays - all the apps using Crashlytics will switch to a different service rather than have their data flow to Twitter. No way Expedia wants their data flowing to Twitter (or anyone else).
Looks to me like a talent acquisition. While Crashlytics was likely popular, I think they likely had limited revenue opportunities given Hockey App and Crittercism.
Really - it's a race to the bottom on these crash services. Switching costs would seem to be pretty low - so my guess is that the VCs saw a quick out.
I agree. We were an early Crashlytics adopter that also used TestFlight for Ad Hoc testing. When TestFlight launched TestFlight Live and introduced its own crash logging service, we saw no need to keep both in the app and shut off Crashlytics. Anecdotal of course, but I think the theory here has merit: crash logging is a feature, not a business model, and the Crashlytics team made a good move here.
(1) Need them in house. Many larger companies have been contracting their app development to ISVs. Some ISVs have been quietly purchased by their largest customers, as mobile has become more "core". Crashlytics was a toolmaker that Twitter and some others used. Perhaps, Twitter thought these tools were "core", or too important to not have as part of their org.
I'd argue this isn't the primary motivator. Twitter could have benefited, and would arguably benefit more, if Crashlytics continued their mission external to Twitter as a straight crash diagnostic solution. If Twitter asked for something cool, Crashlytic would generally jump at the chance to deliver the functionality [w/ no acquistion]. From Crashlytic's perspective, assuming they ran a tight/"well attended" acquisition process, I would hypothesize a higher value from some one like Google (for dev tool for all their publishers + #3 upside + compliment to GA), and/or someone like NetDynamics/NewRelic/EMC. The APM people will eventually see the light, realizing they, too, can't afford NOT to have a mobile offering to their product offering (Facebook is to Instagram as …)
(2) Talent. Crashlytics has always had a competency in UI/UX + hardcore mobile engineering. Remember, they are toolmakers, the hard core of the hard core. These skills would be valuable to any company with a significant mobile presence. The UI/UX talent would benefit anyone.
Given the probable purchase price, anchored by their last round of funding (~$5-6M), pure talent motivations are unlikely due to investor return expectations driving high PP. If competitors had so drastically reduced Crashlytics ability to grow into a standalone business, then this might be a possibility. Even then, there are organizations who they could find to more highly value their particular skillets / current product *
(3) Re-purpose / Trojan horse. Since Crashlytics solution installs an agent inside someone's else app, you can begin delivering all types of services + collect all kinds of interesting info as part of a bundled offering: - (3A) Event logging. Call this the Flurry/GoogleAnalytics play. Every time an instrumented app does something, speaks to the outside world, or most likely, a user takes a certain set of actions, the SDK can report to the mothership. This is particularly useful if you're looking to add tracking across Twitter properties (app, web, etc) and other apps. - (3B) Social plumbing. Twitter might lost-lead this (give it a way for free) to make adding twitter functionality into any app very easy. - (3C) Mobile infrastructure wedge. Secure a relationship with app developers, and do something more beneficial with those relationships than just selling them tooling. Burstly/Testflight is a good example, so is Flurry with advertising. - (3D) Other. God only knows.
3A/3B/3C are a very likely. The "universal cookie" is the holly grail for advertising platforms, and no one has figured it out yet. I would argue Google is better situated to take this role (given control over ad network +leading mobile OS), but can't fault Twitter for trying. You could argue they are making the advertising platform move. If this is the move, they run the risk of alienating their relationships / running a cat/mouse game with the mobile OS platform owners
------------------------------------ So in summary, I'm going with mostly #3, with 1 & 2 as a secondary motivator. Whichever is the case, I'd keep a close eye on their ToS (the hips don't lie). #3 is scary every which way, for both consumers and app dev's. #3 is aggressive, and loaded with cat/mouse games from existing platforms. #3 is thinking big.
How does this play for the remaining players in the space? Either very good or very bad for Crittercism, uTest's Apphance, and Bugsense.
- Bad. There was always a high probability of mobile crash reporting becoming commoditized, and/or becoming a lost-leader for something else. I highly doubt Crashlyitcs is going to remain Twitter's gift to the mobile engineering organizations of the world (a 2nd Bootstrap of sorts)?
- Good. Competitors lost a very credible competitor today. The information and access Twitter would gain via an embedded monitoring agent inside lots of popular apps is very interesting. For example, Twitter would know coveted metrics like real-time MAU #'s for any app using Crashlytics SDK. There's a hypothesis that companies will pay for tooling, especially if they know and can control how the data will be used. This is only magnified, if the new owner has large incentives to misuse that information. ------------------------------------
[I was an early employee at a competitor. I left to join a new startup ~5 months ago]