Pricing software is one of the toughest jobs facing independent developers. We’re stuck in this awkward position where we don’t necessarily have the name recognition to demand the highest prices, but we also can’t afford to “give away” the hard-earned fruits of our labor.

On one side of the argument we hear the endless feedback from the “Cult of Too Expensive.” These are the seemingly endless supply of irrationally whiny “potential users” who insist that a product is “good, but too expensive.” They would buy our products if only they were $5 cheaper. Who are these people, and who gave them access to the internet? They wouldn’t be nearly so annoying if their price wasn’t always ridiculously low. It’s not uncommon to hear people disparaging $15 products (mine among them) as “too expensive.” At some point, you have to wonder whether these people eat out of a dumpster or live out of the back of their truck. Not that there’s anything wrong with those lifestyle choices, but it has little to do with what represents “good value” to ordinary people. In many cases, I get the sense that people got an idea in their head about how much software should cost in 1983 and haven’t adjusted for inflation since.

Another line of thinking suggests that a product must be priced high enough to demand the respect it deserves. This makes common sense, and resonates with many an aphorism: you get what you pay for, etc. In a recent email thread, Brent Simmons (of NetNewsWire and MarsEdit fame) summarized the problem of underpricing software as a matter of perception:

“Anything under $19.95 sounds like a hobbyist or teenager trying to subsidize their iTMS habit. Anything $19.95 or higher sounds like a professionally-made and supported product.”

Surely there is some wiggle room in the exact price, but the logic is compelling. At what point does “bargain pricing” hurt your sales more than it helps them? And how much does this value perception depend on the context the product is stuck in? I think most would agree that the price $1 is too high for a candy bar, too low for a bottle of wine, and just about right for an MP3. The travesty is you won’t even try the $1 bottle of wine, despite the low investment. “It can’t be good!” The magic number for “palatable” wine is between $6-$12, depending on who you ask. Is $19.95 that magic number for palatable consumer-oriented software?

Tom Harrington of Atomic Bird doesn’t seem to think so. His system maintenance utility, Macaroni, costs just $8.99. The company’s flagship product is decidedly not a hobbyist project, and sees substantial sales to both individual and institutional buyers. But even at its low price, he gets hecklers. “I had people who complained Macaroni was too expensive when it was $7.99,” he told me. Is nobody safe from the insane Cult of Too Expensive? Is Macaroni a success because of its reasonable price, or in spite of it? One nice side-effect of such a low price is that a modest rise in price, such as the one from $7.99 to $8.99 should produce a massive 12% increase in revenue. But now that he’s set the pattern of a low price point, is he stuck there?

There is a prevailing wisdom in marketing that “prices should only come down.” This would suggest that developers should “aim high” and then correct when nobody buys the product. This is how a computer would solve the pricing problem: start high and iterate until condition “good sales” is met. But such a strategy in real life could be a public-image nightmare. We hope to hit “pretty much on target” from the start, to avoid embarrassment and second-guessing. If you price too low, you’ll have a hard time imposing a major increase. If Atomic Bird raises the price of Macaroni to $25, there will undoubtedly be squawks of “but my friend bought it for $9 last week!” Most developers who raise prices tend to do it gradually, and in conjunction with feature upgrades. The price remains static between 1.0 and 1.2, but when some major changes happen for 2.0, the price might get bumped by $5 or $10. This makes for something of a “stealth increase” that can really add up over the years.

But sometimes drastic actions are called for. The price can be simply too low. Whether it’s a question of perception or practicality (income not matching expenditures), the price of some products needs to be seriously corrected in order to set things right. Chris Liscio has been struggling for months to find the right price for his professional acoustic measurement software, FuzzMeasure Pro. Catering to a specialized audience where competitors are often priced in the $500-and-up range, his pricing conundrum was tougher than most. For this product, $19.95 was certainly not the magic number. But what was? Just getting his new company off the ground, Chris wanted to make sure his pricing was competitive, but his experience was educational. He told me that he originally intended to charge $125 for FuzzMeasure 1.2, with an introductory “sale” for $85. This is how he released the product: on sale for $85 but making no secrets about the forthcoming increase to $125. What happened when he raised the price? In his own words:

“On August 1, I released FuzzMeasure 1.3 at the full price of $125 and expected sales to drop drastically. Quite the opposite occurred — my license sales doubled, and total sales dollars went up by nearly 200%.”

