>
>/***************************************************************************
>*****
>If REBOL/View becomes commercial, then it is no longer competing against
>the ugly combination of HTML + JavaScript + Java,
>BECAUSE it cannot hope to compete with the ugly threesome
>WITH RESPECT TO availability on the consumer's, the target audience's
>machine.
>****************************************************************************
>****/
>
I agree with Elan's analysis wholeheartedly and I want to share with
some concept from a business letter I'm preparing Rebol Tech's
marketing staff.
Why I'll pay for Rebol/Command eventually
------------------------------------------
Rebol/Command is fairly priced. I can gain far more than the
$300-$500 in a variety of ways, _IF_ I can use the whole family of
REBOL products.
First, I can cut development costs, if I can really write-once, run
everywhere. With the "ugly threesome" I have to do a lot of testing,
literally for each browser version on each platform.
Second, Rebol is so compact, I can deliver my killer-application by
e-mail. That's rebolutionary and it opens the door to a whole new
world of applications.
Third, it takes a lot of time to train a software engineer on
HTML/XML+Javascript+Java. He can learn REBOL in a far shorter time.
So I can reduce training costs.
Last, but not least, REBOL's productivity is terrific.
So REBOL is something I'm happy to pay for... but I'm saying it's
REBOL as a whole environment that it's worth his money.
REBOL/Command is mainly, if not exclusively, a server-side tool.
That's crystal clear.
So...
Why I don't pay for Rebol/Command now
-------------------------------------
Basically, because I don't have a clear roadmap for Rebol/View development.
I believe it's /View, a free /View, that makes the difference with
other solutions. But today we don't have a hint to the release date.
So, I can't plan to develop a couple of important applicationsusing
REBOL because I can't guarantee a delivery date. REBOL/View could be
released tomorrow or next century as far as we know.
Moreover, quite ironically for a 40+ platforms product, I can't use
it to develop my applications because it falls very short from
covering my market. I have no idea about the release time for the
Macintosh version, the second delivery platform as share in the
common user market. If I don't have a Mac version, I lose about 30%
of my educational market and I doubt Amiga, BeOS or Linux versions
could amend for this.
So what is that I need to choose REBOL as my preferred development tool?
------------------------------------------------------------------------
1. I NEED A CLEAR ROADMAP.
I have to plan my work myself and I need to know if and when a tool
will be available.
2. I need /View.
It's the trojan horse for the client-side. It's a free /View that
makes the difference from a marketing viewpoint. And because it's a
client-side tool, I need first the Windows version,and immediately
after the Mac one. Then I have all my market covered today. Then we
can think of Linux, BeOS, etc.
3. I need to deliver my client-side script in such a manner that none
can look at my code.
This is coming as a /command runtime. Obviously, I expect it to offer
also the /View features.
4. I need a robust server-side tool.
I already have it. It's REBOL/Command.
Finally, what is that I'll be glad to pay for?
----------------------------------------------
My technician soul likes REBOL, very much. I want it to stay alive
because I want to work with REBOL. And I want to reward the men who
brought REBOL to us.
But my manager soul would like to pay for support more than for
products. Seeding, assistance, counseling, training, tech news,
etc... about the family of the REBOL products as a whole... that
would be the real value to me.
--
Paolo Russo
[EMAIL PROTECTED]
_________________
PERD s.r.l.
Virtual Technologies for Real Solutions
http://www.perd.com
