One such advantage I noticed is that Squarespace users can log in from any page on their blog, just by pressing the escape key.

By default, WordPress requires that you either memorize the admin page URL, or list an ugly “Login” link i the blog’s template. I never liked the idea of having a login link for a site that only I should ever be logging in to, so for years I have omitted the login link from my site.

This means that when I’m reading comments or something on my site, and am not logged in, I have to do a silly dance before I respond or moderate a comment:

1. Go to the URL bar in my browser.
2. Change URL to /wp-admin/
3. Enter the proper login credentials.
4. Hit back button to get back where I was.
5. Reload the page to see the comment form as a logged-in user.

This ends today. My QuickLogin Plugin for WordPress is a drop-in solution that, when activated, gives your WordPress blog the same delicious escape-key behavior that Squarespace offers. Now when I am browsing my own blog and want to log in, I just press the escape key. After I authenticate, I’m automatically returned to the reloaded page I was viewing.

1. Navigate to a .app file in the Finder, e.g. /Applications/Mail.app
2. Control-click the app icon and select “Show Package Contents”
3. Navigate to Contents/Info.plist
4. Open with a plist editor or your favorite text editor.

These files advertise a number of interesting attributes including the application’s official version and copyright strings. They also include important clues to the system about what kinds of files the application knows how to read and write, and what its minimum system requirements are.

Minimum System Requirements

Declaring the right Info.plist values not only allows a developer to control which operating systems a product should run on, but which of the application’s architectures should be considered for a particular operating system. For example, Black Ink uses a number of keyed values describing its requirements:

	<key>LSArchitecturePriority</key>
	<array>
		<string>x86_64</string>
		<string>i386</string>
		<string>ppc</string>
	</array>
	<key>LSMinimumSystemVersion</key>
	<string>10.4.0</string>
	<key>LSMinimumSystemVersionByArchitecture</key>
	<dict>
		<key>i386</key>
		<string>10.4.0</string>
		<key>x86_64</key>
		<string>10.6.0</string>
		<key>ppc</key>
		<string>10.4.0</string>
	</dict>

Notice the fidelity of some of these options. Black Ink is an application that is compiled with binary code for three separate architectures embedded into it: 64-bit Intel, 32-bit Intel, and 32-bit PowerPC. In order to give the user the best possible experience after they double-click the application icon, the system consults the Info.plist values to determine which binary is most appropriate to load on the current system.

The options for Black Ink start by indicating that all things being equal, it prefers to run as 64-bit Intel, but will settle for 32-bit Intel or PowerPC in a pinch. Next, it conveys that it should not be run on any operating system earlier than Mac OS X 10.4. Finally, it adds an additional restriction by architecture, stating that in the case of 64-bit Intel, the system should consider Mac OS X 10.6 the minimum required OS.

Why so picky? For example, Mac OS X 10.5 will run on computers that are new enough to support 64-bit Intel code, but the 10.5 operating environment itself doesn’t contain enough compatible libraries to make it very useful to a full-featured Cocoa application. So we need to convince the 10.5 system to ignore our 64-bit Intel code. And this is how it’s done.

Embedding Info.plist

This is all well and good for applications, but what about other code that may be run on a variety of hardware and operating systems? In particular, command-line tools do not come in the same bundled-folder format that applications do. Fortunately, Apple thought of this when they implemented support in their developer tools for embedding the contents of an Info.plist directly into the binary itself. You just have to pass the Info.plist path to Apple’s linker tool when it’s constructing your binary file. (Thanks to Paul Kim for reminding me of this functionality). What this means in practice is adding arguments like this to your Xcode target’s “Other Linker Flags” build setting:

-sectcreate __TEXT __info_plist $(INFOPLIST_FILE)

This instructs the linker to crete a new text segment named “__info_plist” in the resulting binary, and to fill it with the contents of the referenced Info.plist file. To make sure the INFOPLIST_FILE expands correctly, just make sure you set it in the separate build setting for identifying the Info.plist (the one you’d normally use in an app, and that is just ignored by default for a command-line tool target).

I brushed up on all this information because I wanted to help ensure that some recent work I did to create a standalone MultiMarkdown tool would be backward compatible with older systems. This required adding an embedded plist much as I’m describing here.

(Note: I have gotten some feedback to the effect that the __info_plist segment’s minimum system version requirements may not actually be consulted properly on Mac OS X 10.5. This would be a bummer, and in fact sort of reject the whole point of embedding the Info.plist in this case. I’m going to see if I can confirm whether it doesn’t in fact work.)

