How will the mobile application space look like in the future? Which proven strategies from the past will still provide an edge? And which strategic levers should be considered to bring exorbitant profits?

To solve the mobile conundrum and peer into the future with the wisdom of the past, I’ve been collecting economic data from the most diverse data sources to estimate regressions(IRLS, LAD) of profit (quarterly and/or annual) on different software categories (desktop, web, mobile) and their features. In other words, the most obvious analysis that nobody has ever carried out.

The following are stylized initial results, omitting exact coefficients but showing their size and direction (* for statistically significant):

DESKTOP

WEB

MOBILE

Total Addressable Market + ++ +
User Base Size +(*) +++(*) ++(*)
Development Sunk Costs ++
Latency tolerant ++ – -(*)
BUSINESS MODEL VARIABLES
License fee + – – (*)
Maintenance fees +++(*) ?
Versioning ++ ?
Bundling ++ ? ?
CPM/CPC +++(*) +
Targeting Quality ? ++ +
Use Time per User ? ++(*) ++(*)
DEMAND SIDE ECONOMIES OF SCALE (NETWORK EFFECTS)
Bandwagon effect + ++(*) ?
Standard setter ++ +++ ?
Linkage / interoperability ++ ?
SWITCHING COSTS
Data/file lock-in ++ + ?
Job/skill effects ++(*) ? ?
Learning/training  effects ++
Incumbency effect ? ++

R^2=0.66, sample size=352 (includes most important and known programs per category)

Focusing into the higher size and statistically significant variables, the data reveals the different nature of each software category:

  • Desktop applications: the most profitable strategy is to develop broadly used programs with low initial price, but higher maintenance fees and a significant impact on the labor market. Don’t make programs, revolutionize professions.
  • Web: very high scale ad-monetized applications with major network effects. The result of the open nature of the web with its hyper-linking structure across domains and the absence of micropayments.
  • Mobile software is a yet-to-be-determined mixture of desktop and web applications. This category is like desktop software, in that it has the same technical architecture, but its evolution resembles more closely that of the web due to the incumbency effects from web companies and lack of switching costs and traditional network effects.

More insights in future posts from this and other data sources.

Data sources: Yahoo Finance, Crunchbase, Wakoopa, RescueTime, Flurry, Admob, Distimo, Alexa, Quantcast, Compete, others.

 

I get more than a hundred visits a day to my iPhone Decompilation & Obfuscation post, that’s why writing an Android equivalent and comparing the results between them will be so interesting to assess platform demand from developers.

To decompile an Android .apk file, you must follow the next steps:

  1. Download the app from the Android Market to your smartphone and backup the app with a tool like Titanium to get the .apk file
  2. Next, use apktool to get back the project file structure and resources
  3. Then, use dex2jar to the obtain .class files from the .dex files
  4. After that, use jd-gui or JAD to decompile the .class files
  5. Most bytecode won’t perfectly decompile and some routines will be hard to reconstruct from the bytecode: get ready to read java ASM disassembled with smali

To obfuscate/protect your application, consider following these steps:

  • ProGuard is the most complete and useful tool to obfuscate applications, but you must use it with the following configuration file to avoid any problem. Note that ProGuard is pre-packed in the SDK from Android 2.3
  • Use LVL for your paid applications, but remember that it has already been broken.
  • Lastly, consider using Android NDK for the most critical code. Writing JNI code is a really cumbersome and error-prone, process that’s why using specialized tools is essential to avoid errors and speedup development: to interface C libraries with Java, try SWIG and  GlueGen; in reverse, to interface Java with C try HawtJNI. It’s a pity that the Integrated Debugger for Java/JNI Environments is only available for the Apache Harmony JVM, as it really helps in the difficult Java/JNI debugging process.

As a final note, the results from the superb paper “On the (Im)Possibility of Obfuscating Programs” will always tame our aspirations in the obfuscation enterprise:

Download (PPS, 31KB)

 


I spoke at a conference about the Prevention, Detection and Mitigation of Denial of Service Attacks years ago. Reviewing its content, I’m surprised of how current the information is even now, at least for level 3-4 DoS attacks: it’s true that there are newer techniques, but for all intents and purposes they are still the same procedures.

If I were to repeat it, the one thing I would add for sure is the recently released Roboo, the HTTP Robot Mitigator, a level 7 tool that verifies the existence of full browser stacks using advanced non-interactive HTTP challenge/responses mechanism to detect and mitigate HTTP robot and DoS attacks.

 

pMARS, the official Redcode simulator

