Comments on: It came from outer space...
REBOL Technologies

Comments on: It came from outer space...

Carl Sassenrath, CTO
REBOL Technologies
27-Aug-2009 22:37 GMT

Article #0424
Main page || Index || Prior Article [0423] || Next Article [0425] || 14 Comments || Send feedback

Our REBOLer friend, Pekr, recently brought this REBOL-related website to my attention:

Well, it was a bit of a surprise. It is possible someone contacted me about it before, but from the domain name, I thought I'd already been there. Funny how that happens.

So, don't let the name mislead you. It's much more than just another tutorial. It includes articles, programs, links, and other insights. It looks like the site is also planning to support community submissions. (I even tried to create an account for myself, but it's not very clear as of yet how that's accomplished.)

The site also contains a sizzling commentary on RT's wonderful marketing savvy: "The JSON Saga: an IT Marketing’s lesson for Rebol?" Yes, some good points there... many have been said before, and it's always good to hammer on this topic.

Yes, our marketing needs to change. There's always a tendency to let marketing activities slide while development takes our full energy. But, as we near the finish line for R3, we need to ramp up on the marketing a lot more.

BTW, if you have inputs on this topic of marketing, post them either publicly in the attached comments or privately to me on the feedback link.

Anyway, we'll add RebolTutorial to our main web links to give newcomers a quick way to reach it. A useful resource for everyone who REBOLs.



Carl Read
27-Aug-2009 19:40:56 is by far the most common site to show up via Google Alerts in recent months. So they obviously know what they're talking about, marketing-wise.
28-Aug-2009 10:40:17
They post abstracts of their articles on aggregator sites like That has a dramatic effect on visibility.
Maxim Olivier-Adlhoch
28-Aug-2009 14:35:07
I think his comments on REBOL's marketing side are a VERY good indicator of *perceived* quality vs. *factual* quality.

IMHO RT has to improve its skills in this area, which is directly related to marketing.

give people what they need, and them tell them they now have what they want. The two aren't always perceptually the same, marketing helps bridge the gap.

look at cars for a very good case of this... people NEED reliable, safe, fun, ergonomic, practical, performing cars... but unless they are also pretty, comfortable, cool engine exhaust sound, and have this indescribable attractive design entity, they will look elsewhere first, even pay more for a factually inferior system.

today's corvettes are among the very best sports cars in the world (performance and reliability wise) at a fraction of the cost of other more prestigious makes... yet it still suffers from "its only a corvette".

Image is everything, when you want to attract people to your club.

Python addressed this about 2 years ago, when it converted its image from a geeky underground "thing" to its now more appealing public figure... which still caters to the geeks, but lets the managers feel confident... guess who hands out the paychecks... ;-)

I think its REBOL's turn... to "turn heads". R3 is definitely becoming one of the best programming platforms in the industry... now we need to start getting people in on the fun... let's start with REBOL Technologie's image itself!

Oscar K
30-Aug-2009 20:11:05
Where did current REBOL writers learn about REBOL, and why do they use it? This might provide a platform to build a new marketing strategy. Build on strengths.

Are other languages like Python and JSON really more successful? Or are these languages widely embraced because they were written to fill the gaps that arose between servers and browsers when advertising / media industries raced to use the internet for their purposes. Did they resemble the languages that programmers were used to? What are these other languages mostly used for?

What has been REBOL's past marketing? What was the spiel?

Example: “Write programs in a few lines instead of thousands” While true, did it also send a negative message attacking the programmer's current expertise? Were the good points overshadowed by a negatives in these types of comparisons? Or, “Internet Operating System” or maybe “language of the Internet” may have been terms once used. But maybe people thought they had enough “Internet” and “Operating System” security issues already.

Who is REBOL written for?

REBOL, it seems to me, is written for advanced programmers. But, paradoxically, introducing REBOL requires entry level instruction.

There is entry level instruction, but lack of entry level follow through support, One example of this might be that only recently was it demonstrated how REBOL could print output (Softinov).

So, lack of follow through support may turn off new users, and none but the most advanced programmers able to bridge the gap from the intro level material to the higher levels. (for a variety of reasons, time, expertise,....)

How to gain acceptance?

