For those unfamiliar with ITA Matrix, it was for a long time the go-to flight search tool for the most dedicated flight hackers, points hackers, etc.
It was built by ITA Software [1][2] in the early-mid 2000s (the earliest mention I can find of it is in 2004 [3]) to test and showcase the capabilities of their flight search platform. I once heard that ITA and other consumer-facing flight search companies had tested that kind of UI with ordinary users, but found that not enough people understood or liked it enough for them to justify making it a mainstream interface.
Hipmunk, a YC-backed flight search site that launched in 2010, was heavily influenced by the ITA Matrix UI, after co-founder Adam Goldstein had found Matrix to be the best way for him to find flights when travelling around the world for college debating competitions. And while Hipmunk did a good job of being more consumer-friendly and popular than Matrix had been, sadly they didn't gain enough traction to make it as a standalone company, and after being acquired by SAP/Concur, it was shut down last year.
It's an interesting, and perhaps depressing case of a product design concept being far superior to what's available in the mainstream for a certain class of user, but cannot gain enough mainstream acceptance to be a viable business or even a well-supported service for those who love it. And far more than most other product categories, flight search has huge infrastructure costs, so it's very difficult to economically sustain niche products (from grim personal experience of being part of a team trying to build a novel flight search product ourselves).
In this case it's just lucky that Google owns the infrastructure and has enough enthusiasm internally to keep it going to some extent.
Hipmunk was OK, one of "the better" free tools out there.
But I'm afraid it never had anything on ITA Matrix. ITA always had copious amounts of extra special sauce.
I extensively tried all competitors I could find (including Hipmunk) on a variety of real-world scenarios. Nothing ever came close to ITA and I was very worried indeed for its future when Google bought it.
Yeah, but you couldn't buy tickets on ITA which made its special sauce only go so far. What's the point of building the best schedule if its unpurchaseable, or unpurchaseable without a travel agent?
Hipmunk actually let you use ITA syntax to search for very specific route constructions, which you could then buy.
There's some sites that let you paste an itamatrix itinerary and show you places where you could potentially purchase it (eg https://bookwithmatrix.com/).
If that doesn't work and you really want a specific itinerary, I've had good luck with amex travel concierge, where I provided them with copy-paste of ITA matrix and they made the booking.
This was part of the benefit IMO, noobs couldn’t burn a ridiculous deal instantly. Our $900 business class (90% off error fare) YVR-HND-SYD roundtrip on ANA with free stopovers was the best one I ever booked with ITA’s help.
IIRC, ITA gave you the flight details in the special syntax (code) that travel agents use, and you could just give that code to a travel agent and they'd be able to buy that exact flight for you.
Google is sometimes the same - presents an option for either calling an agent (never worked for me) or buying same flight for $20k. Then you go to SkyScanner and get same ticket for maybe 10% more but via dodgy-ish website.
p.s. Google seems to be the worst at bait and switch, but that's different story.
Hipmunk had a great feature for sorting by “pain” and filtering takeoff / land times easier than anyone.
But ITA was so comprehensive you could find loopholes, like when you add an additional destination and your first class ticket drops in price by 50% etc. It is super missed in the mileage community!
Seems they will charge a subscription to access this - at first thought I wondered if this is the best option, and not just charge a per-leg fee like https://flightfox.com (who do concierge travel services and I love them) but I suppose, if you get the flight schedule you want, many people will instead jump and book direct with the airline. This can be good, if the flight aggregator is a behemoth and will not help you in case of problems, or bad if the airline is a behemoth.
We’re actually moving away from the subscription model - you can visit our homepage and get the extension installed for free now. The official announcement goes out Monday…
[and yes… that was why we went with a sub model over pay per use]
Between ~2000-2010 I worked for an international airline and I can share that we were testing a lot more innovative search interfaces for consumers. This was still pretty much the dawn of online ticket sales, and people were still either calling an airline or going though a travel agent. I remember our group for ‘online sales’ was a team of literally ten people and technology was mostly outsourced to vendors so we were initially more of a marketing group. I remember the year we joined we crossed $1M revenue for online ticket sales and that was actually a surprise to a lot of people in the company.
This was my first real job after graduating, and one of my roles was industry research and putting together a weekly newsletter of interesting technology to keep an eye on and when ITA released Matrix we loved it.
Long story short, we wanted to do a lot of things like this, but our airline (and most others) were not developing our own tech and instead using some technology from the major GDS companies (Amadeus, SABRE, Galileo). One project I was on was working to try and implement just a basic fuzzy date search (eg +/- 3 days of your preferred date) and our GDS was quoting us something like $3M and 12months to deliver.
Luckily we had an exec who understood business, technology, and design and got resources to build out internal technology team and we started building our own technology that freed us from some of the constraints of GDS to great success!
Others have replied well but I’ll add my own answer...
In order for your flight search product to be useful, you need a database containing effectively every flight in the world - all the airlines, all the destinations - and you need to update it every time a fare or seat availability changes. Then you need optimized routing algorithms to find routes that accommodate a vast array of consumer preferences. So, there are giant costs just to get access to all the data in the first place, then write the code and run all the servers.
ITA Software offered this as a service via an API, but since a couple of years after Google acquired them they stopped offering access to outsiders.
Now the GDS companies (Amadeus, Sabre, Travelport) offer API products, but they are still very costly, so big transaction volumes are needed to justify it.
There is now one way small/niche businesses can offer flight search and transactions fulfillment; a YC company called Duffel. They still only offer a narrow selection of airlines, but it’s growing.
Some other companies like Skyscanner offer access to their API, but only if it’s in their interests (ie, if you generate sales for them; you can’t make much revenue for yourself that way).
The reason Google continued to offer API access after the acquisition was because a 5 year stipulation was in the contract to get it approved by the Department of Justice. Of course once the 5 years were up that was it. ITA had also built a reservation system for Air Canada. Air Canada never used it, but Cape Air switched in 2012. In 2013, Google discontinued it.
The whole acquisition was a huge failure on the part the DoJ Antitrust Division.
The answer above has some good information, but it's also munging together unrelated topics. Flight search APIs that aggregate other, existing, APIs (like the mentioned Skyscanner and Duffel) aren't the same thing that ITA flight search or the Amadeus/Sabre/Travelport flight search engines are.
The hard problem the flight search engines solve is initially for the airlines. They have aircraft of different capacities, ranges, seat types, and so on. Then, different tiers of fares based on seat type, advance purchase, refundability, add-ons like priority boarding, bag fees, inflight wi-fi, etc. Then, a "flight" is some combination of actual flight "legs" (single takeoff + landing).
So, airlines want to maximize revenue. To do that, they set available inventory levels for many of the unique combinations of all the variables above. Perhaps, for example, only 10 of the "deep discount" point-a->b->c coach seats, but 50 for the highest priced b->c leg. Oh, and the price is higher on day "X", because some popular sporting event is held in city "c" on that day, and the morning flights priced even higher.
If you extrapolate then, you can tell that someone wanting to fly from a->c has a lot of different possible fares, with each fare having a different number of available seats to sell. And all those variables are changing underneath your search, all the time. And, you're obligated to show actual fares, including taxes, fees, etc, which vary dynamically by airport, pax type, etc.
Companies like Amadeus, Sabre, Travelport, and so on did a reasonably good job over the years of exposing APIs to both airlines and travel agents to search these. ITA came along with a more computer science based approach and made the shopping part of this much faster, with more results, flexible, more tunable by the airlines, etc.
Sure, but plenty of those jobs still around. In fact they've been struggling with the rest of the market in filling positions. AmEx travel is constantly recruiting.
The graph problem is huge (NP-complete in the full case). You can't reasonably cache things because segment availability changes a lot. Latencies on searches through the GDS may be much higher than you're used to in other domains. Due to all these factors and more, cost per query is quite high. And then on top of all that, conversions for flight searches are quite low and the reward for converting a search is on the order of single digit cents.
Basically the problem is the airlines don't want good flight search so they erect barriers, right? Airlines prefer to have pricing and route info be opaque so they can keep people using higher price options. So the infrastructure costs are about fighting to get the information from people who don't want you to have it.
On the counter-side, if there are 300 seats on a plane, worth $100 each, and everyone does 10 flight searches before booking a flight, that means that your database needs to hold a few hundred bytes about prices, the plane, and departure time, and handle 3000 queries, and for that you get a chance to make a commission on $30k in revenue.
There aren't many computing platforms that could offer a higher profit margin per byte stored or queried!
Every single one of your numbers can be orders of magnitude off. Many people search without buying, there can be hundreds or thousands of fares for a single flight, and industry margins are razor thin. If you're lucky enough to actually get a commission (unlikely), your percentage will still be junk. Skyscanner (much bigger than you) is earning in the single digit percents and I have no doubt there's a cap in many of their agreements.
Pretty much any other computing service has a better ROI.
When I do 10 searches, each of those searches hits a substantial subset of every flight that could satisfy my travel need. Suppose I want to fly BOS to LAS for re:invent. For the outbound leg, I’m probably searching for Sat through Tues, every carrier, every leg, every cabin. That means a leg BOS-SLC, BOS-ORD, BOS-ATL, BOS-LAX, etc are all considered.
You can’t easily prune the tree on cost or time because you don’t know my preferences. You might notice that most pruning is done only on segment count, with (almost?)no one by default showing itineraries with 2 additional segments over shortest. I might prefer a carrier (I do), but even if I do, I still want to see the other choices, because my preference isn’t thousands of dollars strong.
Rather than 10 queries per seat sold, I’d not be surprised if the actual query count was 10K or more.
Airbnb's customer experience team used Hipmunk as a fallback for a long time. The last resort before just hanging up and promising a check was HotelTonight, until Airbnb acquired that.
How did Hipmunk mess it up so bad? It was seriously one of the most pleasing web apps to use, even under time pressure.
The comment you replied to seems to have a fair assesment of why it failed
>It's an interesting, and perhaps depressing case of a product design concept being far superior to what's available in the mainstream for a certain class of user, but cannot gain enough mainstream acceptance to be a viable business or even a well-supported service for those who love it. And far more than most other product categories, flight search has huge infrastructure costs, so it's very difficult to economically sustain niche products (from grim personal experience of being part of a team trying to build a novel flight search product ourselves).
I feel like mess it up implies by default all businesses have product market fit that they "fumble" when in fact that's the hard part in the first place.
Playing with this version, it's a little easier to use, but I don't see any functionality not in the regular version. Still, if it means Google is investing in Matrix, that's a good thing. I always worry at some point it will be killed.
The speed and usability of this website is so refreshing compared to all the other flight search sites. All the input boxes are normal and shown on screen at once, the calendar and airport selection autocompleter dropdowns work instantly with zero lag or animations, and then it shows the results after 2 seconds of processing time.
The new design in the OP is still decent compared to the alternative websites, but slower and harder to use compared to this original design (to me, who had never heard of Matrix before).
> Still, if it means Google is investing in Matrix, that's a good thing. I always worry at some point it will be killed.
This isn't Google investing in Matrix, this is a group of people who work at Google using their spare time to rewrite the product so it doesn't get taken offline.
If anything, the lack of a dedicated team or resources is a strong indicator that Matrix will be on the chopping block at some point in the future.
There isn't a dedicated team because it's not a business product, but internally it's considered very important because it essentially allows power users to beta test our backend. For that reason alone it will be kept around and supported indefinitely.
Wanted to self plug a community project I maintain that continues to enhance ITA Matrix, Powertools[1] and see if anybody wanted to help port it over to this new front end. PRs accepted!
I always loved the creative solutions ITA could find, like transferring to a ferry to shuttle to another airport. To the cost sensitive adventurers, ITA was invaluable.
The reboot is much snappier than the old ITA, and it now supports mobile properly! Looking forward to using. Glad Google engineers are applying their decades of experience honing Traveling Salesman type interview questions to the real life problem.
As a 20%er who worked on this it’s a bit discouraging to see such a shallow dismissal. A lot of people put in a lot of work as a passion project to keep matrix from just disappearing.
As someone who has done some of the most extreme/risky forms of travel hacking (serious FD's with 1X + sX for those familiar with lingo), Matrix lost a huge amount of its value when it disallowed searches that start from multiple countries. It's tedious to have to break up a search. Of course, this is not necessarily what they intended it for, so I can't really complain too much.
And covid uncertainty these days has made proper flight hacking a bit of a pastime.
Can I ask where is good to trade info and stories about this stuff? I have been on FT for a long time, but never came across this level of fare exploration. The extent of my enthusiasm is years ago jumping on things like the Icelandair or BA WT fare mistakes. Never actually searching / generating fare loopholes.
Maybe I'm reading the wrong forums. Even just to hear about it interests me (to know what I'm missing out on)...
Unfortunately people guard this stuff closely for fear of airlines catching on, or at least they used to. I haven’t looked at it seriously in a couple of years but airlines were making a real effort to tighten up fare rules to cut down on this. Even when I was doing it a lot, all of the easy stuff was already mostly fixed, save for the odd mistake here or there.
I for instance would never post the hacks I’ve discovered, and would only share them with a select few. It’s self preservation, but once they’re known, travel bloggers spread them and every Karen ends up doing it.
Kayak licensed/used QPX from ITA back when they were an independent company. Google acquired ITA and as part of the regulatory approval had to operate the APIs for at least the next few years. Kayak continued with QPX, but slowly shifted over to using Amadeus whenever they could. I imagine they've completely switched by now, given how bad the Google <-> kayak relationship is.
That's slightly frustrating to hear that Kayak are getting messed about by Google, as Kayak is about the only flight search tool that I've used that suits the airport situation in the UK.
(e.g. 4-5 international airports reachable within 1 hour drive, another 2-3 reachable within 2 hours drive, flexibility to search across all of them).
The other flight search tools that I've used might, at most, allow one alternative airport.
It seems that (at least the new) ITA Matrix Search can do that as well: Once you select an airport (or city) as origin or destination, it gets added to a list of possible locations.
Being used to Kayak‘s comma syntax, I did not find this intuitive at first. But in fact, it is pretty convenient and powerful.
ITA and kayak were organizationally close in a lot of ways. Kayak brought lots of useful data relationships to the table and ITA brought their technological wizardry. Google was a direct (and hostile) competitor to kayak, who led the anti-trust charge to stop the acquisition. The post-acquisition hostility is just the standard SV playbook stuff like prioritizing Google products in search results and offering amazing incentives to build market share.
I have no particular insight here beyond a general interest in the industry though.
I like it, worked well for the few tests I did, however the main form needs some small UX improvements, I chose a start airport and destination airport but then the search button was disabled, leaving me clueless about what field was not filled out correctly, I quickly noticed it must be the date field, but still to me disabling a submit button of a form seems like a bad idea because if disable it you also remove the display of potential error messages related to the form failing validation, which to me is a UX no go (take my opinion with a grain of salt, I'm not a UX guy). The second thing that bothers me is that none of the form fields actually tells you which ones are mandatory and which ones are not
> Unfortunately, the current Matrix website implementation relies on an internally deprecated web platform slated for retirement.
GWT, as you suggest, is definitely a dinosaur.
> rewrite Matrix using newer web technologies like Angular,
How long until Angular goes the way of GWT, though? It's not exactly a beloved technology. Not quite the same level of pain as GWT, but Angular codebases aren't something I'd like to maintain either.
In 2014 most of the AWS console was written in GWT, and I worked on one of the services. Honestly? I kind of loved it. As a backend Java dev, it made a lot of sense to me, and I almost never had to touch any Javascript.
Every service team at that time chose their own tech stack, and so sometimes I would hunt for ideas of how to implement something in other team's codebases, so I got to see the different tech stacks.
For a brief moment Angular was really popular, and then fizzled out just as fast. For me, it was the worst of all the options by far.
It is not beloved on HN, on Java and .NET shops is the usually the SPA everyone goes for, given the similarities with MVC frameworks, and it was build from scratch for TypeScript, not something that some comunity person is writing type libraries for.
We wrote Application (medical) with GWT in 2010, and we still maintain it, occasionally adding new features.
Once you figure out build step and magic incitation to make debugger work (and docment it), It's really not bad,
and maintaining is easier then most other "older" codebases I come across.
Old rubby/php/javascrip(jQuery/whatever) project is usually pain because they all use tons of external packages/libs that you have to update find new ones etc every time you take project off the shelf. With GWT and Java it just works, because we didn't use that many other libraries and Java libraries generally put a lot more effort in backwards compatibility.
So no I would not start new projects in GWT anymore, but I think that current react projects will be a lot harder to maintain in 10 years, than GWT is.
I've never understood all of the Angular hate on HN. I do understand the fact that it's very much the "corporate" option like .NET is, but that doesn't make it bad. I actually really like it and find it very intuitive.
In my short time working with it, I found it frustrating to debug. Using an incorrect tag meant it would simply be ignored with no indication of why my thing doesn't work, and I found tracing issues back to their HTML tag to be annoying.
The equivalent React/Vue/etc would throw a Javascript exception. Stacktraces aren't the best debugging experience, but they're functional.
I also think Angular inherits from a more traditional UI lineage of composing styling on an element, which I find less clear than something like React that has a more backend-y development flow. That's just personal preference, but I started on the backend so Angular's "build an element and then wire it up" makes less sense to me than React's "figure out the data flow and then build elements on that" style.
I don't find it showstopping. I wouldn't turn down a job because they use Angular. If someone asked me what framework to use, I just probably wouldn't suggest Angular.
I'm not sure that's true. They don't reveal separate numbers for GCP, but they put it under "Google Cloud" umbrella with Google Docs and other products. The revenues are growing, but they're still losing money: https://www.crn.com/news/cloud/alphabet-earnings-google-clou...
Were these rumors based on anything other than "Google will shut it down"? It is always the top comment no matter which product or service we are talking about, so it doesn't mean anything
Google acquired ITA in 2010. Cape Air switched their entire flight reservation/departure control system to ITA/Google in 2012. Google discontinued the system in 2013.
That is absolutely not true. While React has a big piece of the market right now, it has not "clearly won this ballgame". Both Vue and Svelte are very much active in the industry and gaining terrain fast.
Frontend development is an extremely fast moving field and claiming a "clear winner" makes no sense.
Having said that, I agree that Angular may not be the best option in the general sense, but given that it is a Google-backed framework, they probably have the best talent available to build tools efficiently.
Look at how many jobs being offered in angular, vue or svelte vs react, in any given freelance job portal.
It's 1 to 5 at best.
If you want to punish your project and have issues hiring from a limited pool, sure go ahead.
Yes, most current job offerings may be for React, but Angular had that spot a couple of years ago and ruby on rails was the cool new thing to work with before that. My point is that this is not a permanent thing. Technologies change, preferences change. React will be replaced with better tools for the job (IMO Vue and Svelte are better designed than React), I am sure of that. Besides, if you are going to hire by limiting your pool by frameworks, you are doing things wrong. Any decent developer that can work in an Angular codebase should have no problem with React, Svelte or Vue.
I'm honestly surprised 20% time is still a thing at Google. I would say around 8 years ago when I spoke to a Google employee they were saying it was there but basically the 20% time went towards things that were basically just an offshoot of that department anyway. And then I haven't heard of the 20% time at all in the last..maybe 5 years, although I don't really know anyone who works at Google anymore. It kind of reminded me of the vibe with postdoc students having to stick within their advisor's field versus really being able to do projects for themselves.
In my early years I worked at a airline commerce redesign with people from Amadeus (migrating from their e-retail to WDS, great team). It was an awesome experience, as the channel had still a low penetration (2% of sales) on the airline overall sales and the team left lot of the product ownership on my hands (an external consultant). I remember playing a lot with the search features including allowing pax to:
- Search for a date and no destination to get the best deals for that range
- Search for a destination but no date and get a month matrix with the best rates to travel to that destination.
Of course they were barely used by paxs, but I liked very much to leave these kind of easter eggs for more advanced users.
Something I never understood about Google's 20% time concept...do people at Google not have deadlnes?
Like it's just assumed that every project estimate will be added 20% to account for 20% time?
Like it's great when you're a market gorilla dominating the competition in search, but how does it work when you're #3 in the cloud and trying desperately to compete with Azure and AWS from behind. Do those people get 20% time too? Seems like a recipe for always staying #3...
20% time varies widely across the company, and the ability for an engineer to take their 20% time isn't as sacrosanct as it once was. On many teams it's discretionary depending on current team load (though on the teams I was on, generally granted if only as a matter of maintaining morale). Not everyone has a 20% project all of the time.
People still have deadlines, but the amount of work you commit to doing for a particular deadline is scaled by people's availability - and that includes any 20% work.
It's generally not useful to think about project estimates as padding 20% extra time - because deadlines tend to be exogenous (holiday seasons, launch events, etc.) and less negotiable, and more as scope of work that can be committed to in a particular period, which is something you actually have control over.
I've never worked anywhere that deadlines were set with enough precision that +/- 20% would be distinguishable from noise. I think it would be lost to more significant factors like differences in employee productivity and unexpected roadblocks
Maybe there is a Pareto principle (80/20 rule) effect with these side projects: for these, you get 80% of the benefit (vs. working on it full-time) with only 20% of the hours. And for the main gig, maybe it’s 90% of the benefit for 80% of the hours. So, 1.7 for the price of 1? Sounds like free utils to me.
Plus: positive effects on employee morale/retention, skill and network building, (pseudo?) R+D / asset development, etc.
Disclosure: I’m far too dumb to work at Google. Discount accordingly.
I'm on a similar plan with 10% (not at Google!). It's not really deadline sensitive. The 10% projects tend to be long-term so I can easily move them off my schedule for a while and spend more time on them after.
The whole thing is optional for us anyway and in fact needs to be approved every 3 years.
And I'm not really 100% occupied at work anyway. If I were, how would I fit in learning, networking etc?
Google owns the stuff you make during 20% time, iirc, so they use it as a feeder for new products.
Allegedly (I can't verify, but can't see why they'd lie) GMail, Google Maps and AdSense were all born out of people's 20% time and Google just swooped in and turned them into full on products.
It might be worth staying #3 in cloud if they could pull off products like that again. I can't help but notice that those products are all old, though.
From all I can tell, Google Maps was not started from within Google, but started in early 2003 as Where 2 Technologies [1] and was purchased by Google in October 2004 [2].
Google Maps started off as KeyHole, a technology company that was funded by In-Q-Tel aka the VC arm of the US Central Intelligence Agency (CIA), it was acquired by Google.
Why? That just means you need ~20% more people - a bit more because people don't scale like that, but Google has to scale regardless so it's not much difference. And this is an org that allegedly creates projects that will never go anywhere just to keep talent in house and busy, so I'd say they certainly can afford 20% overhead.
The 20% time rule might be useful in attracting good developers and keeping them from leaving too soon. So in the end it might be more profitable for the company to pay people to play around.
You're still taking a 20% penalty hit to your productivity. And if you're 3rd in the market and actually care about getting to #1 (Maybe GCP doesn't), that's a massive impediment.
I would imagine that a lot of the 20% projects end up being incorporated in, or part of something profitable. Adsense, for example, was a side project.
From what I understand the rule is that you get to choose what you work on, but it has to align with the company.
So what you end up with is that your most talented/intelligent staff end up working on, and learning about things that they think are interesting and will help the company.
Former Googler. I can't recall ever being told when or what to do. Management is more backwards-looking and individually-directed, at least where I was sitting. I had to write about what I did every year, and then people would say whether that was good or not. Organizational goals were objective and coarse, such as cut build times by half by end of year, or whatever.
> Google let it rapidly deteriorate after they purchased it.
Is that true? They have a team of people working on SBCL and at ELS a few years after the purchase by Google they were talking about SBCL work to support the app.
The choice of Common Lisp is less flattering than one might hope because it was largely the result of familiarity (Carl de Marcken's doctoral thesis was in computational linguistics and he was most comfortable using Lisp). When I asked him (c. 2007) whether he would have chosen Common Lisp again, he said that he wouldn't have and that he would have chosen Java instead. I don't recall any mention of technical reasons during that exchange (maybe static analysis?), but I do vaguely recall hiring considerations.
(Also, while much of the "business logic" was written in Lisp, a good chunk of low-level stuff was written in C++.)
ITA for a long time was the "poster boy" exemplar case whenever anyone asked whether Lisp was being used for anything big in the real world.
I worked for Orbitz during the era when ITA was still independent, and we used their flight search software in our backend. ("QPX" might have been its product name, that used Lisp, but been a while.)
ITA should instead be the poster child of clueless computer science stunts that actually are not that helpful. The fact that ITA can find and suggest that you could do this trip at a higher price but with a 24-hour layover in Charlotte, or with a 48-hour layover in Charlotte, or with a 96-hour layover in Charlotte, ... Someone with good taste should have stopped these crazed graph theorists before they reached the keyboard.
It looks powerful, however since it doesn't seem to include any results for Ryanair or Easyjet it's pretty much useless for short/medium haul trips in Europe.
I use azair.com for that, although it seems to be quite technologically primitive behind the scenes(complex searches take a long time).
It's not primitive, believe me... It might rather be because no one else makes such complex searches possible (perhaps with the exception of ITA).
Take an example: From anywhere in Germany to anywhere on the Mediterranean coast, next summer, max. 1 connection, for 5-8 days, return to same airport: https://azair.me/!4gDR ... is generated in 2.3 sec. That's not long
With Trabber you can choose "nearby" airports for either departure and/or destination airport. It includes Ryanair, Easyjet and many smaller European airlines.
You still can't do a search with origin from multiple countries, which annoys me. If I want to find the cheapest ticket for a cross-atlantic trip, it would be very helpful to have such a feature.
Kiwi used to have this in their map view -- you could select a very large circular region regardless of country as the origin -- but it seems like they got rid of it.
This was by far the most useful tool to identify cheap segments and cut down the space of options.
You used to be able to. It was brilliant, you could do a quick relocation flight, even make it a nice little first stop, and then get a nice long haul somewhere else.
I want to search for a flight with as many multi-day stops as possible, while keeping the price low. Whenever there is a stopover, I'd like it to be 24 hours plus, so I can explore that city.
Ie. give me the most circuitous route, so I can explore the world.
You can do this sort of thing in ITA Matrix, it still takes a lot of work to craft the itinerary and learn the syntax, but I have used it to do exactly what you suggest, and found cheap 36 hour bonus stayovers.
I wouldn't mind if they federated with Matrix. In fact that would be great. I would mind if they try to control it. Which inevitably happens when a major player invests into a FOSS project on a big scale. They'll start to worm themselves into steering groups and then use that influence to get some return on investment and start steering things towards their goals. In Google's case that would mean lock-in and datamining (and ads but I doubt that would ever fly on Matrix)
And indeed like zaik said below, they used to do XMPP and stopped it. XMPP is pretty good too these days by the way. But I prefer Matrix because of its bridges.
Ha yes, reminds me of this quote from "100 years of whatever this will be" (recommended read) that trended on HN [1] yesterday:
> Software intercompatibility is trending toward zero. Text chat apps are literally the easiest thing in the world to imagine making compatible - they just send very short strings, very rarely, to very small networks of people! But I use at least 7 separate ones because every vendor wants their own stupid castle and won't share. Don't even get me started about books or video.
On the other hand, both Dendrite (Go) and Conduit (Rust) are usable on the public network, despite being beta. There are some missing features, but people can and do run them for real, and both projects are super promising - and with more contributors, they'll land even sooner.
Needless to say, this has absolutely zero to do with ITA's Matrix flight search system :P
There is the main python implementation Synapse, there are two Go implementations (Dendrite and the other chinese finance chat implementation) , one very active and one nearly dead Rust implementation, a half baked c++ implementation and some others.
This is the Chinese implementation. From the README and website it seems its being heavily used in production but the website is Chinese so I dont know for sure.
On first read I just saw "...nearly dead Rust implementation" and didn't notice the previous fragment saying there was another very active one. Just a reading comprehension fail but maybe the sentence structure tripped up others like it did to me.
Yeah but none is production ready. I used to host a matrix node with synapse but it's a waste of time because it doesn't scale well and once you realize that there is no way to convert your users over to a better server software.
So now I'm just waiting until Dendrite or Conduit become fully featured to deploy one of them instead. I'm looking at matrix hosting long term, and synapse is not long term.
I'm not saying I'd reach matrix.org levels, but I am kinda anal about having something that could reach those levels. So that my users won't experience issues. Because once you pick a matrix server implementation you are pretty much stuck with it. Migration would require a lot of hours of converting users, and might not even be possible depending on how the passwords are encrypted.
I know people who've been hosting the same XMPP server for decades. So this really shows the immaturity of Matrix. I still believe in it but it needs some more time.
Well Matrix isn't as old as XMPP yet, so no one could have possibly hosted a Matrix server for decades, but I've hosted Synapse for 5 years now and steadily getting more family/friends on that instance.
No problems so far and performance has been steadily getting better. There was a low period when performance was not up to par about two years ago, but ever since that's been fixed, it's been smooth sailing.
I'd say just stick with XMPP and extend the protocol to fit modern needs. If we want an universal chat protocol that's going to last, reinventing the wheel is not going to get us there.
Maybe I don’t understand, these are Google employees, right? Why are they volunteers too? Google gives employees a day long sabbatical once a week, thus 20%. Aren’t they paid to work then? What’s so dedicated about their offsets?
Wouldn’t it be better to say something like
“A subset of Google employees chose to use their weekly sabbatical time to retire technical debt for Matrix”?
By "volunteering" I assume they mean the fact that you can choose what to do with that time, assuming you actually have it, within the context of the company. So it is an actual choice you have as to what to work on, which isn't usually the case with your normal job duties.
Whether those hours end up being unpaid overtime ("120% time") or not varies wildly from time to time and team to team, in my experience there. I had a real 20% project while I was there ~8 years ago (porting modern Linux to a vendor device Google used internally), but I also stayed late quite often too; I can't say I know for sure how it added up in the end.
Sounds like this is a term used to make them happy about working additional paid time on a Google-owned product. I mean, if they spent this volunteer time (even if paid) on a public good, I could appreciate that, but choosing to do paid work on your own company's money-making products is not volunteering, it's just regular work but you choose what to work on during 20% of your time.
> but choosing to do paid work on your own company's money-making products is not volunteering, it's just regular work but you choose what to work on during 20% of your time.
Disclosure: Google employee, opinion my own.
You are right, but that blog post is using volunteer in the weaker (but nonetheless common) meaning of "someone who raises their hand to do something". 20% time, when done properly, is more of an employee wellness and career/skill building perk. It is like your employer giving you paid time to take a class or training that is related to your job.
When you get evaluated during performance reviews, do your 20% time projects count? If not, it seems like you are just doing a side project in your free time but giving any IP that results to Google. If it does count toward perf, then cool, it’s nice to have complete autonomy for that 20% of your workload.
Performance reviews are how managers provide positive or negative reinforcement for employees who do or don’t further the organization’s goals. Does a really cool 20% time project count toward that if it isn’t related to my work? Does the manager have any incentive to value it (since they get evaluated on progress on the larger team’s goals)?
Every sane boss I’ve had has been happy if I do things that are good for the org, doubly so if they were ideas that I came up with myself for efforts that wouldn’t have happened otherwise. Is 20% time different from this somehow?
What other companies never seem to understand about "Google's 20% time" is that, allegedly, as I don't work there, it wasn't really 8 hours out of your contracted 40 hours, but more like 16 hours out of the 80 hours you chose to work this week for most Googlers. People working on things in 20% time are volunteers in the sense that they're doing extra work voluntarily, rather than going home. It's not like they're doing this stuff during "work hours."
They had something like this when I worked at Atlassian, which was copied from Google (like most everything there)
You could pick a thing to work on outside your normal job and they’d “give” you time. However you had to basically justify it to your manager. This also hilariously ended up in having to plan OKR style achievements for your spare time project. So it was another, voluntary layer of micromanaging crap added over your real job.
I've only heard about it from ex-Googlers so perhaps it's different now. 20% time was introduced a long time ago (before Google went public?) and 80 hour weeks were a lot more common back then...
Anyone have tips for finding a chill team at Google? Passed all interview rounds last time but decided to join another company. Might give it another go if I can get one of those <20hr gigs...
Once you get to senior you can coast forever and no one will bother you as long as you're meeting expectations, which gets easier and easier once you know the company culture. Anyone with 5+ years of industry experience or 2+ years at Google can figure out how to coast on 30 hours a week if they want. There's 100,000 employees, no one notices. Ads is a seemingly endless firehose of revenue so the bottom line is never threatened by your laziness.
It’s hard to say for such a large company with people in so many countries, but I doubt all that many Googlers work much more than full time. Many have families.
How did they fail? They were posting to the flyertalk forums, a site where Matrix is still understood to be the Matrix search engine provided by ITA - a company Google purchased years ago.
It's fine if you don't have the same expectation when referring to Matrix here on HN, but you can't expect them to cater to your understanding on every site.
"The search engines run on databases of flights, prices, and seat availability, provided electronically over private networks by the 800 or so airlines of the world. The data is not directly available to the general public and access often must be negotiated with individual airlines. Flight data is updated daily or occasionally more frequently in the case of unexpected cancellations. Prices are updated about ten times a day, and seat availability continuously. A large portion of the flight, price and seat availability data, called published data, is used by all the major search engines, but a significant amount of private data is restricted." [0]
I had the opposite reaction. The idea of Google employees rewriting a decentralized comms system scared me. Relieved to find out this is some other Matrix.
Yes same here.. No good could come of that. Perhaps at the start they'll contribute some valuable code, but then they will gain influence and steer the project away from this pesky decentralisation.
Though I doubt it's on Google's radar so far as a serious competitor.
It was built by ITA Software [1][2] in the early-mid 2000s (the earliest mention I can find of it is in 2004 [3]) to test and showcase the capabilities of their flight search platform. I once heard that ITA and other consumer-facing flight search companies had tested that kind of UI with ordinary users, but found that not enough people understood or liked it enough for them to justify making it a mainstream interface.
Hipmunk, a YC-backed flight search site that launched in 2010, was heavily influenced by the ITA Matrix UI, after co-founder Adam Goldstein had found Matrix to be the best way for him to find flights when travelling around the world for college debating competitions. And while Hipmunk did a good job of being more consumer-friendly and popular than Matrix had been, sadly they didn't gain enough traction to make it as a standalone company, and after being acquired by SAP/Concur, it was shut down last year.
It's an interesting, and perhaps depressing case of a product design concept being far superior to what's available in the mainstream for a certain class of user, but cannot gain enough mainstream acceptance to be a viable business or even a well-supported service for those who love it. And far more than most other product categories, flight search has huge infrastructure costs, so it's very difficult to economically sustain niche products (from grim personal experience of being part of a team trying to build a novel flight search product ourselves).
In this case it's just lucky that Google owns the infrastructure and has enough enthusiasm internally to keep it going to some extent.
[1] https://en.wikipedia.org/wiki/ITA_Software
[2] https://xconomy.com/boston/2008/12/17/ita-software-the-trave...
[3] https://www.fodors.com/community/europe/customs-question-sea...