Developers just need to provide a package for a distribution. Each distribution then has a way to install this package. This way can be in a terminal (apt-get) or via a graphical interface, e.g. Ubuntu Software Center.

The beauty is that developers just have to care about building a proper package; the distribution makers take care of the rest, and each package installation has the same process.

Because they don’t need to. Linux distributions usually have working package management systems, unlike Windows, where every single application has to re-implement installation and updating over and over and over and over again.

Most closed-source, non free-as-in-beer software for Linux does come with installation wizards. So does some closed-source, free-as-in-beer software, at least until most major distributions pick it up. For open source software, package managers are a clearly superior solution.

So what about the early stages before open source software gets picked up by the major distributions? Why don’t developers create installation wizards during that phase?

First of all, a lot of open source developers plain don’t care about distribution. They write software for themselves to use, and put it out there in case it is useful to others, but they see packaging for distribution as someone else’s problem. If it’s liked enough, someone will take upon themselves the task of getting it into their favorite distribution.

The open source developers who do care about distribution are still better off working within the package manager system, because that’s where their customers are. Linux users don’t typically search the web looking for software. They search their package manager first. Failing that, they search the “community maintained” repositories, like Ubuntu’s PPAs or Arch’s AUR. If you aren’t in those places, your software most likely won’t get noticed, and if it gets noticed, it’s less likely to be trusted.

Foregoing those existing distribution channels is sort of like deciding superbowl ads are too expensive, so you’re going to host your own football championship and advertise on there instead. It may be less costly, but it’s also less effective.

As far as customizing the configuration goes, for software like a web server that’s traditionally easier to handle with a config file, which makes the configuration easier to share, back up, and restore.

For client software like a web browser, it’s much better to create a configuration wizard that appears the first time a new user runs the software, rather than do it at installation time. The main reason is Linux is a multi-user operating system, so you want to customize it per user anyway. This also makes it easier to rerun the configuration wizard later, for whatever reason, without having to keep the installation program around to reinstall the entire software. This type of wizard is fairly common in Linux software.

Linux distributions (as well, I think, as BSD-flavoured Unices) have a user-friendly interface to program installation, via so-called package managers (or ports management in the BSD case): pacman for Arch, dpkg for Debian/Ubuntu, and so on.

These package manager provide a way to install programs by means of uniform configuration files. Once the program you need is packaged according to your distro’s package manager you can simply run its install command over the selected package (with occasional user-specific customizations, though often none at all) and the manager does the rest.

Package managers are usually more user-friendly than Windows’ program-specific installer processes, just for the uniform way programs are packaged for installation. They usually also allow you to query the package manager database for the program you’re looking for, see its dependencies.
They also support centralized update of the packages.

I’ve often asked myself, and others this question, and I’d like to address a point I often see brought up before I get to why Linux sees fewer installers:

Linux distributions provide package managers.

However, I wouldn’t say that a Linux distribution’s package manager is a replacement for an installer for, in part, the following reasons:

• These package managers aren’t standardized in operation

  A package manager is a bit like providing your binary and letting the end-user choose the installer. They can choose the terminal, or they can choose a tool with a more advanced GUI, but it doesn’t afford you the same level control of the process as with a “traditional” installation wizard.

  An example of what I mean by control is documentation. You can’t give your end-user instructions like “Click Next, and you should see “. You can give command-line instructions for a specific tool, but then you’re not only relying on the fact the user has that tool, but also losing most of the benefits of an install wizard (after all, most wizards are providing a front-end for simple command line instructions and kicking off scripts).

  This also ties into aesthetics. Now you’re depending on your end-users distribution to provide an intuitive/appropriate interface. While you are fully aware of that fact, it’s not unreasonable for a more casual user to complain if double clicking your file (installer in their view) opens up an ugly package manager, does nothing at all, or worst of all opens up a terminal window. (The experiences I’ve had with users and their aversion of the “dos prompt” / “black and white box” / “Thing that’s going to delete all their files if they look at it funny” could probably fill a book)

• Package formats aren’t standardized across platforms.

  There are tools to convert between systems like rpm and deb, but it’s not reasonable to expect your end-user to convert your packages if you’re using them in a situation where an installation wizard would be provided on another platform (i.e. clicks-and-done).
  Providing up-to-date packages for an additional package format can be rather straight forward if you have a rudimentary build system, but you’re still adding a new binary that needs to be supported.

  That’s also adding a new binary people have to choose from depending on their platform (it sounds minor, but I’m sure someone here can attest to having to explain x86 vs x64 before [yes, there are ways to deduce the right platform from the browser, but then you’re getting into even more complicated, and harder to support, procedures])

• Package managers are “nicer” to open-source software.

  This isn’t saying that you can’t share closed-source software with a package management system, it can definitely be done. But once you try to share close-source software on Linux distributions you run into a wall as far as your options for getting your software into common repositories is concerned. Things like PPAs or the openSUSE Build Service are out, and even the Canonical Partners repositories aren’t enabled by default.

  That means, unless you provide your own repository, you can’t many of the major features of package management systems, including automatic updates. In my opinion, this is the most important benefit across most platforms that use these systems (e.g. iOS, Android, and Windows Store).

  And even if you provide a repository (another job of variable triviality), you still need to get users to set it up (which is another layer of support, another set of non-standard approaches, and another diversion from the original point of the installer)

