I know what serialization is, but to me, this is one term that does not describe what it means.
Why do we call serialization serialization? What is it about converting objects to raw data (and inflating/deserializing, for that matter) lends itself towards anything that related to the term "serial"? Who coined this term and why?
It's probably from networking and communications, where it is necessary to convert data into a serial stream of ones and zeros.
Wikipedia says:
In computer science, in the context of data storage and transmission, serialization is the process of converting an object into a sequence of bits so that it can be persisted on a storage medium (such as a file, or a memory buffer) or transmitted across a network connection link. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward.
I also remembered last night that the first networking project I worked on (1983) used the term "serializer" for the part of the code that translated messages from structs in C to a series of bytes to be written out to the network transport. It had to take the struct, which logically represented the message, and output it each byte following the next onto the wire.
The authors of this code came from BB&N, so that gives you a direction in which to look for history.
Serial means one right after another. Hence, that it becomes one long stream of bytes.
Serialization transforms data in memory with data structures and pointers into a series of bytes designed to be saved on a sequential media, such as a hard disk or transferred through something like a serial connection.
It basically just means a series of items put in an order. The word serialized is also used sometime in literature.
I think John Saunders is on the right track, the fact that data is sent to disk or over a network as a "stream" is almost certainly the origin of this term.
Another way to think of it, however, is like this: The state of a program is spread all over memory, with pointers/links pointing all over the place. You have arrays, lists, trees, call stacks, heaps of allocated memory, etc., in no particular order.
When you want to save some state, you cannot use much of the information in your program. For example, any pointer values or stack offsets (whether used directly or used internally by the language runtime, etc.) will likely not be valid the next time your program runs because the heap will have been used to allocate slightly different series of memory blocks. Saving these pointer values would be useless.
To save some state, you have to "put your affairs in order" such that the information being saved is only that part that will be relevant later on.