Great American Garage Sale

Recently I was reading an article about how the US government was suing an Apollo 14 astronaut to recover a camera that he was trying to auction. Apparently they want it back. I'm guessing what they're going to do with it is simply put it in some warehouse like they do with everything else.

It occurred to me that the government has TONS of stuff that they could probably sell to get us out of debt. Why is the government holding on to tons of crap when they could just sell it?

When families need to get out of debt. They sell stuff. They have garage sales or sell stuff on craigslist and eBay. So why can't the government?

So here are some ideas:

  • The Smithsonian has millions of artifacts that aren't even on display. Sell them!
  • Instead of putting all the Space Shuttles in museums, take one apart. Sell the tiles. People would pay thousands of dollars for Space Shuttle souvenirs.
  • Clean out all the old junk at NASA and sell it.
  • Does the Library of Congress really need all those books? Sell some.

Wouldn't it be great on the next Independence Day for the government to be financially independent?

Can you think of any other junk the government has that it could sell?

Creating a Universal updateURL

In the discussion of the Firefox rapid release process, one of the complaints has been that add-ons that are not hosted on addons.mozilla.org (AMO) don't get automatically bumped to be current with the latest Firefox. I needed to solve this problem for one of my clients, and here's what I came up with.

Why Do Companies Need Time to Deploy Browsers?

To be clear, I mean browsers that have some level of change to them BESIDES JUST SECURITY FIXES. When it comes to security fixes, I've seen companies deploy those changes immediately.

Throughout the discussion on my previous post, the focus has been on web applications and web compatibility. I thought I'd take some time to bring up all the other issues that go around deploying browsers in an organization.

There was a statement in John Walicki's comment that was missed by most:

Education programs, documentation updates, communications all are planned.

While these changes were between Firefox 3.6 and Firefox 4 which contained major visual updates, there is no promise that these "minor updates" won't include these kind of changes as well. And these changes require all of the internal documentation to be updated as well.

IBM has hundreds of support documents, including walk throughs, screen captures, webcasts, etc. that all reference the user interface of the browser. Every single one of these had to be redone for Firefox 4 (and probably done twice because Mac and Windows Firefox are so different now). And with the new release process, changes like these could happen with as little as 7 weeks to remedy the situation.

There's also the issue of training. As I said in my last post, many companies that use these browsers are NOT technology companies. So the assumption that users will figure out how to use the browser when it changes are simply wrong. When people see things they haven't seen before, or things don't work like they did before, they call support.

Repacking for deployment takes time as well. Most companies would not want an outside entity like Mozilla to deploy software to their machines. So they have to package and certify the application. A lot of changes are also staged, so just because the browser was released on a certain date doesn't mean it will make it down to the user's machine immediately.

There are probably lots of other issues that companies run into in trying to deploy software every six weeks. I'll leave that to other folks to talk about in the comments.

CCK Wizard for Firefox 5

I've updated the CCK Wizard for Firefox 5 and placed it here.

The main change is that you can now explicitly specify the Firefox min and maxVersion when you create your XPI. It defaults to * for maxVersion so it will work on all future versions of Firefox.

Better Firefox Add-on Versioning

So I've been thinking about add-on versioning for Firefox going forward and I'm starting to think that maybe it's being done backwards.

Right now we have to change either our add-on, an updateURL or AMO every time a new Firefox is released (every 6 weeks). Wouldn't it make more sense to mark an add-on as compatible with every future version of Firefox (maxVersion of *)? Then you'd only need to do anything if you realize your add-on is NOT compatible, not change something for every version of Firefox...

Thoughts?

Don't Second Guess Your Life Redux

It's been exactly one month since I shut down my blog and dropped Twitter and Facebook. While it has been kind of peaceful in that month, I realized that I was effectively punishing myself for something that I didn't do. So I'm bringing everything back as it was before, although some posts will remain removed.

The impetus of this decision was my preparation for the message I delivered at church today, Don't Second Guess Your Life. Feel free to give it a listen. Here's the summary:

  • Don’t spend too much time looking back
  • Don’t worry about what other people will think
  • Don’t be afraid to make a mid-course correction
  • Don’t underestimate the impact of one person
  • Don’t overestimate the effect of one decision
  • Don’t keep making the same mistakes
  • Don’t just make good decisions, make wise decisions

Also, in case it hasn't been clear, we moved the family back to Texas. There's more information about that in the message.

We're glad to be home.