[Embedlets-developer] Wiring Tool, Legos, PLCs, PICs, etc.

[Ted K. <tk...@ya...>]

Assertion 1: Without graphic assembly capabilities, Embedlets *don't* have a
market. 

Assertion 2: With graphic assembly capabilities, Embedlets have access to a
significant number of huge markets.

I can amply support both of these assertions.


The premise that Embedlets alone (without state-of-the-art graphic assembly
capabilities) have a reasonable chance for success, can easily be proven to be
*false*.  Here are the reasons for this.

Reason 1)  The only market that Embedlets *without* graphic wiring capabilities
can be targeted toward is *Embedded* Java programmers.  So how many of us are
there?  Lets check the numbers on the Embedded Java lists:

JStamp list - 333 members.
JStik list - 64 members.
TStamp_TStik list - 100 members.
TINI list - estimated < 2000 members.

Extrapolating from these numbers one can (very generously) estimate that there
are probably <10,000 Embedded Java programmers in the whole world at this point
in time.

In addition to the existing number of Embedded Java programmers being very
small ,the rate of new programmers entering the Embedded Java group is equally
small (see #3). 

After looking at these extremely small numbers, one must ask “how do Embedlets
enable this very small and slowly growing group to attain success with Embedded
Java that they could not do with just regular Embedded Java?”  And the ruthless
answer is “Not very much”.  TINIs have been around since 1999.  If Embedded
Java was going to succeed in the marketplace using conventional marketing
techniques, then TINI would have been a commercial success by now.  To date it
has not been a commercial success.

The primary reason for this is that Enterprise Java developers have no where
near the background needed to successfully deal with the Embedded Space and
they never will.



2) Trying to market Embedlets as a programming technology to primarily
enterprise developers (including enterprise Java developers) is a flawed
strategy that will fail.  What capabilities do Embedlets offer an Enterprise
Java developer that normal Embedded Java does not offer them?  Answer: “Not
much”.  Again, TINIs have been around for over 3 years now and they are very
easy to attach to enterprise systems.  If Enterprise Java developers were going
to take an interest in Embedded Java they would have already done so already
with TINIs.  Embedlets without Graphic Wiring capabilities do not bring
anything significant to the table that normal Embedded Java does not already
offer.

Every piece of my input into the brainstorming process has centered around the
goal of finding markets for embedded Java through allowing *non-programmers*
(this is where 90% of the market is) to construct useful embedded system
solutions using graphic embedded component assembly techniques.

I have consistently stated that my “most likely *initial* target market for
graphically wired Embedlets” were the legion of non-programmer IT support
personnel who are present in all medium and large size companies.  The
enterprise Java programmers were primarily a back door strategy for marketing
graphically wired embedded systems to these IT personnel.  

To say that Embedlets are only *for* solving problems in the enterprise space
is just as suspect as Sun stating that Java was only *for* solving problems in
the Embedded Space in the early 1990s.  Thinking about a technology in terms of
what it is *for* is an extremely dangerous and limiting mindset to have.  A
much better way to think about any given technology is in terms of what it can
*do*.  Show any given group what a technology can *do* and they will figure out
all by themselves what to use it *for* in their respective domains.  The best
chance that Embedlets have of succeeding is for us to show as many diverse
groups as possible what Embedlets can *do* and let them take it from there.
(shirky.com).



3) The size of the Embedded Java programmer group is very small, it is growing
at a snails pace and so it is going to be small for a very long time.

This I can attest to from direct experience.  When TINI cam out in 1999 I put
together a free online Java/1-Wire/TINI class for it which lasted 12 weeks. 
Over 400 people took this course and I followed it up with a free online
Java/iTV course which had 600 people sign up for it (javadevices.org/dtcourse).
 I am currently in the process of putting together a free Java/TINI/TStik
course for the new Systronix TStik and a free Java/uVM course for the new PIC
based muvium (muvium.com).  

