Metacard vs. Revolution

Tomas Nally tnally at aga-engineers.com
Wed Apr 17 09:11:01 EDT 2002


Barry Wrote:

>I know that Revolution uses the "Metacard engine". Why, then, do we have 
>-both- Metacard and Revolution? What I mean by that is: Why does 
>Metacard permit Revolution to utilize its "engine" when people buying 
>Rev licenses are probably giving most of the money to Revolution with a 
>small "engine fee"(?) going back to Metacard?

This is a business question which, to me, is almost as interesting as
discussing the technology.  We can only presume that Metacard entered
into a business relationship with RunRev because they saw it as an
opportunity for a decent (long term) return on the costs required to
establish and maintain the relationship.  This is the same reason
why any other two companies may partner together.  

I remember Scott saying on other occasions that he acknowledged
the need for a fancier UI, but thought that his 
company was best served by committing the resources of the company
to improving the engine rather than the UI.  Rev represented
an opportunity to marry the engine to a pretty dang cool UI without
tying up the intellectual capital of the MetaCard organization
(presumably).  Of course, all this is speculation on my part.  

That's one reason why, despite the fact that I'm an infrequent
RunRev user, I always scan for any posts by Scott: the combination
of technological savvy with business savvy is very interesting.

>I guess the other thing that sort of bothers me is this: If Metacard 
>licenses its "engine" to Revolution, what happens if they decide -not- 
>to license it at some time?

I'm not a developer, but I guess developers always build products
with the assumption in the back of their mind that their development
tools will always be upgraded to some new version: each development
tool will be followed by a successor development tool.  I guess that's
quite reasonable: the long term viability of the product lines produced
 by a developer depends on the availability of these successor
development tools.  Therefore, the likelihood of NOT being offered a
successor development tool becomes part of the calculus of risk in
choosing the development tool.

Not being a developer, I currently have nothing at risk.  However,
many posters herein are developers, and they are placing their money
on the bet that the viability of RunRev will continue.  I'm hoping for
that, too, just because Rev seems like an outstanding product.  Even
if RunRev should falter, however, the risk is mitigated somewhat by
the fact that MetaCard has established some longevity (as measured in
computer industry time, rather than geological time).  Rev projects 
appear to transfer very easily to pure MetaCard projects.


---Tom Nally, New Orleans








More information about the use-livecode mailing list