Ever think about paying for your cross-compiler on a per-use basis?
Look at the EDA (electronic design automation) domain. Hardware designers use EDA tools 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.
So far, though, the traditional outright sale of EDA products, for cash on the barrelhead, is the only model proven profitable. At the moment Internet-tool-rental seems as viable a business model as so many others employed by the dot-coms.
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 three-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, in-circuit 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, and can seldom port the tool chain 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. 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 is 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?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .
In my job, it's quite common to have to buy a compiler just to write a 200line program to insert into a customer's board, and then to never use thatcompiler again — except when the test program needs upgraded in 5, 10, 15 years. Then you hope the magnetism hasn't faded from the old installdiskettes and that it will be possible to run the old compiler on muchnewer hardware and operating systems. (Stamped CD's should at least take care of the fading magnetism issue in the future, but prospects for OSsupport seem to be declining…) But as hard as it is to get an ancientcompiler running, it would be worse to have to switch to a new version tocompile old code — quite aside from the matter of having to pay thousandsto buy the new software in order to change a half-dozen lines.
So I would be very interested in renting compilers, but only if the vendorcould provide absolute guarantees that old versions would be available andusable forever — even if they have to write a software emulator for theold hardware and OS. A contract such as this would have to specify that Iwould upgrade my computer every two or three years to a system specifiedby the vendor. OK. It would probably cost as much for a few weeks rentalas buying the software. OK. Usually I'll get the job done so fast I'llstill save money, but even when I wind up paying more, the service ofkeeping the old versions runnable is worth the cost.
The one thing that would be intolerable would be that standard softwarelicensing clause — the one that says the vendor is not responsible forwhether it works… (Usually this is in conjunction with a clause statingthat you can't modify the software. This is buying a new car under aused-car “as-is” non-warranty — with the hood welded shut and jailsentences for breaking the welds.)
JACK REPLIES: A very interesting set of points. It's appalling that our”standards” that define the languages are so weak that we worry that timeobsoletes our code. Perhaps a more Ada-like approach is needed, withextensive testing and intolerance of language extensions?
Renting the tools during the concept and initial design phase might work.After the implementation and integration work begins, then I want a copy Ican archive with the source code. When I have to maintain the code, thefirst step is to verify I can recreate the executable. Then test thelatest versions of the tools with the original source code (This is whenrenting would be applicable). If all goes well at this point, then startlooking at modifying the code to fix the problems or add the latestmarketing bells and whistles using the latest owned version of the tools.
Engineer (who writes software)
While I'm not a design or hardware app engineer developing a product,I ama software engineer specializing in today's manufacturing/applicationdocumentation. I'm the guy you might be renting from. From this side ofthe tool, I have to say that not only have I been seriously consideringthis model for some time, those of us who would go into such a model wouldno doubt support our customers who need previous versions of our product -just as you support your customers who need YOUR previous versions.
I really don't see a problem in this area, although I understand the concern.
K&L Microwave, Inc.
This issue encompasses more than simply lease/rent vs buy.
If the product being used contains copy protection it also falls prey tomost of the same pitfalls the leased software encounters. Unless thescheme is little more than a simple text file it is likely to be affectedby hardware and OS changes. Given the state of flux most of ourworkstations are in (I doubt it's even possible to get the same HW/SWcombination in a machine two years in a row), that means that when yourmachine fails it is necessary to get new licensing information.
We have a project developed using a DOS based compiler. The company thatproduced the compiler no longer makes any compilers. If it were hamperedby copy protection what do you think our chances of getting a new dongleor registration key would be? Or getting a patch to allow it to work on a1 Ghz processor on NT2000? On the other hand it works just fine in aemulated DOS environment.
Compilers and most other development tools are at ther heart file filters,there is no excuse for them to be dependant on anything other than thefile system.
We have the displeasure to use two tools protected by FlexLm. One, astatechart tool, an 'upgraded version' of an earlier product. Thequadrupled the price and memory requirements while quartering theperformance and dispensing with the manual to compensate. In additionthey introduced a rather large number of bugs (many of which are nowcleaned up). We were planning on multiple copies, we are now on thelookout for a replacement. The second tool is a compiler, they introducedFlexlm on an upgrade. Since this is used on a project significantly intoits development phase we have felt blackmailed into continuing. I don'tfeel real confident that we will be able to maintain the product in 10years because of the copy protection.
The upshot? Any new development tools with copy protection or that comefrom companies that use copy protection in other products will be at aserious disadvantage. This also extends to the silicon, if amicroprocessor/microcontroller is only supported by tools that arelikewise 'protected' then we will be looking at alternate processors.
Before starting at VSEA I wasa consultant, full-time fora decade. I have severalversions of C and Fortrancompilers for the x86, DOS,Win16 and Win32.
Don't even *think* about usinga different dev tool than theclient is using, except as anexperiment.
And remind your clients /customers to do off-sitebackup, not only of source,but also of dev. tools!
As for “renting” tools, Idon't think I'd ever beinterested — anything I useI want a copy I can control.I can't control the weather,the tax laws or customer /client expectations — I can& do want to control criticaltools.
With hardware that can bedifficult, try supportingold models that use vacuumtubes. And if some customeris still using it, they WILLwant support.
Even older PMOS or NMOSversions of embedded processorshave been EOLed, gotta migrateto CMOS versions (if anymigration path exists at all).
At least with software, Ican keep using MS Fortran 5.1and Visual C/C++ 1.52c, BC 4.53and my copies of Watcom C/C++and Fortran.
If I had been renting MS Fortranguess what would have happenedto me when MS exitted theFortran market?
Sorry. Not interested.
I just finished doing some maintainance on a product using a compiler andlinker written in 1985. Many products that I have worked on just refuseto die even 15 years later. I have been in many product meetings wherethe statement has been made “lets just change the software on product Xinstead of doing a new product”.
Sr Software Engineer
Buying and owning your tools is the ONLY way they will be available fiveyears later for maintenance on an old design. That may be irrelevant forchip designers, but it is crucial for firmware. At our company we areeven banning the use of tools offered on an annual lease plan, such as thenew Xilinx front end design tool.
Jack Replies: I have seen company after company get in trouble when theyfind they don't have the tools needed to maintain an old project. WatchUSENET and see the desperate cries for PL/M compilers, old versions ofBorland's C, etc. Interesting point about the leased tools, too. This couldbe a huge issue for companies planning for long term maintenance ofproducts. The vendors better pay attention!