It's a little bit old question, but if you still want to know..
There are 2 typical scenarios, what gertvdijk and pl1nk were arguing in one of the answers:
You have a computer with 2 public IPs (2 different ISPs) and you connect to another host (e.g. a server in a datacenter with a fat pipe that's bigger than the aggregate bandwidth of both ISP connections of your computer). So you establish a bonding connection to the host via your 2 connections and then the host (server) serves your traffic via its own internet connection. In this scenario, you can get almost 100% of the combined bandwidth in both directions for a single connection.
This is a particular case of bonding/teaming/ling aggregation where multiple layer 2 (same network) interfaces are joined together. It could be archived by establishing vpn layer 2 (tap) connections on each ISP interface from the computer to the host and bonding them together (round-robin mode) to have a single interface. The limiting factor in this scenario is how different are the delays (ping) on each ISP connection to the host. The more similar and stable they are, the better. We use it in one of our installations, it works well. If you would like to know the details about how to implement it just let me know.
Then another scenario would be without an intermediate host, i.e. a direct connection from you ISP interfaces to the webservers around the world. In this case the best you can get is to evenly distribute outgoing connections between the interfaces – i.e. one TCP session goes entirely via one ISP, a second session via another and so on. It is so because when you establish a TCP connection, it has an origin and a destination IPs for each packet and when a server receives a packet from another IP for which a TCP handshake was not performed, it considers the packet as erroneous and drops it. As each ISP connection has its own public IP, for the same TCP session you can't send one packet via one connection from one IP and another via another connection with another IP.
You won't get here as high aggregate bandwidth utilization for a single computer as with the first scenario, but for a small office it could be a good solution. What you can do to extend it a little bit is to implement custom solutions for specific protocols. For example you could have some sort of a proxy on the gateway (which could be the same computer) for http downloads and ask for different parts of a huge file establishing different TCP sessions via different ISP interfaces. In this case the resulting download rate would be near 100% of the combined bandwidth. It's like offloading to the gateway what ReGet, GetRight and similar downloaders do. Google for HTTP 206 Partial Content. I don’t know any out-of-the-box open-source solutions for this scenario, but there are hardware appliances that do exactly this: google for mushroom networks.