If programmers could learn one thing from successful businesspeople, they should learn about the idea of opportunity costs. Sure, it's fun to throw away a lot of code and rewrite it from nothing, but in the years you're waiting for that mystical magical super sixy project to get usable, you could have been making money with working code, even if it's a little shabby around the edges.
Sometimes opportunity cost works the other way, too. If you can get a 1% return by putting your money in a CD for 12 months or you have the chance to get a 10% return if you can buy the right stock sometime in the next three months, hold out for the 10% return. You might get it. You might not. Yet the reward is greater than the risk.
So it goes with programming.
When I wear my programmer hat, I want to write the best code imaginable. I want to find the right abstractions. I want to discover the most elegant design. I want to put in the least effort. The risk of getting it wrong and having to do more work is greater than the risk of missing a deadline.
When I wear my business hat, I want the most valuable features as soon as possible. The risk of missing out on business value (greater revenue, lesser costs, greater productivity) is greater than the risk of increased future maintenance costs. After all, it should be possible to measure those increased costs and deal with them when it makes the most sense from the business point of view.
Project management includes the art of navigating between the business desire to have working software sooner and the programmer desire to have elegant software. That's not easy, but there are ways to give both groups some of what they need.
Sadly, community-driven development of the free and open source software worlds often lacks this management. We don't lack the tension though. Consider, for example, the debate over whether it's acceptable to release software without documentation. The business argument is "It can provide value to people." The developer argument is "It's not finished without documentation."
This tendency matters less in the F/OSS world as in the business world where your paycheck depends on your ability to deliver working software. What's the worst that can happen? People will move on to a competing project which better meets their needs. (And you thought F/OSS people didn't understand capitalism.) So you annoy your users and drive them away; you're a volunteer, and there are always plenty of volunteers.
... until there aren't.
Sure, that's an extreme position. Though it's easy to trawl through GitHub (and before that, SourceForge) to find the abandoned carcasses of projects which never delivered anything of value to anyone and consequently never attracted sustainable development beyond the whims of the originators, I suspect that it's more interesting to consider the quiet desperation of active projects stuck in not-invented-here rewrite limbo which struggle to achieve usefulness.
What if they spent more time focusing on the value their code should provide to potential users and less time constructing elegant, airy edifices?
It's important to write clean and maintainable code. It's important to focus on quality and craft. Yes, please let us do that. Yet if you want to have real users, shouldn't you also consider how your choices affect them and what that costs them?