Possibly split the market, with segment like product branding,

  • advertising / media (join em!)
  • education – a great intro to programming for every school
  • scientific - research data acquisition/ manipulation

  • business - communications
  • engineering - all of the above, of course.

    Many companies create models, the automobile industry is a great example. Many models, one concept (almost).

    ...and maybe some method of encouraging current REBOL writers to bring REBOL into their communities, kind of an exponential grass roots marketing strategy.

  • Steven White
    1-Sep-2009 13:04:13
    Would there be any value in getting the free (as in beer) versions of REBOL pre-installed on all computers? That would be one more step toward ease of use, not having to even install it in the first place.
    1-Sep-2009 13:57:06
    I think so, thus we include R2/Core in Syllable Server so far and plan to include R3 in both Syllable Desktop and Syllable Server in the future.
    3-Sep-2009 2:49:36
    As for marketing related topics - we can discuss them for years. There are long term strategies, and short term strategies.

    I would like to concentrate upon the short term strategy. Let's try to adress some middle marketing/developers/users questions:

    • Is R3 ready for beta?
    • What defines good beta?
    • Why users are not already using R3?

    3-Sep-2009 4:29:36
    Uh, pressed wrong button :-) So here we - go - continuing my previous post ...

    I think that R3 is in more mature state than R2. The language - its semantic - is much better defined, especially in regards to datatypes and their transitions, we have also got some very cool new features inside. So why is not REBOL community using R3 yet? Does assigning something from alpha to beta change the thing itself? I think - not ...

    What are ppl interested in, is a - deployment. R3 though, is missing some fundamental stuff, which creates perception, that R3 is still far from complete. Here we go:

    • Networking protocols - we have http 1.1, which has troubles with slower connections, and no proxy support. Usefull protocols like ftp, smtp, pop3, along with proxy support, are missing. Some guys are interesting to build R3's networking upon some stronger mechanism, as e.g. Uniserve multiplexing engine is. But generally - if we are about to create new protocols, maybe it would be good to have few parse enhancement in-place, although maybe not necessarily ...
    • DB protocols - there's currently no chance how to connect to DBs using R3. We miss - mySQL, SQLite, PostGress, ODBC - all those were awailable for R2 ...
    • Call - call output is not easily traceable in R3 (see CureCode ticket #1223) - 'call is absolutly essential deployment instrument. Some guys even used it to call command line DB access tools - SQLite, MSSQL
    • Console - some time ago we agreed, that for system admin, raw/native OS console is important. So we've got it. However - for common user, Windows console is a usability nightmare. My psychological estimate is, that it can be as much as 30% of reluctance to even give R3 a try, and I really mean it ...
    • CGI - there was some CGI example for R3, but it was absolutly inuntiitive. We need our CGI functions back, to get it at least to R2 level, or we removed another important possible usage area ...

    We need to address all above points, in order for users to get feeling, they don't need R2 anymore. And I even excluded View this time - so those are Core only remarks. Remember - users do want to USE solutions, not to BUILD them themselves ....


    3-Sep-2009 4:35:53
    So now - is that all? Can we proceed to beta, if we address those? I still think not. So what other questions should we answer?

    • Extensions - let's be sure the API is rather stable, because once ppl start to produce new stuff, it will be bad to break it later. Extensions API could benefit from several suggestions, proposed by Maxim (images, and callbacks beind done as one callback handler/dispatcher per extension handler - Max showed an example)
    • Codecs - codecs are currently missing docs, and they are also not streamed. I surely don't want to load all my blue-ray movie into R3 first, then decode it? :-) Such stuff might have bigger consequences. Some 10 years ago I wanted to have also "streamed parse", to allow building codecs/protocols by using REBOL's parse functionality. This area might need some serious thinking ...
    • Devices - those would too probably benefit from some docs. Will devices be somehow merged/mixed/available to extension authors, via a defined interface?
    • Portability - nothing was said about how actually Core vs Host code is isolated, when Host code is about to be released, what are going to be the porting rules, will there be a code signing available? Will there be the central repository for REBOL, or do we get tonnes of various REBOL repositories around the web? I would like to suggest taking baby steps here, before we get ourselves into messy non-organised situation ...
    • Packaging - nothing was yet said about the packaging mechanism. In R2, we've got SDK, which allowed us to build new executables, but we had to select appropriate kernel to build against. What's the R3 scenario going to be like? What if I don't need View kernel inside? Is View kernel thrown into Host code, without further internal isolation? (being a component, binary module, etc.)? If so - bad enough, how do I easily build Rebbase for my fast CGI purposes for e.g.? Should I strip it out from C level Host code layer? Possible, but surely not for beginners, while Encap allowed that. Would it be possible to have something like boot-loader (startup-sequence, autoexec.bat :-), which would define, what binary and script modules/components we want to load? So that Core can later load View module/component/extension (whatever we call it), then VID, then my VID script?

    I think that my second bullet list does not need to be fully implemented before we go to beta, but it needs some direct answers, so that the architecture and its consequences on later usability is clear fromt the very beginning since when R3 goes into beta ...

    So, my long two cents. And I even touched only the release strategy itself, not further levels as websites, marketing, etc. Those can come a bit later, once we have a product ... a well defined product ...


    4-Sep-2009 1:33:24
    ... thinking further about the topic, I should probably add

  • Unicode - I think we still have some work to do in regards to Unicode and locales. Nothing yet was said about rather important topic - unicode charset sorting. We definitely need "somehow" to allow to define collates. Imagine your grid containing data from DB. DB itself can sort for you. But if you add your data in REBOL form, your grid will not be sorted properly, because R3 can't sort according to collation sequences.
    If View/VID is going to be part of beta, many ppl will be disappointed, if View does not include proper displaying of Unicode chars.

    Generally - in April/May you defined project-plans.html - maybe you could just update it, and make it public. Then we can discuss it, to see, what devs consider being crucial to push R3 into beta stage ...

  • Implement Rebol in Javas
    7-Sep-2009 5:36:40
    If you check Skulpt (, this is an implementation of Python in Javascript so it runs on ANY web Browser. IMHO we need this for Rebol. We accomplish a lot with this:- 1. No more Rebol plug-ins 2. Huge base of Web developers who will migrate to the power of Rebol 3. No more VID ;-) (such as the HTML Dialect)
    7-Sep-2009 12:22:07
    Really interested, what would be performance of REBOL in Javascript. Gee, where the world of IT is heading? ChromeOS - browser upon Linux kernel? REBOL in Javascript? What a crap ... and why? Because of status-quo? Because it is easier to be a sheep, instead of trying to do what you think is the best? REBOL for those who are brave enough to go their own way ....
    9-Sep-2009 1:36:22
    Ok, first off, I am NOT in any way shape or form a programmer. I'm an individual who has been following REBOL development for a few years, with great interest. This has two consequences. First and foremost, it makes me feel lazy because I am an IT person with no coding skills who would LIKE to learn, but hasn't made the time. More importantly, it makes me someone who is judicious about what I spend time following, simply because of my predilection for laziness.

    Now initially, this sound bad. OK, it IS bad =-) However, when it comes to marketing ANY product, be it a physical tool, a mental tool, or what have you, the paradigm remains the same... everyone wants a tool which will make the job easier, the turnaround shorter, and the result predictable. Case in point... in OUR industry (mindset, whatever) many people look at where Xerox failed, and M$ / Apple / Cincom capitalized. I have. But BECAUSE of our industry, AKA blindside, we often disregard a simple reality... Who does NOT know the word Xerox? To this DAY, people will A) make a photocopy, or B) Xerox something. Parc Place be damned, they got the idea across!

    9-Sep-2009 1:38:31

    My point is, Bill (damn his soul) got it right, but liked to compromise. Steve (save his soul) learned to compromise. Every one who has found a commodity niche in IT has been able to lever a certain amount of people into a position of ADOPTING a technology because it fit a certain necessity, whether it was the best technology or not.

    Now REBOL sits in a position where it appears that in most respects it IS the best technology, it DOES answer the most questions... and the majority of comments I see reach a technical level where I would LIKE to understand it, but I can't pidgeonhole it. Look at MetaCard... it was (and is) a great, and in some ways a CORNERSTONE technology... and years later, Runtime Revolution is making a huge revenue from that technology... and deservedly, don't get me wrong. But what if?

    We talk about betas, and production, and foundational concepts. HUGELY important, but NOT RELEVANT. Marketing doesn't rely on the STABILITY of a tool... Gates has proven that! Marketing relies on the ADOPTABILITY of a tool! We can fine-tune a system until it is virtually perfect, but until we target an audience, and make them BELIEVE that the tool is the answer to the job, none of the technical details mean a damn thing!

    Here's an example. Were you aware that early Ford vehicles could run on either petroleum OR alchohol? There was a dash switch. Now , an American president with LARGE (at the time) stakes in petroleum sales did two things... he proletyzed petroleum as a safe and stable fuel, and he instigated a movement which resulted in the Prohibition act. He wasn't RIGHT, but he was SMART, and he spoke the right words at the right times. Everything I've read is eminently correct, but it addresses those who understand FIRST, and almost dismisses those who WANT to understand.

    So: Rebol can fit almost any situation, right? FIND the situation that needs the most addressing, and suit the pitch to the need.

    So: Rebol is intrinsically simpler to learn than most platforms, right? Market it to the simple! Make the average joe both AWARE of the system and aware of what an EASY solution Rebol can be! Look at how many hits RAD programming gets on google daily. Then, make the RAD paradigm fit what REBOL is capable of, not the other way around.

    From someone who WANTS to learn to love and live Rebol, in many ways it markets itself. But let's be honest... like any non-mainstream system, Rebolers tend to think like Rebolers, and that occludes certain vistas. Linux is the biggest example of this situation, followed by SmallTalk. Had either created a presence to the general masses even ten years ago, we would have a totally different IT landscape right now. And with the emergence of metalanguages, script-as-program paradigms, and interpreter - vs - compilation as VIABLE alternatives, There is room for someone to elbow Java or Ruby aside and at least make ROOM on the field. Why not the simple seeming elegance of Rebol, which is backed with a RICH HISTORY of wins (and we'll downplay the history of marketing failure, which HAS lost Carl both deserved distinctions AND deserved dollars, to be honest.)

    I'm sorry if any feel that this has been insulting, because it CERTAINLY wasn't intended to be. I think your project is FANTASTIC, I expose as many talented people as I can to it, and one time allows, I will learn the beauty of being a Reboler myself. I hope I haven't offended, but if I have, please feel free to berate me at gregdobson(at)

    I applaud your work, and hope that you've found something constructive in what I've had to say. Cheers!


    Post a Comment:

    You can post a comment here. Keep it on-topic.


    Blog id:



     Note: HTML tags allowed for: b i u li ol ul font p br pre tt blockquote

    This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

    Updated 3-Mar-2024   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code