There’s a flurry of activity on the macsb mailing list regarding product activation for software as a result of this post. It seems the purchaser of an RSS reader was denied the ability to re-install the program on his computer because he had done so too many times.

Product activation is one technique some software publishers use to reduce the theft of their products. Other techniques have been hardware-based, such as the dongle, and software-based, such as serial numbers, entering data from the printed documentation, etc.

And the problem, insofar as Charles Miller relates, is when legitimate users are penalized because the publisher or his server is afraid one legally purchased copy of the product has become thousands of stolen copies. It is always at the discretion of a businessman to decide what person he would like to do business with. It is also at the discretion of a person to decide what type of company will get his business. Some things you accept as a cost of the relationship, be they qualities of the software, customer support or payments.

A software publisher must decide a multitude of issues that relate to his customers: the features in his software, technical support, sales and distribution channels and how to combat product tampering and theft.

Anti-theft measures, such as serial numbers and product activation, generally operate by disabling functionality unless proof of ownership is demonstrated. For an RSS reader, which requires Internet access to begin with, it’s reasonable for the program to require validation with the publisher’s database of purchasers. However, it’s also reasonable for a purchaser to be able to re-install the software on at least the same machine as often as his needs dictate.

Now, given the choices between entering a serial number and your email address to activate a program, it seems to me to be easier to remember your email address. But then it’s also easier for a thief to guess at as well. And figuring out who holds a license for your products versus who’s broken into them requires additional manpower and overhead. Is the amount of sales that are protected worth the cost of one-upping the determined thief and degrading my customer’s experience, albeit slightly?

This was one of the bigger issues I’ve wrestled with as my own product nears completion, and when I began writing this entry I was determined to ship it with a product activation scheme as a theft deterrent. However, given its product category, the resources and delays associated with incorporating and maintaining some anti-theft scheme I’ve decided to forego adding one.

Not only do I want to remove every impediment to my customers’ enjoyment of the software, I want to reduce the friction and suspiciousness which every customer touchpoint sustains as a result of the “proof” dance. It makes for a better experience for my customers and myself.

Purchasers will be able to download a copy of the product they licensed, and the updates, as often as they need to, whenever they need to and whereever they need to without having to activate or register the software to use it. (After all, they’ve already purchased a license so I should know they’re registered, right?)

The only requirement for running the software is to have a copy of it. It won’t be keyed to a particular machine and it won’t report a customer’s activities back to HQ. The only mechanism that will be in place, and I’m explaining my planned implementation now in the interest of privacy advocacy, is licensees will need to use a licensed email address to download the initial purchased version or an update. The program will only submit the email address (as well as machine type and MOX version) when checking for updates, and the default setting for automatic checking is off.

In addition, customers will be able to track their downloads and, if they so desire, create an optional password to restrict access to downloads

What about the thieves? Well, the determined thief will have stolen regardless of company policy. The casual thief won’t find it as tough to steal from me as he would from others, but I hope my software is considered so valuable to potential customers that they would still consider it a bargain at several times its price.

Neither, it appears, do New Media folks.

Here’s one who does, though. (This lesson may also apply to developers tied too closely to the Mac platform.)

Apple, fresh from delivering AppleTV and in the middle of pushing iPhone out the door, has announced a delay in the planned shipping date of October 2007 for Mac OS X (MOX).

While some bloggers denounce Apple’s claim as deceitful (there isn’t even an entry in its press releases, only a statement for April 12, 2007 on the Hot News page), I’d say it’s more likely a half- (or less) truth. There are plenty of causes for MOX’s delay.

Apple knows it has a process problem. Steve discussed only the AppleTV and iPhone during his MacWorld 2007 keynote.

Apple has a huge backlog of duplicate and unresolved bugs in its radar database. My own entry is #3665065, entered on 23-May-2004 12:26 AM and still open.

Apple doesn’t eat its own dogfood.

Apple doesn’t have enough bodies to handle its current plans. Here’s a listing of the groups with current software engineering needs from a recent job posting:

The following teams at Apple are now hiring:

