Blog archives for December 2007

Yesterday I stumbled across a month old blog post advocating a hack to the excellent Twitterrific application, a client for the free Twitter service. The hack (Update: supposedly, but the point remains) removes the rather unobtrusive ads that the software developers introduced as a way to offset free use of the application. If you didn't want to see them, you could just register the application and they go away. The app didn't start out having them, but after it took off in popularity, the authors (you know, the people who put their time into the application's development and support) decided that this was a better model.

I should take a moment to point out here that as a whole, advertising in general strikes me in a negative light, but I didn't mind the ads in Twitterrific as it was great software and a fair tradeoff for my fifteen bucks.

Anyway, this hack and its associated "arguments" interested me particularly because my application Pukka is also a lightweight client for a free online service, so I left a comment. My initial argument was:

Just like a web browser, RSS reader, email client, FTP program, Aperture, iChat, blog editor… man, the nerve of those people trying to charge for a tool for receiving and delivering content created by others!

Also, I’m a Twitterrific user and I like the ads. Eventually I may pay for the app, but for now, they’re alright.

Try writing a program for which you charge little or nothing, getting a couple thousand users, then see what you do.

Since then, the discussion has gotten rather heated, as well as ludicrous in some cases, as acknowledgement and support of both software piracy and website attacking has been discussed. Seth Dillingham, whom I first got to know (at least virtually) last summer when I supported his bike ride for charity, posted a response and a challenge to users of Twitterrific: put your money where your mouth is. So I took him up and I registered Twitterrific. Money well spent!

If for no other reason (and there are plenty of other reasons), software piracy hurts developers from the support angle. Many users running an app means more support, particularly when a chunk of them are running a cracked version that could develop unforeseen problems. Users report stability issues on the popular software sites or, in the case of larger companies, call the support lines and demand resolution to their issues. I think John Gruber said it best when he wrote about the jailbroken iPhone phenomenon:

The mindset manifests in many forms, but what it boils down to is this: a sense of entitlement that users should be able to do unsupported things and yet still be supported. That it makes no sense to expect support after taking unsupported actions is why I’ve found it baffling.

Phooey. Get your copy of Twitterrific right here. And support software developers if you enjoy their products, but don't feel that you have the right to rip them off if you don't like how they do things. In fact, grab Apple's free development tools and write your own and let's see how it stands up.

Update: Craig at Iconfactory, the author of Twitterrific, weighs in with his take on the whole matter.

Just a note that Pukka 1.6.6 final is out! Grab it here. For more details on the changes involved, see the last post. This release should iron out any remaining crash problems that users have been seeing on Leopard.

I've just released Pukka 1.6.5 with a slew (or, as the changelog refers to it, a metric slew) of performance updates, bug fixes, and usability improvements. You can read on for (much) more detail or just head over and get Pukka now.

The bulk of the changes deal with Spotlight performance and strain on and responding to capacity issues with the del.icio.us (or other service) API. Hopefully this should make Pukka perform faster, be more responsive, and be a better network citizen.

Here are the changes in depth:

• Removed a check on the local Spotlight cache that would run 30 seconds after launch and could cause unresponsiveness in the application. The Spotlight caching mechanism has been updated to perform in a more incremental fashion to avoid the need for this.
• Pukka now waits at least five minutes between API requests of all bookmarks, preferring requests of the latest 15 bookmarks in the meantime, to ease strain on the API and to avoid getting throttled.
• Added CFBundleShortVersionString to app bundle, which will make Pukka's version number show up in Finder's Version column.
• Upgraded Spotlight metadata format to store bookmark data in folders organized by username instead of one big folder. This improves performance during local cache updating.
• Resolved a Core Data issue that may have caused a delay between when bookmarks were cached and when they appeared in the application.
• Changed the interval used to check for bookmark updates online from one minute to three minutes. Although this was a very slight hit on the API, it was reduced in the interest of scaling back a bit because we can.
• A Growl notification is now shown when the bookmark cache on disk is updated. This occurs whether all bookmarks were re-parsed or just the latest 15, and for each account.
• The successful post Growl notification was updated to include the page title and the account posted to.
• A specific error message is shown if a post fails due to API capacity issues or throttling, as opposed to a general error when posting (network, internal server error, etc.)
• Any kind of posting error shows a panel with a "critical" alert style to indicate that data was not saved and may be lost if the application is quit.
• Fixed two small memory leaks related to tag sorting in the bookmark menus.
• On first run, a modal panel is shown as the bookmarks are cached for the first time. When this panel was hidden, the animation would continue. For cleanliness, this has been stopped.
• Trivial about box updates: Two issues were tweaked with the icon animations. The randomness of the selected animation was made better and a PNG representation of the app icon is passed to the animation instead of the .icns file directly. Lessons learned from Ironcoder ;-)
• The HTTP timeout for sending posts was reduced from the default of 60 seconds to 10 seconds to avoid making the app unusable for up to a full minute in the event that the link can't be posted.
• A bug was fixed in the debugging console which prevented it from always scrolling all the way to the bottom on appending new content.
• During posting problems, we now report exactly the message that was received from the API to the debugging console.

That's it! Enjoy and please contact me with any problems or questions.