“Battle programs of the future will perhaps be longer than today’s winners but orders of magnitude more robust. They will gather intelligence, lay false trails and strike at their opponents suddenly and with determination.”
-A. K. DEWDNEY, Computer Recreations, Scientific American (January 1987)

Mahjong is different from Checkers, just like High Frequency Trading is different from Core War: they include the profit motive!

 

The market microstructure of financial markets is a fascinating field: the old customs for trading of financial assets and contracts had been codified on computer algorithms, allowing for their execution at sub-luminal speed. The analysis of market microstructure, through stylized and econometric models, is an overlooked but necessary skill for the high frequency trader to survive in an ever-changing environment, to better understand the dynamics of price formation in financial markets and how the most seemingly innocuous of the rules could alter the short-run behavior of securities prices.

It’s worth recollecting the strengths and weaknesses of the fundamental books of the field here since I’ve read all of them and each one offers an interesting point of view of the subject. And reading at least two of the better would be an excellent introduction to the specialized literature:

  • Trading and Exchanges: Market Microstructure for Practitioners. Excellent introductory textbook on how financial instrument trading works, comprehensive yet accessible to every public. It offers a high-level, non-technical and non-quantitative, recollection of insights of the different institutions, incentives and techniques of all the market players, resulting from years of experience of its author, as well as structural and regulatory issues, plus a stylized overview of the most common microstructure effects. The only negative aspect is that it’s almost a decade old and, even if fundamental market microstructure didn’t change much, technology really did.
  • Market Microstructure Theory. The classical introduction to microstructure theory, now dated, provides an excellent mathematical introduction to the field for the researcher through a systematic presentation of the basic models and results.
  • Microstructure Approach to Exchange Rates. This book covers FX market microstructure all the way through theoretical and empirical models. Although dated, it’s indispensable to understand the idiosyncratic nature of exchange-rate markets.
  • Empirical Market Microstructure. Brief, updated and quantitative book, perfect for an intensive intermediate course on equity market microstructure with an emphasis on the econometrics, but neither on the real world implementation nor technical issues.
  • The Microstructure of Financial Markets. The most updated book of this list, it’s perfect for an advanced graduate course with an emphasis on the empirical models of market microstructure. Recommended for its in-depth treatment of transactions costs and their effects on return on investment.

Trading and Exchanges: Market Microstructure for Practitioners

Excellent introductory textbook, comprehensive yet accessible to every public, on how financial instrument trading works. It offers a high-level, non-technical and non-quantitative, recollection of insights of the different institutions, incentives and techniques of all the market players, resulting from years of experience of its author, as well as structural and regulatory issues, plus a stylized overview of the most common microstructure effects. The only negative aspect is that it’s almost a decade old and, even if fundamental market microstructure didn’t change much, technology really did.

Market Microstructure Theory

The classical introduction to microstructure theory, now dated, provides an excellent mathematical introduction to the field for the researcher through a systematic presentation of the basic models and results.

Microstructure Approach to Exchange Rates

This book covers FX market microstructure all the way through theoretical and empirical models. Although dated, it’s indispensable to understand the idiosyncratic nature of exchange-rate markets.

Empirical Market Microstructure

Brief, updated and quantitative book, perfect for an intensive intermediate course on equity market microstructure with an emphasis on the econometrics, but neither on the real world implementation nor technical issues.

The Microstructure of Financial Markets

The most updated book of the list, perfect for an advanced graduate course with an emphasis on the empirical models of market microstructure. Recommend for its in-depth treatment of transactions costs and their effects on return on investment.

 

I’m eager to learn the outcome from Intel’s biggest acquisition ever, McAfee. As company representatives have said in a conference call with Wall Street analysts, they plan to push functionality down from userland to the die chip, just below the OS. And that is a really bizarre rationalization for this acquisition, since antivirus are memory and I/O bound processes, not CPU-bound applications (see “Characterizing Antivirus Workload Execution” for more information), that’s why significant speed-ups aren’t likely to be attained. And all improvements Intel is going to put into the chips should be also offered to other antivirus companies, otherwise they risk facing antitrust action as the EU has forewarned, coincidentally the same reason Microsoft hasn’t be able to make a good antivirus even if everybody would benefit from a development like that (ironically, the last one being a case of a public bad from public intervention).

Security on a chip should be as simple as possible. I still remember the security fiasco within the Intel 286 ring model caused by an undocumented instruction, LOADALL, which rendered it useless. In my opinion, progress will be more in the vein of current virtualization offerings, seeking to improve performance with multiple virtual machines within a host.

