But they give instructions like
cd downloaded_program
./configure
make install
This creates the ELF that is needed, and probably some .so files.
Why not put those inside a zip file for download, like with windows apps? Is there any reason why they need to be compiled by the user?
Let's analyse the factors...
Analysis:
DEPENDENCIES ACCORDING TO PLATFORM: There are some issues that arise in an environment where developers are creating and maintaining several architecture-specific variants of an application:
Different source code is required for different variants — Different UNIX-based operating systems may use different functions to implement the same task (for example, strchr(3) vs. index(3)). Likewise, it may be necessary to include different header files for different variants (for example, string.h vs. strings.h).
Different build procedures are required for different variants — The build procedures for different platforms vary. The differences might involve such particulars as compiler locations, compiler options, and libraries.
Builds for different variants must be kept separate — Since there is a single source tree, care must be taken to ensure that object modules and executables for one architecture do not become confused with those for other architectures. For example, the link editor must not try to create an IRIX–5 executable using an object module that was built for SunOS–4.
Every operating system has its own linking management scheme and must prepare the ELF (Executable and Linking Format) file as it needs it.
The compiler will generate a build that is a sequence of instructions, and distinct architectures mean different instruction sets (Comparison of Instruction Set Architectures). So, the output of the compiler is distinct for each architecture (Ex: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola's 6800, MOS T 6502, and so many others)
SECURITY:
MARKET: In this section there are a lot of factors, but i'll try to resume it:
Not every company aims to reach all the platforms, it depends on the market and the platforms popularity and what they want to sell.
Free software have the spirit of making software as widely available as possible, but it doesn't imply that the software is designed for every platform, it depends on the community who supports it.
Conclusion:
Not every software is designed for every platform. Providing binaries for all the architectures and platforms implies to compile it, test it, and maintain it for all the platforms. That's more work that is sometimes just too expensive, and can be avoided if the user compiles it in its own platform. Also, the user will be aware of what he's executing.
There is such a variety of platforms and software environments both *nix and other, that the software may be able to be run on, that allowing you to build an application (or library to use with applications) is the only realistic way to support as many combination of those components as a "good" software item does. Of course, licences such as the GPL require the source code to be available - so even if the software doesn't work properly it is usually possible (though it might be tricky to comprehend what is wrong and how to fix it) for the user or some third party to dive in and correct it even if the creator won't/can't/no longer exists to do so.
Distributing software as source code also allows independent verification that the software does what it claims to and does not do something nasty instead of or as well - which despite reducing the level of trust one has to have in the creator, actually enhances it!
First, your question is based on a flawed premise. Programs are distributed in compiled format!
The normal way to install software on Ubuntu, like on most other Linux distributions, and more generally on most Unix variants, is to install a package. On Ubuntu, you open the software center or some other package manager and browse the available software. When you select a package for installation, the binaries (if the package contains a program) are downloaded and installed on your machine.
By default, the package manager offers you packages made by the distribution maintainers. You can also find third-party sources of packages; Ubuntu offers PPA as a standardized way for third parties to offer packages.
Downloading the software from the author in compiled form is a last resort. You only need to do that if the software isn’t popular enough to be packaged, or if you absolutely need the latest version which hasn’t been packaged. Most people never need to do this.
When software isn’t packaged for a distribution, it’s often distributed in source form rather than in binary form. There are two main reasons why this happens often in the Linux world, but rarely in the Windows world. One reason is that the proportion of open source programs on Linux is much higher. Obviously, if a program’s source code is not available, the only form of distribution is a binary. The other reason is that the Linux world is much more diverse. Different binaries are needed for each set of incompatible library versions, which often means different binaries for each version of each distribution. Windows “solves” this by having each package author distribute the libraries they use along with the program (consequence: your computer stores many copies of each library, one per program that uses it; if a bug is fixed in a library, each program that uses it has to ship an update), and by releasing a new version of the operating system only every three years or so. Unix has much more diversity and much more timely bug fixing habits, and solves the library distribution issues by building different binaries for different distributions.
Linux runs on more than just one particular CPU platform. If you distributed ELF files (or any other kind of raw executable), there'd be a chance that some versions of Linux couldn't run the software. In the spirit of making software as widely available as possible, using the source code is preferred. For example, Linux runs on Sparc, Intel, AMD, ARM, and other types of processors.
If the ELF file targeted specifically Intel processors, for example, then other types of hardware couldn't run the software. ELF is platform independent, but the code it hosts needs to conform to a platform's machine code. You'll notice how many distributions have similar packages (e.g. _386 and _586 packages when it supports different processors)-- you have to install the correct ELF file to get the correct operation.
Similarly, if I decide to build a custom Linux version that uses different interrupts, linkers, etc, then I still need the source code to compile the code. Even if the source code doesn't have platform-specific build instructions, each platform is different and may not run an ELF from a different system.
The original reason for distribution as source certainly was platform diversity; the Linux community has continued that methodology both for that and for new, partially political, reasons.
Unlike e.g. Windows, Linux has historically never bothered to keep any ABI (application binary interface) stable across long periods of time - keeping the possibility to innovate on aspects like executable formats, library APIs, and support for new hardware platforms was/is considered more important.
Commercial operating systems achieve long-term application compatibility by being very disciplined about innovation; a new feature/software interface always needs to be added IN ADDITION to an old one - requiring two things to be maintained, and the price of changing anything after release needs to be considered very high. Alternatively, you can embrace the fact of planned application obsolescence together with anyone writing software for your OS (this is not hinting at MS but another OS vendor).
Achieving a long-term stable platform for software distributed in binary-only form (outside of a given Linux distribution) would be even considered undesirable by some elements of the Linux community. As an unapologetic user of both platforms, I am not saying that is good or bad; it is like it is.
In many cases (at least in the *nix world), the source code is the most portable version of the software. Having the source guarantees that the shared software will work on every platform that could possibly support it (which in many cases simply means POSIX-compliant). Releasing binaries only guarantees compatibility with platforms (both software and hardware) that those binaries are released for.
Consider that on windows, binaries are the most convenient and portable form for sharing software. Since compiling source is not part of the usual windows software distribution model, Microsoft has gone to great lengths over the years to ensure binaries work across multiple versions of their OS: http://www.joelonsoftware.com/articles/APIWar.html
Most Linux software is free software. By distributing the source code with some compiling instructions rather than binaries, you have the opportunity to review or even edit the source code before compiling it. This way, you can be very sure what the program actually does and that it is not harmful.
The main reason that I personally don't like just getting an executable of a program is because I like to first check out what the source code is actually doing (mostly because I just enjoy looking at others' code) but I know of several others who also check source code for malicious code.
A lot of answers have said that in most of cases, software are distributed in compiled format. I agree with this assumption. Nevertheless I see a case where distribute a software by its source is better than distribute it in compiled format.
I am not sure that it's true, but I imagine in the beginning of the Internet, because network bandwith were bad, it could be sometimes faster to distribute a software by its source than in compiled format. As code sources are only plain text, it's often smaller than the software in compiled format. So, distribute a software with code source seems to be a better way to share it, provided that users are able to compile it.
Aside from the fact that there are many unix systems that run on many different platforms, just consider the problems that Windows software faces from this distribution modal, even though they really only have to worry about one version of windows, and one platform ( the PC ).
Even with just the PC to worry about, there are still two architectures: 32 bit and 64 bit. If you notice, the vast majority of windows software simply ignores 64 bit and only ships 32 bit software, leaving you with sub-optimal software if you have a 64 bit system. Then there are libraries. One software vendor does not want you to get strange errors trying to run their program if you don't have the proper library already installed, so they just include the library with their program ( making the download larger, even if you already have this library ). A second program does the same thing, but with a different version of the library. In the best case, program B contains a newer version of the library that is backward compatible, so if you install program B after program A, things work, but installing them in the reverse order leaves you with the older version of the library and so program B breaks. Often times though, the library vendor makes changes that are not backward compatible and does not bother changing the name of the library, so no matter which order you install the two programs in, the first one will break. This is called "dll hell".
Sadly, to avoid this, most windows software has resorted to shipping all of their libraries in their own program directory instead of a shared directory, so each program has all of its own private libraries and will never share with each other, which defeates the whole point of dlls in the first place and you end up using a lot more ram and disk space and time downloading all of the duplicate libraries.
This is why open source software is published in source form, and OS vendors have come up with package managers that sort out the dependency issues and download only the precompiled binaries that you actually need, without duplicating libraries all over the place. This also deals with the fact that there are many different unix systems that run on many different platforms.