You could technically embed all kinds of stuff in the binary, with different section names. But the contract in this case is that when Mac OS X is determining information about an executable, it will consult the bundle’s Info.plist file, if it happens to be an executable in a bundle, or the binary’s __info_plist segment, if it happens to have one.

Another common reason for needing to embed Info.plist information into a standalone binary is if you are using Apple’s code signing mechanism to sign an individual binary tool. Code signing uses information from the Info.plist of a product, and in the case of standalone binaries, the only product-cohesive place to put this is in the binary itself.

Examining Binary Info.plists

After you’ve performed the magic above, you’ll probably be keen to inspect your command-line tool’s Info.plist to see if it worked. To do this, you can use the otool command from the Finder. If you run otool with the “-l” option to show all load commands, it will include the load command that identifies the __info_plist segment. Use grep to narrow it down to the part you’re interested in:

otool -l ./yourTool | grep info_plist -B1 -A10

Any results at will confirm that there is Info.plist information in the binary, but how does it look? The “-s” option to otool lets you examine the contents of a specific segment in a binary, but it dumps it out as hex code. Fortunately, another system-bundled tool called “xxd” is capable of easily converting between hex-dump and text formats. As it turns out, some of Apple’s bundled developer tools (at least on my Mac) contain these embedded __info_plist sections, so if you don’t have a command line tool of your own to try this on, you can peek at what the “atos” tool has to say for itself:

otool -s __TEXT __info_plist /usr/bin/atos | xxd -r

In Summary

Info.plist values are important for conveying information about your product, from the crudest, most obvious stuff like version number, to the most nuanced details such as which architectures are supported. Knowing how to specify an application or tool’s requirements as precisely as possible will ensure that the product performs optimally on whatever supported system your user happens to be using. I’ve barely scratched the surface here with a few common deployment keys that control execution behavior on Mac OS X. Be sure to skim Apple’s Information Property List Key Reference to see if there are other useful bits of information you can share for your application or for your command-line tool.

On the other hand, I wrote an alternative years ago, called Usable Keychain Scripting. Its main advantage over Apple’s implementation is that it is (or at least, was) enormously faster. Today I updated the app to be 64-bit compatible and to fix a pernicious bug in which the password value returned for a keychain item would sometimes have garbage appended to the end of it.

Download Usable Keychain Scripting 1.0b4

This is not a supported product, and your success with it may vary. But it has been very handy in the past for me, and hopefully it will come in handy for you if you need to script the keychain.

When I first saw the Lion version of iCal, my eyes were drawn to the obnoxious bits of paper that cling to the top of the window, artificially and pointlessly leaving the debris that you might find on a real-life calendar with removable paper sheets:

As Cathy Shive pointed out in her NSConference talk on user interface metaphors, the presence of junk like this in an application is at best useless, at worst distracting and detrimental to the usability of the application. I remember her saying in her talk, before Lion’s iCal had even been presented in a private developer beta, that little things like paper scraps in an application are particularly annoying because she always wants to try to pick them off just as she would with a physical object.

Lion has given me the opportunity to empathize deeply with that concern. I hate those cruddy paper bits, and I can’t pick them off! Or can’t I?

To clean up your copy of iCal on Lion:

1. Select the iCal application in the Finder and press cmd-D to duplicate (make a backup, for safe keeping).
2. Control click the application icon and select “Show Package Contents.”
3. Navigate to Contents/Resources/
4. Select “CanvasTopTile.png” and open it up in Acorn or another, less attractive image editor. Or download my edited version and replace the original file.
5. Select the paper bits and “clean them up” by deleting them.
6. Reopen iCal, and bask in the glow of your clean white calendar:

Granted, this only fixes the paper bits. You’re still stuck with that horrendous tan leather toolbar. But at least that doesn’t beg to be picked at. It’s worth noting that the tan leather can also be tweaked by editing a variety of other image resources in the bundle. It’s trickier because many of the graphical components of the toolbar are designed to blend with the leather background, so you’ll end up having to change quite a few of the images.

I’m reminded of another great observation Cathy made in her talk: when you make very stylistic choices like this for a user interface, you dramatically increase the variety of reasons that the customer can be repulsed by the design. What if I don’t like leather? What if I don’t like tan leather? What if I prefer a running stitch to an outline stitch? You can argue that matte grays and subdued color gradients may invite the same controversy, but there’s a reason they are so common in user interfaces: because they’re far less likely to distract from the form and function of the application itself.

