By Jack Ganssle
Pay By Use Tools
Published 5/11/2001
Ever think about paying for your cross-compiler on a per-use basis?
Look at the EDA (Electronic Design automation) domain. These tools are used by hardware designers to create new chips, lay out PC boards, and run complex simulations and emulations. They're expensive, sometimes in excess of a million dollars when hardware accelerators speed the IC emulation process.
For the last couple of years some EDA vendors have been dabbling with providing access to their tools on-line. One version lets users upload designs to tools hosted at the vendor's site. The compiled or emulated design then zips back to the user over the net. A variant lets you download the tool, which runs for hours, days or weeks before turning into empty bits. In either case, charges accumulate on a per-use or per-hour basis.
Yet, it is a pretty cool idea. Partly there's the engineering ego-thing at play; after all, don't we all just know we're good enough to get the design right on the first try? Why buy when we're hardly ever gonna use the thing? (As a reformed ICE vendor I well remember so many developers who figured renting was cheaper than buying. Almost without exception that 3 month rental drifted into 12, 24, or more. A serious profit center, dontcha know).
The EDA and firmware tool worlds are, well, worlds apart. Each caters to a different breed of developer, one the hardware designer, the other the software folks. I think that those purveying firmware tools (compilers, emulators, and the like) could learn a lot from their EDA cousins. Why not deliver the products via the net?
Serious access to non-crippled tools has some big benefits. How do you know, for sure, that the product works - I mean really works - with your complex design? Sure, we can take advantage of the almost universal 30 day trial, but - again speaking from vendor-experience - practically no developer ever gets around to running exhaustive, meaningful tests till long after the trial period expires.
Perhaps your company designs around lots of different technologies; an 8051 on this product, 68332 on another, and others as needs vary. Consulting outfits, especially, are at the mercy of their customers needs and biases, so can seldom port the toolchain between projects. Why buy when you'll be done with the tool, forever, in a few months?
Even if you're not consulting I bet there's lots of things you use infrequently at best. Me, I'd love to be able to get rid of Visual C++. I use it a few times a year, but for the rest of the time it sits there, eating up system resources. How much better to rent the thing, always using the latest version!
(The extreme of this is to get rid of the PC and replace it with a gateway into the net. Need a word processor? Download it as required. Me, I'd rather have a big old hard disk with all of the commonly-used programs resident and running fast, all of the time. I just don't want to have to own every program I'd ever use, no matter how seldom).
As a project waxes and wanes the size of the team varies. Need an extra developer for just a month or two? Who wants to pay big bucks for one extra compiler seat for that time? Embedded cross compilers can cost $5-10k, far too much for such a short-term need.
There's some downside: upload your code to the vendor's server and the company's lawyers will go into spasms of brief-writing over their fear of losing trade-secret protection. I, for one, can live with the threat of losing some control over the source. Clearly the open-source movement is showing us that "secret" is not necessarily the same as "good business practice".
Perhaps my biggest fear is that I may lose access to old tool versions. Embedded systems live forever. In two, five or more years, when the 22 year old marketing weenie wants a quick feature change to the product, I want to use the old tried-and-true compiler. Over the course of those years surely the tool will have evolved considerably, from version 4.0 to 6.2, with new bugs and issues. At the very least the code generator will be different. which means the real time performance of my product will change. If the net-delivered tool is always the current revision, then I've lost access to that version 4.0 that we know worked so well on this project.
What do you think? Would you rather dynamically rent your cross development tools rather than buy?