Hi Jochen,

a few months ago Carl proposed that REBOL/View should replace REBOL/Core as
REBOL's free, entry-level product. I don't think that Carl intends
REBOL/View to become a commercial product. I don't know if Carl (as CTO)
has the final say on these matters.

I don't think you can compare REBOL/Command to REBOL/View with respect to
commercialization. REBOL/Command (and other commercial REBOL
implementations) will only become profitable if REBOL/View is deployed freely.

REBOL/Command is a corporate type tool that would most likely be used to
control a local workstation, an IntraNet or to run as a CGI interpreter on
a Website. Meaning that the use of REBOL/Command does not depend on its
availability on a third party's, a target client's machine. 

Perhaps I have a Website, or I need to provide a tool for my corporate
strategical planning department to retrieve and process data from some
database, or I want to glue applications together to automate some
processing done by me, or by a department I'm responsible for.

In all these scenarios I do not rely on a target audience - that makes its
OWN purchasing decisions - already being in posession of REBOL/Command. 

IMHO REBOL/View's strategical position as a product is very different. It
is to ensure that REBOL as a technology is marketable on a mass consumer
market. 

REBOL/View = A REBOL Language Visual Browser
The relationship between REBOL/View and the REBOL programming language is
similar to the relationship between a webbrowser and HTML. REBOL/View is
essentially a REBOL browser. It takes the combined effort of HTML +
JavaScript + Java to replace REBOL/View. That's where REBOL/View's strength
lies. That's also where REBOL Technologies chance for survival lies. 

/***************************************************************************
*****
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. 
****************************************************************************
****/

A commercial REBOL/View distribution will prevent applications that target
the Internet mass consumer market (i.e. portals, ecommerce solutions) from
migrating to REBOL/View because they cannot reasonably assume that their
target clients have REBOL/View available on their machines. It is this type
of applications that REBOL/View targets. 

Developers, who have to provide solutions targeting this kind of audience
will have to deliver technologies that are accessable to the target
audience, and will be stuck with whatever technologies can reasonably be
assumed to be freely available to the consumer: HTML + JavaScript + Java. 

If REBOL/View cannot replace the ugly threesome, then REBOL/View cannot
fulfill its strategical role for RT. 

IRONICALLY, 
developers WILL be able to use the freely available REBOL/Core to manage
their threesome projects, they WILL be able to use REBOL as a CGI engine
serverside to generate their HTML and Java/Script pages, 
BUT THE CONSUMER WILL NEVER HAVE HEARD OF REBOL, 

because there is no point for consumers of Internet services to put
REBOL/Core on their machine, and therefore neither developer's nor
consumers will turn REBOL/View (or other REBOL implementations) into a
commercial viable product.

For REBOL to become a product (in contrast to being a technology) REBOL
must become the consumer's favorite view of the Internet!

This is only possible if REBOL/View is freely available to consumers so
that it makes sense to develop REBOL/View scripts. REBOL/View will only be
accepted by consumers if there are plenty of useful applications written in
REBOL/View out there. They will only be written if it is realistic to
assume that every consumer who now has a Web browser running on his machine
will soon enough have REBOL/View running on his machine as well.

In this situation IMHO REBOL/View would die as a product, if it were sold
for a price. No consumer will acquire REBOL/View if there are no useful
REBOL/View scripts around. No developer will invest into a commercial
development effort under REBOL/View if there does not exist a large target
market that uses REBOL/View.

REBOL Technologies still has some way to go before commercial REBOL
implementations become profitable. (Just because they're charging a price
doesn't meen that they're seeing a return on investment). IMHO the free
REBOL/View distribution is a tool to turn commercial REBOL implementations
into profit. I think that REBOL/Command (and other commercial REBOL
implementations) will sell because of REBOL/View's popularity and
acceptance by Internet consumer's. And as a company RT stands and falls
with acceptance by consumers, not by developers. Once REBOL/View becomes
the consumer's favorite browser, the developers, investors and jobs will
come running.

As a later step, once REBOL/View has been broadly accepted, I do see a
market for a REBOL/View pcode (bytecode, or slim binaries (Oberon 3,
Juice)) type engine. Commercial developers who want to protect their
scripts from prying eyes will purchase a REBOL/View compiler that generates
slim binary runtimables. The freely available REBOL/View interpreter will
include an engine that interprets the slim binary scripts. Developers who
are willing to share their scripts by deploying their application in REBOL
source code do not need to pay anything to be able to do that. They are
making REBOL more useful. Commercial developers who want to protect their
source code and take advantage of somewhat faster execution speed (slim
binaries are almost as fast as native compiled code, see Oberon 3) will be
willing to pay for technology that will convert their source code files. 

But IMHO the key to RT's success remains to bring out a stable version of
REBOL/View that is freely available and promotes the sharing of /View
source code.


At 12:36 AM 9/22/00 +0200, you wrote:
>After the announcements of the REBOL/Command 1.0 release
>I wonder if REBOL/View will be free or commercial?
>
>If it will be commercial will it be similar expensive like
>REBOL/Command?
>
>Please don't understand me wrong - I like REBOL but coming
>from the CommonLisp section I wonder about some things:
>
>- If REBOL will be mostly commercial how does it compare with
>  e. g. Common Lisp or Python?
>
>1) REBOL has "dialecting"
>In Common Lisp we have the same "dialecting" features of REBOL.
>Python doesn't have such features.
>
>2) REBOL is higly network integrated
>Common Lisp and Python lack the high integration of network-protocols
>that Rebol has.
>But it seems to me that this could be really change fast if enough
>Common Lisp/python developers see and understand the network
>related features of REBOL.
>
>3) REBOL is highly portable (40 platforms?)
>Common Lisp exists for nearly all REBOL-capable Platforms too
>Python exists on a lot of platforms (including all Platforms that have
>Java)
>
>4) REBOL is small (~300k)
>Small Common Lisps need around 1,5 MB
>Pyhton needs ca. 2 MB
>So here is REBOL really a lot better...
>
>5) REBOL/Command
>The features of REBOL/Command exist for Common Lisp and Python
>without the need for paying.
>
>
>To come to the point:
>If REBOL/View will be commercial liek REBOL/Command then
>I wonder if REBOL will be a real competitor against Common Lisp for
>me personal needs...
>
>But again... I like REBOL and I hope it will not be fully commercialized
>
>Regards
>Jochen Schmidt
>[EMAIL PROTECTED]
>
>
>

;- Elan [ : - ) ]
    author of REBOL: THE OFFICIAL GUIDE
    REBOL Press: The Official Source for REBOL Books
    http://www.REBOLpress.com
    visit me at http://www.TechScribe.com


Reply via email to