I love several of the podcasts produced by Leo Laporte’s TWiT Network. He’s doing a great service to a variety of communities, and I particularly enjoy the MacBreak Weekly show, which features regulars such as Merlin Mann and Andy Ihnatko. The typical show includes a light-hearted roundup of the week’s (sometimes scarce) Mac news, and some regular features such as a weekly “picks” where show panelists are invited to share a Mac application or other product which they’ve found particularly valuable.

I have been very fortunate to have my own products picked by panelists on the show, and even by Leo himself! It’s a great honor to hear your own name spoken through those tiny earbuds, as you’re listening to the podcast. I was also flattered to recently hear Leo quote my twitter feedback to him about the excellent FLOSS Weekly.

On this week’s MacBreak Weekly, Leo chose for his pick an application called Pukka, which is a Del.Icio.Us client developed by my friend Justin Miller of Code Sorcery Workshop. Congratulations, Justin! Leo made a great case for the usefulness of the application, describing how it makes adding web pages to Del.Icio.Us so easy and pleasant, even celebrating the cute smooching kiss sound it makes after it does its job.

But what I found most interesting and, as a software developer, somewhat disappointing, was the way in which Leo seemed embarrassed by the fact that the application is not free. After explaining how cool it was, he hastens to add that he doesn’t know if it’s worth $14.95. “It doesn’t do much, I just love it!” He summarizes the joy it gives him by declaring “Pukka is simple. It just does what it does.” But later, when repeating the price and contact information, he hastens to inject that it “should be free.”

Now this is particularly interesting, and I don’t mean to pick on Leo, but it’s a topic worth thinking about. The majority of the show up to this point had been spent chatting with Patrick Wilson of the band Weezer, about his take on technology and, among other things, the business model for selling music to the public. During the chat, the entire MacBreak Weekly crew discussed the danger to the music industry that comes from younger listeners having a built-in expectation that music should be free.

Leo Laporte is one of the most supportive advocates for independent software developers that I have had the pleasure of (virtually) meeting. But on this episode I believe he has inadvertently helped to perpetuate the same kind of thinking about software that the panel had just finished expressing concern about with regard to music: the idea that the hard-earned fruits of somebody’s creative labor should be free.

What Does It Mean To Be Free?

Before we can understand why Leo and many other people like him have grown accustomed to expecting things “for free,” I think we need to try to develop an understanding for what it means to be free. In the English language it’s particularly difficult because we use the word to describe two fairly radically different concepts: the freeness of liberty and monetary freeness.

The free software movement recognized this problem early and has reduced the distinction to a couple of catch phrases. To determine whether something is meant to be free as in liberty or in cost, they ask whether it’s “free as in speech” or “free as in beer.” I return to this sometimes myself when trying to make sense of something’s freeness. But I also like to use the more explicit phrases “free of restrictions” and “free of cost.” Some things are neither and some things are both. You might find it easier to evaluate in which way something is free by substituting one of those phrases for the word free.

Although the freeness of restrictions is significant to software, particular as it pertains to open-sourced software which other developers are invited to use, for the topic at hand I’m mostly interested in freeness of cost. It’s freeness of cost that Leo was alluding to when he suggested that Pukka should be free, and it’s freeness of cost that I think many consumers are becoming more and more expectant of on the web and with computer software in general.

Freeness of cost feeds an ongoing expectation for more of the same. But there are so many varieties of cost-free products, that it’s worth exploring in some more detail what it really means to be free.

Five Ways Of Getting A Beer

The aforementioned “free as in beer” metaphor is valuable in that it helps distinguish monetary freeness from liberty. But consumers and developers run the risk of misunderstanding this freeness if we don’t elaborate on the variety of ways in which something can cost money, be free, or fall someplace in between. Each comes with its own tradeoffs, hurting or helping customers and vendors in their own particular ways.

Without thinking particularly hard about the idea, I came to the conclusion that most of things we receive possession or ownership of, we get through some combination of the following five avenues. I’m sticking with the beer analogy because otherwise things get way more complicated, and this blog post gets even longer than it already is.

