If development is done properly, "maintenance" isn't some massive chore. It's pay-as-you-go and takes the form of proper testing, early design review and refactoring, and a shared sense of responsibility for the upkeep of the code (none of this "give maintenance work to the juniors" attitude).
When a company decides to put its junior people on full-time maintenance to have them pay their dues, it's setting itself up for failure. Unskilled maintenance makes the code worse. Unmotivated maintenance makes the code worse. Finally, even in the best-case scenario where the junior programmer is motivated and skilled, he still doesn't have the clout to do maintenance properly, which often pisses off people who depend on ill-thought-out features.
Ideally, people who care about an asset (i.e. who use it) should be the ones to maintain it. Ideally as well, the maintenance overhead should be small enough that the "stakeholder" can perform this maintenance pay-as-you-go at the same time as doing other things. Maintenance is really only done well (and if it's done well, it improves rather than "maintaining" the code) when done by people who have reasons to care about the system they're maintaining.
Once a project's maintenance overhead is measured in X full-time developers where X >= 0.5, it's time to stop pissing away time and money and motivation and kill -9 that sucker. The warning range is 0.25 to 0.5 full-time developers. If the maintenance burden is in this range, it's time to get a competent person into fixit mode (not "maintenance", but active improvement and refactoring) immediately.
Here's my somewhat long post on the topic: http://michaelochurch.wordpress.com/2011/09/23/taxation-with...