Now, having said all that, I still haven’t addressed the original problem, why installers are less common on Linux in spite of these factors (amongst others). The original question asks if it’s technical, or based on convention, and it’s based on both in part.

If you look at the above factors I’ve mentioned, they also make things more complex for a “wizard-like” installer. For example, would your wizard include multiple package formats to install? How do you handle look-and-feel across distributions? The list goes on, and one thing that that packages do afford you is that none of this will be your concern (for better or for worse) as long you provide the right packages. And depending on the nature of your project, you can start to take advantage of those more “specialized” resources, like submissions of apps to the Ubuntu Software Center. This would all relate to the technical.

But the aspect that I personally find to be the driving force is convention. (I hope I’ve buried this deep enough that the people who downvoted that other answer to oblivion have stopped reading..)

I feel that poster had a point, but might have stated it too bluntly, and not actually provided objective reasons for that point. If you examine the differences I stated for a package manager and an installer, I wouldn’t be surprised if you found most of them to be nearly non-issues (maybe even bordering on pedantic). But (excuse what I hope is viewed as legitimate use of an ad hominem argument) we’re also users on site for programmers. I see Linux distributions pushed as an excellent Windows alternative for casual users (amongst many other things obviously). Not providing a commonly defined clicks-and-done procedure that all of these users can use really isn’t ideal imo.

But at the same time, I don’t find that many things in Linux to be especially ideal for that group either. Sure some distros have GUI-based package managers, but that means these people have to start looking into how to use a separate tool, on that isn’t strictly focused on your program’s installation (compare this and this to this).

Naturally you can use the GUI to do a majority your average casual user needs to do, especially with certain distros (ironically the things those distros are doing aren’t always embraced in the open source community [look at complaints about Ubuntu and it’s “walled garden”]) But I don’t think it’s deniable that Linux conventions favor someone who’s comfortable with a CLI, or at the very least not deathly afraid it’s appearance means they did something horribly wrong.

I’m not saying that this is what they aim for, but it’s really what I see those conventions do. And package management systems in Linux seem to be following that. After all, most of their “downsides” nearly non-existent if your end-user is more comfortable with the underlying concepts.

Installers on most other platforms aren’t really affected by that, and are designed so, to quote a comment on the question, “99.99% of users [can] blindly click “Continue”. The problem with package management is getting those users to a “Continue” button, letting them know what that “Continue” button is (I’ve seen users get tripped up by tools that said press enter with other text), and letting them know when they’ve hit that “coast on clicking the “Continue” button” stage.

To large extends it’s both. The Linux distribution model is closer to AppStore/Play Store then traditional Windows/Mac OS X one – and even those platform are moving there from what I’ve heard.

The convention is that it’s simpler. Most arguments for the AppStore/Play Store applies to Linux as well:

• Automatic updates. Having 20 programs update separately on Windows is disruptive and inefficient. User needs click though Java/Flash/Adobe/… updates on boot.
• Single, trusted, repository. Do you check if you download via secure connection? Or you haven’t download from an Reader update from get.adobe.com.hackers.example.com/setup.exe? Even if you do most users, especially not power users, don’t. Instead you go to software centre or similar program in Linux and get a trusted copy.

Furthermore there are following benefits, which may not apply to AppStore/Play Store:

• Not every Linux has GUI – think http server – yet most distros supports such configuration. Ok. Not everyone needs one but sooner or later someone will want to use it for whatever reason.
• The ABIs of libraries on various distros may differ. Not going into details having an installer would put responsibility of the program working on you instead of people maintaining a package in repository.
• Connected with previous one – you need to manage dependencies somehow. Bundling is considered improper for a reason – in such case you need to ensure that you have updated the library to version without a bug – for example you didn’t include openssl 1.0.1f into your bundle. Practise shows that people do include outdated libraries with known security vulnerabilities.

Usually, the installation doesn’t need interaction with a user (most apt-get packages for example), or can be scripted. This makes it very easy to automate in order to deploy a piece of software on many machines. Instead of doing things through the wizard, you do those same things through scripting or through configuration files.

Given that in Linux world, terminal comes first, and the GUI is optional, it becomes obvious why do they lack actual installation wizards.

Windows, on the other hand, is very user-oriented. Most MSI files can easily be deployed in unattended way, in the same way Windows installation can be unattended (how easy/difficult is to get WAIK to work is a different subject). This also means that a bunch of applications for Windows are not based on MSI, and are not scriptable. Among enterprise-scale application, Adobe products, for example, are known for being rather difficult to install in a scripted way.

The target audience is different. Unix, and Unix-like systems, were usually used by professional programmers, sysadmins, engineers and serious hobbyists who customized each system to their needs. Any “installation wizards” would only limit their choices instead of giving access to all the variables they need. And the ones now out there still do.

Windows is not targeted at professionals in the same way and, thus, has more general purpose installers geared toward “users” who only want the thing installed. Linux is garnering more of these user-types who would probably appreciate such a thing but, possibly, most distros still have the professional in mind.