- X Grid
- Core OS
- File Systems
- Build and Integration
- Kernel Development
- Vector Numerics
- Java
- Networking
- QuickTime
- Compiler
- User Interface
- Graphics and Imaging
- Frameworks
- Security
- Localization and Release Engineering
- Core Audio
- Video Codec
- Desktop Management Solutions

On top of that, the Professional Audio, Professional Video, FileMaker, Desktop Apps (incl. iTunes), Interactive Media, iTunes Store, iPod, AppleTV and other teams I wouldn’t even guess about need developers to develop products currently on the market as well as future goodies and you can see why Apple’s in the pickle it’s in.

After working to release AppleTV and iPhone with their own variants of MOX, the Leopard team most likely has to reintegrate those branches back into the main branch. As a bonus, they will most likely develop some inability to let you run an AppleTV as a standalone MOX system in the future and cripple the iPhone’s OS to prevent that sort of thing as well.

There are serious scope and process issues within Apple’s development groups. Do not expect a speedy resolution.

[Update - 2007-04-20] Here’s another loss to one of Apple’s product teams. His story is far more indicative of Apple’s problems.

It takes a small man to criticize and undercut others for the sake of attention.

It takes a small man to lash out at another because he feels slighted or put upon.

It takes a small man to blame his cronies when the consequences of their actions brings more than he expected.

It takes a small man to shy away from doing the right thing because it isn’t popular.

It takes a big man to show just how small a small man really is.

There were no big men in this little sideshow, although the Rutgers University women’s basketball team stands slightly above the rest.

Jeff Langr wrote about the importance of pair programming, which I’ve already discussed before.

However, one important issue he raises is what to do on non-paired time. The tasks he outlines are very important for any agile project as they definitely will increase your overall velocity.

His list:

• work on any non-production code: the acceptance test framework, other tools, build scripts, etc. In most shops, these are in dire need of attention.
• work on documentation
• work on spikes for future stories
• learn how to use a new third-party product; learn a new coding technique; and so on
• identify problem spots in the production code that need refactoring
• refactor tests
• improve the existing test coverage if necessary

I would augment “learning to use a new third-party product” to be “learning to use the software development tools at your disposal”. How much extra effort are you expending because you don’t use a document versioning tool in your workflow, or you aren’t using a source-level debugger, or don’t fully know the features and commandset of the debugger or text editor you use? How many possible bugs would you catch if you enabled certain warnings on compiles, or used a test coverage analyzer or performance profiler (e.g., gcov and gprof respectively)?

Here’s a great quote from Mike Ash:

“not knowing how to use the right tool is not a good reason to use the wrong tool”
— mikeash

Tools are probably already available for the things you need to do, so stop reinventing the wheel. After all, others have been writing software for over sixty years. What workflow-related (or even non-workflow) speedbumps could you eliminate if you just took the time to internalize a better mastery of your workflow?

How much more agile can you be if you spend a little effort improving your process?

Whom do they think they’re kidding?

This is why Microsoft is treated like the bad guys: they attempt to associate any technology buzzword or trend with their own product offerings. This is called posing.

They need to get a better understanding of credibility and community marketing.

Wagner James Au over at GigaOM reports that traditional advertising companies find marketing to the Second-Life crowd tough sledding.

I wonder what part of salesmanship they don’t understand. I guess the first point, “Know your customer.” Instead of waiting for them to beat a path to their door the suits should talk to SL inhabitants. Better yet, they should have hired a few to help them design their marketing efforts.

Hey, suits! Get A clue!

Instead of wasting ad dollars trying to force-feed your marketing message, get an understanding for what ad execs have preached was the oldest and most effective marketing technique ever.

Some bigmouth makes an ass of himself in public, and the whiners start crying about it.

He’s a shock jock, children! That’s how he gets attention. And when he gets attention he makes his advertisers happy.

You just made his job easier.

Thanks for nothing.

Technical Debt. Although it sounds more like an issue to be heard in bankruptcy court than software development. I would prefer a term like “workload debt”, but oh well.

In any case, this is precisely the term I was looking for to describe the build up of costly delays in rework due to putting off the necessary tasks of software development.

Huzzah!