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

Licensing, components ... Re: REBOL FAQ updated

 [1/25] from: petr:krenzelok:trz:cz at: 13-Sep-2002 8:15


Carl at REBOL wrote:
>The REBOL Language FAQ is alive again. >Check it out at http://www.rebol.com/faq.html. >Now that the FAQ is stored in REBOL format, it will get updated more often. > >-Carl >
*#051 Can REBOL launch other programs?* 1-Jan-2000 Yes. However, launching other programs breaks the language portability. Therefore, REBOL/Core (which is intended to be as cross-platform compatible as possible) doesn't support launching other programs while REBOL/Command fully supports it. REBOL/View supports launching additional REBOL/View instances as well as the system default web browser. Carl - still the same objections? The question is either rather old, or you just don't mean it anymore, right? Noone here will agree anymore. Is that the way of how to lock us completly in the rebol only world? Locking library and shell were one of the worst RT's decision points and turned MANY potential Rebol newcomers out. At least for me, both following examples are one and the same: call "my-app.exe" open sound:// while first will fail, because "my-app.exe" will not be present on linux e.g., the second will fail, because not everyone has /Pro license - in both cases script will not run. So - free them both - I don't believe they a) generate any substantial income for RT b) they break portability. Let Rebol fly into other areas of usage ;-) btw: maybe you could add clear license terms to FAQ too? I do remember that ppl here (including me) are not clear on where can be rebol used for free, what is "commercial" usage, etc. stuff? Are there any plans on license scheme update? I think that View/Pro should be for free - library, shell and sound - definitely - security is needed too - at least for non-commercial, education, etc. usage ... Remember - we both want the same thing - Rebol to succeed. But we need more than 10 deveopers hanging around ;-) -pekr-

 [2/25] from: jason:cunliffe:verizon at: 13-Sep-2002 14:07


Hello Very good news that the FAQ is being improved and 'rebolized'. Thank you.
> Locking library and shell were one of the worst RT's decision points and > turned MANY potential Rebol newcomers out.
YES, I agree 100%.
> At least for me, both > following examples are one and the same:
<<quoted lines omitted: 6>>
> income for RT b) they break portability. Let Rebol fly into other areas > of usage ;-)
I agree completely. REBOL and RT deserve to succeed. But it is painful in the extreme to watch a this marketing decision cripple its wider acceptance. There are daily better alternatives to REBOL. Most are free, open and have large contributed libraries, developer and user communities, bookshelf presence etc. REBOL is brilliant, innovative, unique, fun and useful. But its success depends upon people being able to explore those unique virtues up-front. And that means being able to freely use REBOL with other tools. People simply laugh out of pity when they hear REBOL cannot by default call an executable script on a server.. Hmm... Calls itself the language of 'x-internet', yet it cannot talk to anything else running on a server? C'mon. Get real... - This is what I usually hear when I try to introduce how cool REBOL is. The only reason people will use REBOL these days is because they have fallen in love with the language and love to explore. Those are good reasons, but not enough to build a growing community. If REBOL is adopted into schools and computer literacy research projects they might be reason enough. [Rebol as 'LOGO' for internet generation. really I wish for this.] But even then, REBOL would have to compare itself to Python. hello? There are many ways REBOL can succeed, and that RT can generate revenue. Locking people out from use of 'call' + shell is not one of them. Please help us to help you.. ./Jason ______________________________________________ Jason Cunliffe [NOMADICS: Director art+design] Tel/fax: +1 718 422-1078 [jasonic--nomadics--org] N 43:00.000' W 074:31.875' ALT:1144 ft 84 Henry Street #3C Brooklyn NY 11201 USA

 [3/25] from: greggirwin:mindspring at: 13-Sep-2002 14:11


