You've heard this said before.  In fact, If you regularly peruse the pages of JDJ, you've heard it here more than once.  In case it hasn'y sunk in, repeat after me: J2ME (especially MIDP) will provide tremendous opportunities for developers.

Not convinced? Think about it, then: a virtually untapped market of mobile-savvy users who aren’t likely to dish out the thousands necessary to buy a computer, but will probably be willing to hand over a lot less money for something like a mobile phone. There are a lot of computer users out there, to be sure, but there are a lot more mobile phone and handheld device users. And mobile phones are far less daunting for a nontechnical person to come to grips with. There are fewer buttons, and the screen is smaller, which necessitates a much simpler user interface. It’s a technology that people are already comfortable with – hence it’s a good bet that they aren’t going to be uncomfortable with the idea of replacing their phone with a device that provides the additional capability to download new games and other applications.

They might not know that Java is the force behind this functionality, but if they can remove Snake and replace it with Pacman with just the click of a few buttons, there’s definitely a selling point there.

Stumbling Block
The one stumbling block in Java’s bid for world domination is the massive glut of mobile phones already on the market. People will undoubtedly need to upgrade at some point – as their phones get lost, stolen, broken, or become unfashionable – but how long will the process actually take before the majority of phones in use are MIDP-enabled? Well, I guess that’s for the phone manufacturers to predict.

A Veritable Obstacle Course
While MIDP development presents numerous opportunities to developers, the restrictions inherent in the platform also place a number of fairly major obstacles in your path (see Glen Cordrey’s article “Pushing the Limits,” JDJ, Vol. 6, issue 12).

Unlike when developing applets (or, indeed, server-side applications), it may not be as easy for a small development firm to reach its intended audience. Some networks may provide unrestricted Internet access to their customers; others may prefer a portal approach (so only a few preferred providers will be able to present their wares). Perhaps some mobile users who have a home computer will come across your MIDlet suite on the Web and choose to load it onto their phone. Users with no computer may have only restricted access through a TV, console, or WAP phone.

Your application may require various utility/support classes to provide necessary functionality; considering the memory on a mobile phone available for a MIDlet suite, if every suite uses the same library, a lot of storage space is wasted for no good reason.

Assuming you want to make money from your development efforts, how do you charge? Who do you charge? It will be beyond the resources of many small developers to go it alone, negotiate a contract with Sprint (for example), and interface with their back-end systems so that:

1. The software can easily be provided, in the right way, to the right phone.

2. They can charge the end user for the privilege of using it. (Unless, of course, they’re selling their software outright – and possibly selling away a chance at larger profits).

 These difficulties mean that we as developers will have to come up with alternatives to the prepackaged shareware and e-commerce methodologies that have provided revenue streams in the past.

An Almost Open-Source Portal – the MIDP Cooperative
A number of companies have already developed (or are in the process of developing) server-side applications that assist in delivering applications to mobile phone users, along with the associated tasks involved in the process. Mobile provisioning is one of the terms used to describe these kinds of applications. Most provisioning applications will require a considerable investment (financial, infrastructure, and otherwise), and certainly the target market will be big corporations. Nextel, as an example, could use a provisioner to handle the applications available for their MIDP-capable phones.

Small developers, however, could be left out in the cold. Suppose I produce a game that I’d like to make money from; currently, I’ll have to contact the Sprints, Nextels, and BTs of every country in which I want to sell it. Then I’ll have to do a good enough sales job to convince them to either buy my software outright or give me a share of the revenue when their customers play my game. There aren’t a lot of other options. So…enter the MIDP Co-op.

Safety in Numbers
At www.midlet.org you can find a free Java repository for downloading various applications to your mobile phone. You can either download apps to your PC (and then transfer them to your phone from there) or use OTA (over-the-air) downloads if your network and phone provide that capability.

The MIDP Co-op (yes, it’s a crappy name…no, it wouldn’t actually be called that) would work in a similar way. However, instead of downloading any number of suites (usually one application per suite in the case of midlet.org), users could select a number of applications that would be packaged into a single suite, ready for download.

Rather than individual developers having to charge for their applications, the co-op would do the job. Users who want to download software to a PC use traditional e-commerce mechanisms (a secure Web site with some form of merchant/shopping cart facility), but OTA would require the co-op to negotiate with the various networks over delivery and payment. In the best tradition of the middleman, a certain percentage of the sale (or use fee) of an application would go to the co-op. Most of the money, of course, should (and would) go to the developer.

Here are a few more ideas on how it might work:

Compiled at Our Place
In the co-op, as final compilation would potentially be done on the server, only authorized utility libraries could be used in a hosted application. For example, applications requiring a floating point class would have to use the class provided by the community. If some guy decides that his floating point class is better (more efficient perhaps), he can submit documentary proof to the board of directors, who would make the final decision (probably based on its impact on other hosted applications). All utility classes would be required to be open source to community members, and, in the interest of fairness, developers of utility classes should be allocated a percentage of any sales.