You walk into a bar, and you get a beer in your possession by:

1. Pure Payment. The classic mode of acquisition. You choose your favorite brew, and the bartender pours it for you. You get maximum control over the choice of product, and the vendor gets maximum compensation. Mutual gratification. See also: market price, supply and demand.
2. Subsidized Payment. The bartender recognizes that by occasionally giving you a “free beer,” you will continue to buy beers, and may even start promoting the bar. The product is free for a moment because the vendor is virtually guaranteed it will pay itself back. Very gratifying for the customer, tentatively gratifying for the vendor. See also: loss leader, senior discount, government programs, insurance.
3. Pure Charity. Your friend arrives to find the four of you, all close friends for years, sitting around a table. Great news: he’s buying! You’ve just been the recipient of pure charity, which comes with few or no strings attached, but which gives you very little control. Don’t like Pabst Blue Ribbon? Too bad, that’s what he’s buying. At least it’s free! See also: open source, birthday gifts, dinner parties.
4. Subsidized Theft. You think you’re so smart. You discovered a tap at the end of the bar that almost nobody has their eye on. When the bartender isn’t looking, you can grab a free pint of whatever happens to be on tap. You don’t actually enjoy what’s in there much, but hey, at least it’s free! You enjoy the benefit so much, you insist on coming to this bar and always instruct your gigantic social group to meet here. They buy tons of drinks, and the bar prospers not only in spite of, but ironically because of your theft. See also: file sharing, mix tapes, some software piracy.
5. Pure Theft. You’re passing by the back entrance of the bar when you notice a few full kegs of beer just sitting there. Later you come back with a friend and roll one into the back of his pickup. That night, you call all of your friends to share the great news: party at your house, free beer! Not only will you not be meeting at the favorite bar this weekend, you just cost them a keg’s worth of profit. See also: resold pirated goods, fenced car stereos, muggings, home robberies, etc.

I realize some of these scenarios are a little far fetched, just to make the beer analogy work. But the “see also” items are meant to inspire you to think about the other transactions in your life that fall into one or more of these categories. For instance when you go to a web site and read the news for free, you’re participating in a subsidized payment. The advertisers just happen to be paying for the content for you, in exchange for your attention to their products. Likewise, a big software company such as Apple might give you “free” software such as GarageBand or iMovie, which is actually subsidized by the cost of the new computer you just bought.

You Get What You Pay For

When Leo suggests that Pukka “should be free,” I believe what he’s suggesting is that because the application is simple, and because it works with a popular free web service, that it should also be free as in pure charity. But this makes some hasty assumptions about the product and the developer. If the product were “free as in charity.” Would the product be as good as it is? Would the developer have income to survive?

In short, if the product were free as in charity, would the product even exist, and be good enough to mention on MacBreak Weekly, where Leo could wish that it was free? Don’t get me wrong, there do exist many, many fantastic products of charity. And there also exist many total pieces of commercial crap. But the mechanics of the transaction are most obvious and, in a sense, honest, when they are reduced to pure payment.

Going back to the bar analogy, let’s consider the free peanuts that you might see in bowls at many such establishments. These subsidized freebies are a tasty snack, and furthermore encourage customers to continue buying beers. In New York City and other large cities, you’re liable to find street vendors on many corners, peddling peanuts and other snacks that are quite similar in quality and quantity to what you’ll find for free in some bars. “These peanuts are great, but they should be free.” Try telling that to the guy standing in the cold on 34th Street!

Software costs money, time, and resources to develop, just like many of the other products in our lives. And just like those peanuts on the bar, many companies with other things to sell you are in a good position to give away freebies that help to promote their business; to encourage you and your friends to give them money for different reasons.

But smaller companies don’t often have the variety of products and services that lends itself to such a complex strategy. Given a good product idea and a market to sell to, they’re forced to adopt the simplest of all strategies: pure payment. Build something brilliant, and be rewarded with money. This money translates into a great motivation for the developer, which in turn translates back into product greatness. It’s easy to understand why the majority of great products in this world do cost money to obtain.

