Mark,
You said:
> The other RTOSes are almost as old and no engineer needs to be convinced
> that they work.
>
> There are 3 reasons why so many projects use proprietary software:
>
> 1) The military-industrial complex exists to provide jobs, not to defend
> the nation in the most efficient possible manner.
> 2) Nearly every engineer is proud of his work and believes the code he
> designs and develops is the most elegant.
> 3) The code already exists from a previous project and there's no sense
> in paying an RTOS vendor for code that performs the same functions.
While there may be some truth in your above statements (#2 in particular!),
my opinion is that you are missing the point a bit, or at least missing
the trend in software today.
I've been a software developer for 10 years in an Information
Technology (IT) group. While no one would confuse me with someone who
has great vision of the future, I am able to see a very clear, strong
trend here towards moving to off-the-shelf software solutions.
I don't know that much about the RTOS industry, but from what I've seen,
it appears to me that the same trend I am seeing first hand in IT software
is also happening in the RTOS industry.
My restatement of your points above would be this:
The reason that there are so many projects that use proprietary software
is that in many cases you didn't have much choice. 10, 15, 20 years ago,
if you wanted software to run your business, you had to write it
yourself. As time went by, you added onto those systems, connected them
to other systems, further tailored them to your business.
Well, now, 10-20 years later, where are you? Yeah, your systems work
(at least they do what they were designed for 10 years ago), but you want
to extend them to be able to do all the wizzy things that computer systems
do today (Internet, java, whatever, insert your favorite buzzword here).
But your system is based on 10 to 20 year old technology. Now you're in
a bind.
Of course, the difference compared to 20 years ago is that now you have
the option of buying an off-the-shelf software package. Sure, it doesn't
do everything your old home-grown package did, but you can add some
"bolt-on" stuff to tailor it to your needs, and the system is already
written for you by this 3rd party company so you can make this a quick
transition, and say, look at all those neat new technology doors that
are opened up!
To a project manager trying to do something about moving forward from
all the old legacy systems (and do so quickly enough not to get fired),
the COTS looks pretty attractive. Sure, the engineers will turn up their
noses and complain about the crappy system designed by these 3rd-party
yahoos (after all, I could do much better!), but they're
not the ones making the decision to buy the COTS package!
This, in my mind, is the force behind the move to COTS packages in the
IT world, and is why companies such as SAP and Clarify are doing so well
selling software. I suspect that the same process is taking place in
the world of embedded systems.
Of course, transitioning to an off-the-shelf package is not as easy as
the above two paragraphs make it sound (in fact, it's damn hard, at
least in the IT world of a big company), so a project manager is going
to be nervous about such a large change. They've got enough other things
to worry about without having to also worry whether the COTS package is
reliable. In the project manager's mind, the COTS definitely does
need to prove itself before he/she is going to feel comfortable choosing it.
> I hope you're not offended by the fact that I believe Allen Benn's
> statement is absurd that the project shows that COTS software works
> well enough for critical missions.
So, to get around (finally) to my point, I really strongly disagree with
your above statement. Something like the Mars Pathfinder mission is
excellent publicity for a company, and is the kind of thing that will
stick in a manager's mind when it comes time to make the all-important
decision of what package to choose.
If you're a manager getting ready to choose a COTS package, which do you think
is the safer choice: a package that only has a couple of small users, or
a package that has been successfully implemented by a large number of other
companies first, including ones with mission critical needs?
Jim |
