On Google: We did not enter the search business, Jobs said. They entered the phone business. Make no mistake they want to kill the iPhone. We won’t let them, he says. Someone else asks something on a different topic, but there’s no getting Jobs off this rant. I want to go back to that other question first and say one more thing, he says. This don’t be evil mantra: “It’s bullshit.”

(via Layton Duncan)

I never implement registration systems thinking they will be immune to crackers and others who are destined to find a way to not pay for my software. Instead, I opt to make a system that is the least amount of work for the user, as well as the least amount of maintenance effort for myself.

Today 1.0 and Check Off 4 both make use of the AquaticPrime framework. AquaticPrime uses RSA encryption and generates license files. I liked it because it was dead simple to setup on my end, but the concept of a license file has proved to be a support nightmare for anyone that is not a well versed computer user. The fact is people expect serial numbers and when you email them a file with a strange extension on it, they aren’t really sure what to do.¹ Cocoa Boutique aims to make the usage of AquaticPrime less painful for the end user by hiding the license file process from the user, but it currently requires using Paypal as your payment processor.

With Today 2.0 I opted to implement a traditional serial number system similar to what you’d find on the back of a shrink wrapped disc. The support load in terms of registration issues for Today has dropped significantly, but I still run into a few users a week who have issues with typing in their serial number due to not being able to differentiate between O and 0 or I and l. Telling the user they can just copy and paste the serial from their email into Today solves the issue, but it’s still frustrating that this is one of the first experiences the user has right after paying for my product.

This all has gotten me thinking about why we are still using things like license files or arbitrary strings of letters and numbers as the way of verifying a user has purchased our software. It seems like there should be a better identifier for a user to validate their software purchase.

This is what I had in mind:

1. User purchases a copy of Product X from the Second Gear store.
2. Upon successful purchase, the user can then enter their email address into a registration dialog.
3. The app will ping home, validate that the user has indeed purchased the software, and mark it as registered.

A single network transaction to validate the user. No per-seat licenses or periodic phoning home a la Adobe or Microsoft. The idea behind this is that a user’s email address is easier to remember and type rather than a string of random characters and numbers.

I chirped up on Twitter about this and got quite a few responses that I wanted to highlight and respond to.

Justin Pennington writes:

@justin I agree but think the reason is because of having to keep that server side process up forever in order for the app to work.

It’s honestly not that much work I wouldn’t think. A PHP script that takes an email address plus a product identifier and returns a pass/fail status is minimal effort both in terms of development and maintenance.

The forever aspect of software is not something I really take too seriously. There is very little software that I was using five years ago that I’m still using today. I’ve purchased upgrades or just found a better workflow. If need be, you could offer unlocked copies of previous releases to users who request them, or if you plan to go out of business or discontinue the product, offer an unlocked copy somewhere.

Alastair Houghton of Coriolis tweets:

@justin That’s what we do here; it causes far fewer problems and very few people mind the minor inconvenience of initial activation

I recently reinstalled iPartition on my Mac mini, and the process Coriolis has in place is seamless. I honestly can’t remember how it worked, which is a testament to how easy it is for honest, paid users. Coriolis goes a step further by having user accounts that are tied to each purchase. It’s a bit more work on the server side, but it seems to be working well for them.

Daniel Jalkut chimes in:

@justin Serial numbers are simple and allow customers to activate their own purchased software at any time under their own control.

This is actually the biggest reason I have against the idea of using an email address or order number as the system for registration.

Patrick Burleson and Steve Streza says something similar:

@justin My guess would be that email addresses are easy to guess. If someone knows I own a product and knows my email: free registration.

My initial response to this was that it’s just as easy for someone to pass around the user’s serial number, but this could be afford a larger uptick in blind piracy. If I knew that Patrick had a copy of FancyApp 1.0, I could download the trial, test out his email address and possibly have a free copy.

The workaround for this could be to replace the email address with the Order # as the identifier, but I’m not sure how much of an upgrade that is versus serial numbers as the possibility of mistyping still exists. Not to mention that order numbers are tied to your purchasing system, which may be a problem longer term.

Nick Peelman brings up the enterprise angle:

Please please please remember some form of enterprise activation… no matter how insignificant you think your app is in enterprise, help out the guys running a managed environment :)

This is something I hadn’t considered, and a valid point. I’m honestly not sure of a good way to handle this without adding a ton of infrastructure work on my end for a small use case.

I am honestly not sure if there is a better system than the traditional serial, but it’s certainly something to ponder.

1. It should be noted that these people also don’t read the instructions you provide that explain exactly what to do with the file.

Unfortunately I discovered a pretty significant road block when working on improving Check Off’s accessibility. NSStatusItem, the class that inserts the check mark in the Mac’s menu bar, is not accessible via VoiceOver. Try it for yourself:

