Demand openness now

April 17th, 2008

I started reading Fast Company recently and in this month’s issue there was a pretty interesting quotation in an article about Patagonia exploring how green their products are:

Dumain concludes that the benefits of openness outweigh the costs, because the company wants to spur others to action: “Our influence is larger than our impact. If we’re willing to share that information, it becomes exponential.”

That’s a pretty powerful idea, especially when it’s applied across the business and not just to a company’s green activities.  It’s too bad more companies don’t believe in this; sharing information and being more transparent can not only increase your influence, it can also help turn customers into evangelists for your company and products.

Remember, there are plenty of FOSS fish in the sea

January 20th, 2008

I’ve been running into a fun bug with Firefox on Linux, Windows, and Mac OS X. Opening a new tab while another one is actively loading content causes the browser to crash.

As a good open source citizen, I was going to go report the bug, but then I saw the Firefox bug submission page. To summarize:

  1. Use the latest nightly build of Firefox and create a new default profile
  2. Determine which Firefox component is causing the bug
  3. Verify that the bug has not already been reported
  4. Read the bug writing guidelines

While I’m willing to do some extra steps, like capturing a backtrace, I’m not about to go jump through a bunch of hoops to report a bug that will probably sit there untouched in Bugzilla. So I didn’t bother to report the bug.

When opening bugs the onus should not be on the end user. If you want me to report bugs in your software, you need to make it take only a few clicks. I don’t mind installing debug packages as long as the heavy lifting is done for me (and I refuse to install software that cannot be managed by apt or whatever package management system is used).

There are a number of solutions that people have come up for the easy submission of bugs. Apple and Windows have built-in crash reporters. Netscape had Talkback (which is now unsupported). GNOME has Bug Buddy, and Google has released Airbag (now Breakpad).

Sadly each of these have potential drawbacks. Bug Buddy reports the stack trace, which isn’t useful if debug symbols aren’t available (you can’t tell where the various threads were when the program terminated). Breakpad and the Windows crash reporter send memory dumps, which causes me to worry about what private information is going along with it.

I’m sure others will eventually come up with a good solution to this problem, but the important thing for developers to remember right now is this: your end users have only decided to use your software; they have not agreed to be developers or your guinea pigs. Do not treat them as such, even if the bugs they submit are vague, unreproducible, or not helpful. If you upset your users, they won’t remain so for long! If it’s open source they don’t have a financial incentive to see through like commercial software licensees do.

Update: I think I should issue an apology to the Firefox team. As pointed out in a comment, the page I referenced are suggestions for bug writing. And much of my frustration lies not with Firefox, but with the usability of Bugzilla itself (and not just the Mozilla instance of it). And to be perfectly clear, it was not the Firefox project treating users like guinea pigs. Thanks to Gavin Sharp for taking the time to comment.

Thanks, but I think I’ll keep my account number to myself

December 31st, 2007

What is the risk and cost involved in having a data breach at a large company these days?

The Associated Press reported today that personal data loss hit record levels in 2007. Between the TJX break-in early in the year and the weekly reports of unencrypted tapes being lost or stolen, I’m really not surprised.

To be honest, I think companies that aren’t smart enough to use encryption for their data when it’s readily available deserve to be hit. This seems like a case where legislation to mandate back-end data encryption would be good, but instead banks are being told to add stupid security features like multi-factor authentication to secure the front-end.

What strikes me as even more silly is that given the exorbitant cost of a breach [1], companies still want to be the keepers of customers’ personal or financial data and impose fees on the customers that don’t want to share it. For example, my auto insurance company has an extra $5/mo. service fee for customers that opt to make payments themselves instead of providing bank account information to them and letting them pull the money via an electronic fund transfer (EFT).

Given that there is little to no security for most electronic transfers (all you need are routing and bank account numbers and a willing bank), I am reluctant these days to provide my bank account information to most companies. I don’t even provide my credit card number to most service or utility providers any more. Instead I use my bank’s online bill pay feature and have them push the money electronically or via a paper check in the mail [2].

But hey, instead of charging a fee why not pay me a few bucks to keep my sensitive information to myself as long as my payments are made in a timely manner? I’m doing you a favor because if you don’t have my account number, I can’t sue you later for accidentally disclosing it.

[1] The public settlement TJX made with financial institutions was around $40M and included 3 years of credit protection to consumers plus fraud insurance.

[2] Still not great, as most of these checks are done as personal checks and not bank checks (which wouldn’t include your account number), but one can hope that an electronic record containing account information isn’t created by the recipient.

The cost of supporting openness

December 30th, 2007

Jacob asks why software and hardware vendors insist on restricting their products (such as Apple’s iPod and iPhone or Microsoft’s Zune) so that customers cannot easily modify or add to the product.Having worked for an Internet Service Provider as well as a fairly large software and hardware company for a number of years, the answer that first came to mind was related to another response I wrote to him: the cost of support.

Most consumers that purchase a product want to be able to call up the manufacturer when things go wrong and expect them to be able to fix it.  Anyone that’s done technical support knows how difficult troubleshooting can be when dealing with a complex system.

An iPhone is complex you say?  Well yes, actually, when you allow consumers to arbitrarily modify or hack the software that’s loaded onto the phone.  Tracing problems to the root cause are difficult enough without having to worry about third party apps.  Maybe that one little tweak it made just caused something as subtle as a timing issue in the system, maybe it just mangled the encoding for some essential property, or maybe it just caused some unexpected memory contention the system wasn’t designed to handle (particularly with embedded systems where resources are usually limited).