Addendum: Updating the iCal code signature. Thanks to rentzsch and daagaak on Twitter for pointing out that editing the resource will break the “code signature” on the application, put there by Apple to assure users that the application 1. Was developed by Apple, and 2. Has not been modified by anybody but Apple. You can re-sign the application after tweaking it, to put it back into a  ”signed” state, albeit not by Apple. Hopefully this will prevent it from prompting you all the time about approving connections to services like MobileMe. From the Terminal:

 codesign -f -s - /Applications/iCal.app

This reveals how little things like tweaking an application’s resources have wider-reaching consequences than they used to. I’m pretty sure you won’t miss any functionality in iCal by using a self-signed copy of the app vs. an Apple-signed version. But I could be wrong!

Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.”

The trick relies on a implementation detail of the system, that allocated blocks of memory will always be aligned at 16-byte offsets into the address space. This leaves a bunch of numbers that can be represented in 64-bits, that cannot reasonably be assigned to any other object. To understand this practically, imagine that your neighborhood’s postal addresses are all assigned at offsets of 10: 30, 40, 50, etc. A clever postal service could institute an addressing system that uses an “invalid” address such as “31,” to perhaps mean “deliver to 30 with expedited afternoon delivery.”

Cleverness like this with encoding extra information in memory addresses is a time-honored tradition. I recall the days of 24-bit addressing on classic Mac OS, where Apple, and many 3rd party developers, observed that the high 8 bits of a typical memory address could be tweaked and used to store additional information, because the system would never reference those bits when resolving a particular address.

In those days, using those extra bits turned out to be a pretty significant headache when 32-bit addressing ultimately came along, and lots of code had this “crufty” treatment of addresses to clean up. Perhaps it is a memory of situations like this that caused Jon “Wolf” Rentzsch to comment in his bookmarking of the above-referenced blog post:

“Every tagged pointer has its lowest bit set, hence tagged pointers are odd integers” Strikes me as a really bad idea. [Emphasis Mine]

But the difference now, in this scenario, is the “cute hacking” is all being done by a central power, with and in terms of opaque objects that only Apple has the authority to change. I think this is a really clever hack that will undoubtedly lead to some serious performance gains in Lion and beyond. It’s hard to imagine specific outcomes that will make Apple regret adopting this strategy. In the worst case scenario, an addressing system of future Macs will not leave any “spare” bits to be exploited, so the runtime will simply revert to its previous behavior.

I encourage everybody to upgrade to Lion. I’ve been running it for months in pre-release form, and even while the bugs were being ironed out, I found the experience of using it to be (mostly) superior to running 10.6.

If you want a more detailed analysis of Lion’s features, sit down with a tall glass of your favorite beverage, and read John Siracusa’s famously detailed review. If you’re looking for a quicker overview, check out Jason Snell’s Macworld review, or my developer buddy Matt Gemmell’s guest appearance at the Guardian UK.

Supported Systems

We have known for some time that Mac OS X Lion would drop support for a number of Macs. In particular, all Macs that do not support Intel’s 64-bit memory addressing are not qualified to install the OS. But I was curious to know a bit more about how Apple makes this determination when, say, a user is browsing the Lion “product” in the Mac App Store.

As I described in an an earlier post, you can learn a lot about a product in the App Store by inspecting the HTML that makes up the product page, and by manually loading the references resources. In the case of Lion, the “Buy Now” button contains a number of parameters intended to inform the Mac App Store client about whether a sale should be allowed, and what some of the conditions of sale are. In the case of Lion, here is the raw HTML:

<button is-rental="0" dk-id="30" is-pre-order="0" preflight="http://a5.mzstatic.com/us/r1000/
065/Purple/cd/82/29/mzm.tvvarwmu.pfpkg" item-name="OS X Lion" bundle-id="com.apple.InstallAssistant.Lion" version-string="10.7" buyparams="productType=C&amp;price=0&amp;salableAdamId=444303913&amp; pricingParameters=STDRDL" large-icon="http://a4.mzstatic.com/us/r1000/083/Purple/00/00/00/ lion.170x170-75.png" is-install-button="0" is-update="0" check-is-osx-server="http://r.mzstatic.com/static/isOSXServer.pfpkg" is-free-download="0" adam-id="444303913" metrics-leaf="1" metrics-loc="Buy" class="button-area" aria-label="Install, OS X Lion, Free">    <span class="price">Install</span>    <span class="left-cap"></span>    <div class="inner"><span>Install</span></div>    <span class="right-cap"></span>  </button>