Hi Jason, Just to voice my own opinion... << The only reason people will use REBOL these days is because they have fallen in love with the language and love to explore. >> Or because they can see the potential and are willing to a) deal with the licensing issues; or b) work with RT to come up with a licensing model that is viable for them. I have nothing agaist Perl, Python, or any other language (If I hadn't found REBOL, I might be using Ruby right now), but I come from a different world, a world where I paid for the software I used, so that's OK with me. On one hand, some languages are free, OTOH Visual Studio .Net costs from $1,000 to $2,500 (an upgrade is $550). Do I like their current licensing model? Not entirely. I also come from a world where tools that required royalties fell out of favor very quickly. I'm a simple guy and I want to keep things simple. The thing that is off-putting to me is the extra accounting/paper-work involved, much more than the money. Also, I think encap was an annual license so there's no point in buying it until I have a product ready for testing and a site up through which to sell it. I think the new model they proposed a while back would be good. Give the full power to people that want to try it out, create shareware, etc. so they can do everything on a "trial" basis. Then charge them if they start making money with it, use it internally at a business, etc. For me, I'd like to pay once and not have to worry about it after that. If I want to protect my code, I'll buy encap. If I distribute things in source form, say shareware style stuff, is that valuable to them as far as getting the word out and making REBOL visible to more potential users/buyers? If so, should I pay less? I'm *more* than willing to pay $100 (current View/Pro price) to do that, but I can't ask users to pony up $100, on top of a small shareware fee to use my app. Now, the trick is how to get those new users to pay if they already have *my* licensed version on their system? Since we don't know everything they know, it's hard for us to make truly informed decisions, but I think they do listen. Like us, they do what they think think is best. --Gregg

 [4/25] from: jason:cunliffe:verizon at: 13-Sep-2002 18:30


> Just to voice my own opinion... > << The only reason people will use REBOL these days is because they have
<<quoted lines omitted: 3>>
> licensing issues; or b) work with RT to come up with a licensing model that > is viable for them.
Hi Gregg Yes. Thanks for your clarifying your position. The irony is that I also agree with your arguments. I don't have any quarrel with RT about making money. They truly deserve it. But it's not really the price that counts. There are other obstacles to certain kinds of software and perceived obstacles. My concern is for the reality that's out there now, the trends and options. REBOL really needs a boost to get more people to appreciate it, both developers and their commercial clients. I am really in favor of your option b) [work with RT]. Surely there is a better way to enable features up-front, but still manage further professional commercial licensing of them? REBOL is little known or documented. This mailing list is THE place and a wonderful group it is. But a simple trip to the book store shows what the public and commercial obstacles are. So people need extra motivation and time to get up to speed and create with REBOL. Encap + call/shell access are the ones which I consider essential. Why not even just open these with some clear conditions: a. ENCAP 90-day any non-commercial demo use, then application displays licensing messages and connects to RT. b. ENCAP n-applications, no time limit. fixed price c. ENCAP Education d. ENCAP developer e. ENCAP full commercial end-user Perhaps you have a better idea... Since REBOL has built-in messaging I don't understand why that can't be used as part of a transparent licensing 'engine' attached to demo and other versions. I believe that if more people knew of real-world ENCAP uses, they would be more willing to trust and buy it without trial. I have no idea who uses it, how well it works, what's really involved and cannot even read the docs on it. I can find no examples 'Made with Encap'. Even the 'search' tool on rebol.com has never heard of it!! Apart from some rare old messages in the list archives I might be tempted to conclude that Encap is either buggy as hell, vaporware, or else the best kept secret this side of the rocky mountains. Other commercial software release partial demo versions with save disabled or similar strategies such as graphics apps which overwrite a demo text. I imagine that Encap is a little more complicated, and needs people to get hands-on for a while. Maybe I am going about this all wrong and should be directly contacting RT and negotiating for special consideration. You email sort of implies that is the way to go. Can anyone shed light on this? I hate to be openly critical of RT marketing/licensing. I even get email off-list from people who agree, but do not wish to say so publicly in this forum. But REBOL is so interesting that it kills me not to see it grow. ./Jason

 [5/25] from: greggirwin:mindspring at: 13-Sep-2002 20:32


Hi Jason, No brilliant ideas here. Sorry. :) << Since REBOL has built-in messaging I don't understand why that can't be used as part of a transparent licensing 'engine' attached to demo and other versions. >> Gotta be careful with that kind of thing, at least to me. If it looks or smells like copy protection, people will zap it. You have to be really vested in something to ante up if it says "I'm going to expire..." Also, people are wary of anything that transmits info without their knowledge or approval, even if the info is totally harmless. Then there's the issue of all those license hits being handled by some process, which has to be 100% reliable. Hmmm. I sound kind of pessimistic don't I? :\ Well, I'm not, and I don't have any better ideas, but I'm all for something blindingly simple and obvious. << I believe that if more people knew of real-world ENCAP uses, they would be more willing to trust and buy it without trial. >> Agreed. << Other commercial software release partial demo versions with save disabled or similar strategies such as graphics apps which overwrite a demo text. I imagine that Encap is a little more complicated, and needs people to get hands-on for a while. >> I think encap is really simple. Bind script to runtime; done. Reichart and company could say for sure since they use it for FTPGadget. << Maybe I am going about this all wrong and should be directly contacting RT and negotiating for special consideration. You email sort of implies that is the way to go. Can anyone shed light on this? >> For the general case, I think it would be good for them to clarify things as much as possible for all of us, and put it on the web site as well. At least a plain English summary of the intent of the various licensing options for each product. I think contacting them doesn't hurt if you have a model in mind and can show them enough "goods" to let them decide if it's worth the effort to spend time on a custom arrangement. << I hate to be openly critical of RT marketing/licensing. I even get email off-list from people who agree, but do not wish to say so publicly in this forum. But REBOL is so interesting that it kills me not to see it grow. >> I agree wholeheartedly. Open discourse is very important though. Since this issue comes up periodlically, I'm sure they think about it long and hard. Like they said once (paraphrased of course) "getting the legal parts right is three times harder than getting the code right." and I can imagine that it's true. Safer for them, maybe, to write a more restrictive general license, that avoids loopholes, and tweak it as necessary. I think they understand that everyone here wants REBOL to succeed wildly, but sometimes our passions and frustrations get the best of us. --Gregg

 [6/25] from: jason:cunliffe:verizon at: 13-Sep-2002 21:56