Another potential issue is that hacks could run afoul of legal agreements that the vendor has made with others.  Apple had to convince the music industry that it could protect their product and wouldn’t allow unauthorized copies.  Not only could individuals circumventing the copy protection be liable, but perhaps Apple could be as well.  At the very least the industry could revoke Apple’s ability to sell or distribute its music.

And in the case of the iPhone, one serious issue I was recently made aware of is that cell phones are often designed so that apps are isolated and cannot take over the transmitter and wreck havoc on the (largely unprotected) cellular networks.

While I as a technology-savvy consumer would love to be able to hack my gadgets, I can certainly understand why manufacturers might be afraid of openness.  It’s our duty as the enlightened to help assuage their fears and to help design the appropriate solutions to ensure that the FUD doesn’t become reality.

While I’m at it…

December 2nd, 2007

Final question to empty out the pending queue…

Anyone come across any good JVM performance comparisons? Namely Sun vs. IBM. I’m especially curious about app server benchmarks and general desktop usage with Eclipse.

Comparison of web frameworks

December 2nd, 2007

Dear lazyweb,

Has anyone published an in-depth comparison of TurboGears vs. Rails vs. various servlet/JSP frameworks?

Two points that I’m especially curious about are the templating solution offered by each alternative and how easy it is to write extensions for them.

Most of the templating packages I’ve found suck because they really don’t separate the model from the view. JSP is my preferred method for building views so far, as I’m not forced to embed scripting code into the HTML and its easy to define new tags.

As for extensions, a friend and former colleague at IBM tried both Rails and TurboGears and found that writing extensions to Rails was cake compared to the hoops he had to jump through for TG. I’m wondering if this is a common experience or whether his particular situation was an oddity.

Proposing new solutions to IT problems

December 2nd, 2007

Jacob, I’m sure you’ve already considered this, but keep in mind that cross-platform support and technical superiority don’t always cause universities or enterprises to make changes to their IT infrastructure.

Two primary things to consider when proposing Zimbra as an alternative to Exchange are the availability and cost of support as well as the cost and effort required to migrate the University to a new solution.

From looking at the Zimbra site, the University would likely need to purchase their premium support option in addition to the base Network Edition software subscription.  Here’s hoping the sum of those prices is less than the potentially steep discounts Microsoft can afford to offer for Exchange pricing otherwise you can forget Gard et al. from considering it seriously.

From the stone age to the future in 6 weeks

November 17th, 2007

The day I walked into VMware it started. It didn’t hit me right away, but by the end of the day I was surrounded by it: virtualization. It ran on my development server (ESX 3), it ran on my laptop (Workstation 6). Everybody in the company seems to run one of our products on some machine of theirs, whether it’s ESX, Workstation, or our Fusion product (which I look forward to trying very soon).

Virtualization isn’t new to me. I’ve been using it for 4 years, but mostly on IBM mainframes. What is new is being surrounded by it. All of my work has been in virtual machines and you quickly come to recognize the power of taking an entire system and transferring it from your workstation to your laptop, or letting your teammates capitalize on your labor and get copies of a VM you spent days setting up and tweaking.

Yesterday I found myself wanting to use Drupal for a new project, because someone is always talking about it (and happened to coauthor a series of articles on using it). But Ubuntu doesn’t have the latest release and I was reluctant to install Apache, MySQL, and Drupal on my desktop PC.

What did I do? I downloaded the VMware Player, snagged a minimal Ubuntu server appliance from the Virtual Appliance Marketplace, and installed it all there. Problem solved. In about 15 minutes even.

I’m now wishing that I had a beefier PC at home to run additional VMs. And no, I have not had any Kool-Aid or taken any blue pills. It’s easy to win someone over when the product is good.

Changes

October 18th, 2007

Stacy and I are now living in Massachusetts and I am working for VMware in Cambridge. Great company, awesome products, and the area is pretty cool too. That is all.

They’re like ASCII windows into our lives

September 2nd, 2007

As part of the preparations for our move to the Boston area next month, I’ve been shredding old receipts I had saved for some reason. It was rather enlightening to look back on what I’ve been doing for the last two and a half years.

Most of the receipts from 2005 were from Potsdam favorites such as Eben’s Hearth (big beers & wings), Maxfield’s (beer), P&C (beer), T&R (liquor), and Sergi’s (fat bags). Looking back on it, I can see where my spending and temporary drinking habits started, as illustrated by the daily Maxfield’s receipts between April 1st and May 8th and the weekly trips to Eben’s before COSI meetings that spring.

You can even see how my habits have changed. There are plenty of receipts from Starbucks and the Eveready Diner in the fall of 2005.

There are better ones too, like December 17, 2005, when Stacy and I went to New York City for the first time. The receipts reveal the plans for the day: a train ride down & back, coffee at Dean and Deluca, cheesecake at Roxy’s in Times Square, dinner at Planet Hollywood (it sucked), a quick stop at Starbucks, and then Fiddler on the Roof on Broadway. Reading through them the whole trip came back to me.

Stacy always asks why I keep receipts. Now I have an answer. Because they’re just as revealing as photographs.