Short, technical explanation: ASCOM is a standards-based implimentation of Microsoft's Component Object Model (and therefore of the Distributed Component Object Model and of dot-Net). ASCOM allows high-level control of astronomical telescopes, cameras, and related devices in real-time, and allows automated data reduction.
Long, laypersons explanation: See below.
ASCOM is a standard method of writing computer programs that accept external calls. This means that the user does not have to sit at the computer and click menus and command buttons to get the software to operate. The user can instead start some other software program which does its own menu clicking behind the scenes.
If you are used to operating software such as a word processor or a star charting program, you will be familiar with a menu-driven interface. To carry out some task, you need to activate the correct menu items in the correct order. To print a document from your word processor, you click "file" and then "print," in that order.
ASCOM can be thought of as a means of allowing another program to click those menu items for you. In programming terms, each menu item activates a "function," which is a discreet piece of programming. In ASCOM, a "function" is called a "method." When one piece of software calls a method of another piece of software, it activates a function that does something.
Similarly, user interface driven programs have settings. You are probably familiar with telling a word processor how many pages of the document to print. A setting basically sets a variable in the software program. In ASCOM, these variables are called "properties." Another piece of software can access a property - reading it to learn some result, or writing to it to store a piece of data or control how the software will operate.
In ASCOM, these "methods" and "properties" are bound up into "objects." Each object holds a related set of functions (methods) and settings (properties) that can be used by some other software.
A piece of software that offers methods and properties for use by other software is called a server. An example of an ASCOM server is ACP, the telescope control program by DC3 Dreams. This program has a number of functions that allow the control of a wide variety of telescopes. For example, software can find out the sidereal time from this program (by reading a property). It can also tell the program to slew the telescope (by calling a method).
Software that knows about a server and uses its functions are called clients. So in our example, the software that is reading the sidereal time from ACP, or asking ACP to slew the telescope, is an ASCOM client.
The reason that this is so handy is that there is very little highly customizable software in the menu-driven, monolithic Windows environment. If you want to go to the store and buy a software package that slews your telescope to ten objects, takes a picture of each with your particular brand of CCD camera, and verify that it is pointing correctly all the while, then park the telescope for a few hours, then take a picture of something coming up in the east before sunrise - you can't. Nobody makes that software. You have to sit at the computer running the telescope manually to get this done.
Or, you can use ASCOM software and (in theory) you can write your own program to do this for you. ASCOM gives you a software toolbox that makes this possible. You don't have to learn how to access the serial port with your C++ compiler, and you don't have to learn what commands to transmit down the line - ACP takes care of that for you. But you are also not at the mercy of some programmer who didn't write a "slew to ten objects in a row and take pictures of them" function in their software because they didn't think you'd want to do that.
Fortunately, you also don't have to have a C++ compiler to do this. Any script will do. Windows can run scripts in VBScript, Javascript, perl, TCL, Python, or whatever other language you want to use. Some of these languages (VBScript and TCL especially) are very similar to English in their syntax and are very easy to learn. Others are a bit more complicated - perl has been called the "swiss army chainsaw" of scripting languages. Anyway, scripts on Windows run in the Windows Scripting Host - and the Windows Scripting Host can be an ASCOM client or an ASCOM server, so compiled programs are not required.
Finally, you can just download a script someone else has written and use it for your own telescope. it doesn't matter if I have an Optical Guidance Systems telescope and you have a Meade - the abstraction layer (another fancy word!) in ACP takes care of that for us. The script doesn't have to know and certainly doesn't care what telescope is being used - so the scripts are portable. Since scripts are distributed as source code, you can also go in and modify them to work the way you want them to, without going to the trouble of learning how to write an entire application using a scripting language.
Bob Denny, well known for writing popular web server software, devised the ASCOM standard, wrote the first piece of software to use it, and released it to the world on September 8, 1998. By early 1999, an image reduction package by the same author, called PinPoint, was in open beta testing. Around this same time, Doug George, author of Maxim DL/CCD, made Maxim into an ASCOM server, allowing the control of CCD cameras through ASCOM automation. This troika of applications, now in more recent versions, continues to drive the overwhelming majority of robotic and remote telescopes.