> I have nothing agaist Perl, Python, or any other language (If I hadn't found > REBOL, I might be using Ruby right now), but I come from a different world, > a world where I paid for the software I used, so that's OK with me. On one > hand, some languages are free, OTOH Visual Studio .Net costs from $1,000 to > $2,500 (an upgrade is $550).
Gregg hmm.. I don't think we come from very different worlds. I use lots of free software: Python being an excellent example. I also buy lots of software, from $20 shareware on up, and including REBOL/Command for Windows [but now wish I had bought the Linux one instead or that there were a friendlier cross platform package pricing for existing customers.. incrementally if you own one buy the next ones at 50% off or something. Buy all versions together for ... $really attractive package price]. When there is even a very modest budget, I make sure software licenses are part of that. I buy lots of upgrades. I also downloads lots of demos to get a feeling for new tools, new versions, compatibility etc. When I can't find demos, and between jobs I educate myself by browsing around with tools like Limewire. Sometimes just to learn what's hot, in the sense of popular/interesting/happening.. I learned about VegasVideo2 that way. Took it for a test-drive. Was really impressed... I am now proud and happy owner of Vegas Video3. I never shy away from buying 3rd party tools, even ones which support free software. I buy a ton of books too every month, which I consider software also, and they don't have to have CDROMS in them. When I am unemployed like now with a pile of bills I have to suspend all the above luxuries of learning. On a limited, private, individual basis, it's OK with me too that REBOL charge. But I do question its impact or strategic effect on public perception and acceptance of the technology. And in that respect it affect my own choice of it also. I have various ideas for REBOL-based projects, some of which would require embedding it in other SDKs. The current policies are deterrent at this stage of the game. Not developer-friendly, neither speculative start-up friendly. I don't think it is fair, or relevant, to compare REBOL with Microsoft products. Massive market penetration, promotion, documentation, with huge installed developer and use populations...not to mention monopolistic tendencies. Not try to flame you please understand.. just hoping for some insights and changes into this very difficult problem at a difficult time in the techno-economy. What to do? I wish there was REBOL conference we could all go to.. ./Jason

 [7/25] from: greggirwin:mindspring at: 13-Sep-2002 20:51


Hi Jason, We could be twins. I tend to specialize and follow areas that interest me, which then somehow always seem to be useful. I spent a lot of time on the technology treadmill from Windows 2.11 to NT4, at which point I got really tired of trying to keep up with all the little changes in the API, what worked on which specific version, new APIs that were added, etc. I want to spend my time making things *better* instead of just trying to keep them working. :) When we're flush, I also buy a *lot* of books but, like you, I'm pinching pennies (hence no encap for me yet). Last year I deciced that .net was not where I wanted to spend my time (after being a BASIC hound from QB4 through VB6). I dove into REBOL, and...all my work dried up. But, things happen for a reason. If it had played out differently, I might not have spent the time I have with REBOL and would be missing all the fun. :) --Gregg

 [8/25] from: gchiu:compkarori at: 14-Sep-2002 15:17


On Fri, 13 Sep 2002 18:30:25 -0400 "Jason Cunliffe" <[jason--cunliffe--verizon--net]> wrote:
>Apart from some rare old messages in the list archives I >might be tempted to >conclude that Encap is either buggy as hell, vaporware, >or else the best kept >secret this side of the rocky mountains.
ftpgadget is the only application that I am aware of that is encapped. http://www.progadget.com/FTPGadget/ -- Graham Chiu

 [9/25] from: carl:cybercraft at: 14-Sep-2002 15:49