If you load the “preflight” URL content from the command line, and unarchive it with the “xar” tool, you get a few files including a file called “Distribution”:

% mkdir TestFolder; cd TestFolder
% curl -O http://a5.mzstatic.com/us/r1000/065/Purple/cd/82/29/mzm.tvvarwmu.pfpkg
% xar -x -f mzm.tvvarwmu.pfpkg
% more Distribution

Inside you will see a number of constant constraints such as hostArchitectures=”x86_64,i386″, but also more nuanced tests that, for example, test the current computer’s motherboard model ID with a fixed list of allowed values. Presumably this will prevent the App Store from allowing (without some hacking) downloading Lion and installing it, for example, on a Dell PC that happens to meet the ostensive hardware requirement.

Perhaps the most heartwarming bit of code in this relatively complex document is a small function call from the start of the test for whether the install should be allowed on this computer:

function isSupportedPlatform(){

        if( isVirtualMachine() ){
                return true;
        }

It has already been announced that Lion 10.7 will finally support virtualization, e.g. with the use of products such as VMWare or Parallels. This install-time test seems to drive home how true that is.

One particularly vexing issue is the question of whether an app that is already on your Mac is “installed” or not in the eyes of the App Store application. Dan Moren of Macworld presents a great summary of the situation.

In a nutshell: if App Store thinks an app is installed, it’s impossible to buy it. If App Store thinks an app is installed, but it’s not really from the App Store, there’s a risk of repurchasing something that you already own a license for.

What this brings into focus is the very problematic nature of that small multi-purpose button the App Store, that allows for either buying an app you don’t own, or for linking to an app that you do own:

As it happens, the App Store user interface is implemented primarily in HTML. Using a surprisingly under-appreciated feature of WebKit, the omnipresent web inspector, I was able to look behind the scenes at some of the interesting HTML that supports this Buy/Installed button. For Black Ink’s button above, this is what I see:

<button version-string="1.2.3" is-rental="0" is-pre-order="0" 
   buy-params="productType=C&amp;price=24990&amp;
                 salableAdamId=402376365&amp;pricingParameters=STDQ"
   preflight="http://a1757.phobos.apple.com/us/r1000/
                 057/Purple/e7/fb/12/mzm.gytejomu.pfpkg" 
   is-install-button="0"
   large-icon="http://a1.phobos.apple.com/us/r1000/013/
                 Purple/74/8c/bb/mzi.wpgwhzjm.170x170-75.png" 
   is-update="0" item-name="Black Ink" adam-id="402376365" 
   is-free-download="0" bundle-id="com.red-sweater.blackink.macappstore"
   metrics-leaf="1" metrics-loc="Buy" title="Buy, Black Ink: $24.99"
   disabled="" its-bound="iTSBuyButton">
   <span class="price"></span>
   <span class="action">Installed</span>
</button>

Formatting XML, even with a cool app like MarsEdit, is still a huge pain. I’ve tried to make it readable here so you can enjoy some of the interesting tidbits in this markup. There are some tantalizing attributes like is-update and is-free-download, which might lead some of us to imagine whether a paid update may be a configuration away. There’s some hocus-pocus sale parameters which surely mean something to iTunes on the other end of the network connection, and there’s a link to the application’s pretty icon.

Wondering about that global web inspector trick? Any application that has the NSUserDefaults key WebKitDeveloperExtras defined to YES receives access to the sexy WebKit web inspector that is so awesomely utilized in Safari. You can define this for the App Store app by running this from the command line in a Terminal window: defaults write com.apple.appstore WebKitDeveloperExtras -bool true Make sure you quit App Store before you run it, then relaunch it.

But What’s Really Interesting…

All of this is fun to poke around at, but what I find fascinating is the preflight attribute, which points to a mysterious asset on the web. This “.pfpkg” file, which as it turns out is simply xar archive format, contains an interesting file called Distribution, an XML-formatted file that contains rules and attributes for how the application should be installed, how the App Store should locate an “Installed” app on the user’s Mac, etc. I’m not going to the trouble of color formatting this one, but have a look in a separate window:

View Black Ink’s Preflight Rules

I believe the format for this XML document is either completely or partially tied up in the way the Mac OS X Installer packages work. I have been lucky enough in my lifetime not to have to do all that much with installer packages, so I am not sure exactly how to parse the whole file. It’s clear however, that the file contains information about the application, its version and bundle identifier. It also contains similar information for each of the frameworks that ships with the application.

But the interesting stuff begins below that, where we see flags such as customize=no, and an alluring volume-check, which seems to be terminology from Installer-land that alludes to installers being able to determine whether the targeted volume is suitable for installation.

As you can see, the Black Ink preflight document is pretty boring. No, there is no customize flag. No, there are no interesting volume-check attributes, aside from the fact that this requires 10.6.6, like every other dang app on the Mac App Store. Yawn.

I decided to take a look at another application in the App Store. One that, if anything was going to be interesting, surely this one would be.

One of the things I keep reminding myself, when trying to deduce what Apple’s plans are for a variety of “would be nice” features in the App Store, such as upgrades, trials, etc., is “how does the current setup inconvenience Apple itself?” Many of Apple’s apps are shipped for free with the system and are updated for free along with OS updates. But others are not: iLife and iWork are sold in a bundle with no upgrade pricing, and other apps such as Final Cut Pro and Logic have complicated pricing, which perhaps explains why they aren’t on the App Store at all. But Aperture falls right in the middle: fairly straight-forward pricing, but it’s expensive enough that they offer reasonable upgrade charges for users who already own a license. Maybe there will be something interesting in these preflight rules:

View Aperture’s Preflight Rules

The file length alone indicates that something slightly more complicated is going on, and my eyes are drawn immediately to the JavaScript code in the middle of the document, and a function named shouldAllowPurchaseAndInstall(). Hmm, you mean there’s a choice? Usually what happens when you click “Buy” in the App Store, is you are prompted to login if necessary, and then you are warned that this is going to cost you money, it’s a big deal, etc. But as far as I can tell, a side-effect of clicking Buy in the App Store is that the aforementioned volume-check is also run on the target system, giving App Store one last chance to bail out of the process before something unfortunate is done.

In Aperture’s case, you can see by the nicely commented script that it takes care to only allows the Buy order to go through under certain circumstances. In making this determination, it checks all of the installed copies of Aperture on the system, looking for signs of App Store purchase such as the presence of a “_MASReceipt” inside the app. It also takes care to differentiate between different versions of Aperture, failing in some cases with a specific string that is presumably passed along to the App Store user.

If you’ve managed to follow along this far, you’re probably putting two and two together and realizing that the technology exists today for applications to avoid at least one of the problems mentioned above: the inadvertent redundant purchase that may happen when a user thinks it’s safe to buy an app, because “they already have a license.”

The preflight XML document may be documented in part or in full in the context of Mac OS X Installer Packages, but as far as I know, none of this is documented in the context of the Mac App Store. I do not know if any 3rd party developer has been invited to use this technique, or if it’s something we could just put into our installer packages somehow on our own, and hope for the best.

What’s most interesting about all this is that there is clearly an infrastructure in place for allowing a wide variation of behaviors, all centering around the multi-purpose Buy/Installed button in the App Store. I would like to see the volume-check options documented and made explicitly available to developers, so that we can help prevent unwanted redundant purchases on the part of our customers. I would also be curious to know if other hooks are in place or are planned to for example allow developers whose apps do show up as installed to second-guess that assumption and encourage the App Store to provide a “Buy” option to customers.

Where we’re going, only Apple knows, but I thought the details I discovered in this nook of the App Store app offer some interesting clues. I’m also interested in sharing this because I believe that the more we understand about the App Store install process, the better we’ll be able to offer meaningful enhancement requests to Apple. “Support paid upgrades” and “Allow variable behavior depending on installed apps” are fine feature requests, but if we are able to put them into the context of what Apple already knows is possible, they may be more likely to get implemented.

If anybody else has delved into the underbelly of the App Store and has observations to share, please do so in the comments, or with a link to your own blog article on the subject.

This functionality is based largely on the great work of the iMedia project, which was spearheaded by Karelia to replicate Apple’s own ubiquitous media browsing interface, some variant of which is available in Pages, iWeb, Mail, etc.

iMedia has been around for a while, but in the past year or more it has been undergoing a significant overhaul as its primary developers gear up to release the official 2.0 milestone. I have been involved in the 2.0 project for a long time now as an “early adopter,” using MarsEdit as a testing ground during the beta phase, and taking (mostly!) only the refined and polished aspects of the product for the final MarsEdit 3.0 release.

We are still ironing out some of the kinks, especially in parts of the project that were not tested in MarsEdit. One of the cool new features is support for the Flickr photo-sharing service. Like MarsEdit’s own Flickr-browser, it shows thumbnails of images on Flickr, and lets you treat them more-or-less like ordinary image files that you’d find on your computer.

Things get a little bit complicated when a user selects and drags one of these Flickr image thumbnails to another app, such as the Finder, or Photoshop. Since the image lives in the internet, and not on the local hard disk, it is not something that can be popped over to the application in an instant. Instead, a progress dialog comes up while the image is downloaded to the disk, and then the local copy is passed to the receiving application.

I try to contribute back when possible in the form of bug fixes and architectural feedback. Some of the work I did for iMedia 2.0 involved updating its drag-and-drop functionality to take advantage of new features in Mac OS X 10.6. In the process, I became a sort of de facto expert on handling dragging, which is a shame, because we could sure use a real expert, instead!

The other day, an issue came up that relates to the dragging of Flickr files. If the download is taking a while, and the user tries to cancel, mouse clicks are apparently ignored and they are stuck with the progress dialog above. I agreed to look into the issue, but there was just one problem: my network is too fast! Whenever I try to drag a Flickr image to another app, it’s done within a couple seconds, and I don’t have time to play around with clicking the cancel button.

If only I could get a really slow connection to Flickr, then I could easily test this. In the old days of Mac OS 9 or earlier, I may have resorted to plugging in a slow modem to simulate the experience of the less bandwidth-fortunate. In Mac OS X however, I can take advantage of the advanced firewall software that comes bundled with the operating system, and which allows me to configure “traffic shaping” policies on the traffic coming in and out of my computer. I found a great hint from Macworld that got me on the right track.

My goal is to cause Flickr downloads to be artificially slow. In order to achieve this goal I need to find the specific web address that the downloads come from. To do this, I use the standard tcpdump terminal utility, which also comes bundled with Mac OS X:

sudo tcpdump -Atqp -s 0 -ien1

The only part you may want to change is the bit at the end that says “en1″. Depending on the network interface you’re using, you might want en0 or en2 instead. With this running in the terminal, I go back to iMedia and start downloading Flickr files. This lets me see what the addresses of those files look like, and I discover the pertinent host name is “farm5.static.flickr.com”. Using the information I gleaned from the Macworld article, I set up the following firewall traffic shaping rules:

sudo ipfw pipe 1 config bw 15KByte/s
sudo ipfw add 1 pipe 1 src-port 80 src-ip farm5.static.flickr.com

Translation?

1. Create a pipe (you might prefer to call it a “tube”). A pipe is an artificial pass-through which can be configured to slow down, block, or otherwise alter the network traffic that goes through it.
2. Configure the pipe to limit bandwidth to a crawling 15KByte/s.
3. Configure all traffic coming from port 80 (the standard HTTP port), and originating from a specific hostname at Flickr, to pass through that pipe.

As soon as these commands are executed, the pipe is in place, and Flickr download speeds are brought to screeching halt. I can now debug the issue with the download dialog and the cancel button patiently and curiously, instead of racing to try clicking the button while I still have the chance.

When I’m done debugging, I definitely want to delete the pipe, so that download speeds go back to normal:

sudo ipfw delete 1

Mucking around with the built-in firewall on Mac OS X is not for the extremely faint-of-heart. This is why all the commands listed in this entry require “sudo” superuser privileges. Yes, you could seriously screw up your computer’s network connection if you do something wrong. But if you are the type of person whose work requires you to test and debug network related tasks, this traffic shaping functionality can be a real asset when it comes to mimicking the network environments of other people.

Addendum: I should have known I might be doing it the hard way, as usual. Clint Ecker reported on Twitter, and several folks in the comments below, that speedlimit, a Mac OS X preference pane, gets the job done in a much friendlier manner.

WordPress is licensed under the terms of the Gnu Public License (GPL) which, in a nutshell, stipulates that you are free to use the software however you like, but if you make changes and distribute those changes, then you must share those changes under the same terms. This simple, radical restriction means that you are prohibited from taking a GPL project and incorporating it with a closed-source project.

Violating The GPL

Violating the GPL is easy. All you have to do is write some code, intermingle it with some GPL code, distribute a changed copy of the original, and refuse to share your contributions. Bam! You’re toast. Assuming the original authors discover your violation and decide to pursue a resolution.

Once a violation occurs, it might be settled privately, or could escalate to legal court procedures. But the most obvious form of resolution is for the author of the changes to release their code to the public under the terms of the GPL.

Depending on how much code you “mixed” with the GPL code, this could mean only a small portion, or it could mean the entire source code of your project. This so-called “viral nature” of GPL is what scares the bejeezus out of companies, large and small, who fear the consequences of having to give up their own intellectual property to the public.

The terms of the GPL sound pretty simple at first read, but due in part to the epic consequences of a violation, there has been a great deal of debate and uncertainty about what legally constitutes a violation. Most of the debate seems to boil down to two questions:

1. What counts as a change to the original product?
2. What counts as distribution of those changes?

If you can legally justify that your additions to a GPL project either don’t change or derive from the original product, or haven’t technically been distributed, then you are not subject to the restrictive terms of the license.

Take GIMP, the popular GNU-licensed image editing application. The application supports plugins, analogous to the types of plugins you might find for the commercial, closed-source application Photoshop. A savvy developer may argue that a plugin doesn’t meet the criteria of changing the original application, because the original application still runs in its unaltered condition whether the plugin is there or not.

But promoters of the GPL take the position that plugins, by nature of being loaded into the same code space as other GPL code, do constitute a modification of the original, and are therefore subject to the terms of the GPL. As far as I know this is not a question that has been well-tested in courts.

Let me take a moment to make this abundantly clear: I respect the rights of authors to license their software under whatever terms they choose, including the GPL. In my opinion, all the legal mumbo jumbo ceases to matter once the original author’s intentions are made clear. So if the author of GPL-licensed code clarifies to me that it cannot be run on Sundays, then their GPL means it cannot be run on Sundays. But this is one of the problems with the GPL: its terms are not often understood, even by the authors of GPL-licensed code.

WordPress Themes & Plugins

WordPress supports two explicit forms of extension, each of which may affect the appearance and functionality of the product. Themes tend to work as a “skin” for the appearance of a blog, while plugins tend to introduce completely new features. Since plugins in WordPress are analogous to GIMP or Photoshop plugins, it would stand to reason that they would also be covered by the terms of the GPL. But what about themes?

Themes have been controversial in the WordPress community, as a few commercial business models have sprung up to take advantage of bloggers’ desires for high quality themes at an affordable price. One approach is to distribute “free” themes that contains commercial ads. So you might stumble upon the perfect theme for your blog, only to learn that the glaring “Brought to you by Hostess Cupcakes” line near the bottom of your page cannot be removed.

But the terms of the GPL, if themes are covered, would require that end users be granted the legal right to modify and redistribute their own copy of the theme. Zap the sponsorship, reupload to your site, and you’ve got a free, high quality theme with no ugly ads.

Today, Matt Mullenweg of the WordPress project announced his lawyer-supported opinion that themes are partly covered by the GPL:

I reached out to the Software Freedom Law Center, the world’s preeminent experts on the GPL, which spent time with WordPress’s code, community, and provided us with an official legal opinion. One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.

If you’re starting with the understanding that WordPress itself is GPL, and WordPress plugins are GPL, then it’s not so much extra hay on the camel’s back, to also clarify that its themes are to some extent GPL. But it got me thinking again about my own blog, and about the restrictions the GPL imposes on the kinds of things I can do with the software that runs it.

GPL Stifles Participation

Now for the most controversial point of this article, where I suggest that the GPL does more to harm collaborative development than it does to help it.

For the purposes of this argument, let me reduce all the source code in the world down to three rough categories. I recognize I have omitted some classes of license here, but for the sake of argument, most projects fall into these camps:

1. GPL code. Changes may be distributed only in other GPL products.
2. Liberal-licensed code. (MIT/BSD/Apache/etc). Changes may be distributed anywhere. Appropriate origin-attribution may be required.
3. Closed-source code. May be distributed only by the copyright owner and other explicit licensees.

Now, there are a few people in the world who, for political or philosophical reasons, will only participate in a GPL project. And for comparable yet opposite reasons, there are some who will only participate in commercial, closed-source projects. But I propose that the vast majority of developers will participate in any project that is advantageous to them.

So let’s imagine a representative, run-of-the-mill developer who is working on a project that falls into each of these three camps. If this developer is not radically committed to their own project’s license, they will naturally look to outside resources in order to bolster the success of their own work.

As the developer evaluates communities to participate in, they must evaluate the legal impact such participation will have on their own project. The closed source communities are, by definition uninviting to outsiders. GPL communities are open and embracing of other GPL developers, but generally off-putting to liberal-license and closed-license developers. Only the liberal-license communities are attractive to developers from all 3 camps.

I know what some of the GPL-enthusiasts are thinking now: “leeches don’t count as community.” Many GPL developers take comfort in the fact that their hard work can’t be quietly taken and incorporated into a commercial product, without any payback of time or money to the original project. But you’re piloting an open source project, and the first step of building a community is to get people in the door. Liberal licenses? Whoo-eee do they ever get people in the door.

If you operate from the presumption that great developers love to build great projects, the first step in any successful open source project is to get as many great developers in the door as possible.

It’s Your Party

Yes, this is just me and my crazy theories. I haven’t done exhaustive research to prove that liberal-license communities thrive more than GPL communities. But the anecdotal examples are staggering. The very foundation of Mac OS X, the operating system through which I’m typing, is thanks to the liberally-licensed FreeBSD operating system.

Looking over to the right of my screen, I’m watching this sentence appear in a live web preview as I type, thanks to the WebKit project, whose liberal license makes it compatible with closed source projects such as Safari, as well as open source efforts such as Google’s Chromium project.

For years, the problem of a generic HTTP client library that runs on every major platform has been addressed by libcurl, whose liberal license has caused it to be embraced by countless companies and projects.

The popular Subversion source control system’s liberal license enabled Sofa, a commercial software business to contribute value to the community with its extremely polished, award-winning client application. Meanwhile, the newly popular distributed source control systems presents three major choices: git, Mercurial, and Bazaar. All are restricted by the GPL-license, and therefore none is likely to inspire development of a Versions-caliber client.

I’ve touched the tip of the iceberg, and yes I’ve neglected to mention some GPL success stories such as Linux, MySQL, and gcc. These communities have thrived to some extent because the passions of the GPL community are strong, but we can’t know whether their success is in spite of the restrictions their license places on participation by the broader developer community.

Speaking of GPL succeses, WordPress is itself an example of monumental success. All of its developers have something to be immensely proud of. But whenever I am reminded that WordPress is GPL, my passion for it takes a bit of a dive. I’m more comfortable with the true freedom of liberally-licensed products. If a liberally-licensed blog system of equal quality, ease of use, and popularity should appear, my loyalties to WordPress would not last long.

It’s your party, and you’re entitled to write the guest list. But take a look around the room: not as many folks as you’d hoped for? Liberally-licensed projects are booming. Speaking for myself, a developer who has been to all the parties, I’m much more likely to pass through the door that doesn’t read “GPL Only.”

In the wake of his high profile MacHeist debut, Gus announced something new today which is decidedly less consumer-oriented (though if it takes off, it could certainly have wide-reaching consequences). JSTalk is Gus’s JavaScript-based answer to what he sees as outdated and clunky about AppleScript, Apple’s preferred scripting language on the Mac.

For starters, Gus’s JSTalk provides syntactic sugar on top of standard JavaScript in order to give it some comfortable Objective-C style conveniences. Then, he provides a teeny bit of source code that any application can embed in order to respond to incoming JavaScript commands. This results in a scenario where an Objective-C based application can easily expose its internals to other applications, so that a script written in JSTalk can control it from another application.

I’m excited about the idea of JavaScript taking a more prominent role in the scripting infrastructure of Mac OS X. In fact, about 9 months ago I wrote some challenging words about my opinion on the matter. Responding to Apple’s impressive enhancements to JavaScript in the context of WebKit:

I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.

Since then, Apple has given no indication of pursuing a system-wide infrastructure for JavaScript scripting. So in comes Gus Mueller with JSTalk, and solves the problem. Right? Well, sort of. Gus’s idea is very cool and clever given the constraints he’s working with. Namely, he can’t easily control how every application works, or how it interacts with the system and every other application. His solution is cool, and may even be worth adding support for to your application, but it’s not as cool as a system-wide, Apple-endorsed solution would be.

Michael Tsai makes some smart observations about JSTalk, also agreeing that it’s cool, but taking exception to Gus’s claim that getting away from the rigid structure of AppleScript’s XML-based scripting dictionaries is a good thing:

I think defining the object model, e.g. using XML, is a feature. Otherwise there’s no separation between the scripting interface and the application’s unstable internal interfaces.

Taking a closer look at Michael’s post, I think I could have avoided this somewhat long-winded post by starting simply with, “Yeah, what Michael said.”