[REBOL] Re: Rebol SDK vs Command
From: henrik::webz::dk at: 16-Sep-2007 17:57
On 16/09/2007, at 1.58, Carl Read wrote:
> On Sunday, 16-September-2007 at 0:46:19 Gabriele Santilli wrote,
>
>> Carl Read:
>>
>>> From RT's POV, staying proprietary might look the easiest way to
>>> make money
>>> from REBOL,
>>
>> That's not the reason why R3's core is not open source.
>
> And the reason is? I can think of others, such as it containing
> licensed code from sources other than RT, or that RT has made
> promises to customers that they wouldn't open-source it. Or that
> they're just stubborn on this point. But you didn't say why, so I
> guess you're not allowed to. Thus we waste time guessing...
To keep others from meddling with the language. It's that simple. And
yes, if it were opened, people WILL meddle with it in directions that
could quickly move it into a corner, feature wise, so you can't do
this or that with it. You can't avoid forking or design by committee
as seen in so many open source programming languages. To be frank,
how many coders out there can outsmart Carl Sassenrath and code a
better REBOL 3?
If people say, they won't use REBOL, because it's not open source,
then they will likely not spend time on it anyway in order to
understand the way the language is designed, and then just use it as
a traditional language; For them, REBOL gives no added value and they
might as well turn to Ruby or Python. I've had this conversation with
some open source enthusiasts, and it goes exactly like that. They
will not accept it as anything but a Ruby/Python alternative and
completely ignore the features that make REBOL unique and powerful,
not as a language, but as a platform. Same reason, why I was asked
why we didn't use GTK+ for the UI rather than write our own VID3.
It would be nice if the open source crowd (particularly the GPL
crowd) were a potential audience, but they can't be that, unless they
are willing to go truly in depth with the language and try to
understand it.
The commercial opportunities for RT would likely be in products like
IOS, not the language itself. I don't know the plans, but I hope and
expect that R3 will be much less costly than R2, perhaps completely
free.
And let me tell you this:
R3 builds on the 7-8 years of experience of R2. I've used the R3
alpha since early July, and one of the big differences here between
R2 and R3 is that almost anywhere in R2, where you have a limitation
or a design flaw, be it ports, async, tasks, file management, error
handling, graphics, sound or hardware, those flaws are simply gone in
R3 or will disappear over the course of alpha and beta development.
Not many shortcuts have been taken. Redesigning the graphics system
has made it a breeze to use along with VID3, where you in the old VID
constantly bump into limitations and bugs and have to spend hours and
hours of hacking to achieve a certain functionality, if it's possible
at all to do, due to the hardwired nature of the event and graphics
system in R2.
We won't get everything with 3.0, but be sure that the limitations
are far fewer than with R2.
This opens a subject of post-beta development that leaves the
argument of open sourcing the core language in the dust: The question
of how fast the peripheral capabilities of R3 can be developed.
Porting to other OS'es, building drivers, the Wildman project,
additional documentation and cookbooks.
This is almost only a question of how many smart people you can find
and put on these parallel, almost autonomous projects. The pace of
integrating R3 into your environment will no longer be decided by RT,
but by you. There is going to be a _lot_ of work to do: Easily
everyone on this list can have a job to do, and the members of the
core R3 team already have their hands full enough that there is going
to be need for extra help soon.
I'm betting personally that with around 50 people, we can support and
maintain the 40 advertised platforms by the end of 2008, plus have
better integration into each system, and all of them will have proper
documentation. This leaves RT to focus on the core language and their
commercial product endeavours.
--
Regards,
Henrik Mikael Kristensen
