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 (jobs@volantio.com)

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.

Absolutely, this is the technique used by Topsy/etc. That said, @ mentions have multiple contexts (replies, mentions, retweet, follow-friday, etc).

The formal retweet structure lets you build a true/formally defined social graph.

Nice work guys, congrats!

Apache/FastCGI/PHP _should_ be very stable (it's mature/old).

I have used it on production sites for years, and in fact, have not used mod_php since before PHP5 for the exact reasons you describe.

You may need to tweak your FCGI settings a bit - the amount of children/fcgi process lifetime, etc all make a difference.

One thing I would highly recommend is ensuring you run under a PHP accelerator (APC is free/great), particularly with FCGI. This will reduce the time each PHP-FCGI child takes serving a PHP request (as it doesn't need to reparse the code every time), which means you can have less children. Less children means more memory available and we all love memory.

If you're having specific stability problems with fcgi, do some googling on the errors you're getting. There definitely have been bugs in the PHP fcgi interface, so an upgrade to later/latest version may help you there.

Alternatively, something like lighttpd/nginx could be a good option for you (though they both recommend fcgi if you want them talking direct to PHP as well).

Good luck!

I recommend http://99designs.com/ as a great starting point.

You can run a design contest for a small amount of money, and you'll get a FAR broader range of options than with just one small designer.

You have the option to only pay if you're actually satisfied with one of the entries, so the risk is essentially nothing (ie: just the $39 entry cost).

Be wary that the quality of entries is somewhat in line with how much you're offering and the quality of your feedback. That said, you should be able to get something really decent for <$1000.

Another option would be to trawl the site and find designers who's work you really like, then offer them something inline with what they'd get in the competition environment (but with guaranteed payment).

Cheers!

It's a publicity stunt. You'll often see press releases from the low cost carriers with stories such as this (or "Fat people to be charged extra") - RyanAir are particularly famous for it.

They've got so much mileage out of this particular one, I'd be surprised if they don't roll it back out again in 18 months.

Spot on. The flights are pretty much all australia/south-east asia at the moment. We're not officially launched yet (I'm co-founder at Adioso, btw) and site is in beta using a subset of full airline data, hence the lack of results people have noticed for USA/etc.

It wasn't intended that we'd really be used outside of Australia yet, but demo day has had some interesting publicity side effects :)

You want crowbar + solvent: http://simile.mit.edu/wiki/Crowbar http://simile.mit.edu/wiki/Solvent

Basically from an opensource MIT project to do very close to what you're trying to do.

Alternately, you could contact YC startup http://www.awesomehighlighter.com/ for advice perhaps (which does EXACTLY what you're talking about).