Hello! Sign me up for developing niche audio software! Charge more, sell more, everybody’s happy (especially the developer). Today FuzzMeasure retails for $250, almost 3-times its original price, yet it still undercuts the competition by hundreds of dollars.

At the extreme end of pricing corrections are movements from and to “Free.” People hate it when things stop being free, and love it when things become free. Unless they just bought it. Then they’re angry because they got “ripped off,” even though it was a good deal before it was free. An application that recently went from $25 to Free is Don Briggs’s Suite Modeler. It’s hard to tell what the motivation was for this move. Probably the market was never particularly lucrative, and to be honest things are moving pretty steadily towards a newer dictionary format (sdef) that sort of obsoletes the application. But it was $25, and now it’s free. Somebody’s probably stinging.

Kevin Callahan’s Accessorizer has been a life-saver for many Cocoa developers over the past several years. Roughly in conjunction with its 2.0 release, its price jumped from Free to $20. Now this is a perfect example of something that people love to get upset about, even if it makes no sense at all. “Because you let me use your software for free for several years, you have no right charging for it now!” This seems to be a common sentiment. Ironically, if Kevin’s app had been $30 from the start, a reduction to $20 would have been met with cheers. I’ve even heard tell of some people describing the sudden shift in strategy as a “greedy move” on his part. And what precisely was selfless about their years of freeloading off of his hard work?

Another product to go from Free to $20-ish is Fraser Speirs’s FlickrExport. This product used to be so free you could download the source code (still can for the 1.x version). Now it’s closed-source and costs money. Not free as in beer. Not free as in speech. Free as in demo. Yet somehow I don’t hear the same amount of outrage in this case. Perhaps it’s because Fraser eased customers into the idea over a period of time. Over a period of months he hinted at the transition to a for-profit enterprise, and gave salient reasons for why this was an important direction to take the product in. Users, the ones you care about – not the crazy Cult of Too Expensive, seem to be amazingly resilient if given half an ounce of reason to be so. After all, they want to like you, they just need a little psychological hand-holding.

So what’s the takeaway from this article? Price your product above the “magic number” for your target market, but not so high that nobody buys it. Easy, huh? I wish. What is your target market? Obviously Macaroni, NetNewsWire, and FuzzMeasure fall squarely into distinct ones. Where will FlexTime fall? Probably somewhere between the $14.95-$24.95 – i.e., the price of a mid-range economy bottle of wine. Will I match the magic number? We’ll see. And I’ll get my share of hecklers, too.

Paul Kafasis from Rogue Amoeba made some interesting observations about the possible impact virtualization could have on Mac developers.

Virtualization is technology, rumored to be present in the forthcoming 10.5 release of Mac OS X, that would allow Windows applications to run natively and transparently in the Mac environment. Paul’s thoughtful analysis reveals that Mac users will benefit because of the increased flexibility, and Windows developers will benefit because of the new potential market. Where does that leave Mac developers? I definitely think Apple should spend at least a few hundred thousand dollars researching this on our behalf. Protect us, Apple! Still, the threat of Windows developers suddenly having access to our customers doesn’t scare me too much.

Such an outcome wouldn’t increase the competition so much as the noise. Look at the situation today on the Mac. It’s relatively easy (in my not-so-humble, unproven opinion) to identify products on the market that can be vastly improved upon, put in the hours to build a better solution, and market it directly to the customers. The problem even today is not “being better than the competition,” but reaching the customers who give a damn about your being better. This basic rule won’t change with an influx of new developers.

Take some popular class of application as an example: the 2D vector art editor application. There are at least 10, probably 100 of these apps available on the Mac, and they range in quality from developer examples like Sketch to expensive commercial apps like Illustrator.

Of these 10 or 100 existing apps on the Mac today, I’m guessing from my experiments that only about 2 or 3 are actually really useful. Therefore the competition pool is only 2 or 3 products, regardless of how much noise there is.

Now with virtualization we’d probably get 1 or 2 additional “really useful” apps, although their usefulness would probably be diminished by their Windows-esque UI. Anyway we’d also get probably 10-times as many “non-competitors.” More noise. These products attract users’ attentions but don’t ultimately satisfiy them. So they make it harder for the user to identify your working product.

On a side-note, one could consider the opening up of Mac OS X to linux/unix as a test-run of such a strategy. Essentially for the past 5 years, Linux developers have had open access to the vast installed base of Mac users, but they haven’t made much headway in driving Mac developers out of business. I think it’s reasonable to assume that if Mac users are not interested in free alternatives that don’t cut muster, then they will be even harder to woo with paid ones.