On 13-Sep-02, Petr Krenzelok wrote:
> *#051 Can REBOL launch other programs?* > 1-Jan-2000
<<quoted lines omitted: 7>>
> or you just don't mean it anymore, right? Noone here will agree > anymore.
Noone Petr? (; I've said this before, but allowing the launching of OS-specific apps from the free REBOLs is a recipe for producing an OS-specific REBOL. It just needs someone to produce a cool Window's add-on for REBOL, ("Here - just stick this in your REBOL directory and use `call %cool-rebol-extension.exe' and you'll be amazed!"), and every second REBOL script on the Net will be a Windows-only REBOL script. Remember, a free REBOL will mostly be running free scripts, and those writing free scripts are a lot lazier than those trying to make money from their work. We see it already on this list with people posting scripts that only work on the beta REBOLs, despite the betas being available for only two platforms. REBOL's good, but it's not good enough to change human-nature.
> Is that the way of how to lock us completly in the rebol only world? > Locking library and shell were one of the worst RT's decision points
<<quoted lines omitted: 5>>
> linux e.g., the second will fail, because not everyone has /Pro > license - in both cases script will not run.
Fair comment, but there's two different questions there. I do think sound access should be in the free versions, (and encryption and 3D-support if it ever comes, and any other stuff you can think of that can be cross-platform), just not OS-specific calls. If you need them then buy Pro or which of the commercial REBOLs give you what you need. I'd say the same for REBOL as a whole if it wasn't supposed to be creating a Reb for the world to play in. For that to happen though we need a free "player" REBOL so there's as little restriction to entry as possible for the masses. -- Carl Read

 [10/25] from: amicom:sonic at: 13-Sep-2002 22:33


At 03:17 PM 9/14/02 +1200, you wrote:
>On Fri, 13 Sep 2002 18:30:25 -0400 > "Jason Cunliffe" <[jason--cunliffe--verizon--net]> wrote:
<<quoted lines omitted: 3>>
>ftpgadget is the only application that I am aware of that is encapped. >http://www.progadget.com/FTPGadget/
The version of Encap I never used before Encap was available was vaporware. The first version of Encap I used was somewhat limited in its use, but I wouldn't call it buggy. Now, I've got probably two dozen encapped applications written for a client of mine. Works great! So the correct answer would be:
>>"the best kept >>secret this side of the rocky mountains."
I'd recommend it for software projects of all sizes. Last time I checked, it was $499 plus 10% commission on all sales of products where Encap was used (or something like that). Bohdan "Bo" Lechnowsky Lechnowsky Technical Consulting

 [11/25] from: ptretter:charter at: 14-Sep-2002 13:31


Check and you will see that the lack of licensing lingo is a benefit to the consumer at least in the terms of the court. RT would be wise to revisit their lawyers and better define this. After all some of us want to be resellers as much as end users. Paul Tretter

 [12/25] from: kemp:extelligence at: 14-Sep-2002 15:00


I've got to comment on the silliness of this issue: Some stuff has to be coded platform-specific to take advantage of certain features; some stuff doesn't HAVE TO, but often does anyway, usually because of convenience, ignorance or unwillingness to try 'odd' cross platform tools. REBOL opens up the world (for the brave and foolish :) to the second category - we all see that. But the first category isn't going to change - it NEEDS OS and HW-specific features and access. Anyone who needs specific features MUST have them available, or they won't and can't use REBOL. Anyone who wants to be cross-platform simply WON'T use those features - it's that simple. If there is a proliferation of Windows-specific scripts, it's because they are valued and needed. One thought, though - would it not be great if the REBOL header had ENFORCED tags in it to indicate whether a script was cross-platform or not (req. COMMAND), and another for VIEW or not? That might ease your concerns. Kemp

 [13/25] from: rebologue:yaho:o at: 14-Sep-2002 12:17


From a business standpoint, the value of the REBOL platform by itself is very little (really), regardless of how cross-platform it is. That is because the value of the REBOL platform is determined by how many people are using it and developing with it. In the hands of tens of thousands of developers and users, however, the value could be huge. RT should be doing whatever they can to make sure that developers in key markets are happy and that the REBOL interpreter is being distributed far and wide. Cross-platform capability is a solution to a problem that affects a relatively small percentage of developers in the desktop world. It mainly affects the ability of a language to survive platform extinctions; it has little affect on popularity or profitability (despite what Sun marketing has drilled into our heads). --- Carl Read <[carl--cybercraft--co--nz]> wrote:
> I've said this before, but allowing the launching of > OS-specific apps from the free REBOLs is a recipe > for producing an OS-specific REBOL. > It just needs someone to produce a cool Window's > add-on for REBOL, and every second REBOL script on > the Net will be a Windows-only REBOL script.
Look, cross-platform compatibility is a feature; it shouldn't be a mandate. It is not the end-all be all of software. If a commercial vendor is aligned with the goals of the programmer, the vendor stands to reap potential benefits from the relationship. The dysfunctional version of this is, "If the programmer is aligned with the goals of the vendor, the vendor stands to reap potential benefits." Programmers/designers write scripts to serve their own goals, not those of anyone else. If a programmer doesn't particularly care about audiences beyond a single OS, that is his/her decision to make, not the vendor's. In any case, it should come as no surprise that the vendor's business case and cross-platform agenda factor little in the decision. For the sake of argument, let's say RT changes it's policy, and grants /Pro the same license as /Core. Would this be the death of Rebol? Hardly. Would the world become littered with programs that only work on Windows, on Amiga, or on QNX? Maybe yes, maybe no. Are we saying that these developers would choose to implement OS-specific code even in cases where the same result could be achieved in multi-platform code? I doubt it. Even so, maybe that exotic QNX-specific app will help turn new users onto QNX. If an OS-specific app turns out to be a success, you can bet they will try to extend it to other platforms. It's a true mystery (is it?), but commercial, OS-specific software seems to be the norm on user desktops. The situation isn't under any threat of being fixed by REBOL. Users that don't want to see OS-specific code are probably nervous that "cool" scripts would become available exclusively on dominant commercial platforms such as Windows or Mac. Their platform-of-choice could be eclipsed by OS-specific scripts written by multitudes ex-VB and RealBasic upstarts. Perhaps this ml would no longer be a diverse, multi-platform speakeasy if OS-specific discussions become the norm. Despite possible increased platform visibility and equity, RT probably would not welcome this direction. RT does not want to be harried by all of the OS-specific baggage that they might attract. Much easier to manage a cross-platform (reduced) feature set, and wall-out the OS barbarians. This is how I interpret RT's current policy: True REBOLs write only multi-platform scripts. RT supports the REBOL platform, not those of any individual OS. If you want to write any OS-specific code, you must pay to play. You will need to buy a special interpreter, and all of your users will need to purchase this as well. If you need OS specific features and an inexpensive runtime to support it, we suggest taking a look at the multitude of free or open-source tools that 99.999% of developers end up choosing.
> REBOL's good, but it's not good enough to > change human-nature.
I agree. But it depends on your perspective. Who's place is it to say what is wrong with human nature? REBOL should sell its products in a way that serves its business and let human nature be handled by human individuals. It won't do any of its platforms justice if can't afford to hire staff and the platform continues to live in the margins. // Ed

 [14/25] from: jason:cunliffe:verizon at: 14-Sep-2002 15:25


> One thought, though - would it not be great if the REBOL header had ENFORCED > tags in it to indicate whether a script was cross-platform or not (req. > COMMAND), and another for VIEW or not? That might ease your concerns.
Yes it would be great, and it falls nicely into the Rebol 'metadata header engine' scheme we discussed recently. Presumably the same functions should be added using Encap also, to facilitate dependencies, and help rebol to browse encapped scripts also. ./Jason

 [15/25] from: jason::cunliffe::verizon::net at: 14-Sep-2002 15:46


> >From a business standpoint, the value of the REBOL > platform by itself is very little (really), regardless > of how cross-platform it is. That is because the value > of the REBOL platform is determined by how many people > are using it and developing with it.
Yes.
> In the hands of tens of thousands of developers and > users, however, the value could be huge. RT should be > doing whatever they can to make sure that developers > in key markets are happy and that the REBOL > interpreter is being distributed far and wide.
Yes.
> Cross-platform capability is a solution to a problem > that affects a relatively small percentage of
<<quoted lines omitted: 3>>
> (despite what Sun marketing has drilled into our > heads).
Hmm... The most interesting new magazine I read these days is "Bio.IT World". An excellent [free] monthly tracking the explosion of software, hardware, politics, science, business tech and biology. It is very well written, and provides a fascinating window into the new area of science known as 'proteomics'. I am not a trained scientist, but am delighted to stretch my reading with such good front-row seats. The lucid editorial style makes the field very accessible to non-specialist. http://www.bio-itworld.com http://www.bio-itworld.com/subscribe/ The September issue has an article titled "Peeking at Big Pharma's IT Playbook", discussing IT at the Drug Discovery Technology World Congress. http://www.bio-itworld.com/news/090902_report1148.html .."One especially promising track of the conference was exclusively devoted to IT. Its focus: integrating data from a variety of scientific endeavors and technologies in an effort to streamline the present chaos of instruments and software that can't communicate with each other. "We have a format nightmare," said Robert DeWitte, director of marketing for Advanced Chemistry Development Inc. "We have a data integration problem."" ... For Peter Smith, director of discovery research at Wyeth Research, the familiar buy-vs.-build dilemma in IT has turned out to be especially painful in the pharmaceutical industry. When a drug company builds its own software, Smith said, as soon as you have the stuff in production, it's now a legacy." But buying can be worse. "The software you buy is often generic," Smith said, and so has little competitive advantage for you. You spend most of your time customizing it to your organization. Smith proposes a more modular, nonproprietary approach in which all of a company's tools run on a network using standard file formats. "No one vendor can supply all the pieces you want with all the variety you want," he said. He prefers an a la carte approach, ticking off modular products from SciTegic Inc. and Spotfire Inc. "I didn't buy all of Spotfire," Smith said. "I just bought the visualization component." Smith said he won't buy any more applications that do not support industry-standard formats. For example, he loves Java, which kicked off the component revolution in software. ./Jason -- To unsubscribe from this list, please send an email to [rebol-request--rebol--com] with unsubscribe" in the

 [16/25] from: carl:cybercraft at: 17-Sep-2002 22:58


On 15-Sep-02, Ed O'Connor wrote:
> Cross-platform capability is a solution to a problem > that affects a relatively small percentage of
<<quoted lines omitted: 3>>
> (despite what Sun marketing has drilled into our > heads).
I don't see the free REBOLs as a solution to a problem, though they might be for some. I see them as allowing us to create something new. Is the WWW a solution to a problem? Maybe some problems, but it's much more than just the solution to some problems, isn't it? If those webpages were all OS-specific though, the Web would be a lesser place I think.
> --- Carl Read <[carl--cybercraft--co--nz]> wrote: >> I've said this before, but allowing the launching of
<<quoted lines omitted: 11>>
> is aligned with the goals of the vendor, the vendor > stands to reap potential benefits."
None of which has anything to do with a "free" interpreter running free scripts directly from the Net. I don't see why the Pro versions of REBOL have to be free for those wishing to use them for commercial purposes.
> Programmers/designers write scripts to serve their own > goals, not those of anyone else. If a programmer
<<quoted lines omitted: 8>>
> world become littered with programs that only work on > Windows, on Amiga, or on QNX? Maybe yes, maybe no.
Yes, no and no is the correct answer.
> Are we saying that these developers would choose to > implement OS-specific code even in cases where the > same result could be achieved in multi-platform code? > I doubt it.
I don't. As I pointed out before, people already post beta-only scripts here. It's human nature - test it on your system - it works, therefore it works.
> Even so, maybe that exotic QNX-specific > app will help turn new users onto QNX.
How come? The only users who'll see it working are those already using QNX. Much more likely is that it'll turn people off REBOL. "I tried it and it didn't work. Happens a lot with REBOL code I hear - a lot of what you find on the Reb is OS-specific these days."
> If an > OS-specific app turns out to be a success, you can bet
<<quoted lines omitted: 9>>
> be eclipsed by OS-specific scripts written by > multitudes ex-VB and RealBasic upstarts.
Ummm - but what if your platform-of-choice is REBOL? What if you don't care about the underlying OS? What if you want to be able to move from Windows to Mac to whatever without having half your software die on you?
> Perhaps this > ml would no longer be a diverse, multi-platform
<<quoted lines omitted: 20>>
> I agree. But it depends on your perspective. Who's > place is it to say what is wrong with human nature?
I wasn't judging human-nature - just pointing out how it'll behave given the chance.
> REBOL should sell its products in a way that serves > its business and let human nature be handled by human > individuals.
Sure. But I'm not asking human-nature to change. I'm just saying this is how it is, and if the OS-specific stuff in REBOL is made free it'll result in a high proportion of the scripts made available being OS-specific which would kill any chance of the Reb becoming something really interesting. The world's full of OS-specific languages for those who need them. But how many good cross-platform ones with a GUI are there? Can you point me to many lists like this... http://www.rebol.com/view-platforms.html languages with support for that many OSs and where all the versions are at the same version number?
> It won't do any of its platforms justice > if can't afford to hire staff and the platform > continues to live in the margins.
Indeed. -- Carl Read

 [17/25] from: greggirwin:mindspring at: 17-Sep-2002 11:02


(note to self) OK, so one of the things the new library system needs to do is segment the OS agnostic scripts from the platform specific ones. --Gregg

 [18/25] from: rebologue::yahoo at: 17-Sep-2002 16:06


Carl R-- Thanks for your responses to my comments. My take-away from your posts is: 1. You believe that OS-specific scripts will be fatal (or highly detrimental) to REBOL. 2. You believe that RT should not offer an attractive runtime license so that developers can distribute OS-specific scripts. I disagree on both accounts, but I acknowledge it's a moot point. I think there are also a lot of grey areas in the discussion. For example, where do we stand regarding features that: Change or vary (perhaps radically) based on the user OS? Fail silently if your OS doesn't support it? Use a workaround to support the feature across platforms? Expect other software (i.e. a browser) on the user's system? As I expressed previously, I think that all options should be in the hands of developers. They already have enough complexity to deal with and tend to flee when they see puzzling restrictions and red tape. So what happens when you want want to switch from Windows to Mac to (Plan 9 ?) without losing apps? My answer isn't going to please you. In the case that your apps are OS-specific, the .1% of the market audience (multi-platform-switching desktop users) with this dilemma will need to find reblets that support those 3 platforms. Fortunately REBOL makes multi-platform dev more feasible than just about any other tool. I can't vote in favor of "100% cross-platform purity" if it means constraining REBOL (licensing or functionality) in ways that effectively limit the kinds of apps developers are able to create. Or that deter the volume of developers required to build a healthy market for RT. So I am against licensing policy that deters developers from building the scripts they want. I don't believe that OS-specific erases prospects for the Reb. Lack of developers-- lack of customers, that's something that darkens prospects. In my view, RT's commercial success is by far the largest factor in securing the future of the REBOL platform. An extension of this is that REBOL needs to be sufficiently popular in strategic markets (commercial OSes) in order to achieve success. I like the concept and practice of "multi-platform"-- it's one of the reasons I like REBOL. However, I put it at a slightly lower priority than a successful, growing vendor and platform. When I talk coarsely about cross-platform support, it's not because I disagree over the merits of PalmOS , Novell, etc. It's because my inner business marketing strategist warns me that, given finite resources, all platforms are not equal (let alone identical). While I surmise the above is an unpopular viewpoint to the REBOL supporters on this list, I hope it is accepted as fair input. Regards Ed

 [19/25] from: chris:langreiter at: 18-Sep-2002 2:14


> I like the concept and practice of "multi-platform"-- > it's one of the reasons I like REBOL. However, I put > it at a slightly lower priority than a successful, > growing vendor and platform.
Ed, Once again, I can only agree. May this time our voices be heard ;-) -- Chris

 [20/25] from: jason:cunliffe:verizon at: 17-Sep-2002 20:33


