Most buses in the US run on routes with schedules. There are some problems with schedules. The biggest one is that the real world is not that predictable, so buses are often not on schedule. In an effort to make buses run more on schedule, there will often be downtime built into the schedule where the driver will park the bus somewhere for 5-20min so that the next trip will start on time, which is of course wasteful. Often there will be bunching, where buses on the same route get stuck one behind the other, so you'll get two in quick succession and then none for half an hour. For routes with relatively frequent service leaving from the same station (ex: buses 74, 75, 77, 78, 86, and 96, which all leave from harvard station's bus tunnel) I have another solution:

Keep the current numbers of buses and routes the same. Train the drivers on all the routes in a pool. Passengers arriving at the station swipe their transit cards on readers indicating which bus they want. Readers do not charge the cards, but they do note the id of the passenger. Passengers can swipe multiple readers in a form of approval voting, indicating that they'd be willing to get on multiple buses (ex: swiping for the 74 and 78, which both run between my work and harvard square) but additional swipes on the same machine would be ignored. Each machine displays it's total for the route. As buses come in they are assigned the route with the most votes and that machine goes to zero (other passengers who swiped on both this reader and another reader are subtracted from the other reader). Passengers may give up or take a bus not in the pool (say a trackless trolley, or even a subway) so after some amount of time (20min?) passengers are assumed to have gotten on a bus they didn't swipe for or left, so swipes are forgotten. Passengers waiting for unpopular buses could then reswipe.

Update 2010-08-19:Reilly and Becky point out that this has a 'starvation' issue, where unpopular users could end up waiting indefinitely because they give up before enough of them collect to qualify for the next bus. Potential solution: you can swipe as many times as you want, as often as you want. Each swipe tells the system "I'm still here". The 20min timeout becomes an assumption that someone is not still there if they've not swiped in the past 20min. The longer someone waits, the more likely they get their way. Make this exponential, where even one person waiting for 45 minutes beats a busfull waiting for 10min on the grounds that waiting a long time is unpleasant.

This doesn't account for picking people up enroute, so there'd need to be something in the system to deal with such people. One way is that the buses record data on who got on when, so that could be used to add votes for passengers who presumably would vote to request a bus.

This system could also work for something like commuter rail trains on the outbound trip.