The next time Leo has such a gushingly positive reaction to a product, as he’s obviously had to Pukka, he might consider all the materials going into creating it, and what it costs to perpetuate it. In the case of Pukka, he might have better exclaimed “thank God this isn’t free!” Because if it was free, it probably wouldn’t have rocked his world so hard.

In indie software acquisition news, Decimus software has acquired Polarian Technology. Lee Falin took a very public approach to selling his company when he announced his intent to sell on his blog last month.

The primary product being acquired is Screen Mimic, a video screen capture application. After a hiccup with a prospective buyer who didn’t work out, I’m pleased to hear that Lee found another developer to take over the reigns. The screen capture business seems to be taking off right now, and I’m sure we’ll all benefit by the healthy competition this product adds to the market.

I was honored to be interviewed by Chuck Joiner for his series of interviews with members of the Mac community. Chuck asked me to reflect on my product lineup, the company name, and my feelings about the Mac community. Nicely done, Chuck!

MacVoices #870: Daniel Jalkut Discusses Red Sweater Software

Chuck and I had a terrible time working around networking problems with Skype, while we were doing the interview. Bu thanks to Chuck’s brilliant (and laborious, I’m sure) editing job, you’d be hard pressed to tell.

Thanks a lot for the great interview, Chuck!

A couple months ago I reported on a particularly nasty, crashing bug in NSURLConnection. What was particularly nasty about it was how widespread it was. I had received dozens of crash reports, all containing the same tell-tale sign of a problem in this part of the system.

After getting tired of explaining again and again to customers that the bug was in Apple’s code and the best we could do was hope for a fix, I realized that maybe it was worth me writing up the bug and reporting it to Apple. I supposed maybe, even though this bug’s crash log shows up as fairly common in Google, nobody has bothered to report it yet. So I wrote the aforementioned blog post and reported a bug.

Since the issue only affects 10.4.11 users, I figured the chances of a fix might be slim. Apple naturally is most concerned with the latest releases of 10.5, although they continue to issue security fixes to protect users on 10.4.11. But this was just an extremely annoying crash, not a security vulnerability, as far as I knew.

After writing the blog post I started to hear from other developers that the crash logs were extremely common for them, too. One developer mentioned that he had no less than 100 separate crash reports in his logs, from users afflicted by the problem. Users reported that it affected them while using Safari, MarsEdit, essentially any application that uses Cocoa to access resources from the web.

It sucked, man! But would it ever be fixed? Well, I have to confess that my expectation for a fix went up when Apple contacted me a few weeks ago to ask me how I would like to be credited in a forthcoming security update. How interesting! I had not reported any bug recently which I thought had security implications. I immediately became hopeful that it would be have something to do with this nasty epidemic of a bug.

Today, Apple released Security Update 2008-002, whose release notes include the following note:

Description: A thread race condition exists in NSURLConnection’s cache management, which can cause a deallocated object to receive messages. Triggering this issue may lead to a denial of service, or arbitrary code execution with the privileges of Safari or another program using NSURLConnection. This update addresses the issue by removing an unsynchronized caching operation. This issue does not affect systems running Mac OS X v10.5 or later. Credit to Daniel Jalkut of Red Sweater Software for reporting this issue.

Everything about this description sounds like the bug I reported, except that I didn’t realize it could possibly be used to exploit the security of a system. I guess this is one of those situations where it’s lucky there was as security flaw, because without it, I don’t know if it would have ever been addressed.

Now users are not only protected from this strange security vulnerability, but perhaps more significantly, protected from the repeated frustration of crashing in their network enabled applications!

The moral of the story for other developers (and users, too): always report bugs, even if they seem so widespread as to have been “surely reported.” It turns out that my frustrated effort to bring attention to this problem might have been what Apple needed in order to spot the security flaw and ultimately decide to fix it.

Many, many thanks to Apple for fixing this problem! Of course, I am putting a lot of faith in this actually meaning it’s fixed, but it sure sounds like it is. Time will tell if the “willCacheResponse” crash logs stop trickling in.