Bottom line? Optimistically I think that better products will win. The problem is cutting through the noise, and technology seems to be on our side. The growing popularity of blogs and “peer editorializing” seems like a natural match for promoting quality products and thereby elevating them from among the noisy ineffective ones. To the Mac developer’s advantage, there are already complex systems in place for distributing Mac propaganda. The online news sites and download trackers that many Mac users frequent are going to be hesitant to embrace and recommend lackluster Windows software – because they themselves are Mac users who know the benefits of native software.

Even if we assumed that the best Windows developers could acquire Mac style, and truly understood what Mac users want, their Windows apps will always be at a disadvantage on the Mac platform. The trend from Apple is increasingly to differentiate Mac OS X by adding technologies with a system-wide impact. Spotlight integration, for instance, will likely not come for free with a “virtualized” Windows app. Furthermore, the development tools and APIs from Apple are getting more and more powerful all the time, in ways that are precisely tuned to work well with differentiating features of Mac OS X. It wouldn’t just be difficult for Windows developers to try to compete with this, it would be a colossal waste of their time!

It’s easy for me to be cavalier about this because I don’t yet make my living from direct software sales, but I’m inclined to think that Windows developers, with their platform-inappropriate styles and habits, will have a hard time competing against Mac developers – even the worst of us.

Bring on the crappy software! It can only make ours shine brighter.

John Siracusa recently wrote about Apple’s almost universally condemned strategy of distributing recorded conference materials after the show is over. He asks “Why does Apple jealously guard the content presented at WWDC?”

It’s a good question, and it probably has to do with compelling future attendance at conferences. After all, Apple is probably thinking, if you can get the milk for free, why … uhm, go to the cow? By “jealously guarding” the content that makes up the “intellectual reward” for conference attendees, they’re making it clear that the best way to stay on top of Mac OS X technical issues is by attending the conference.

This rationale makes sense on paper, but there are major problems with it.

Being In The Room

The first mistake is in assuming that reproduced content will approximate the value of “being in the room.” I’ve watched a fair number of the WWDC 2005 videos through the (painful) streaming ADC Select interface. Aside from the benefits of being able to pause, rewind, and skip the boring parts, let me tell you, it’s no conference. I am roughly able to absorb all the data that my peers who attended did, but they benefitted from a much richer experience.

Watching the WWDC sessions from home is like watching the New York New Years Eve party on television. You are a passive recipient of the information, but you don’t get to participate. You know when the new year arrives at very close to the same moment as all the thousands of people in the crowd, but you don’t get the satisfaction of washing the champagne stains out the next morning.

Even though the information (the passing of the year) from this great event is free and widely spread, the event is hugely successful. Why do those thousands of people travel to downtown NYC to participate in an event they could watch at home? It’s about being in the room.

The value of being in the room at WWDC is about 10 bajillion times greater than being in the room at new years. At WWDC, you can ask questions. If the line was too long and you missed your chance, you can recognize the speaker in the halls and track her down for clarification. At WWDC, you can participate in hands-on sessions, working through the new technology as you learn about it. At WWDC you can visit the labs and work in an environment where smart people are hovering about, waiting to answer your questions. Unless you’ve found a particularly well-stocked IRC room, these benefits are not available to you at home.

Being Outside The Room

The other major motivation for attending WWDC has nothing to do with the conference itself, but with the milieu surrounding it. There is quite simply no other time of year that such a concentration of like-minded Mac software developers exists in any one point on the globe. The closest thing you’ll find to this amazing congregation of Mac nerds, is the sizable number of them that reside permanently during working hours in Cupertino, California. The rest of us are lucky if we’ve found a half-dozen similarly inspired people within a 50 mile radius of where we live or work.

Apple takes this benefit to the ultimate level by opening its own doors for one evening during the conference, inviting attendees to relax, have a beer, and mingle with conference attendees and Apple employees on the Apple campus. This degree of access is totally incomparable to anything a developer can hope for via the web, email lists, chat rooms, or forums. The Apple campus on one summer Thursday becomes an absolutely sizzling hotbed of Mac nerdiness for 3 hours every year.

And Apple’s party is only the tip of the iceberg. Events like the Buzz Andersen’s annual party are gaining momentum with each passing year. The number of extra-cirricular activities is so great that groups of developers with niche interests find it difficult to find a spare lunch or evening in which to meet. In summary? WWDC produces a week of nearly non-stop hot developer-on-developer action. You can’t buy that at home (ahem – nor, with that particularly risque choice of words, would you want to!).

