What ICANN should have done about batching

And what it says about the organization that it didn't

Last week ICANN approved its "digital archery" plan for splitting up new gTLD applicants into batches.

With between 1,000 and 1,500 applications expected, the batching process is going to be incredibly important, especially since, as one commentator has pointed out with some frustration, ICANN has given no indication of the time gap between batch processing.

If we take the assumption that it will be six months between batches (likely since ICANN has already agreed it will not add more than 1,000 extensions per year) - that means if you are in the third batch, your competitors will have a 12-month headstart. And that could mean the difference between success and failure.

In the new TLD era, it will all be about segmentation and target markets: making that person or company see the additional value in your extension. If someone is going for the same target market as you and has 12 months as well as a product they can actually sell, you can kiss goodbye to your brilliant business plan.

Surely ICANN realizes this?

Well, one arm of the organization does - the arm dealing with applications. Unfortunately, they are not the ones making the decisions.

The "digital archery" plan - and much of what is currently decided by ICANN - was devised by the organization's legal department which is the most powerful politically within the organization. Unfortunately, as lawyers have a tendency to do, many of the subsequent decisions focus on avoiding litigation over and above reasonable business considerations.

The RAA negotiations should be being handled by the compliance department, as should the dot-jobs dispute; new gTLD communications should be decided by the marketing department; whether a 'Twitter wall' is projected at ICANN meetings should be decided by the meetings team. But in each case, it is the lawyers in charge, with damaging results.

That situation has led to the unfortunate digital archery solution. The lawyers felt that randomly picking applicants - which on one level at least is a fair system - could open ICANN up to being sued for running an illegal lottery. So there had to be some element of skill involved.

Unfortunately the issue then became not about how to make a system that worked for the applicants, but how to avoid potential litigation.

The end result is universally disliked by those that will actually have to use it. When the process was finally revealed, it was met with immediate criticism. If you are an applicant, you will pick a day and a time and then will have to click a button as close to that time as possible.

ICANN produced a graphic showing the time interval used to differentiate the clicks as being one second - something that everybody immediately knew was misleading to the point of deceptive. Who takes more than one second to click a button? This is going to go down to hundredths, maybe thousandths of a second.

ICANN shows second increments between applicants. Who are they kidding?

With no information given either on the timeframe for when the other batches will be processed, or on when the next round of applications will be opened, the pressure on this bad system is all the more intense. If you have already invested $185,000 in an application, are you really going to be willing to let it just sit there in ICANN's bank account while everyone else moves ahead and launches their new Internet extension? Of course not.

Market solutions

The ever-resourceful Rob Hall has seen a golden opportunity in this atmosphere of fear, uncertainty and doubt and his Pool.com is now offering a "digital archery engine" to increase your chances. The cost? A mere $25,000 if you get in the first batch.

But note: there is no guarantee. Pool.com will do its best and if you get in the first batch, you cough up $25,000; if you get in the second batch, you pay $10,000. Otherwise, no cost to you.

Overnight ICANN has created a multi-million dollar market to deal with the uncertainty it induced by making bad, legalistic, self-protectionist decisions with no thought to its customers.

What's worse is that it did so knowingly - details of the program were kept purposefully vague until the last minute, and then pushed through the ICANN Board with lip service given to "public comment" on the issue, all of which was negative.

No doubt the lawyers argued that if details were provided earlier it would give people the opportunity to game the system (ICANN is obsessed with two things: how systems can be gamed; and who is paying people to say whatever it is that they don't like.)

What ICANN should have done

So, let's just assume the lawyer's fears over being sued for running a lottery are well-founded (rather than overly paranoid): what should the organization have done instead?

We have three answers:

1. Spent its energies and resources on figuring out how to deal with 1,000 applications at once, rather than 500. Applicants are effectively paying for ICANN's inability as an organization to scale beyond its own initial assumptions of 500 total applications.
2. Asked applicants and the Internet community what solutions they would recommend, rather than develop a bad system in secret and then push it through to approval, ignoring criticism
3. Given the process to the new gTLD team - who are focused on applicant needs, rather than insular fears unrelated to the program itself

Who knows what system would have resulted if ICANN had taken any of those more logical courses of action.

One solution was put forward during ICANN's public forum, from one of the companies most focused on the process. Fred Kreuger of Minds+Machines suggested: "Regarding possible batching processes, perhaps the Board of ICANN could consider using the same technique that airlines use when they're overbooked. They offer people money to take a later flight." In fact, an economic solution would very likely have proved to be the best solution for developing batches.

Unfortunately, ICANN has a dangerous deficit in economic expertise - demonstrated during the new gTLD implementation process when the issue of "economic studies" into the value of new gTLDs was a constant source of complaint and it became clear that ICANN had little or no understanding of the market it oversees. The result is a batching system that makes sense to the lawyers and no one else.

Money, money, money

Everyone seems to have forgotten that the $185,000 application fee was in part based on ICANN recouping its "development costs" for the new gTLD program. It was also based on 500 applications, and a total, fixed cost of $12.5m. ICANN has publicly stated that $25,000 per application is to cover those costs.

An economist would take one look at this scenario and tell you that if there are 1,000 applications, you have $12,500 per application to play with in order to get people to fit within a queuing system.

You could go as low as $1,000, as high as $50,000, depending on what system you use. If there are 1,500 applications, you have $16,667 per application to devise an efficient system for distribution.

But instead, the brave new world of new Internet extensions is presented with a "digital archery" scheme whose results the organization will almost certainly have to keep secret because it almost certainly won't work well enough to stand up to public scrutiny - and that could open ICANN up to litigation.

But if you really want to ask an interesting question, how about this: of the $185,000 application fee, $25,000 goes to cover "historical costs", the application itself is estimated to cost $100,000 (a nice round figure), but what of the remaining $60,000?

Well that $60,000 - or $90 million if there are 1,500 applications - is earmarked for the legal department to cover "risk costs". Even though this amount will exceed ICANN's overall annual budget, there has never been an explanation for how the figure was reached.

Just as there will never be an explanation for why people clicking a button ended up as the final solution for deciding which of the people paying $185,000 for an application will be given a six-to-twelve-month advantage over others that clicked the button very, very, very slightly slower.