(keitai-l) Re: BREW vs J2ME: money vs standards

From: Josh White <josh_at_blackbrick.com>
Date: 04/18/01
Message-ID: <NCBBKJAPCBCPOELPJJKBEEMKDBAA.josh@blackbrick.com>
> The BREW figures are probably the number of people who have registered
> interest in BREW technology

Qualcomm says they have over 1000 developers who've registered on their
website (http://www.qualcomm.com/cda/pr/view/0,1800,583,00.html), and looks
like they have nonbinding deals ("MOUs") with something like 60 developers, 4
handset mfr's and carriers
(http://www.qualcomm.com/cda/pr/view/0,1800,583,00.html).

[the rest of this email is speculative / analysis:]

Of course, these are tiny numbers compared to J2ME as a whole...and even
though J2ME isn't just wireless, it's got a huge lead.  However, assuming
Qualcomm can get enough momentum behind BREW to be competitive with J2ME,
wireless application developers may have some interesting options.

One thing wireless developers can be thankful for: neither of these APIs are
owned by carriers or handset manufacturers.  Developers should live in fear of
having their cash cows stolen by suppliers they depend on: technology vendors
(API, tool providers) and access to market (ie, carriers/publishers).

I think BREW vs J2ME differences reflect the parent companies' focus.
	Sun is aiming broad: its longterm vision is "Java everywhere"; that means
they want wireless development to be as similar as possible to other kinds of
development.  The advantage? The wireless industry gets many more developers
writing wireless applications, yielding lots of new content.  Sun is one of
the few companies that could eventually standardize an industry, without
owning the user base.  The drawbacks?  Those millions of Java developers
aren't experienced in wireless development, and J2ME may not be a great place
for them to start. J2ME is meant for all kinds of portable devices - from
radios to mini-laptops. There is no focus on wireless. Worst case, J2ME might
mean one bloated world: rookie wireless developers + murky API = endless
streams of poorly written, low-quality applications.  Or it might mean: a
thousand versions of J2ME-for-wireless, killing the portability that Java
supposedly holds so dear.
	Qualcomm, on the other hand, is focusing tightly: BREW is an API for CDMA.
The advantage? Qualcomm's wireless expertise means they're presumably better
than Sun at giving wireless developers what they need. Until the API is
released we can only speculate on the technical differences, but Qualcomm's
offering developers more than an API.  BREW includes an I-mode-style access to
revenue streams ("...server software for carriers, and/or end users to pay for
your applications. QUALCOMM will track the adoption of your applications and
distribute revenue..." - BREW FAQ on www.qualcomm.com).
	BREW Drawbacks?  Assuming BREW really is a lot better than J2ME, and assuming
Qualcomm can actually land revenue-sharing deals with carriers, Qualcomm is
now the developer's revenue middleman, but Qualcomm's revenue comes from
carriers, not developers. Thus Qualcomm may not have incentive to provide
developers with the most advantageous deals.  Other drawbacks: BREW is the
opposite of portable.  Developers don't care what type of wireless
infrastructure is in place, as long as it works. But using BREW means
committing to CDMA. That's an unnecessary restriction for developers.  BREW
worst case: developers get a mediocre API, bad financial deals, and a tiny
percentage of a wireless market...thus developers have to rewrite their apps
in J2ME (or whatever widespread standard emerges) anyway.

Anyway, BREW vs J2ME is an academic question unless Qualcomm can land some
major deals with major carriers that give developers access to users, as J2ME
provides.

-Josh


[ Did you check the archives?   http://www.appelsiini.net/keitai-l/ ]
Received on Wed Apr 18 20:01:49 2001