Beyond this I gave a Java/TINI BOF session at JavaOne last year and I put
together a compelling proposal to OReilly for an Embedded Java Beginner's book
(which they utterly rejected on the grounds that Embedded Java was a
non-existent market).  I was also part of a team that was a finalist in last
year's Visa Blue SmartCard programming contest and after this I submitted a
proposal to teach a free Java/SmartCard class to Gemplus users.

So, after working extremely hard for years to increase the size of the Embedded
Java developer pool I can confidently state that it is going to happen *very*
slowly and it is going to be an uphill battle every centimeter of the way.  I
now know the reasons for this but we do not need to go into them here.

To summarize, Servlets, EJBs, JavaBeans... these technologies are wildly
successful because the pool of developers that use them is in the *millions*. 
Embedlets without graphic wiring capabilities are going to *fail without
question* due to the simple fact that the Embedded Java developer pool is
estimated to be < 10,000 and it is growing very slowly.  Almost anything
marketed to a target market that is this small will very likely fail.

Refute this conclusion if you can but you better have evidence to back up your
position.



ARE THERE MARKETS FOR EMBEDDED JAVA?

Yes!  Lots of them and they are huge!  But the only way Embedded Java is going
to gain access to these markets is by not requiring them to learn how to
program in Embedded Java.  At this point in time the best way we have to
realize this is by giving Embedlets state-of-the-art graphic wiring
capabilities.

To me, the most important thing I have learned from all the brainstorming we
have done on the Embedlets idea is that *Embedded Java's primary strength is
that it is the best technology in the world for the task of “protocol
neutralization”* (which was Gregg's insight).  Embedlets represent the best
technology we could think of to capitalize on this strength.

So, Embedlets are 

- A Camelot 'round table' that allows diverse technologies and communities to
be brought together for a common purpose.

- An airport terminal that allows data from multiple sources to be routed to
multiple destinations.

- A United Nations which allows different languages using diverse protocols to
work together to solve mutual problems.

- A benevolent Borg which accommodates and assimilates wildly diverse
technologies into a collective that can leverage the laws of synergy.


The best chance that Embedlets have to fulfill this roll is by providing a way
for extremely diverse market segments to be able to easily use them for solving
their domain specific problems.  Currently, the most promising technology we
have for enabling this is graphic assembly of software components (Embedlets). 



Here are some low hanging fruit markets that graphic assembly Embedlets has
access to:

- PIC programmers (huge group of non-Java developers).
- 8051 programmers (huge group non-Java developers).
- AVR programmers (huge group of non-Java developers).
- PLC programmers (huge group of non-Java developers).
- Non-Programmer IT personnel (millions of members).
- Lego Mindstorms programmers (huge group of non-Java programmers).
- etc.

The only way I can see that the small number of Embedded Java programmers can
possibly support such an enormous combined market is by developing reusable
Embedlet components that this large group can use to graphically wire together
their own solutions to their respective problems.  There just simply are not
enough of us to directly service this combined market by directly programming
these solutions ourselves (again, anyone who thinks they can refute this claim
will need to show their numbers).


As for the assertion that graphic assembly of applications does not work, the
large Lego Mindstorms user base easily refutes this claim.  It obviously *does*
work and is quite *successful* even when allowing for the fact that there is
still much room for improvement in this area.


In conclusion.  I absolutely agree that a well architected Embedlet
specification is extremely important to the Embedlets effort.  I also maintain,
however, that giving Embedlets state-of-the-art graphic wiring capabilities,
and then marketing these capabilities to any and all markets that could
potentially use them, is *equally* as important for Embedlets to succeed.

I will take Bruce's following response to the idea of Embedlets having graphic
wiring capabilities as an indication that I am not quite ready to be sent off
to the 'funny farm' just yet: ;-)

>Yes [...] yes [...] yes! [...] Yes [...] Yes [...] YES!!! 


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com