> > I like the concept and practice of "multi-platform"-- > > it's one of the reasons I like REBOL. However, I put > > it at a slightly lower priority than a successful, > > growing vendor and platform. > > Ed, > > Once again, I can only agree. May this time our voices be heard ;-)
REBOL [] voices: voices + 1 hear voices ./Jason

 [21/25] from: petr:krenzelok:trz:cz at: 18-Sep-2002 8:27


Ed O'Connor wrote:
>While I surmise the above is an unpopular viewpoint to >the REBOL supporters on this list, I hope it is >accepted as fair input. >
Ed, why unpopular? There were/are few RT-thinking supporters imo. It used to be Elan (where is he nowadays?), sometimes Allen, Steve, and now Carl. You point is 100% accurate in my eyes. It seems to me though, that some folks here would better risk death of the platform, instead of letting rebol being introduced into many other areas .... -pekr-

 [22/25] from: cyphre:seznam:cz at: 18-Sep-2002 11:01


Hello Ed, Petr I completely agree with your POV and second your thoughts. Here are just some more ideas... I'm not against Rebol's crossplatformity but this has nothing to do with possibility to interconnect Rebol with other APIs or launch other code from Rebol. It is up to developer which method want/need to use and it shouldn't be restricted in that way. Moreover, there are plenty of other crossplatform and free APIs and libraries so why not make them accessible from Rebol for free? I think this would be very usefull for the whole Rebol community. For example I want to make image viewer/converter/editor for more than 200 image formats. I also know that RT never enhance Rebol for such huge image format support(which is understandable). So I found free and multiplatform library API for such task. This library is free so every software which use this API should be also free. But I cannot make it because of the commercial licensing of the library interface. The only possibility is to buy Pro license, buy license for the commercial usage of the API and make only commercial software. But who buy my Rebol/Pro commercial software when he(she) can use such image converter/viewer for example in VB for free? I think the sound, library interface and external calls should be free by default in the Rebol/Core and Rebol/View. These features can only help Rebol to spread, be more visible and enhance the area of Rebol applications. Maybe considering to free the encryption routines would be a good marketing move: Communication you do in rebol is secure by default! I also agree that we need something like Rebol/View/Player for internet browsers which could be the nowadays non-pro Rebol/View just with added sound support (and in future with 3D engine as Carl metioned). There should be also some kind of interface for controlling the browser's DOM from such player in future. The possibility of embedding Rebol into browser would seriously endanger whole JS and Macromedia stuff and open wide market of embedded applications... regards, Cyphre

 [23/25] from: rebologue:ya:hoo at: 18-Sep-2002 15:16


