This is it. I won’t have time to work on PackRat very much any longer, though I can certainly oversee development a little. Some generous offers of help recently have given me the final nudge towards opening up the PackRat sources to the public.

Let’s hope this will revitalize the project a little. It’s a shame to see it stagnate for so long; I still like using it myself.

I’m sorry to announce that PackRat will no longer be updated. I should explain.

As you may have noticed, updates to PackRat — or this blog — have been relatively scarce these past months. While for a large part my work is to blame for that, it’s not that I’ve been entirely idle, and have worked on PackRat improvements.

There’s a plethora of things I started to implement or improve. Most notably, though, are a cloud synchronization service. In order implement the client side of that, I used a number of open source libraries from the Apache Software Foundation that happen to implement JSRs, that is, specifications by the Java Community Process of which the ASF has been a part.

The part of their rationale that concerns PackRat directly is that they concluded the JCP makes it impossible for them to guarantee that users of their open source JSR implementations are protected from IP litigation. Failing to have the legal resources the ASR can muster, I choose to believe their interpretation.

In other words, if I were to publish the current PackRat codebase, I could be sued by Oracle. Given that this is a hobby project from which I generate no income, that is not a risk I am willing to take.

I have two options now:

Reimplement those open source parts I’m using in a manner that is not in accordance with the JSR, making them original designs, or

cease to publish updates to PackRat.

Given that my time has been short of late and my progress on updating PackRat slow, I do not think that the first option is feasible. I therefore conclude that I must cease to publish updates to PackRat.

I’m very sad it has come to this. I feel like I’m letting you down, even though rationally, it’s Oracle’s fault. I hope you will continue to enjoy the current version. And maybe, some day, I’ll either have found time to work around this or Oracle has seen the light. They’ve already sued Google, so I kind of doubt the latter will happen.

If you’re a happy Nexus One owner and are eagerly awaiting the latest Android version 2.2 (aka FroYo) to magically appear on your phone, wait no more! A few days ago I forced my N1 to upgrade, and I’ve written up instructions on how to do that here.

It worked like a charm for me. Of course, the usual health warnings apply, and remember to make backups of everything you really need.

This release is mostly thanks to Mark Sunderland, who thankfully pointed out to me that PackRat’s lending feature does not work on HTC Hero phones that were upgraded to Android 2.1-update1. That’s now fixed — and kudos to Mark for helping me circumvent that bug in HTC’s upgrade!

Other than that, I managed to solve a rare and vexing issue where items you scanned or searched for might be added to the database without you selecting to do so. This fix does not remove those items, though — it just prevents the same from happening again. If you want to remove these items, long-press on them in the shelf and select the delete option.

Next, on Android 2.1 and 2.2 the search might crash when searching within PackRat via the hardware search button.

It’s been a busy few weeks since the last release, and that prevented me from pushing updates recently. But I’m glad to say that nothing terribly bad seems to have happened since then.

This release fixes one fairly strange issue: if you added an item to the loan list, then from there to the wishlist, and then removed it from the wishlist again, it would not be back on the loan list, but it would still have a due date and loanee contact set. The due date and loanee are now cleared if an item is moved to the wishlist — after all, how can you lend something you don’t yet have?

I receive a decent amount of emails from you guys out there, detailing what you think PackRat is good or bad at, telling me about crashes, etc. Today I received an email from a user that first astounded me, then angered me because I found it offensive, but that I then realized really requires answers. It concerns your privacy, and pretty much asks the question what sort of data PackRat tracks, and what other hidden behaviour it has.

Now a lot of that I’ve covered in a previous post about privacy. I won’t repeat it again save to say that under some error conditions, PackRat sends just enough information to tracking servers for me to figure out what the problem was and fix it.

But that previous article skips over the fact that PackRat tracks some information under normal operating conditions. Let me explain what that is and why.

Another week or so passed, another bug fix update. I’m getting into a rhythm here, hope I can keep this up. The good news is that the overall number of bugs is dwindling. The bad news is that as some bugs get fixed, the route gets cleared for you to encounter others.

This week’s batch of bugs was the usual mixed bag of force closes and minor annoyances. But I’m glad to say that the minor annoyances seem to outnumber the force closes by now.

Here’s what’s really weird, though: about two thirds of the errors reported occurred on the HTC Droid Eris. That’s quite a big number. So either that phone is selling like hot cakes, outselling the Motorola Droid — but that doesn’t seem entirely likely.

Or, and that’s a more reasonable assumption, the Eris is particularly prone to producing errors. Now for that second theory, I can come up with two possible explanations again:

The hardware or software on the Eris is flakey.

The hardware of the Eris is outlandishly fast and/or different so that weird race conditions get triggered that no other phone managed to trigger to date.

While there’s absolutely a chance that it’s the latter, the specs don’t really show the Eris to be all that different from other current HTC phones. Hmm. If I were a betting man, I think I’d bet on the first being the reason. And that means, I’d stay away from the Eris for now.