[MacRuby-devel] A Future for MacRuby

[Jeff Hemmelgarn]

I guess my main angst is with the the direction and philosophy of the project.

One vision of MacRuby has it being a fully compatible ruby implementation, that happens to be built on the Objective-C runtime and have good integration to all of the libraries provided by Apple, but wrap the guts so that everything is a ruby object.  This is basically how I see the JRuby project.  Access to java libraries and code, but regular ruby runs correctly.

Another vision of MacRuby is instead an Apple-centric tool that exposes it's Objective-C underpinnings in non-compatile ways.  I am talking about using named parameters and having classes like NSMutableArray in the class hierarchy, at least.  There may be other things that I am not aware of.

If the project had been started outside of Apple I would expect the first vision to hold sway.  The second vision is how I perceive the project from what I have had a chance to glean from the code and the Trac database.  As an Apple outsider, it is harder to get behind the project when I see it as very Apple-centric.  It is a big problem that there are gems that currently look like they will never work under MacRuby (anything using Fibers, or less importantly string encodings).

I agree that integration with XCode is tangential to the core questions.  However, iOS is another matter unless either 1) iOS now has garbage collection (I wouldn't know because I don't follow iOS, I just think it is important to the community of (possible) MacRuby developers) or 2) MacRuby can be compiled to work without built-in garbage collection.  I am perfectly happy to be educated on how either of those things are true.  If they aren't true then there is a lot of developer time between now and being able to run MacRuby apps on iOS, whether Apple allows it or not.

I don't have the time to fix all of these things myself, and I fear that the current direction of MacRuby is not what I would choose.  Therefore anything I contributed would potentially be rejected because I was not pulling in the right direction.  I am not complaining about that:  it is the prerogative of the project lead to take it where they want to go.  To be honest even if the project was running exactly as I wished I wouldn't have the time to contribute too much.  But I think it would be easier for other people outside of Apple to contribute if they saw that MacRuby was trying to be compliant first and Apple-serving second.

A large part of the problem is that there seems to be no communication out of Apple about what is going on.  This is generally regarded as a bad sign for an open source project.  It will be very hard to convince people to contribute when it looks like Apple is taking anyone's contributions and not reciprocating by being open about the process.  How does someone propose a change to the architecture of MacRuby?  Where are the archives of discussions about the design decisions made so far?  Where are the design documents?  Where is the roadmap for bringing MacRuby to 100% compatibility to matzruby?  The contents of the MacRuby Trac component is not sufficient.

All that being said, I will be trying to contribute what I can, especially over the next week and a half since I have the time off.  I do want to help.  I just have quite a learning curve and little time left over from my family and day job.  I look forward to the day I can use MacRuby and be confident that I can use any ruby code, any gem, any library while still using the Objective-C libraries available on MacOSX.  To clarify, I think MacRuby should take all valid ruby code and compile and run it correctly.  I don't have a problem with it also taking the named parameters syntax when I want to work with Objective-C code, as long as it doesn't interfere with regular code.  It is a bold vision but if you can communicate that vision convincingly you may be surprised at the support you would get.

Jeff Hemmelgarn