That sounds like it could end up costing literally hundreds of pennies.

You're forgetting about the significant overhead imposed by every process having its own copy of the necessary libraries loaded into memory, and having to load those libraries from disk every time an app using those libraries is started. If those apps were all using a version included with the OS, all those pages could be shared between processes and only loaded once.

But maybe people don't care about apps starting fast on their macs anymore, since a lot of them come with SSDs :)

This is a deliberate design decision in OS X in general, it's been this way for a very long time. OS X is not into the whole DLL Hell Thing.

I don't believe you. Apple includes OS standard versions of packages like SQLite and Python, are you of the opinion that developers shouldn't use them?

If they are standard and public and they work, sure. If they're not public and not standard (like MacRuby) then probably not.

I think the GP post was simply referring to the fact that a vast majority of software is 'installed' on the mac. Just drag it to the application folder. And drag it to the trash to uninstall. This almost certainly means you have a bunch of duplicated library files on your computer, but also means each app doesn't have any external dependencies.

I know Firefox bundles its own sqlite on OS X because the native sqlite is far too buggy.

For a long time (maybe even today), the system sqlite3 did a full filesystem sync every time you did an UPDATE.

As is required to make sure that there is no data loss. Yes, it is a performance loss as well, but it makes it much better with regard to possible crash scenarios.

I always package the full Python interpreter when I release applications because I am guaranteed a specific version and set of libraries. The tradeoff of a few megabytes for stability is a good one regardless of the availability of the framework.

Steve, that's a fair argument but maybe we should let developers decide. If you want to write a simple task bar app, you might not want to embed 30MB worth of extra stuff when your app could just be a few KBs.

I think that's the plan. New frameworks are usually private before they become public, right? There's a positive way to look at this.

In the absence of Apple's cooperation, a standard build of the MacRuby framework could be distributed independently, à la Growl (http://growl.info/). In this way developers could not only drastically reduce the size of their downloads, but also stay as up-to-date as possible. It would certainly seem that the license would permit it: http://creativecommons.org/licenses/by-nc-nd/3.0/us/

Yes, the App Store rules would prohibit apps with external dependencies such as that one, and at least for self-contained apps distributed through the app store, Apple themselves would be paying for the bandwidth resulting from their own poor decision, so an argument could be made for both ways.

You mean like the builds on http://www.macruby.org/, that are hosted by Apple?

Yes, that would be where you would start, but I mentioned Growl because it comes packaged as a self-updating framework.