Some misunderstandings...
> The philosophy of FLOSS is that given enough people and enough
> time to review, things will get fixed.
> Great as far as it goes - because it doesn't specify WHEN.
No. That's not what FLOSS is about.
The advantage of open-source is that your bugs get found. There are far more people looking at the code, so it gets far more testing by people who have a good idea how to stress the code in question.
This says nothing whatsoever about how you go about *fixing* those bugs - it just provides a mechanism for discovering them.
> But what about projects and software that ABSOLUTELY
> have to go live in a short amount of time?
You pay someone to debug the code - just as you would in a closed-source application. Being open-source does not hamper this development flow at all - it just provides additional volunteer testing resources.
> When is there the time for FLOSS to be reviewed, discovered, and fixed?
> And then those fixes themselves reviewed and tested?
Being FLOSS does not preclude exactly the same reviewing and testing that closed-source would require - so the same job can be done. Being FLOSS does get extra testing for free.
The only thing that FLOSS precludes is security through obscurity. For a voting system in particular, that is a very god thing to prevent...
> But let's at least examine when it MIGHT have limitations
Sure. This is not one of them.
> such as short time-frame deliverables on systems that have to be verified.
Short-time deliverables is when I absolutely would want to go open very early - get people on-board and helping out.
You appear to be describing FLOSS as projects with no paid, fuill-time staff. This is not even close to the truth. FLOSS has the same development resources available as closed-source - but it *also* has unpaid volunteers looking over the code to help find bugs. This is additional resource, not alternative.
Vic.