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

[Christopher S. <cs...@oo...>]

Ted,

You're a passionate man on this topic!

Personally, I agree that the graphical tools will be an essential part of
the acceptance of Embedlets. There are numerous examples of successful
graphical configuration and monitoring tools including schematic/PCB CAD and
Enterprise Workflow tools. You can still make circuit boards by laying tape
on acetate but why would you? It has been my experience as well that you can
have the slickest and most thought-out technology on the planet, but if it
doesn't flash and whirrr, nobody is interested.

I am less insistent, however, that this project create the standards for GUI
components. One of the premises of an open standard projects such as this is
that we cannot predict what systems it will be required to connect to. This
could include but not be limited to: Workstations (PC, Linux, MAC, Sun...),
Web servers (JSP, ASP, .NET, J2EE, Perl...), Wireless devices (Palm,
PocketPC, Cell...), Legacy MainFrame/Mini (AS400, IBM9000...).

That being the case I would recommend:

1. We concentrate on the core Embedlet technology to let us quickly produce
a standard with a demonstratable reference implementation.

2. We create a simple, flexible communication protocol that will accomodate
any XML, TCP/IP capable system.

3. We create demonstration GUI based configuration and monitoring tools. At
least a JavaBean/Swing component that can be used as a bsisi for extension.
This, I have found from experience, is the 'easy' part as long as the
underlying technology is simple and directly exposed as it is in XML.

Chris

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of Ted
Kosan
Sent: Saturday, February 01, 2003 2:46 AM
To: emb...@li...
Subject: [Embedlets-developer] Wiring Tool, Legos, PLCs, PICs, etc.


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


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer