During the discussions which led to Parrot and Rakudo having monthly releases (and which helped lead Perl 5 to monthly bleadperl releases and yearly major releases), I focused on predictability. This concern has two parts. Users can plan their upgrades around the release schedule and can see how the project makes and meets public commitments. Developers can find a rhythm in the schedule to help them plan testing and merging and scheduling of changes.
Another overlooked aspect of a reliable (and relatively short) schedule periodicity comes from physics. A project at rest tends to stay at rest. A project in motion tends to stay in motion. (Dividing the viability and utility of a project between its users and its developers seems useful. Think of "motion" as both "used productively by users" and "under active development".)
That's inertia. What's more important than inertia? Momentum.
A project at rest will take effort to put in motion again. When it begins to move, its momentum is a product of its inertia (how much it can stay in motion) and its velocity (the progress it makes). Similarly a project in motion has a momentum of its inertia (how likely it is to stay in motion) and its velocity.
We want to increase momentum for our projects in progress.
Obviously the direction of the motion is important. A project picking up momentum going the wrong way is in trouble just as a project losing momentum even if it's going the right way.
Momentum as a metaphor has another good quality going for it. Because it's a combination of velocity and inertia, you can have a project with good momentum with a little bit of velocity and a lot of inertia just as much as a project with lots of velocity and a little inertia. A small library everyone uses doesn't need a lot of velocity to remain viable. A new project used nowhere needs a lot of velocity to make it to the point where it is viable.
This is why it's difficult to watch a project slowly lose developers. If a project is mature—if it's reaching a point where maintenance is more important than new development—then inertia can take over from velocity. If a project hasn't reached that point, losing velocity almost certainly means momentum will slow or even stop.
One of the worst things you can do in your project is to impede momentum. You've probably heard of Joel Spolsky's excoriation of the Big Rewrite, but you may not have read Adam Turoff's Long Now take on rewriting software. Spolsky's point is about the momentum of the short term. If you reduce your project's inertia to zero, you'll face a superhuman effort to get it back. Turoff's point is about the long term. If you can survive the short term, you may be better off.
(Mozilla is the tofu of project management. It takes on the flavor of any argument you pair with it.)
I wish I could give more practical advice than throwing out a metaphor, but as I look over the history of Parrot and P6, this metaphor fits better than most. Parrot has, over its history, had a lot of velocity but it never had much momentum. One of its biggest failures is not running a working P6 implementation from the start. (Sure, it had some attempts in that direction, but Pugs was the first attempt at anything actually serious, and that wasn't a Parrot project at all.) One of Parrot's worst failures is that we tried to give it inertia beyond P6 and failed miserably.
One of P6's failures is that it's never achieved much in the way of moving inertia. In the past couple of years Rakudo has improved its velocity greatly, but that's been at the expense (at least in opportunity costs) of Parrot, and thus it's undercut its inertia. Years of work have gone into getting Rakudo to more or less the same partially-implemented state on multiple backends, and that state is still not ready for general use.
Certainly the cost of development is important, but so is the likelihood of success. Can you analyze the state of a project in terms of its inertia (for its developers and its users) as well as its velocity? I believe a project's viability hinges on its momentum. You can draw the four quadrants and plot your project to see the risks involved.