Finally, note that EBITDA margins aren’t exactly attractive, in particular for a company like Intel:

 

I’ve just updated the list of the best technical presentations available on the net about smartphone security. Nowadays, smartphones are the weakest part of any corporate network and it’s quite fun having lots of flashbacks while watching the same attacks of the 90s working  again and again on the new smartphones.

 
  1. Manage memory properly, but resist the urge to use
    1
    retainCount

    , it’s a bad idea. Also, it’s better not use

    1
    autorelease.
  2. Draw on the available toolset to improve the quality of the code: Instruments, to find the root cause of bugs; Shark, to improve performance; Clang Static Analyzer, to get the most detailed and comprehensive compiler warnings.
  3. Try to anticipate every iOS update, because there will always be changes to be made.
  4. Develop re-entrant code, because every method could be interrupted and the app could get any message in any state: it’s very important to remember this before coding every method. Read the open-sourced iPhone app code available on the net: the idioms and the patterns are very different from the Java/C++ paradigm.
  5. Beware of using SQLite with flash memory I/O: it will block the GUI.
 

Let’s imagine that the desktop OS market starts from scratch, with no strings attached. That is, neither lock-in effects nor switching costs; zeroed learning curve effects, resetted economies of scale and scope and absent network effects; just free-entry without any of the preceding oligopolistic and monopolistic market structures.

Wouldn’t it be wonderful if we could find a natural experiment, not a thought one, in which to observe the resultant market shares? Could we know how would they most likely rank?

Yes, we can. It’s the mobile OS market!

  1. Android (Linux)
  2. iOS (Apple)
  3. Windows Phone/Mobile (Microsoft)

In other words, the desktop OS market, in reverse order.

 

The computer system architecture used for cloud computing provides a powerful computing environment for web services, but not for the tightly coupled parallel processes required for High Performance Computing (HPC), rendering the vast data centers built for the cloud useless for supercomputing purposes. This fact is very well presented in the paper “Can Cloud Computing reach the TOP500”: it is shown that the cost for solving a linear system increases exponentially with the problem size in Amazon EC2, the opposite of what happens in a genuine supercomputer.

A real market demand for the ability to run HPC workloads in the cloud lead Amazon to offer a new Cluster Computing Instance, increasing performance of typical HPC applications by an order of magnitude more than the one offered by the previous EC2 instance types. This supercomputer processes information at the rate of 41.8 TeraFLOPS and ranks at #231 of the TOP500 list as of November 2010. What it’s really noteworthy is that Amazon released a new Cluster GPU Instance on Amazon EC2 some months later, but the LINPACK benchmark was calculated without using the available GPUs, so the Amazon Cluster must really rank much higher in the TOP500 list: since almost every supercomputer at the top of the list now uses GPUs, it has become an almost mandatory prerequisite (except for Cray). The available benchmarks show excellent performance, but the real GPU speed-up on a standard benchmark remains unknown.

To get at the top of the list, Amazon should provide more RAM per node and much better interconnects than 10GB Ethernet (vg. Infiniband FDR or Gigabit Ethernets). One thing is for sure: meanwhile, I’m having fun renting the GPGPU clusters from $2.10/server/hour, each node delivering a TeraFLOP using the dual NVIDIA Tesla M2050 GPUs and immediately accessing the performance of an HPC Cluster GPU, with no upfront investment or long-term commitment.

 

Example of A* algorithm where nodes are cities connected with roads and h(x) is the straight-line distance to target pointIt’s funny how two of the most studied algorithms of a discipline, that are considered polynomially optimal for decades under a set of well-accepted assumptions, turn out not to be so great. That’s the case of the famous A* and IDA* algorithms, cornerstones in AI and currently implemented in thousands of computer games because there were thought to be polynomial in the search space since 1968 under a set of broadly defined heuristics, even though nobody has found practical instances of them after hundreds of proposal and attempts. Their optimality is finally debunked in “How Good is Almost Perfect”: general search algorithms such as A* must necessarily explore an exponential number of search nodes even under the most optimistic assumption of estimators with heuristic error bounded by a small additive constant. What is worse, other similar search techniques cannot perform better than A*.

These are the kind of results that reminds you to always revisit assumptions, to search more closely where others may have obviated, no matter how well-accepted and reputed are the sources, in particular with folklore wisdom, beliefs and other uncanny heuristics.

Download (PDF, 446KB)

 
Set your Twitter account name in your settings to use the TwitterBar Section.