Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 ... Elan wrote:
> 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 scared ) 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 time ago. 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 feature XY That's for RT part - in some areas we can help ... if we can find enough manpower ourselves. 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 Cheers, -pekr-