Source Code: never distribute an app as “source code”

I just ran into a 2004 piece of FREE software that I wanted to use, but can’t, because of poor choices by the original author. I’m posting this because I think the ideological reasons behind those choices are now “of historical interest only” and I’m liable to forget them completely a few years from now – but the underlying issues remain.

Especially in a world where Android, on a marketing platform of “openness”, is competing with iPhone, on a platform of “all users are lazy or idiots”.

(As a user, I hate being treated like an idiot. Except when it means a computer does all the work for me. Fair? Reasonable? Nope! When it comes to users … developers can’t win :) )

How should you distribute an application?

There used to be a raging debate, for decades, about the “correct” way to distribute applications. A bunch of well-meaning (but IMHO un-wise) Open Source programmers advocated:

“The only way to distribute a program … is as raw Source Code”

This was not about “is Open Source good?” – this was *in addition to* making source available. The question was: should you send people a copy of the source – or should you compile / package binaries (one-click applications) for people to download and “just run”?

The debate seems to be dead (finally), with the world coming down on the side of practicality, rather than theory/ideology. I’m not entirely happy with that – but it always felt obvious to me that it would go that way. I think the App Store in particular has gone a long way to “proving” it once and for all: people who want apps … want apps. They don’t want source code. Even if having the source would sometimes help.

2012: a worthy project that’s dead and useless

Today I ran into a tool that concretely demonstrates the futility of the “only source code is correct” argument: SLOCcount

The project as it stands is unusable unless you happen to be running one of the two linux distros where people have built the binary – or you’re willing to waste anything from “hours” to “days” of time “configuring” the app.

(with a normal app, that “hours of time” is replaced by “0.1 seconds it takes to double-click the app icon”)

This is a simple command-line tool. To run it, you must:

1. Download the source
2. Read the usage instructions
3. Ignore the usage instructions. Start again with the “installation” instructions
4. Install “make” (takes 0.5-3 hours)
5. Learn how to use “make” (takes 1-3 days, if you don’t already know it)
6. Debug “make” (takes 0.5-3 hours)
7. Re-write the config files for the project so that they will work with “make” (takes 0.5 hours)
8. (probably) install a new compiler (takes 0.5 hours)
9. (probably) install a new linker (takes 0.5 hours)
10. Cross your fingers, pray to whatever Gods you believe in, sacrifice a lamb, etc
    • In case you’re unfamiliar with “make”: it typically doesn’t work on any computer except one identical to the one where it was originally tested, so you have to go through and keep tweaking and fixing until it works. Kind of. There’s no checks-and-balances – so you NEVER ACTUALLY KNOW if make has worked, you just have to hope.
    • Finally: go to Step 1 of the usage instructions, and try to use the app

No wonder people don’t use it. No wonder people don’t update it, even though it’s “Open Source”. No wonder this – otherwise useful tool – is effectively dead.

Fundamental problem?

OK, so the straw-man example above mainly comes down to:

“make” is the world’s worst configuration tool

SLOCcount was probably killed by the choice of bad tools, as much as anything else. But – how much choice did the author have, really?

The problem is – and this is the interesting point of this blog post:

(in general) Source Code does not fully describe a program; it merely describes “SOME OF the internals of a program”

To create an actual usable program you need something like (off the top of my head, I think this is correct?):

1. Source code
2. Programming language definition
3. Operating System (OS)
4. Compiler program
5. Programming language libraries
6. OS-specific Linker
7. Launch wrapper

…where the final output of step 7 is collectively known as “an application” (or just “an app”).

The folks who used to argue that all code should be distributed as Source tended to use arguments about the “value” of Source Code, as if it were a valid substitute for all the above items. It was never a *substitute*, although getting the output AND the Source would have been better than the tradition of only receiving the output.

Of course, even better would have been: receive all 8 items above (all the things necessary to make the app, and the app itself).

A brighter future

And so … if you’ve ever wondered what’s inside package-management sytems … take that list of 7 items above, and go revisit your favourite system of choice.

And … bear in mind that all the above things can have complex version dependencies – e.g. “only works with library A, version greater than 2.3, but less than 2.6, or with library Aa version 7.99 exactly”. A package-manager has rather a lot to handle…