Walled Gardens, VM Sharecroppers, and "Sugar Daddies"

Tim Bray went to RubyConf 2009. Ignore the provincial "The Ruby community knows how to build, test, distribute, package, and reuse software better than almost any other language in the world" comment (c'mon, Tim -- the CPAN has been around for a while and the CPAN Testers service has over six million test results for CPAN distributions -- and the current rate of reporting is four million a year). There's a better quote buried deeper in the report:

... it turns out that there's almost nobody who's actually getting paid to work on actual core Ruby (less than the number who are getting paid to work on JRuby and IronRuby and MagLev and so on). Ruby really needs to find a sugar daddy -- in my opinion, a deep-pocketed Japanese corporate sugar daddy -- and find it soon.

Do I recall correctly that Tim helped convince Sun to hire a handful of JRuby developers in 2007? (They've since left the Oracle-eclipsed Sun.) Hmm. Hirer's regret?

Ian Bicking criticized Sun for the JRuby hire at the time; apparently I'm not the only one who detects a whiff of provincialism here. It's odd; John Ousterhout worked at Sun for a while, putting resources behind dynamic languages in the form of Tcl. (Anyone who says their favorite dynamic language is unsurpassed in automation abilities, easy embedding, Unicode, event handling, and GUI integration probably knows nothing about Tcl. Those who do not know programming language theory condem the rest of us to hear their incessant chest beating.)

I don't really want to talk about Ruby, though. I want to talk about Perl.

I wrote How Perl Happens as a subtle reminder that Perl has little corporate sponsorship. To my knowledge, there's no IronPerl nor JPerl. There's no Enterprise Perl fork of the Perl 5 interpreter. There's no Perl on the Smalltalk VM, nor on V8, nor on SpiderMonkey.

Booking.com did make a large donation of $50,000 to contribute to Perl 5 development -- and they deserve credit and thanks and acknowledgement for that, as do all of the contributors to TPF... but try to find someone (anyone!) employed anywhere, as an agent of TPF or otherwise, with the full-time job to implement, support, maintain, or manage any implementation of Perl.

TPF hasn't spent (to my knowledge) any of that $50,000 -- though not because TPF is unwilling, but because no one has made a plausible, workable plan for spending that money.

Ian Hague made a generous donation to help with Perl 6 development, and that's sponsored several grants to people such as Patrick Michaud, Jonathan Worthington, and Jerry Gay. As well, Vienna.pm has sponsored a portion of Jonathan Worthington's time for several months -- but again, these are modest grants, not resembling anything close to full-time employment.

The thought of a business benefactor is interesting, especially in comparison to other language communities. Does the close-knit Japanese community primarily developing MRI form a barrier to sponsorship from outside of Japan? Does Python gain an edge from Google's deep pockets? Can anyone argue that Zend's control over PHP has helped the language more than it has hurt the language? Would Lua have worked anywhere outside a research university?

I don't mean to criticize or condemn alternate Ruby implementations for their own sake. RubySpec is the most important project to come out of completing implementations; it can turn them into complementary implementations. (I do choke back chuckles every time I read a starry-eyed programmer who's only ever learned Ruby say that the Ruby community has the best testing of any programming language ever invented in heaven or on earth, because they figured out how to write test descriptions and invented a new acronym for it, but I'm a history-aware jerk that way.) There's nothing wrong with multiple implementations of a programming language built around a common specification (hey, Python has a pretty good one!) and a comprehensive test suite (fill in your own parenthetical statement here).

The problem comes, as Tim Bray is just starting to discover, when the reason for those competing implementations is to divide up a pie of consulting and support fees by capturing market segments tapped, untapped, unrelated but tappable, and not invented yet but looking very tapperific without replenishing the commons.

In other words, while I have no doubt of the good intentions of someone porting Perl 5 to the CLR or the JVM to run in businesses where standard Perl 5 might not be allowed or appropriate or to give access to libraries not available in Perl 5 yet, I suspect that the corporate interest in sponsoring such development is to expand the walled garden around the CLR or the JVM, not to make a better Perl 5 or to help programmers get their work done with less ceremony and mess and frustration.

This leaves me with two questions:

• Why doesn't Perl 5 have sponsored development beyond a few donations here and there? (Again, those businesses and individuals who have donated to support Perl development in any form deserve praise. By no means do I intend any slight or anything other than gratitude toward them.)
• Is the Perl community fortunate that it hasn't fragmented by implementation on various platforms, or unfortunate that it couldn't perform corporate aikido to turn walled-garden sharecropper sponsorship into dollars to improve the Perl core for everyone?