Still getting used to feeling the ring on my finger!

Chrissa and I were married yesterday in Lincoln, MA. Everything went really well, and the weather even turned out perfectly. Really couldn’t have asked for a better day.

It was great to turn the computer back on today and find not only a number of thoughtful emails, but scattered – well – wishing from some of my Mac developer colleagues. Thanks, guys! We were both touched by these gestures.

Probably won’t be posting much if at all over the next couple weeks. It’s been a very happy May, and now it’s going to be a very relaxing May.

Brent Simmons unearthed some ancient history from 2002, when MarsEdit was just a twinkle in his weblog-dreaming eye. Check out the screen shot.

I’m writing this post in a very early development build of MarsEdit 2.0, which is the great grandchild of Brent’s original TigerEdit vision. The differences are astounding, and yet so are the similarities! We’ve come a long way, baby.

Notice the name of the product is TigerEdit? Brent has an affinity for cats, big and small. One of the first questions I had for him after taking over the MarsEdit source base was whether I should leave this funny method in the the system-determination code:

 - (BOOL) isTigerBlog;

MarsEdit supports all of the world’s most popular blogging systems, including Blogger, WordPress, LiveJournal, MovableType, Drupal, and yes, TigerBlog :)

Developers, having their entire livelihood invested in the hope that people will actually pay for their products, are naturally concerned with the problem of software piracy. Attitudes toward piracy cover a wide spectrum, ranging from nonchalant to obsessive. I was talking to Stephan Cleaves about this earlier today, and it started me thinking.

I believe the two extremes are driven more by psychology than pragmatism. The nonchalant type would rather believe that people are honest and that things will work out in the end. So they do believe it, even if it’s not true. I hover dangerously close to that mode of thinking. On the other end, the developer can’t help but fume at the thought of illegal copies of their software being used by pirates. At the sight of one illegal code making its way around the net, they envision thousands of hard-earned dollars funnelling out of their bank account and into the the pirate’s filthy chest. It’s not about money so much as the principle of the matter! They shouldn’t be getting something for nothing!

The last thing I want to do is legitimize piracy. It makes me boil, too. Pirates either have no conception of how hard we work, or else they choose to ignore it and rationalize their theft. Does our working late hours day after day, handling development, marketing, quality, and support, all on hardware we had to purchase ourselves, warrant a $25 payback from a customer who reaps the benefits? Absolutely. But are the pirates getting something for nothing? I’m not so sure.

Pirates give us a lot less than their law-abiding counterparts, but let’s be realistic. A pirating user is better than no user at all. The pirating user may serve all of the functions of a regular user, short of actually giving us the hard-earned money. These services include:

1. Word-of-mouth marketing. A pirate who is enough of a fan might even sell enough copies of your product to in some sense make up for the theft.
2. Peer-provided support. A pirate who is expert in your product may serve as a valuable second-tier support mechanism, answering questions about your product in forums or chat.
3. Market saturation. The pirate who chooses your product and shuns your competitor’s is contributing to your dominance of the market.

And the brightest possible take on these anger-inspiring hooligans? Pirates are future customers. My impression is that theft in general is an immature act. True, some folks never outgrow this particular immaturity, but what can be done about that? When a substantial number of today’s pirates do grow a moral backbone, they’re going to need software. The fact that they’ve been using your product illegally for years will probably make it among the first that they legitimately pay for.

Piracy is a real problem that we should try our best to systematically cure. This means more about teaching wrong from right than crime and punishment. Consider that many of the “rules” in our society are enforced not by threat of punishment, but by mutually agreed conventions of social correctness.

When piracy is viewed by our culture as akin to spitting in somebody’s face or letting a loud fart rip in a conference meeting, we’ll sell more of our software and have easier lives. Until then, I think a pragmatic view is best. Pirates aren’t exactly paying your bills today, but give them a few years to grow up, and they might.

Brent Simmons shares a good deal of wisdom in his post about managing a large-ish Cocoa project. In particular he’s referring to NetNewsWire, but his advice is especially pertinent to me now that I own and maintain a rather substantial number of source files that were designed and authored by Brent (MarsEdit, for anybody late to the party).

I love the emphasis on “researchability.” He points to the fact that projects of a certain size become impossible to keep in your head. So when you go to work on any particular subsection of the app, you need to be confident that you’ll find your balance quickly so you can get on with your work.

In particular, I liked the suggestion that weak binding in the form of notifications or key-value observing can be detrimental to researchability. Brent notes that the weak binding makes it difficult to mentally follow the source code, so it can be prudent to strongly bind classes that are otherwise useless without each other.

He also reminds us of some good IDE habits for maintaining code. I was glad to be reminded that the function popup in Xcode is keyboard invokable (as Brent says, “Every time you touch the mouse, God kills a kitten.”). This is very cool because with keyboard navigation of the menu you can quickly jump to a method by name.

Another tip he reminds us about is the “Open Quickly” option (cmd-shift-D). I use this feature frequently, but not in the way he describes. It’s infuriating that when you want to “open quickly,” the dialog for typing in the name of a source file doesn’t tab-complete. Imagine how much more powerful it would be if you could type “MyPic<tab>” and get “MyPictureThingyController.h”. Having to type the whole name of a file in removes most of the quickness. When I use the shortcut, I do so with the cursor inside the quotes or brackets of an include line. When invoked in this context, Xcode is smart and just jumps to the desired header file.

Update: Quentin over at Rogue Amoeba noticed this shortcoming a long time ago, and developed an Xcode plugin to address the problem. Check out Xcode Open Quicker.