As an investor in WIND it is good that you try to understand the nature of the business. But be happy it is as complicated as it seems (actually it’s a lot more complicated). If it were easy, then WIND would encounter new competition at every turn. Customers that have committed resources to learning how to develop applications using VxWorks would be able to switch RTOS vendors like pencil suppliers. This is why I like WIND in the Embedded Systems RTOS and Tools sector.
A few years ago Oracle Corp was stumbling, going from the high teens to less than $5 per share. At the time I had just purchased the Oracle RDBMS and knew it held 40% to 50% of the emerging Unix market for SQL databases. I then looked on my bookshelf at the two feet of Oracle manuals needed to administer and use the RDBMS, and realized they had to win. Anybody who went to the trouble of installing and using Oracle would not switch without a fight. So I bought and bought the stock, all the way down. My only mistake was when the stock recovered nicely, I thought it was fully valued and sold just before it really took off.
Now, what’s going on with the press release indicating that hardware debugging vendors can get background debug mode support? Remember a few posts ago when I took exception to the claim that Tornado was just another GUI, cute but not necessary for down-and-dirty embedded systems developer? This is an example of what I mean’t.
The fundamental problem is that embedded targets must work by themselves in a robust and often exquisitely precisely timed manner. Sometimes it may be obvious that the stand-alone target under development is not working exacting right, but the cause of, say a timing problem, may not apparent. At other times, the target may appear to function correctly, but cost of failure is so high that you must guarantee perfection. At other times, you may not even have a development target, but are simply simulating one in advance of receiving a sample chip, or in order to decide which processor will do the job most cost effectively. Embedded systems applications are extremely cost sensitive since they involve thousands if not millions of targets in production.
Consequently, the embedded systems world has evolved lots of tools, and tool makers, for developing and debugging embedded systems. Targets can be simulated/debugged using software (e.g. WIND’s WINDVIEW or INTS’s esp). If there is a concern that the software footprint alters timing, or if there is some other aspect to be inspected that is outside the range of software, then hardware might be the tool of choice. However, in all cases there is a problem connecting the tool to the simulated or actual target. Precious resources are needed on the target, and a series of compatibility issues need to be resolved. There are many possible processors, running many possible RTOS’s, hosted during development by many possible development environments. What is a best-of-breed tool-maker to do? Even if he can undertake all the work necessary to make his tool useful in most situations, most of his potential customers might not appreciate the extra work on top of what it took to get their basic development environment running. This can cost the tool-maker sales.
Tornado is the answer, and saviour, for these tool makers, software and now hardware, too. Once the developer gets Tornado running with a lean target (no wasted resources there), any Tornado tool, software or hardware, is immediately available to the developer, just for the price of the tool. This is how Tornado gets its name: the power of all (hooked in) tools able to focused on a small, lean production-size target.
Why is WIND so nice to all those stranded tool-makers? Because the relationship becomes symbiotic. If it is in the interest of tool-makers that developers use Tornado, and if developers using Tornado can easily access any tool they want, whether or not it is one of WIND’s, then the decision to use Tornado and usually VxWorks becomes overwhelming in most market segments. As tool-makers realize that Tornado is dominantly popular, each of them will want to connect to Tornado, making Tornado even more popular. The only practical way I can think of to counter this dominance is to focus on a market niche with a huge assortment of useful library routines like MWAR is doing with DAVID.
As an analogy, Tornado may becoming the MS_Windows of Embedded Systems, dominate because of all the inexpensive applications, and has all the inexpensive applications because it is dominate. MWAR is Apple developing niche killer applications (first visicalc, then desktop publishing, then graphics).
Another, impractical way to counter the dominance, is to develop and market a better Tornado-like tool. Unfortunately, Tornado took an average of 12 engineers over three years to develop, so even if you could afford the high cost of development, the game will be over before you can deploy the new tool. Remember the high switching costs!
Hope this helps. By the way, only an embedded systems developer or tool maker could explain exactly when one tool might be preferable to another. I’m looking more at the forest than the trees.
Allen, |
