Will REBOL/View be commercial?

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 [jsc--dataheaven--de]

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? >Jochen Schmidt >[jsc--dataheaven--de]

Elan, Would you give us some pointers re: Oberon 3 and Juice. I know where Oberon-2 is but not Oberon 3. Just curious. Thanks Geo... [rebol--techscribe--com] wrote:

Elan, Sounds really plausible! I really hope you're right and REBOL/View continues to be free and well supported. BTW: I really enjoyed your book :-)

Hi Geo, Oberon 3: http://caesar.ics.uci.edu/oberon/ Juice: http://caesar.ics.uci.edu/juice/ At 06:44 PM 9/21/00 -0700, you wrote:

>Elan, >Would you give us some pointers re: Oberon 3 and Juice. I know >> 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.