Hopefully Google will make flight search suck less. Currently even the most basic searches like "What's the cheapest I can fly from any airport within 50 miles of my house to any airport within 50 miles of NYC at any point during August" are impossible. I understand it's a computationally expensive question, but why the hell can't I just buy $5 bucks worth of computing time for an answer if I potentially stand to save a couple hundred bucks.
We've been doing those sorts of radius searches for years, although we don't currently integrate street-level data for any customers that I know of. Head to http://matrix2.itasoftware.com, put in where you are, then click "Nearby" - the default is 50 miles, even! Then ask for a calendar of lowest fares. You can even tell it "I want to stay 2-5 nights".
Many of our customers have something similar, but it's not always on the front page.
Doing these kinds of searches is the next great business opportunity in online travel. When you buy a flight ticket, what the airline is really selling is a fare - a pre-made package of one or more flights, on one or more partner airlines, with specific restrictions and price. QPX (and all other flight search engines) don't search specific flights - they search fares.
If you miss a connecting flight, you will be re-booked on the next flight, but it all stays within the context of your fare. Not so if you split up your journey into two distinct tickets. However, a lot of people won't mind this.
In your example, you can split up your travel dates, and use part of the $1600 you saved to stay a few days in New York. I like to do exactly this - the cheapest trans-Atlantic flights are offered by charter airlines from London, and I like to make time for a few days stay there when flying from continental Europe.
Not a big chance of missing your next flight with that kind of window. Even if you know you are going to miss the next flight, with most airlines (but very rarely with charters) you can re-book up to an hour or so before boarding, for a fee that may be less than the difference in ticket prices you would have paid anyway.
This also works for round-trip flights. I often book round-trip flights as two different tickets. A lot of the time it is cheaper, but it also offers more flexibility (remember, you have to pay change fee and ticket price differences - and the airline might only have expensive fares available!) in case you want to change one of the departure or return flights (but obviously not both, as then you're paying 2x the change fees).
Of course, what I haven't said yet is how difficult this will be to pull off. Any travel company that does this will be boycotted by all major airlines. Many fares you're bound to buy this way are sold at a loss (better to sell for something than have an 80% empty plane flying and get nothing is one way to put it; there really is no easy way to price flights - most airlines have teams of math and OR PhDs working on pricing). The multi-flight fares usually have a larger margin tacked on.
The only way to solve this problem is really to nuke the existing fare system and start over. As long as "flagship" airlines keep getting bailed out by the government, they will be able to undercut the competition (and themselves) into bankruptcy with the irrational fare arrangements.
I live in Montevideo, Uruguay, and Buenos Aires, Argentina or Sao Paulo, Brazil are major hubs nearby (especially Buenos Aires which is an U$ 30 trip).
Last trip I made to Toronto (Canada) I just booked from Buenos Aires, and saved about U$ 400.
There's also the visa restrictions you have to factor in - for example I can't take any flight with stopovers at the United States because said country is stupid and requires visas for stopovers (!!!) - end result is I won't travel to the US, they've lost at least a few thousand bucks of my tourist money, make me book different carriers (I used Air Canada even though an US-based airline would have been cheaper) and make my life more difficult.
So, booking a flight requires nontrivial calculations for me :(
I want to know which is the easiest and cheapest way to get from point X to point Y (with a few options/alternatives I can choose from) at a rough time range. And that is any possible combination of train, car or airplane or whatever.
The nearby-feature is already nice (and I haven't even really seen that elsewhere) but I still found myself too limited. For example I don't care if I have to travel maybe 500km or even 1000km by train to another airport if that can save me 500€ or so.
I assume that doing these radius searches requires far more computational power than a "simple" single-origin/single-destination search, which surely must translate into a higher cost-per-query for QPX customers. Is this perhaps why very few QPX-powered sites actually offer the option?
Ahh, thanks for pointing that out. Searching for near SFO to near ITO in August returns flights for over $100 cheaper than what Kayak is showing. (Now I just wish I could actually go.)
Note: Tickets cannot be purchased directly from ITA Software.
If you find a fare you like, you can give the information from this site to your travel agent or airline when making a booking.
This is a deal breaker. I do not want to contact travel agent OR airline customer rep for booking my tickets. I want to find the best fare, enter my credit card and be done. Also, why should Travel Agent OR airline honor the fare which you posted when we all know that flight ticket pricing is highly dynamic?
ITA Software provides the back-end for other online travel companies. They don't actually sell tickets, so if someone is misinformed about their site and tries to buy a ticket they are told where to actually do so.
Given the detailed info from an ITA search result, any travel agent can book that exact fare, or determine that it has sold out. All those obscure codes do mean something!
And you don't even need the cheapest option. Anything within 10$ of the cheapest option is probably OK. (Allowing approximations make the problem easier, at least in theory.)
It actually doesn't. Unless you search directly from one airport to another airport on a specific day, it just pulls in cached results from old searches to get the best fares chart and the nearby airports data.
Is it just me or does that sound cheap? Though I'm sure Google has a far better idea of ITA's revenues than we do. CrunchBase says they had a $100MM Series A round in 2006, but they've been around since 1996.
I'm thinking that's going down as a 'returned 2x capital' sort of purchase on the VC score sheets, unless they took most of the company in the Series A. It's impressive that they ran for nearly 5 years on a Series A, if they did.
I also think the value for Google here isn't revenues so much as controlling another piece of the internet transactional infrastructure.
They have substantial revenue, so not taking much investment isn't surprising. I just wonder what the thought process was in deciding to sell to Google at this price.
This must still be a huge win for the founders. They probably still had most of the equity since they only took one round of financing, and at a point when the company was already mature.
The price does seem relatively low. ITA's revenues are probably not very significant for Google, so they may be buying purely for the team and technology. And for a team and technology acquisition $700M is pretty huge.
ITA has a big problem: their follow on to the QPX product that everyone has been talking about is a airline reservation, management etc. system called RES. This is desperately needed since pretty much everyone is running these systems on expensive mainframes with ugly old code bases.
Dan Wienreb did a very interesting talk, "Lisp for High-Performance Transaction Processing" that covered it and a bit on the future of Lisp (for a outline and link to the talk see: http://xach.livejournal.com/225634.html).
RES is a three tier system with Oracle RAC as the backend (pretty much the only choice), stateless Common Lisp middleware and Java with the usual web libraries for the front end. 300 milisecond? general max transaction time, which they weren't finding to be a big issue even with GC.
The problem: someone has to go first. While it's arbitrarily sized/scoped to accommodate American Airlines, Air Canada was going to be the lead customer. In August 2009 they suspended their participation in the project, I strongly suspect due to the general recession/depression in the industry. Switching would be very expensive in all sorts of ways and raw survival almost certainly is taking priority. (ITA has continued developing the system.)
This part/project of ITA is very likely to be a victim of bad timing; I sure can't see Google credibly continuing it, it's all wrong for their service culture, although perhaps it'll get spun off.
It's not the first project that I have seen that was cancelled. Building a PSS (RES and/or INV) is not a small thing, given that there is so much complexity in the airline industry which has to be supported. I think it would be very exciting if Google continued these developments. Some of the major players (e.g. 1A) are in a quasi-monopoly and they definitely exploit that. More competition would be good. (But I agree, I don't see why Google would want to compete.)
Btw, many of the PSS vendors already have or are currently in the process of renewing their "expensive mainframes with ugly old code bases".
Good points. You're probably right than it'll get spun off given the technologies behind it. I have to ask though, how much of this is a result of technological inertia as opposed to cultural inertia?
I don't think they'd have an aversion to buying a piece of legacy software written in Lisp if said software had a proven revenue stream and was part of the core underpinning to a major category of search they want to get into more.
However, it's reasonable for them to be averse to writing totally new projects in Lisp, in-house, because when you're at a huge company as a general rule you don't want dozens of different languages in use: it's inefficient and you lose out on a lot of opportunities to leverage skills across teams and across service layers if you do that. Lisp, from what I heard, didn't make the cut, despite it's strengths. They still allow a few though, and I believe they are Python, JavaScript, Java and C/C++.
That doesn't strike me as fitting the requirements. They need high transaction rates and true high availability (don't know if Bigtable is as good). And they don't need petabyte scaling, which I gather is one of Bigtable's big attractions.
You have a good point. You are kind of implying that it is good for transactions in large batches, but may not have the 300 ms response.
But the oracle RAC (just guessing here) may act as a cache between the 300 ms part and the actual tables, and to be a fat reliable pipe.
But they do take on some interesting problems, such as how do you keep this up across system upgrades, hardware failures, application version migration, among others.
ITA Software is one of the few remaining "sleeper" sites I use constantly but few people have heard of.
Its routing language and "graphical" view of flight times (which have each been there for what, 7 or 8 years?) are still light years ahead of anything else on the web in terms of travel search.
Let's just hope Google doesn't mess it up somehow.
Agree - I travel to some obscure places, and Matrix is about the only online aggregator out there that goes down to the level of sub-regional airline. It also displays (especially in that graphical view) routings that exist, but that the more mainstream travel sites won't advertise - things that there is no reason for a normal person to do, but which can be incredibly handy if used well.
There's no business reason to, but if they managed to integrate data from SeatCounter into that view, it would rock my world.
ITA Software does not market a consumer oriented flight search site.
That's probably not completely true. Matrix, although not a booking site, is one of the better flight search sites, allows consumers to find the cheapest time to leave and come back in a given month for a particular number of days of travel.
Although it's a bit of a reach to say that they "market" matrix/matrix2... It isn't terribly nice to use, they don't actively promote it, and they don't allocate it very much processing power.
That being said, I have always gotten the impression that they maintain it as a sort of testbed -- a huge number of Flyertalkers use matrix for very esoteric queries, and I'd imagine the feedback that ITA gets from those users is invaluable.
Not only will they leave it, this is the most important part for Google. I expect that they will spin it into a 'Google Travel' product and take over the travel market pronto
Google says "...we think there is room for more competition..." - but now they own both how most people find tickets and the service that provides the link between the airlines and the internet. My guess is that they will keep with their mantra of giving user's the fastest possible answer by providing links to buy tickets in response to queries like "cheap sf tickets". Problems for companies like Orbitz ahead?
Google is already starting to apply this approach to accommodation, another high value segment. Searches for hotels in most cities now return as their first result a Google map with listings of actual hotels - over time I expect these to become more expansive and traffic to independent hotel aggregators to decline. With the current strategy Google is moving to an approach where they scrape review and hotel data from all the aggregators and then serves this in its own listings - eliminating the need for its users to perform a secondary search with a independent aggregator.
I hope Google should 'behave' more like AT&T built unix and C rather than like Microsoft built Money.
Yes, I am disappointed by this move, not because I worry about the travel industry or the potential monopoly power google is holding in its hand. I'm disappointed because Google has yet to re-define the business rules for growth. Allow me to explain.
I understand that as a public company, it's Google's responsibility to create values for its shareholders. But that doesn't mean it should keep expanding into anywhere "consumer-facing problem that can be solved with huge amounts of (needs for) computation". Just like Microsoft keeps on expanding into any desktop software market that has a rapid growth.
There are so many important questions that are yet to be solved. The search is still a pretty dumb statistics engine. Google still can't distinguish between "who wrote python" and "when was python written?". Wikipedia's Python entry shows up in both cases and other results are irrelevant. Why wouldn't the company who invented "20% time rule" continues to make the web better?
Maybe that's the nature of public company and maybe this is just another case where human gets sucked into the rules of wall streets.
"I hope Google should 'behave' more like AT&T built unix and C." Well you have to remember more of the Unix Wars of the 80s. AT&T tried to sue everybody who had any dialect of Unix. The main thing that stopped that was showing that many of the code segments shared by BSD Unix and SysV Unix were due to AT&T lifting code from BSD (not the other way around). Plus in that era people started removing the C compiler from Unix distros as it was "too valuable" to give away. A very different world than now.
"AT&T tried to sue everybody who had any dialect of Unix."
Perhaps. They started with BSD (http://en.wikipedia.org/wiki/USL_v._BSDi), suing the initial commercial BSD vendor and the university proper. They utterly lost when it was shown they hadn't followed the BSD license with BSD code they'd incorpated in their own versions, that had been licensed to others and that were used for their own operations (they were thrown a face saving bone in the settlement that required a relative handful of BSD files to be re-written, but were otherwise skunked).
I'm not sure why they stopped doing this, although it's telling that Novell bought UNIX(TM) in the middle of the year in which AT&T settled with Berkeley.
There are at least two dimensions to this: "organize and make accessible and useful" and "the world's information". You're complaining about inadequacies in the former, this is a move to expand on the latter.
Hmmm, for that matter, they're buying some brainpower that could help them with your specific complaint but also the "organize and make accessible and useful" part of their mission in general.
I'm working for kind of a big travel portal and yes, we are shitting ourselves to the point that at least I am considering switching industries. I'm not even sure they did it for the content as much as for access to the raw data.
Raw, massaged data. From everything we've been reading ("the industry worships syntax, not semantics"), turning those data flows into something comprehensible is a major trick.
ITA's start in this reminds me of the FU MIT delivered to Xerox when MIT bought their first big mainframe Xerox laser printer in the early '80s. Xerox wanted $100K to reveal the format, so instead a group just took one or more output tapes (a normal data flow was the mainframe wrote to tape and the printer read them) and decoded it.
Huh? How is this content? QPX is "searching" on airline provided content.
OK, you could say that a QPX suggested route is content, but it's algorithmically built from on the fly constantly updated airline content. Very much like classical Google web search.
You are right, it's not content. But currently many OTA have not much more to offer as content. The OTAs are pouring huge amount of money to get those reservations made on their site.
Do you think that Expedia and the rest are thrilled to see this move by Google. The OTA have stopped the disintermediation at consolidation and economy of scale, now they will have to go farther or someone else will.
I've heard that the Python folks already drove most of the Lisp folks out. Lisp is only used for a very small part of their infrastructure, from what I've been told.
Farther down the same page they ask you to solve puzzles. "Puzzles submitted in C++, Lisp, Python, Java or Perl will be reviewed most promptly, because those are the languages we use every day"
If you (or someone else) wouldn't mind taking the time to explain it, I'd really like to know why your unsupported and vaguely anti-Ruby statement is so popular. I'm assuming that it means that the problems with Ruby are so widely known that you don't even need to spell them out in order for people to agree with you, but I guess I didn't get the memo. Why "really shouldn't" we? (Serious question - thanks.)
One thing, of all the dynamic languages the default Ruby implementation is by far the slowest. For anything that is slighty computational expensive, the default Ruby implementation is poor. Also think green, if you have lots of computation in a slow language, that easily adds up in a large data center in form of wasted electricity, which adds to cooling and is generally expensive. Some Ruby implementations try to get in the direction of, say, a Lisp implementation like SBCL - which is used by ITA. SBCL provides since quite some time a compiler that can generate reasonably fast code.
In Dan Weinreb's "Lisp for High-Performance Transaction Processing" talk he mentioned that SBCL was being used for QPX because of the quality of its compiled code (as I recall they started out with CMU CL so this was a natural choice).
For REs, Clozure CL was being used in part because faster compile times were more important and run time preformance was more than adequate; stateless business middleware is a very different beast than compute intensive route construction, where we can be sure the cutoff in optimizing choices is based on response time.
There were other reasons for Clozure CL, including the fact that it has a company behind it, one who's principles Dan and others have had long relationships with and ITA was buying one (man?)day a week of their services to support RES. SBCL is (has always been?) a volunteer effort.
Unlikely that they will go away from lisp. They are heavy users of SBCL (performance) and CCL (fast compile) and have some interesting fraction of a million lines of lisp code and might just be one of the larger employers of lisp programmers.
It also isn't a "location based application that lets you casually hookup with your friends" that used to be acquired in droves 2005-2008. This is a serious and existing, profitable business with a serious and scalable technology platform and experienced talent. Not just ambitious and smart college kids getting a slightly higher hiring bonus (not that there's anything wrong with that).
The critical infrastructure pieces (where GC is an issue) are already in C++. The front-end is already in Java. A full scale re-write will be a dumb thing to do. It's not going to be difficult to have Common Lisp FFI to hook the ITA middleware into Google's infrastructure instead of ITA's.
The software that ITA developers that makes them different from the rest (I am guessing lots of these are heuristic solutions to NP complete problems) is exactly the sweet spot for Common Lisp, where it provides a significant advantage over other languages even for large groups of programmers. While I will enjoy writing a web app in Common Lisp much more so than writing a web app in Java (less boiler plate, interesting language compensates for a mundane task) I doubt there are going to be great advantages to doing the more routine development in CL for a large corporation.
As I understand it, C++ to maintain the QPX in-memory database and SBCL to do the routing magic (which is even more non-trivial than you might think, e.g. a "best" result set is not 20 routes that are all within a dollar and that hit the same airports, etc. etc.).
RES uses Clozure CL (formerly OpenMCL, an evolution of Macintosh Common Lisp) for the stateless middleware with Oracle RAC for the backend and Java with the usual libraries for the web front end.
I'm a current ITAer working on QPX -- by lines of code, QPX is probably actually split pretty evenly between C++ and Lisp. But accounting for verbosity of C++, the logic is heavily on the Lisp side. I think anyone on my team would consider himself to be a Lisp developer before anything else.
It's so good to hear this. I'm always afraid that Python is going to squeeze out Lisp. It's a total absurdity, but people seem happy to learn Python and that puts a huge pressure on keeping Lisp shops alive.
"It's a total absurdity, but people seem happy to learn Python and that puts a huge pressure on keeping Lisp shops alive."
I think that it's less about learning, because Python is way more similar to languages like Java or C++. Using Python, they have to learn less. Than they discover some cool new features in Python and are bought. Then they don't see any need to bother further with lisp.
Yes, corporate travel is a huge market, but service companies like Christopherson are probably becoming less relevant in light of all this new competition. Wouldn't be surprised if Google took this on..
Also, package tours and cruises often include airline tickets and they are usually still booked through travel agents (or via the operator's website which I doubt counts as online airline sales).
My Mum was going online for flights yesterday (though she's never been one to go to a travel agent). I pointed her to Orbitz. She was impressed, but another (UK-based) website she'd tried was $200 cheaper than anything on Orbitz. Not sure why.
In the near term, may be no major impact (visible to their respective users anyway, though there will be ripples under the hood.) Longer term, generally some flavor of bad. However, as others have mentioned, one silver lining in this event is that it may increase demand for some sort of pseudo-ITA replacement company upstart to slide in sideways and takeover providing this service. Perhaps new ventures will be formed to do exactly this. But there will also be chilling effects on other enterprises and projects. So it's really hard to say.
It definitely takes Google one step closer to a position where they can make Kayak/Orbitz-like sites a little more irrelevant. Are they all the way there yet? Of course not. Also, Google has a track record of being pretty shitty in certain areas (like customer service, especially human contact, voices and bodies, etc.) and so those are areas where they can still differentiate. Plus, there's still no sign of Google wanting to get into taking the booking orders. Just the fare/trip search. Search of any kind is something that clearly their infrastructure and scale is going to have massive competitive advantages in delivering. Booking: not really. And many OTA's and metasearch sites make their profit on booking fees and kickbacks, not really on search itself, which for them is more of a cost center (though they do sometimes monetize those use cases too in various ways as well -- this is where they will hurt the most, in medium term).
Also, Google has said it plans to honor the existing ITA contracts. But who knows how long or how pervasive that will be in the future. I personally know of one startup that came very close to signing a contract to get service from ITA and we actually backed down ultimately, in part, because of the fear of lock-in to their service. Plus they were expensive. ITA is/was a bit like the Oracle of fare search products. Good shit, but really expensive shit. At least for a wee little startup.
They also power most of the meta search sites, which Google is easily positioned to become (and link to actual OTAs for booking). Huge conflict of interest.
However, ITA is not the only option out there, and given the concerns I bet everyone has with their contracts there's now room for another data provider to jump in and snatch up contracts during renegotiations.
A general rule of thumb I find valid is if there's some consumer-facing problem that can be solved with huge amounts of computation, Google will get into it. They certainly have the infrastructure for it.
(I'm a former TripAdvisor Flights engineer, which is owned by Expedia)
I dunno. Do people really have trouble finding the cheapest flights with the likes of Kayak and Farecast around already?
My question is how this acquisition really helps travelers. I can see how it might help Google possibly become an online travel agent, but how does that help me when the carriers set the prices anyway? Are we hoping for Google discounts or better visibility of seat sales? Or is there something that Google can do to really change things beyond how ITA already has?
It's not just about prices, it's about routings. For roughly the same price (give or take $100), I often have 50-100 options for each segment, of wildly varying convenience and robustness (in terms of flight time, layover, delay likelihood, airline, etc.). Their system does an incredibly good job laying out this info in a comprehensible form, and more importantly, providing an advanced routing language that allows me to say, for example:
MSN :: AA ORD AA X AZ
BLQ :: AZ X AA ORD AA
...which means I want an American Airlines flight from Madison, WI, connecting through O'Hare, and continuing on to Bologna, Italy, with one and only one intermediate connection, with the over-the-pond leg on AA, and the final leg on Alitalia.
It can then lay out the options for me graphically, so I can instantly see which flights have nasty layovers or bad schedules without having to parse a single text digit.
A Google buyout of ITA could improve things in one simple area: resources. As in, way way more. Hardware and cash.
Even if Google made no significant changes to the behavior of ITA's existing code, if they instead just tweaked it to run on say millions of cores, highly distributed and parallelized in Google data centers, with gajillions of cached results -- endusers would probably be able to see better, fresher, more "long tail-y & last mile-y" and faster results. I'm just making an educated guess here, I could be wrong if there's some fundamental bottleneck in the ITA architecture I haven't considered (and someone chime in if you know that to be the case) but I don't think this will be an issue.
As far as I know ITA's QPX system has no inherent insurmountable bottlenecks, but I'm not sure Google's scale will make much difference anyway:
There's a C++ backend that collects and massages the various data streams and then loads the data into an in memory database. Much of that is quite parallelizable, e.g there are various data sources, the massaging probably needs only so much global state, etc.
The computational front end is an SBCL process that does its magic based on a copy of the in memory database. One process, one query at a time, that scales out very nicely.
I suspect the biggest tricks besides groking the data (hard since it's so messy and special cased) and their secret sauce that does the routing is maintaining the required availability. There I suspect ITA's service/operations culture has things it can teach the corresponding Google culture.
"ITA's QPX software tool for organizing flight information is used by leading airlines and travel distributors worldwide including Alaska Airlines, American Airlines, Bing, Continental Airlines, Hotwire, Kayak, Orbitz, Southwest Airlines, TripAdvisor, United Airlines, US Airways, Virgin Atlantic Airways and others."
to differentiate from old fashioned bodies-in-seats-in-office-somewhere travel agencies that you had to call, fax or stroll into in person. Agents there typically sat in front of either a terminal connected to a GDS like Galileo, or, more recently, a Windows box with native apps doing approximately the same thing. Agents would perform queries for you on their computers and they sometimes had to type in a sort of mini-language full of various commands and brief codes.
This event will also have a chilling effect for some travel startups. Though maybe act as an accelerant for others. Either way it will impact almost every company in the travel space. (Assuming its not blocked by govt.)
I'm quite surprised that with some of Google's recent pickups more people aren't concerned about how it may negatively impact competition. We might get a better travel search out of this but I personally would have enjoyed seeing a company other than Google be successful at search for once. Same with AdMob -- Google is already a giant powerful advertising company. Not sure they really needed to gobble up AdMob to be successful there.
Part of Google's challenge may be that many of the best engineers now prefer to go the startup route and build something they're passionate about, rather than join a large corporation, even Google.
And Google's ~$25B in the bank is much better spent buying and integrating those companies than investing in mortgage securities and whatnot.
How has Google's history of buying and integrating companies gone? I know about successes like Android or Google Voice, but what about failures? I guess there aren't any epic failures as of yet (we'd know about them), but it's unlikely they've been 100% successful.
Dodgeball's a commonly cited failure. The founders left two years after being acquired to start a very similar competitor, which even has a hilariously similar name (Foursquare), and then Google discontinued Dodgeball two years after that.
Some hits, some misses. It's hard for anybody to say with authority just how many should have been hits but were not. I think it's unrealistic to expect ALL of them to be a net win. Nobody can predict the future, not even Google.
NOTE TO SELF: start a web-based service that successfully predicts the future. Sell out to Google.
