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
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.
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
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
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
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
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
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
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
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
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.
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é!
Jason R. Briggs is a Java analyst programmer and – sometimes – architect.
He’s been officially developing in Java for almost four years “unofficially for five.”