Hi Petr, Cypher, Chris, Jason and others-- Thanks for chiming in. I hesitated to respond to Carl R for a few reasons: 1) It's a downer to hear complaints on the list. As developers, we're pretty happy tooling away with REBOL, honing our craft. Solutions read better than problems. 2) REBOL is from Carl (& team), who put their lives into their work. Despite the corporate vehicle, REBOL wasn't built by a faceless corporation. I reflect on that before I post. 3) RT carefully chose the current licensing policy. I'm sure our proposal (a liberal license extended to View/Pro) isn't new and was probably rejected for some reason. 4) This mailing list is heavily populated with developers who use multiple platforms on a daily basis. It's part of the culture here (a good thing) and at RT. However, the commercial desktop world isn't very diverse. I don't expect RT to give away their seed corn. They need to charge us money somewhere, either on the dev tools side or with distribution licenses. Hopefully they can aim for more mass-market acceptance and target prices for distribution licenses accordingly. REBOL is amazing technology, elegant on so many levels. But Macromedia, an 800 pound gorilla, now camps on this turf. The "imbalance in the force" can't be ignored. Flash MX products are impressive ( see http://radio.weblogs.com/0113297/2002/09/11.html#a4 ), and they cover most of the bases: compact, cross-platform, IDE, backend, XML, developer community, marketing dollars, you name it. Think about what a cool world this would be if 2-3 years from now there is a significant job market for IOS developers. What will it take for REBOL and RT to achieve that? With all due respect to RT, I believe they either need to engineer a commercial breakthrough for the platform, or they need to provide developers with the keys to create their own. I hope I'm one of the people hiring IOS developers in the years ahead. // Ed --- Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:

 [24/25] from: carl:cybercraft at: 19-Sep-2002 19:52


