[kbenson]

I agree with this as well, but from the other side. Giving out timeframes based on volunteer schedules in an industry that is already famously known for not hitting release times is not really useful. I think it's more useful to say "Perl 6 is already useful for many tasks, feel free to download one of the implementations and take a look. If you find it lacking in some area, let us know and maybe we can fast-track a solution for that." IMO that's not only more accurate and truthful, it's also much better way to draw in potential users.

[chromatic]

Yes, predicting schedules based on volunteer effort is much more difficult than predicting schedules based on paid developer effort. Your proposed wording is a lot friendlier, but it doesn't match my experience with the project. (However, I've already written far too much on that subject, so I won't bore everyone again.)

[kbenson]

Well, I know it's in use in a few places now (I personally know someone using it at Google's engineering as a tool to retrieve and collate information, utilizing the newer async features), but of course there are still many rough spots. Whether it fits the bill for that person will be highly dependent on what they need.

I'm of the opinion the only way to solve the chicken and egg usage problem is to convince a few people to be chickens. That's not going to happen without them trying it out. (I'm aware you've thought quite a bit on this issue).