Upstream refers to the originator of the component that is being discussed.
E.g. if you wrote a torrent client which is based upon libtransmission, then a bug is found in your client which is tracked back to libtransmission. The bug is fixed with a patch which is now included in your client.
Merging the patch upstream in this context would mean to send the patch to the authors of libtransmission for inclusion. This way the fix would be propagated to every project which is based upon libtransmission.
The alternative to merging upstream is keeping the patch for yourself.
Using Ubuntu as an example.
Ubuntu is a distribution which packs a lot of software together, small and large. There are graphic drivers, the X server, and Gnome, among others. Ubuntu itself is not developing those software. Ubuntu is “just” packing the software together, making sure that the individual components work together. All that software which Ubuntu is packing together are called upstream from Ubuntu’s point of view.
In the process of combining all that software together bugs might pop up. The bug might be in one of the software components, for example gnome, or it might be in the very special way Ubuntu is doing things. After all, a distribution is a distribution because it does some things in it’s own very special way.
If the bug is caused by the way Ubuntu is doing things, then Ubuntu will have to fix that bug for itself. If the bug is in fact in one of the software components, for example Gnome, then Ubuntu will have to patch Gnome. When Ubuntu sends the patch back to Gnome, so others can also benefit from the patch, then Ubuntu is sending that patch upstream.
If Ubuntu decides to not send that patch upstream, or the upstream project rejects the patch (but ubuntu decides to still keep the patch), then Ubuntu has technically forked the project.
The opposite of upstream would be downstream, Ubuntu is downstream from Gnome. I do not hear/read that term used often.
See also the article about upstream in Wikipedia.