On the importance of providing binaries with your software package

This writeup springs out of my urge to kill someone after trying to compile and install a software package

In this article, I'll ignore for the sake of argument that I am a developer, and side with users.

Nowadays we have tens of thousands of applications available for Linux. Some are simple, some are rather complex, some are huge. This ought to be enough to achieve world domination, according to some Linux proponents.

False. Software may exist and may be available to download in source form, but, in practice, if there aren't any binaries, it's as if didn't exist. I'm going to make an assertion which I hope becomes a fundamental axiom for the developer:

A source package alone is worth nothing

That's right. It might be heresy for some people, but it turns out that:

• 95% of computer users don't have a full development environment
• Installing the development environment (assuming best-case scenario, with CD and binary availability) takes at least 45 minutes
• Many times packages require extra -devel dependencies and won't compile without them, so it's a job of hunt-and-peck

That's right. If you, as a developer, don't generate RPMs or DEBs from your software, you just lost 95% of your potential users. Moreover, you will miss users which DO have working development environments for the following reasons:

1. RPM and APT have consistency checks which let you quickly audit dependencies for a certain package
2. A package system lets you control which files are installed and if they have changed
3. A package system saves lots of time (in some cases, hours). By taking 15 minutes to generate an RPM, you're saving thousands of hours on the side of the users.

I'll repeat: end users don't want to compile anything. We want everything fed to us, ready to install. Lindows has been criticized heavily, but its Click-n-Run system should be the role model for everyone else. Even Debian's APT pales in comparison. And binary packages are a prerequisite for such a system.

Here's a short list of what to do in order to multiply your software's users by ten:

1. Include a .spec file in your source package to generate RPMs, and menu entries for the most popular desktops (KDE, GNOME and the Debian menu system)
2. Create a Web page that explains what your software is and does, and which version is the latest, at the least
3. Post your source package there, with an easily identifiable file name
4. Generate an i386 and a .src RPM package, at the least, and place it below your source package on your Web site; below those, place hyperlinks to the RPMs that are required for your software to work.

Up to the challenge but don't know where to start? Read Creating high quality integrated Linux applications, an excellent article with guidelines and tips to take your software to production quality.

Too much work? Then don't mess with software development, unless it's only for your needs. You can't consider your software package finished without complying with at least this short-list. These are elemental software quality notions. Oh, and by the way, respect the Linux Standard Base and don't place files in odd locations, to ease the life of system administrators.