Fenn

Well said :)

Sorry, I possibly stated that poorly - what I meant was: The current state of duopolistic airlines technology suppliers means that there may not be sufficient motiviation to evolve the capabilities of the old systems.

Case in point: Regardless of whether Sabre/Amadeus have replaced their legacy layer with some sort of nosql, I can absolutely guarantee you that many of their primary APIs are literally screen-scraping terminal sessions and returning the screen as XML.

The game theory is indeed complex.

> offer compensation equal to the reservation price of the customer

It's a little more complex than this. It's highly feasible to offer compensation higher than than the original purchase price of the ticket while inducing passengers to move to a different flight, meaning they're effectively being "paid to fly".

In many cases, customers are actually not on their preferred flight in the first place, but merely the one that was cost-optimal at time of purchase.

Changes in market demand in the intervening 3-6 months can easily mean that many passengers on an aircraft can be compensated above their original purchase value to move to their preferred flight.

The above case is an idealised version, but the equilibria is complex and difficult to intuit without experimentation (which is primarily what we're working on).

More news as it happens :)

Sameless self-promotion (I'm cofounder/CTO): We're also hiring (https://angel.co/volantio/jobs / https://www.workatastartup.com/directory/270)

This. (Disclosure: I'm cofounder/CTO of Volantio). Airlines are very much currently burdened with a legacy that was cemented in sometime in the 50's.

It may be worth mentioning that airlines are perhaps less-evil than is apparent from the outside. Most of their baffling behaviour is (IMHO) largely due to lack of capabilities rather than malevolence.

Ultimately, they're given a large multi-dimensional optimisation problem in a marketplace with extreme illiquidity (eg: traditionally, seats can't be resold effectively once purchased).

The complexity is, frankly, staggering - the seminal paper on the topic is probably this: http://www.demarcken.org/carl/papers/ITA-software-travel-com...

We are taking the (very small) initial steps in alleviating some of the issues by introducing increased liquidity into the market, but the ultimate goal is helping shift the industry into a more dynamic place (perhaps as described by the parent comment).

It's a little more nuanced than this. Gate auctions are a good solution, but can only happen in the last ~15-20 minutes prior to departure, which leads to "too late" scenarios as everyone is already present/committed to travelling.

Oversell is sometimes known with high confidence at checkin-close (1 hour prior to departure) or even before, due to the fact that oversell thresholds can change throughout the booking curve.

Airlines don't have a current solution to rebalance/correct loads prior to the gate auction.

This. (Disclosure: I'm co-founder of Adioso/Volantio btw)

Just confirming the above: The no-show rate is actually relatively stable in _most_ cases, which is why airlines try and optimize for this by selling past physical aircraft capacity.

In some markets it's illegal, in which case the average airfares are often notably higher.

This can have a more extreme effect than is immediately obvious: Because "last minute" fares (the ones that often fill up the aircraft) are usually the highest price and are critical in how airlines are able to make flights profitable.

Additionally, the most common no-shows are those who have booked early (the cheap tickets), meaning oversell allows the airlines to make space for urgent last minute travellers when the earlier ones don't turn up.

Without catering for no-show, it's feasible that air fares could end up a LOT more expensive (potentially 20%+) to remain profitable, depending on the distribution of prices in the demand curve leading up to departure.

You can certainly not do it, but on average, customers end up worse off (and the market is relatively good at optimizing this).

The biggest problem (in our mind) is that airlines don't have a good "safety valve" in cases where things go wrong. That's what we (attempt to) fix.

Slava is one of the smartest people I've met (and I'm sure the rest of the team follows suite) - it's indeed sad that the RethinkDB company is no more.

I feel we're at a stage where some of the key technologies/platforms are coming out of relatively small companies (docker, storm, rethinkdb, to name a few), however, it appears it can be tough to make a business out of this alone.

I'm consequently very happy to see that the RethinkDB team have found a home at Stripe and hope that works as a setup to allow the talent to flourish and keep producing great work/innovations.

Volantio (YCW09) | Full Stack Engineer | Atlanta | Full-time | ONSITE

Volantio is hiring an experienced full-stack developer to help us fix travel tech for airlines. We make some of the world’s biggest travel sites suck less, by providing technology products to airlines and other travel companies (and drag them kicking and screaming into the 21st century).

Everything we do works on improving the end-to-end airfare marketing/search/purchase process for some of the worlds biggest airlines, from being honest about prices in ads, to delivering emails that only contain real fares that you actually care about. If you’ve ever gotten an anger-inducing email from an airline with prices that are a blatant lie: we fix that.

We’re a close-knit team and have a variety of challenging work on our plates. A typical day can consist of everything from optimizing the Fare Prediction System in the morning to putting the finishing touches on a CSS animation in the afternoon. Our work spans multiple technologies, cultures, and languages (both programming and spoken!), so we value high quality communication and a continuous process of learning from each other.

We're looking for someone with at least a few years of professional software development experience that wants to work with us. Our product is built on Django/Python/Postgres/Redis/TypeScript and various other technologies used as needed. You'll be a core member of our team - able to develop the role and technology in a direction that you find exciting as we grow the company.

If this sounds interesting, we would love to hear from you. Please include whatever info you believe is relevant: resume, GitHub profile, code samples, links to personal projects, etc. You can apply by emailing directly ([email protected])

Volantio (YCW09) | Full Stack Engineer | Atlanta | Onsite

https://news.ycombinator.com/item?id=11402428

I'd be really interested to see the pricing/commercials around this too. There was a startup that did exactly this a few years back that got Branson's attention and turned into Virgin Charter: http://en.wikipedia.org/wiki/Virgin_Charter - I believe it got hit by the 2009 financial downturn.

Hey Simon,

Hmmm, you're right about the IE issues (http://mrcoles.com/blog/cookies-max-age-vs-expires/). I haven't looked into how possible/hard expires would be in nginx config, but you could probably hack it in with http://wiki.nginx.org/HttpUserIdModule

Expanding on this, one of the things ITA/QPX comes with is a dirty big availability cache that's constantly being primed (and paid for) by their customers (ie: Kayak, Orbitz, et al), who are now ironically not getting any traffic from Google :)

And they have this: http://itasoftware.com/pdf/BrochurePDF_DACS.pdf

I would think the limiting factor is availability. You can pre-compute valid fares between cities super-fast with sufficient computing power, but you're still (somewhat) limited by the rate at which you can update availability, which _still_ has to be polled from airline systems (to some degree) and can't give you answers in <400ms :)

One of the bits ITA/QPX got really right was smart availability caching (http://hasbrouck.org/blog/archives/001880.html) -

I would think they can do the fare search/assembly in realtime with their infrastructure, but they're relying on cached availability, hence the limit to "popular US cities" at the moment, to keep caches fresh enough within the practical throughput limits.

Anyone had any practical experience with this?

I'm somewhat skeptical of the practicality of a graph database backed by a network-connected datastore (as distinct from a graph database exposed over a network interface, ie: neo4j) due to the inevitable latency when traversing the graph.

Also the practicality of scale-out using an ostensibly sharded datastore (cassandra) for a structure that's notoriously difficult to shard meaningfully (graph).

Hmmm, interesting! I hadn't heard about that - Do you have a reference URL?

I heartily agree - I may have overstated my case slightly with the "Giant Step Backwards", it just definitely seemed that way on initial experience.

It also made for a better title than "Confusion, Then Indifference, Slowly Turning Into Understanding & Affinity"

It sounds like your experience was very similar to mine. Except that I long ago upgraded my 80-char margin to 120 :)

Hmm, nice spot. Incorrect assumption of synonyms on my part.

This absolutely happens, sometimes even in the same round - for example, in YC W09 there were two photo sharing services: Divvyshot and Picurio.

Hah, the images are chosen algorithmically at random based on geo-tags, popularity rank and a few other things.

In some cases, less than appropriate ones can sneak in (now moderated). Looks like the algorithm could do with a few tweaks :)

Original photo: http://www.flickr.com/photos/19835636@N00/3124241249/ for those who are interested.

We've actually just recently added that exact feature (though we're short on South American inventory at the moment): http://adioso.com/nl/amsterdam-to-north-america

Looks like we need to tighten up our geo-constraints a little, not quite sure how Istanbul snuck in there :)

This is wonderful stuff, great work guys.

Whether it works perfectly from the get-go is immaterial, StartMate, like their fundees, can launch and then iterate.

Excited to see the first round come through.

It's not actively in production yet, though that was the original purpose for writing it - I realised it was useful so thought I'd decouple it and release it as a standalone opensource library.