[REBOL] Re: free REBOL?
From: petr:krenzelok:trz:cz at: 4-Aug-2003 12:33
Hello Elan and all,
sorry if I don't match the discussed topic precisely - I was away for
some two weeks from all rebol happenings, but I will try to provide
another pov. I have to say that your post is very educated and balanced
and my intention will not be to say - hey, you are wrong here or there,
but rather to ask questions ... kind of passing another arguments into
the game ...
> Hi Mike.
> You wrote:
> > I know I'd never suggest my company use REBOL
> > because I know I can accomplish the same things
> > with python, ruby or Java for free, even though I like
> > using REBOL.
> 1. Why do you like REBOL? In my mind REBOL is superior to the
> languages you list, because it makes me by far more productive. I can
> produce results much faster and more easily maintain existing
> solutions using REBOL. My increased productivity translates into
> significant savings for the company I'm working for. The $$ they pay
> me generate more results for them, therefore the per-result-cost is
> lower. Since when do companies prefer to spend more money on labor,
> rather then invest in tools that lead to a higher degree of
> productivity? No business entity I know of relies on the existence of
> free tools, in order to be successful. Everyone understands that
> superior technology has a higher price that is rewarded by improved
> results and increased savings over time, i.e. lower cost-per-unit.
> In short, IMHO you are not doing your company any favors, by assuming
> that the cost (free vs. commercial) is the most important criteria
> for choosing the appropriate tool for a job. This may be true for the
> impoverished hobbyist, who'll make do with substandard tools, since he
> can't afford anything better, and does not have to deliver commercial
> quality results within a set deadline, but certainly not in a
> professional/commercial environment, where money is meant to be spent,
> invested, used as a tool to improve productivity, the ability to
> compete on the market place, and the ability to optimally satisfy the
> needs of critical customsers, who want to spend as little as possible
> in return for as much as possible. Here, in the commercial
> environment, money is not intended to be saved and hidden away under
> the mattress and stretched to last as long as possible, here money is
> a means, a tool for accomplishing these commercial goals. If REBOL can
> improve the company's ability to accomplish these goals faster, and
> with less payroll costs, then REBOL is worth every penny of its price
> to your company.
I think there are several levels mixed here. I think that with rebol, we
- developers (but also RT) is still walking in circle and we can't get
past the circle:
1) Large companies - I work for one. There is already the list of tools
for programming set. It is very difficult to introduce new ones. Let's
face it - IT manager does not care about the tools - he/she just wants
things to safely work ... and work the cheapest way it can be. So how
does rebol technology get itself into the company? I think there is
nearly NO chance for it to happen from the management pov. Rebol is not
known, even amongst programmers, not to mention IT managers. So the only
chance is some programmer/employee, who really likes Rebol and starts
writing some small helpfull scripts in the company. Even if Rebol is
free for basic scripting, it still brings a risk and IT managers will
try to kill any such initiative - and why? Because me - the programmer
trying to introduce rebol to the company environment can get hit by car
and noone else will be able to fix my scripts anymore! I know it because
I faced it with our VO (Visual Objects) project, where the rest of the
company used Delphi.
Now let's say I have some influence on IT managers and they will listen
to what I say. I am in such position, but to be fair, I am scared to
suggest rebol - and why? Because they will ask me questions like
- where can we buy books about rebol?
- where is enough web resources, docs?
- training courses?
- rebol success stories?
- rebol roadmap?
- known bugs database?
- RT technical support?
- ... and finally - how many ppl uses it?
Should I tell them 8 ppl in Czech Republic, 5 in Italy and maybe 30 in
france? IT managers really tend to be realistic (or let's better say
) of new, unproven things and will regard rebol as a hazard game
for the IT department.
Let's even supposed I will be succesfull and some manager will say - OK
- then I will probably face another problem even Steve Shireman
described - programmers are already using some scripting environment
anyway, being it python, ruby, curl, php and they will feel you try to
push them to use rebol, will provide IT managers with SWOT analysis of
why tool XY is better than Rebol is etc. And you know what? - It all
will be negative to rebol - ah, you can't even start externall app in
free version? What? Just to access mySQL we whould pay for /Command etc
kind of nonsense, which will lead to feature to feature comparisons and
suddenly you will find yourself in the hostile environemnts ...
2) hobbyists - kind of folks like web scripters etc. I had quite few
friends who were interested in rebol. But quite frankly, mySQL as part
of Command was one of RT's mistakes. They just laughed where I told them
there is no apache module, no ability to access at least mySQL - for
free. Yes, for free - because that is how those ppl start - from one
project at a time, small websystems and then - they grow. Those who
don't understand, that it is like spiral effect and think only in
narrow-minded $$ fashion should not do marketing. Because - just in my
case - I lost at least 10 potential rebol users. You may say - well,
they wanted everything for free, but that is EXACTLY wrong pov I am
talking about. Those ppl run some websites here or they, they grow,
employ new ppl, but all happens without Rebol. If they would have had
rebol at hand back at that time, they would be using rebol even more,
they would spread it, another ppl joining their projects would be
influenced etc etc. - can you see the tree/spiral of potential users,
who, in a long term, would bring RT and rebol much more money? It all
was blocked with /Command 250USD pricing - basic features which should
never be charged for were not identified. What you are offering now is
how to cure situation which should be avoided in the first place long
I am one of those who paid for /Pro, our company bought /Command and
upgraded to /Command SDK for two platforms and I also hope I will bring
RT another sales - just to prevent potential reactions that I am the one
who suggest everything to be for free.
I think that the problem rebol faces nowadays is - how to spread it even
more. Some folks here even surprised me with opinions like - VB was cool
untill it was masivelly accepted, but well - in my opinion, we didn't
reach critical mass acceptance for current situation at least to be
vital. And results we have to face:
RT is rather slow for commercial accpetance and I will once again name-
- not enough manpower
- no clear and public defined roadmap
- no known bug public database
- sometimes non existant tech support
- we can't be sure when/how RT decides to implement eventually needed
That's for RT part - in some areas we can help ... if we can find enough
So - can't you see us still running in circle? I can. New features are
only slowly implemented if even, it all smells like stagnation from
external pov (pov of ppl who don't use rebol yet but follow it from time
to time - no significant technology changes for 2 years), not enough
customers to pay RT, so RT can't employee another ppl to implement
requested features and take technology further ... still the same circle ...
The question is - how to escape it?
Do I know the answer? I don't know - my proposition was -
- the roadmap (goals, heh, Gregg? :-) - Carl should define areas in
which we could help, set some coordinators - BUT - he would HAVE to be
available at least from time to time - not like with VID projects where
we reached some decision points and were not able to get some questions
asnwered for 2 months. Maybe RT could even accept few skilled community
members to participate on technology (C level) development itself. Once
roadmap is defined, we should try to get there - fullfill the goals. I
would think in following areas:
- where do we want to see rebol? As for me - Win, Linux, maybe one or
two Unices, Mac and mainly - mobile devices .... if rebol is too
resource hungry, let's internally modularize even more
- rebol technology developments - announced plug-ins, async networking
- product redefinition - especially /Command and /Pro - kill pro, free
library and shell, remove mySQL and Oracle from kernel - it does NOT
belong there. Improve certificates handling in Command, add fast async
engine to Command (or all products - kinf of Doc's proposed uniserve) -
simply - make the framework stronger!
- VID group
- docs group
- and finally - IOS group