Parrot as a Mature Platform
wknight8111.blogspot.com
wknight8111.blogspot.com
Also, how do those projects acquire new developers? Say, you're an open source enthusiast with a set of relevant skills / preferences (VM skills, programming languages, technical writing, FOSS project management, whatever), looking for a project to join. Why would you choose a project with a history of staying in "experimental, unstable and incomplete" state for 10 years, no deadlines mentioned and unusable for anything serious in production? At this rate, it will probably still be in the same state in 3 years; what will you have achieved by then? "I wrote a lot of highly complex code / documentation, but almost nobody really uses it"?
I have no problem explaining the presence of Parrot and Perl 6 on my CV to employers willing to ask honest questions about my participation in both projects. All of our successes and failures are visible to anyone willing to understand them. We deliver working software every month, with continual improvements. We review the way we schedule, develop, and deliver that software regularly. We have a good testing infrastructure. The software gets more and more usable and more and more useful and we manage to attract more and more users and more and more contributors. Parrot has to walk the fine line between making architectural changes Rakudo Perl 6 needs and maintaining a stable base for Rakudo -- two desires which often conflict.
Yet somehow, month after month for almost three years now, both projects release usable, useful, well-tested software. You can see the monthly improvements.
Does the fact that Parrot suffered a critical project personnel failure four or five years ago forever taint everything good it's done in the intervening years? Does the fact that Perl 6 had to invent new parsing techniques ruin its suitability now? In five years? In twenty? (Just how long should it take to invent something new anyway?)
I believe that an honest assessment of both projects as they stand right now will demonstrate that we can make and meet commitments. What more can you ask of developers and project managers?
You point out that you perl6 folks make a steady progress, and that the work you're doing is fairly hard. All valid points, but... I don't want to sound cruel, but a steady progress solving hard problems is not very valuable per se to the [potential] users of the software or employers of the participants. They usually care much more about results. If you deliver the results without much progress and avoiding hard problems, you're fine; if you do a lot of progress working through hard problems without practically useful results, you're screwed.
You say your software works; fine, but for what definition of "work"? "Passes tests" is one thing, but "usable for production heavy lifting" is something in a completely different league. I see people migrating from ruby-1.8 to ruby-1.9 now and then; a move from python2 to python3 is a fairly rare beast; but did anyone move from perl5 to perl6? or started a non-toy / non-research project using perl6 / parrot?
You mention the research value (new parsing techniques et ol). I have my share of doubts wrt this part (so does the author of the article, IIRC), but let's skip it. My bigger point is, is it what users and employers want? I honestly don't see it. Please don't misunderstand me here; I'm not saying you must do what some other people want. You, of course, are free to do whatever, I (or anybody else) is not in position to tell you what to do. But then again, when other people (production perl users, potential investors, employers and contributors -- in short, industry people, not research people) judge your projects, their judgments will probably be aligned with their very specific industrial needs, not with potential research value and/or some decades-long perspective.