[REBOL] Why I'll pay for REBOL/command (or not). Was - Will REBOL/View be comme
From: petr:krenzelok:trz:cz at: 23-Sep-2000 16:33
> 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.
Let's say everyone of us has his/her needs for the products. Let me add my
own ones:
I need REBOL/Command and REBOL/View to work together. We've changed some
main concept of our CCD camera, so maybe I will be able to overcome /command
at all, but not sure yet, waiting for our hw guys to decide ... BUT, if I
will need to use some library calls, and would like to offer GUI front-end,
then it's clear I will need /Command and /View together. You know why can I
see RT's policy as failure?
- I am asking one stupid, really stupid question for more than a half a
year. I can't get the same kind of really stupid :-) answer. If I will
regard Carl as having official word for the company, I would think they will
deliver what I need, if I understood him correctly. I remember him stating
something in regards to /Command and on-demand loadable components. IF it
was true, then /View component would be loadable to /Command. But there is
no separate /View component available and marketing department answered me
the requested modularity is not the way to go. Then I repeated my question,
how do I get /View component being available for /Command? Bzzz ... no
answer yet. Maybe Elan thinks I want to use new modern technology for old
purposes, while I would like to offer something new and maybe exciting to
academic and amateur astronomers. I think RT would gain much more thru
presence in various fields of usability by not being so strict about product
usage (e.g. freeing /Library and /Shell components for free or low fee /Core
usage, but making it really pluggable/unpluggable) .... I just yesterday got
to rebmail website and keep smiling while seeing Carl talking about
plug-ins, while opposite is true for REBOL itself ...
I use Visual Objects from Computer Associates here at work, but I really
apreciate CLEAR roadmap for existing products - "planned for 3.0, next
version, not planned, 1Q2K1, interface for 3rd party add-ons" etc kind of
answers ...
I am really confused by seeing all that "BUY IT" links thru website, while
not being able to read end-user/developers agreement before I buy. It really
makes me laught :-) What should I base my decision upon, if I don't know
anything about the form of app delivery to customers? I am e.g. interesed in
form of delivering solution using /Library component, while letting people
adjust my code ... Is there any kind of solution, while preventing our
customers from buying /Command for XXXUSD? You mentioned run-time /Command
version. I've never before heard about anything like that :-) Will it solve
my needs? Will runtime isolate library calls e.g. while steel allowing users
to adjust scripts? So many question ....
> 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.
> 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.
Hmm, now I can see I am not alone having similar requirements ...
I think RT had enough time (more than 3 years?) to define strategy. We are
customers, we are REBOL supporters, we would like to get REBOL to our
customers, now RT - show us the way how ...
PS: If I will decide to write my articles for our magazine I mentioned
yesterday, I want to have clear answers, to prevent myself fooling people,
as I expect the same kind of questions going my way ....
Thanks a lot,
Cheers,
-pekr-
