programming project management

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…

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

Raw source code is indeed bad, but I’ve found that source RPM packages are nice when you want the source for ideological or practical reasons. They not only specify the build and environment dependencies but also the (automated) processes required to build your own binaries.

Agreed. Although … I’ve had many more “bad experiences” with source RPMs than normal ones, over the years.

OTOH … I dumped RedHat approx 8 years ago, when I discovered that RPM could *permanently corrupt* a kernel, to the state that it was impossible to build a new kernel.

(you have to wipe the hard disk and re-isntall from external media).

That’s a catastrophically bad package system :). I moved to Debian and never looked back (I’ve found DEBs to be considerably more robust than RPMs – the system’s rules are enforced far more rigorously, and tend to be far more accurately written / maintained)

“brew install cloc” :)

I don’t enjoy building/compiling software that is distributed as code either. When you think about the number of hours wasted re-compiling the same packages over and over again on linux distributions that use src packages… bleah. The only thing it does is keep the build environment tested and running. And as you’ve seen, once the build environment for a piece of software deteriorates, it’s more trouble than it’s worth to fix…

Can you remember back to when your only reasonable choice for distributing software as to give someone the source code and tell them to compile it, because you had no way of knowing what sort of architecture or distribution they could be using? So “only feasible way” becomes “best way” and best practices never change, right?

Also part of the problem is that you (and probably a lot of other people) are discounting the documentation and the make process as not part of the open source project. If the project doesn’t build well on some other distribution, that’s probably because no one has sat down to try it and then reported back what they needed to do to get it working. If no one’s done that, the people on the project are unlikely to become divinely inspired to build for that distribution/platform.

So you left out
11. Contact the people responsible for the project and tell them what you had to do in steps 1 through 10 so that the next poor schmuck gets the advantage of your pain and suffering.

Comments are closed.