To top it all off, WWDC has for the past several years been held in San Francisco, one of the most attractive tourist destinations in the world. The conference is epic, the scenery is epic, the attendees are epic. Attendance is an almost irresistible proposition for companies and developers alike. Apple has nothing to fear from making the information free.

Ask For What You Want

The value of WWDC is about 5% information and 95% being in the room and being with your peers. If New Years were celebrated like WWDC, only a few thousand people would be running around on January 1 knowing whether it had truly come to pass. I agree with John Siracusa – it’s time to free the WWDC content. We want high quality, downloadable archive versions of all WWDC sessions. These should be available to any ADC member at any level of membership under the terms of their NDA.

If you also agree, let’s stop talking about it and start telling about it. Telling Apple, that is. Use the ADC contact form to let Apple know how you feel. You want this information freed! This is not just for whiny non-attendees, either. Those of you who attend every year have also bemoaned the loss of DVD archives of the sessions, for instance. Take this opportunity to make yourself heard. We’re all in this together!

I encourage you to write whatever you feel in your feedback to Apple, but this is what I am writing and it might spark some motivation in you to “make the call”:

Cocoa contains an awesome but sort of half-baked infrastructure for “autosaving” UI configurations for the user. Many of the common UI elements, such as windows, table views, and toolbars possess the ability to write out their configuration to the app’s preferences so they can be automatically restored the next time the app is launched.

When this works, it works. And it is, as I said, awesome. But for such a cool idea there is a great lack of consistency in its implementation. NSWindow lets you autosave the frame by setting a unique name under which it will be saved. The API is rather extensive:

+ removeFrameUsingName:  
– saveFrameUsingName:  
– setFrameUsingName:  
– setFrameUsingName:force:  
– setFrameAutosaveName:  
– frameAutosaveName  
– setFrameFromString:  
– stringWithSavedFrame 

Notice that there is no BOOL “autosavesFrame” method – it just figures if you set a name, you want it to be saved. This name can even be set from Interface Builder. The number of methods is a bit large for what seems like a simple operation, but what’s really nice is it exposes the “magic format” to developers so we can override the default behavior or make different use of the autosave information.

For example, let’s say you wanted to implement a funky little “Exposé” feature for just your application, something that tiles all the windows so that they fit neatly into the available screen real estate. That’s fine, but you should be prepared to put all the windows back the way the user had them before. Using “stringWithSavedFrame,” this is trivial. Just iterate over your open windows and collect the screen position information in a format that NSWindow itself guarantees to be usable for resetting it. It’s not like we couldn’t figure it out ourselves, but AppKit already figuerd it out! Thanks for sharing.

NSToolbar takes a different approach. Instead of allowing developers to participate in the complicated question of “naming” the autosaved information, it offers a simpler API, implying it will come up with a way of saving the information itself:

– autosavesConfiguration  
– setAutosavesConfiguration:  
– configurationDictionary  
– setConfigurationFromDictionary: 

This is a great compromise. We’ve lost the ability to influence naming conventions, but who cares? They still give us access to the magic format! So if we don’t like the way it’s handling autosave, we just turn it off and implement our own with the help of “configurationDictionary.”

But NSTableView, oh NSTableView. You had to go your own way:

– autosaveName  
– setAutosaveName:  
– autosaveTableColumns  
– setAutosaveTableColumns:  

NSTableView lets us alter the autosave name, but unlike NSWindow, merely setting the name doesn’t imply that the feature is active. We have to set that BOOL separately. Notice how NSToolbar’s technique uses the same number of methods, but provides a lot more flexibility. The worst part about NSTableView’s approach is it hides the magic data so we can’t even override the default mechanism.

If only NSTableView exposed its magic data!

I really wanted this functionality, because in developing FlexTime, I decided to offer a feature to “save window layout” to the document itself. The other autosaving mechanisms work well with this approach – just grab the magic data and archive it. NSTableView stymies me, though! Perhaps I could set an autosaveName, then do something to provoke it being saved, then look it up manually. Nah! It’s all too fragile.

NSTableView+RSAutosaving is my solution. Yours too, under MIT License. It’s a category on NSTableView that adds the missing (IMHO) methods:

- dictionaryForAutosavingLayout
- adjustLayoutForAutosavedDictionary:

The “magic data” in this case consists of the widths of every column and their ordering in the table. There are a few subtle gotchas to doing this right, and I think I did it right. So you’ll be glad if you end up not writing it yourself.