On 18-Sep-02, Ed O'Connor wrote:
> Carl R-- > Thanks for your responses to my comments. > My take-away from your posts is: > 1. You believe that OS-specific scripts will be fatal > (or highly detrimental) to REBOL.
Not quite - I believe it'll be fatal to REBOL as a cross-platform language. Being OS-specific has been good for lots of software and lots of companies. It does tend to tie one to a particular OS though, as that approach guarantees one OS or another will dominate. Cross-platform software is a way out of that bind.
> 2. You believe that RT should not offer an attractive > runtime license so that developers can distribute > OS-specific scripts.
Define attractive. I believe RT should do what RT believe is best for RT. (I think they'd be betting the farm by making ViewPro and Command freely distributable though. They wouldn't get the baby back in the bath after that.) But I'm attracted to REBOL because it's a cross-platform language first and a good one second. In that order. The world's not short of OS-specific languages, but good cross-platform ones with GUIs are a different matter. I want to be able to surf the Reb knowing that 90% of the scripts there don't care what OS I'm running. The Reb will be a pointless exercise if they're not. (Yes, I know it's not much now, but it has the potential to be very interesting.)
> When I talk coarsely about cross-platform support, > it's not because I disagree over the merits of PalmOS
<<quoted lines omitted: 4>>
> While I surmise the above is an unpopular viewpoint to > the REBOL supporters on this list,
I don't think so. (:
> I hope it is accepted as fair input.
Very fair. It's just that I'm old and cynical and don't believe that humans collectively take all that much care with what they do. If cans of spray-paint were free to all, do you think that'd make for better painted walls? -- Carl Read

 [25/25] from: rebologue:yah:oo at: 19-Sep-2002 14:40


Hi Carl-- --- Carl Read <[carl--cybercraft--co--nz]> wrote:
> ... I believe [OS-specific] will be fatal to REBOL > as a cross-platform language.
Ok, so the licensing for /Pro is needed to keep those OS-centric developers in check. It begs the question: which is the greater torment to the general computing public; when you can't run every /View script on 30+ platforms, or when you can't find or build REBOL scripts that compare favorably to native, OS-specific ones?
> [OS-specific software] does tend to tie one to > a particular OS though, as that approach > guarantees one OS or another will dominate. > Cross-platform software is a way out of that bind.
It's a way out only if the cross-platform softare is as good or better than the OS-specific flavor. If the situation were truly dire, I think we'd all be using StarOffice and Java on open-source platforms by now. Inertia wins; without clear direction and sufficient motivation, the main herd stays put. I think that REBOL will be attractive to independent software developers. The RAD-like features of REBOL are a powerful force multiplier that helps compete in the marketplace. This market group is trying to optimize every available advantage; they are not likely to abandon cross-platform compatibility (a potential market) unless it's a necessity. In most cases, corporate developers don't need the cross-platform compatibility (for desktop apps, anyway). They need to preserve the user experience of the platform, and to integrate with their tech infrastructure.
> Define attractive.
Attractive meaning priced affordably for small to mid-size development development houses. Right now it is priced prohibitively (IIRC, each user must purchase a license for /Pro).
> I believe RT should do what RT believe is > best for RT.
I agree. They're probably doing exactly that. My experience with RT has been good. They usually listen and pick out the ideas that work for them.
> The world's not short of OS-specific languages, but > good cross-platform ones with GUIs are a different > matter.
I don't want to get into a language tussle, but I think there quite a few cross-platform languages with GUIs. Many folks will assert that, for simplicity and ubiquity, plain-old HTML front-ends are the way to go.
> But I'm attracted to REBOL because it's a > cross-platform language first and a good one second. > I want to be able to surf the Reb knowing that > 90% of the scripts there don't care what OS > I'm running. The Reb will be a pointless > exercise if they're not.
I bet almost 100% of public scripts are cross-platform now, but there are only a few hundred scripts available, and mostly with limited functionality. We could risk seeing a small number of OS-specific scripts become extremely popular, which might belie the overall numbers and distort the perception. I'm curious to know if your convictions are shared by many developers/users.
> (Yes, I know it's not much now, but it has the > potential to be very interesting.)
While you may find it interesting when it's cross-platform, if you want it to be really interesting, why not let developers drive REBOL wherever they want? (Oh yeah, you answered that. ;^)
> If cans of spray-paint were free to all, do you > think that'd make for better painted walls?
It would result in many many more walls being painted. 80% of the paint jobs would be poor or unremarkable, 15% would be acceptable, 4% would be noteworthy, and 1% may be the among finest murals you've ever seen. It's that 1% of applications, the VisiCalc, Mosaic, and Napster that drive the industry forward. Of course, a cynic might say "Put a million monkeys in front of a typewriter and...". Cheers, Ed

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted