Re: Collaborative Ruby Language Specification

I'm sorry - I didn't mean that Ruby Central would make final technical decisions - that's clearly Matz's job. However, there are lots of administrative and sponsorship issues where it makes sense for a neutral organization to drive it. Witness the Python Software Foundation and how they drive their process.

There are also issues about IP rights assignment of contributors to the *specification*. This is why there are long, formal processes around any real standardization, with lots of scary legal terms and agreements thrown into the mix. I suspect that such a large effort would be beyond the scope of what we're all trying to do here.

Back to the original point: rather than creating a 'Ruby Software Foundation', might it make better sense to drive spec work through Ruby Central?

Thanks
-John


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Sunday, January 28, 2007 12:45 PM
To: [e-mail]
Subject: Re: Collaborative Ruby Language Specification

On Mon, 29 Jan 2007, [e-mail] wrote:

> Hi --
>
> On Mon, 29 Jan 2007, John Lam (CLR) wrote:
>
>>>> I'm not sure what there is to be non-neutral about :-)
>>
>> Here's the problem: there are going to be multiple implementations
>> of Ruby in the wild. And for those who run in other VMs, there will
>> be compatibility problems. It's up to the spec to make
>> determinations about what are 'important' incompatibilities vs.
>> 'unimportant' incompatibilities. For example, which Ruby C libraries
>> will be deemed to be 'unimportant' and not something that must be
>> ported to a 3rd party VM in order for that language to be called
>> 'Ruby'.
>>
>> So, it's in the best interests of the community to have a neutral
>> 3rd party be the 'owner' of the spec, otherwise there may be the
>> perception of, let's say, some large company trying to steer the
>> specification to run Ruby better on its own VM. These are issues
>> that I'd like to get out in the open and have a resolution that
>> everyone is comfortable with, and as early as possible in the
>> process.
>
> If it's a matter of the applicability of the name Ruby, then Matz is
> the first and last arbitrator.

I should add: I'm not unwilling for Ruby Central to get involved in
some way, but I'd want to be clear that it wasn't at the level of
actually making decisions about what was or was not Ruby, since that's
Matz's prerogative (unless he delegates it, of course).

(And I probably meant "arbiter" :-)


David

>
> David
>
> --
> Q. What is THE Ruby book for Rails developers?
> A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
>   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
> Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
> A. Ruby Power and Light, LLC (http://www.rubypal.com)
>

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)