Philosophy Be Damned
To save on philosophical arguments, it should be up to the individual developers whether their application source would be made available to other developers in the community – hence “almost” open source. The source would, of course, have to be uploaded to the server for any application to be hosted (and compiled) on the server, but it could be viewed only by community members, and only if the developer allows. Obviously, open sourcing an app should be encouraged because it means that the community as a whole benefits (newbie developers looking at veteran developers’ source code to determine the best way to accomplish a task, for example), but “religious views” should not be forced upon the members. One way of looking at it: If I don’t want to open source my application, then why the hell should I?

Remember that there’s a benefit to be gained in either case. Whether closed or open source, the more applications a co-op hosts, the more likely it is that visitors will come, download, and spend their money!

Multiple Personalities
Initially the co-op would host only client applications. At some point it might possibly become financially viable to set up full server-side hosting as well. This means multiuser (multiplayer) applications with application server and database access. Multiplayer games seem to be a big draw in the PC world, so it stands to reason that the same will be true in the phone market – hosting multiplayer apps is going to be necessary for the co-op to thrive.

Tell It to the Board
The board of directors should initially be drawn from “interested” parties, those who have contributed to the estimated running costs (e.g., hosting, legal expenses) for the first years of operation. If/when the co-op becomes profitable, directors would be repaid (with interest, based on typical bank savings account rates over that period), and their position could then be voted on by the community at the end of the term of directorship (only community members would be eligible to run). If only contributors (those who have applications hosted on the site) could be community members, after the first elections only contributors would remain on the board.

Show Me the Money!
To get a better idea of how a co-op might work in the real world, let’s look at some figures. To start with we’ll make some guesstimates:

1. We’d have between 50 and 100 hosted applications at launch; midlet.org has, at the time of this writing, over 140 applications, so it seems reasonable to assume that the co-op could attract at least 50 for its initial launch (especially considering the enticement of possibly making money from your applications). Over time that number could be expected to grow, so the hosting requirements should take into account a certain amount of expansion.

2. Developers would set the price of their applications, but should be encouraged to seriously discount them for at least the first year of operation. (Note: Nextel is currently selling applications ranging from a few dollars to $12.95.) A certain percentage of applications would in-
evitably be free, which is a good thing if the co-op wants to attract more business.

3. The worst-case scenario for an application size is 128K, based on the maximum memory size in the MIDP specification. Assuming such a scenario, the storage space for a thousand MIDlets (if the number of applications hosted grew considerably, of course) would be in the area of 256MB (assuming the co-op holds both source and compiled files). Adding various infrastructure components (an e-commerce initiative) to this figure, along with annual hosting costs likely to be at least $3,000 (a conservative estimate based on an extremely quick skim of some popular hosting companies), source control, community support functionality…and the figure rapidly starts to climb.

4. The number of directors on our hypothetical board would be 12. Why 12? Why not?

5. Assuming a two-year hosting cost of $6,000, initial legal expenses of $3,000 (a complete guess), and an emergency buffer of $3,000, each director would need to contribute a total of $1,000.

6. Ten percent of total sales would go to the co-op to cover running costs, expense payment, and perhaps a nominal fee to each director. Another 2% would go into a kitty to be paid to the utility class authors.

We’ll make some additional assumptions regarding the average download and the distribution of applications according to price. At a guess, consumers wouldn’t spend more than $10 on a download, and are more likely to buy cheaper applications than the more expensive ones. For the moment we’ll assume that the most expensive application would cost $3 (see Table 1).

The number of monthly downloads would initially be fairly small, but let’s get starry-eyed for a moment using Nokia’s projection of over 50 million Java-capable mobile phones shipped by the end of 2002. Assuming only a measly 0.1% of those 50 million would download the ave-
age application suite in a year, that’s still 50,000 people, total sales of $425,000, and income to the co-op (at 10%) of $42,500. The co-op could then consider purchasing its own server rather than using prepackaged hosting facilities, and paying off the initial board (even a minimal 5,000 downloads in a single year would mean that hosting expenses can be paid the following year).

The top developer might hope to attract 10% of the 50,000 downloads. Assuming the top developer also charges a top price ($3), he or she could make in the neighborhood of $15,000 for the year. Not a lot of money admittedly, but not bad, considering the developer would dish out a grand total of $0 to have the application hosted.

Community
This is only a simple sketch of what might go into one such co-op or foundation. One thing is certain: going it alone in the wireless environment would be extremely difficult for the average individual developer. As a consequence, the J2ME developer community will somehow have to come up with ideas that are acceptable to larger groups of developers so the little guy, not just the big corporations, can make some money from J2ME development.

After all, it’s to be expected that some of the most innovative products will be those developed outside the confines of typically restrictive corporate environments.

Vive la communauté!