A funny thing happened the other day. Other people started singing a song over the drum I've been beating for several years. (My favorite exploration of this idea is Squeezing One Year of Work Into Eight.)
It's an old idea. If you're waiting for volunteers to build something, it'll either be good or fast. By limiting the pool of available workers to volunteers, you've already chosen cheap.
The good news is that you're going to get Perl 6 for very, very cheap. The bad news... well you know it's taking a while.
In the most recent round of TPF grants, the grants committee declined to fund a recently-started Perl 6 implementation called SMOP. As happens when the possibility of trickles of pennies starts to circulate in the minds of people who sneak a few hours a week to work on things for free, there's disappointment when those little droplets of spare cash don't arrive.
(Besides that, TPF isn't always transparent about how much money it has available, what's already allocated, and exactly what its goals are for giving grants. Plenty of great hackers don't apply for grants either, at least in part due to the confusion around them. That doesn't help.)
That's all just background, though.
I've done my own personal math on the subject. The other day, inspired by a dose of realism regarding funding from Joshua Gatcomb, I posted what it would take to buy me a month of full-time Parrot hacking. Those are just my numbers. They're not a promise, nor are they a suggestion that I'm the most likely candidate for such a sponsorship. (Jerry Gay and Jonathan Worthington are first on my list, assuming we can keep paying Patrick and that taking care of his family leaves him sufficient time and energy to hack.)
Several people have offered personal donations, publicly and privately, and I'm grateful to see that people believe in the work that all of the contributors to Perl 6 and Parrot are doing, sufficient to back that faith with pledges of funding. Thank you all.
However, like Richard Dice and Dave Rolsky (and I believe Jim Brandt) have said, it's probably time to approach businesses for larger grants. I don't mean just the usual suspects, either. If your business depends on the healthy ecosystem around Perl, it's important to support that ecosystem with code, with bug reports, and occasionally with funding. That may take the form of hosting Perl Mongers meetings, or releasing code to the CPAN, or donating a few hundred dollars to TPF.
With that commercial concluded, there's one more point to address again -- the appropriate targets of funding.
Brandon Allbery pointed out the roadblock to further progress in Pugs:
The real roadblock with Pugs is that Audrey Tang was the only one who really understood it.
There's a legitimate discussion about which Perl 6-related projects are worth funding. I happen to think Parrot is the most likely successful target for Perl 6, but the design of the language (and especially the test suite) is such as to encourage multiple implementations. I think that's healthy.
I also believe that a little friendly competition -- and not-quite-parallel divergent exploration of a problem area -- is very healthy. It can lead to better solutions than even the most laser-precise unidirectional focus. (Or maybe I just want to brag that I've read way too many papers on alternate garbage collectors for the JVM.) This is especially true when all of the work on a particular problem comes from volunteers. Not only can you not tell all of them what to do and expect that they'll do it, you can't say that if there were only one implementation, they'd all work on that.
I suspect that more people would have hacked on Pugs if it used something more accessible than bleeding-edge GHC. I suspect that more people might feel comfortable hacking on Parrot if it didn't require C knowledge as well as Perl knowledge. Yet multiple implementations are not a zero-sum game.
There's a big however, however. Funding changes the nature of the game. $5000 may buy a month of my time, though it may buy two months of Audrey's time. Which is more valuable?
I know I've already poisoned the well with my overly-provocative headline, but that question is highly hypothetical and overly-dramatic to make one very important point.
I believe that Pugs, as it stands now, is dead. That's unfortunate. That doesn't mean that Pugs is useless. Quite the contrary. This also doesn't have to be the end of the Pugs story, but without drastic change, Pugs will not go anywhere. (It hasn't gone anywhere for a long time.)
Pugs died because it failed to attract sufficient hackers to maintain it even in the absence of its founder. Parrot nearly died from a similar problem.
While I know Larry is very keen on multiple implementations hopefully converging from different starting points, there's a funding risk related to multiple implementations. Funders need to keep in mind the difference between research and production implementation and consider the goal of the funding in that relationship.
You can't guarantee that a project with two committers will die any more than you can guarantee that a project with twenty-five committers won't die. History doesn't support those kinds of experiments. However, you do need to keep in mind the relative risk of projects when deciding how to slice that cash pie.
Please don't misunderstand me -- I'm all for experiments. If funding an experiment has a concrete goal and we're likely to learn something valuable from that experiment, fund it! Just keep in mind what you think a successful outcome will be from that funding, and make sure that it's realistic for that project.
Re:Perl6 on Perl5
chromatic on 2008-02-23T05:59:52
There have been a few. None turned out to be maintainable.
Re:Management vs Implementation
chromatic on 2008-02-25T06:35:00
Thus my preference to just hand out commit as often as possible.A management problem lurks in that as well, however. Do you vet contributors such that they assign you some sort of copyright or perpetual license to the code they write? I squawked about the potential release of Pugs into the public domain for several reasons. One was my potential legal liability as a contributor.
This also worked for Audrey with pugs, but may have been let down by the whole blead GHC problem making the barriers to contribution so high it placed the project in a high bus-sensitivity situation anyways.Even with hackers as talented as Gaal and Yuval, the internals of Pugs are byzantine enough that really only Audrey can make substantive changes with any appreciable timeliness. Without Audrey, well, compare the progress of Pugs in the past 18 months to its progress in the previous 18.
Tracking blead GHC certainly raised the barriers to contribution, as did the perpetual performance problems, but I'm not sure that they're the prime factors in the low bus number.