1. Launch System Preferences -> Universal Access
2. Turn on VoiceOver
3. Hold down `Control-Option-m’ to access the menu bar via VoiceOver. You’ll be at the Apple menu.
4. Press the Left and Right arrow keys to navigate between the File menus.
5. Press `Control-Option-m’ again. If you have them, you’ll jump to the standard OS X menu items like Airport, battery status and the clock.
6. Press `Control-Option-m’ again to access Spotlight’s menu.

Notice how VoiceOver skipped over your third-party menu items like Check Off, TextExpander or FastScripts? That’s not good. In essence there is no way for a user to get access to these menu items without using the mouse or establishing a hot key to toggle them.

The Apple menu extras get VoiceOver support due to them using the private NSMenuExtra class. Besides accessibility, NSMenuExtra items are draggable by holding down the Command key and moving them left or right. The disparities between NSStatusItem and NSMenuExtra were discussed back in the Jaguar and Panther eras, and sadly it doesn’t seem the two have moved any closer to being alike.

At this point, Check Off 4.1 will be fully accessible, save for the menu extra which is out of my hands. I would like to see Apple add accessibility support to the NSStatusItem class in a 10.6 point release, but I won’t hold my breath. If this is an issue for you as a developer or user, I encourage you to dupe this Radar bug.

• OpenRadar: OS X 10.5: Status Items created with NSStatusItem are not VoiceOver accessible
• rdar://5037324

Update: As Martin Pilkington pointed out, it’s actually NSStatusBar that isn’t accessible. Semantics aside, the issue remains as of Mac OS X 10.6.2.

• Creating Applications In Xcode Using Frameworks
• Store Options For The Indie Developer
• Experiences Setting Up Potion Store

EMKeychain is a Cocoa wrapper class for Keychain, which has unfortunately been frozen in carbonite. It’s much cleaner than interfacing with keychain yourself.

Traffic Numbers

For an idea to go from a single tweet to a massive, worldwide charity drive in the span of six days is impressive and possibly insane. That said, I’d do it again in a heartbeat (though I hope that won’t be necessary).

Just to give you some numbers from the traffic side of things:

• Sunday January 17, 2010: 0 visitors
• Monday January 18, 2010: 1,962 unique visitors
• Tuesday January 19, 2010: 31,667 unique visitors
• Wednesday January 20, 2010: 43,664 unique visitors

The biggest source of referral traffic was Twitter with Daring Fireball, and the Google.

In terms of bandwidth, IndieRelief.com pushed a whopping 75 gigabytes in the span of two days. My thanks to my hosting provider Joyent for agreeing to cover the overages and ensuring that everything on that end went smoothly.

The Money Raised

In terms of money earned, here’s just a sample:

• Wil Shipley of Delicious Monster raised $6000. He was also kind enough to agree to match funds up to $5000 for his charity of choice, Partners in Health.
• Gus Mueller of Flying Meat raised $6461 for Doctors Without Borders.
• Daniel Jalkut’s Red Sweater Software raised $2300 for Partners In Health.
• Kevin Hoctor’s No Thirst software $3,195 donation to the St. Boniface Haiti Foundation.
• Marketcircle raised $7000 for Doctors Without Borders.

I’d really like to go out of my way and thank Wil and Gus for being so forthcoming with their numbers and the #teammeat vs #teamdelicious battle. I sincerely think it eased the minds of a lot of other developers to share their donation numbers. Sharing your numbers with me wasn’t a required aspect of participating in Indie+Relief, but I’m happy to say that 100/140 companies did.

After tallying the donations over the past day, I am pleased to report that…

Indie+Relief raised $143,872 for charity!

I cannot begin to explain how far above and beyond this amount is compared to what I had in mind a week ago. What I thought would just be Second Gear and a few other small Indie Mac developers banding together for a small benefit turned into a massive fund raising effort.

Indie+Relief 2.0

All things considered, this went off fairly smoothly for being an idea on Twitter 6 days ago to a full blown promotion, but there’s obviously room for improvement should we do this again.

As for the sequel, I don’t anticipate doing something like this annually. Like Comic Relief, the event which inspired the naming, I think Indie+Relief is a great thing to do when there’s an event that calls for it.

With that in mind, I’ve setup @IndieRelief as a sort of Bat Signal should the time arise. We also have a really great foundation in place for setting this up again and can certainly build on it to improve going forward.

And speaking of that foundation, I hope you all do take the time to thank Garrett Murray who spent countless hours getting the Web site up and running for Indie+Relief. This thing wouldn’t have happened nearly as smoothly as it did without his help.

Thanks again for participating.

I asked on Twitter for people who were participating in Indie+Relief, but not listed on the page to let me know so I could build a list. I’ll update this list through the day as companies email me (justin at secondgearsoftware dot com).

• Battle For Vesta by Insight VR is supporting Healing Hands for Haiti
• CoverSutra by Sophiestication is supporting UNICEF
• iLikeCereal by Marroni Electronic Entertainment is supporting Cross International Catholic Outreach
• iTimeZone by Tangerine Element is supporting the Red Cross
• Humidor and MyGarden by Perceive Designs are supporting Yéle Haiti
• Rivet and Ringtones by The Little App Factory are supporting Doctors Without Borders

As a bonus note, Wil Shipley of Delicious Monster, has agreed to personally match donations up to $5000 for any Delicious Library purchases today. All his sales will be going to Partners in Health.

If you’d like to see a preview of the companies participating on the 20th, head to the Indie+Relief now. Many of the companies you have probably heard of, and I’m certain there are a few gems in there you haven’t. Even if you don’t have any intention of buying software on Wednesday, do yourself a favor and see what awesome Mac & iPhone products are out there.

The response leading up to the event has been great. We got great coverage from the likes of Mashable and Macworld. Now that we’re nearing the actual event, what I really want to focus on now is getting the word out on Wednesday. This is where I need your help.

If you are a company participating in Indie+Relief consider writing a blog post, tweeting your customers or announcing it to your newsletter subscribers. I’ll do my best to prompt my media friends and colleagues to raise awareness about the event, an I’d encourage you to do so as well.

Even if you aren’t a participating company, it’d be awesome if you could spread the word via Twitter (sorry, no automated Tweetblasts) or blog posts. You could also put an Indie+Relief banner on your site or blog to let others know about the promotion.

• 500px wide banner
• 250px wide banner

The more awareness there is, the more software will be bought. The more software that is bought, the more is donated to charity. I realize we won’t be making nearly as much money as the text messaging campaigns or other telethons, but it is refreshing to know the Mac & iPhone community has the opportunity to at least make a dent in the Haitian relief effort. Thanks for being a part of that.