James talks about Runtime/Development Time and I can’t help adding my 2 cents. In Kolibri, we opted for a simple ‘lockdown’ instead of image stripping (or, IMO the better way, reconstructing a deployment image from the bottom up by starting with a minimal image and adding your code). It’s just not worth it.

When we start with a basic wxSqueak image, our installer ends up at around 11Mb. That’s a fully self-contained executable distribution–the wxSqueak VM (with libraries statically linked in) is part of it. Looking at what some other environments need, this is acceptable. Not great, but acceptable.

So, when preparing the image for the installer, we pop up a Squeak project with some interesting statistics (Squeak on Win32 wants a window whether it runs ‘headless’ or not - the window in the latter case appears in the task bar’s "mini icon area"), and save the image in the middle of a script that starts up the main wxWindow. It runs in ‘deployment mode’ (which means that it’ll crash and write a trace file on an exception rather than opening a debugger), but all the development tools are there and readily accessible - not really a big issue for an Open Source project

With applications becoming more and more complex, they’ll load in more and more libraries, tools, etcetera. Stripping out the development tools quickly becomes an exercise in futility (preventing access to them is a different thing - Squeak has a utility method somewhere to do that in case Open Source isn’t your thing).

. The bytes saved are marginal, but the features you remove (like live updates, engineering access to the innards of a running application/server, etcetera) aren’t.