Yes and no. Yes, the classical scenario is a developer using a compiler to generate machine code from source code, and the machine code is then distributed to the users.
There are a few exceptions to this though. First, many open source projects are distributed primarily (or even exclusively) in source code form, and expect the end user to install them by typing in a couple of commands like
make and then
make intall. This will invoke the compiler, linker, etc., to generate the machine code from the source code for that users computer. In these cases, however, the process of building and installing is (at least intended to be) automated to the point that the user rarely needs much knowledge of it beyond the fact that if they've never installed a source code-only package previously, their package manager will typically list some "development" package as a prerequisite for installing the application they really care about (though some still see this as unfriendly to end users).
Another exception (that's been alluded to, but not explained very well in the other answers I've seen) is just-in-time (JIT) compilers. A couple of obvious examples of JIT compilers are the Microsoft Common Language Runtime (CLR) and the Java Virtual Machine (JVM). In these cases, there are normally two entirely separate compilers involved in translating source code into machine code. One is used by the developer. However, rather than generating machine code directly, it generates a machine-independent byte code. The CLR/JVM then includes a second compiler, entirely separate from the first, that converts those byte codes to machine code for the target computer.
I should add that the second compiler isn't strictly necessary. Early versions of the JVM (for one example) just interpreted the byte codes instead of compiling them. This often carries a fairly serious performance penalty though, so most reasonably recent JVMs intended for production use include a JIT compiler.