Eweek magazine is the latest to jump on the “Green Issue” trend this month (enough already). Within it are the numbers I have been looking for to justify the very ungreen practice I have of never shutting off my computers. As a CTO and software guy, I am at my computer throughout the day and night, and I can never stand to wait through the 2-3 minute boot time so I can do a quick check of whatever information I need at the moment. It seems that many corporations are frowning at this practice, installing software on their computers to shut them off each night, or after certain periods of inactivity. Eweek says “…the savings can be significant…you can save anywhere from $25 to $75 per PC per year by using the power management features on your PC.”

Let’s run the numbers, shall we? We’ll take the high side, at $75 and compare that to the time wasted waiting for the PC to boot. Best case, we’ll say it takes 2 minutes to be completely up and running, with all required software up and running also. At 50 weeks per year (2 off for vacation), that $75 savings is a break even point for an employee that gets paid … wait for it … $9 an hour. It doesn’t take a rocket scientist to see that turning off the computer makes no business sense. Does it “save the earth’s resources” by using less electricity? Of course. Does it make any kind of economic sense? Of course not. However, idling the processor when not in use makes sense, but shutting down the machine entirely does not.

A mentor engineer of mine at my first job showed me how many of these “save a little here, save a little there” types of decisions make no sense, especially in high-tech companies. I remember his point about getting the engineering managers to not be so cheap, and buy the engineers a new computer every once in a while. We wrote our code in C, so we were constantly running compile cycles. He demonstrated that if a faster computer, over all your compile cycles that day, saved you just 10 minutes a day, for a $75k engineer, that works out to be a $1,562.50 savings for the entire year. Hence, a brand new $1200 computer once a year could be a savings to the company. Imagine that.

It pays to run the numbers on all the silly cost savings corporations try to push down the ladder. They’re better off spending some money and getting down to business.

Over on TechCrunch, there is post about the new Mundu chat software for the iPhone that I have to take issue with. It makes some ridiculous statements about the price and pricing of software, but if you can get past (and discard) those statements, the argument may be sound.

In a nutshell, Mundu wants to charge $11 lifetime to use their web-enabled iPhone chat software/service, and Nick thinks they are out of their minds to be charging money. He makes two statements that are absolutely ridiculous in defense of his argument:

1) “There are way better ways to monetize software. Offer a free version and drop an advertisement …”
2) “The marginal production cost of software is zero. That’s what the price should be.”

If there are “way better ways to monetize software”, then why are two of the richest people on the planet sellers of software? Being a fan of all the new concepts, services and software falling under the Web 2.0 umbrella, this is the one part of this movement that I can’t always agree with; software should be free, supported by advertising. I can’t find the site now, but several months ago I went to a new Web 2.0 service that was launching, and on its front page it said something like “It has become accepted that this type of service should be free, and be supported by advertising”. Wow, way to be proud of the service you’ve built and the expectations of your users. You’ve just said your software isn’t worth much to your users, and its best feature is that it can be turned into a billboard.

Next, we have the almost-always true statement “The marginal production cost of software is zero.” followed by the utterly ridiculous “That’s what the price should be.”. Yes, that is one of the beautiful things about software compared to hard goods; the marginal cost of production of a web service/software is zero. Marketing guys love to take this fact and extrapolate it into all kinds of falsehoods, like “therefore the cost should be zero”, or “so giving away 100 copies for free costs us nothing.”. Wrong. What really matters is the marginal cost of distribution, the cost to have another person use the software. There are support costs, upgrade costs, and for web services, additional server and bandwidth resources, which cost more money. Having the marginal cost of production be zero means you can put a zero in your spreadsheet for that category, where you could not for physical goods, and that’s all, nothing more.

If I can take serious liberties with what Nick has written, I think under there is a good argument. If we can say “There are way better ways to market this type of software at the point in time they find themselves”, then there is value here. As he notes, Mundu’s main challenge is to get a critical mass of users before Apple releases their own chat application for free. To do so, he asserts that Mundu needs a freemium pricing model; free with advertisements, or paid with no advertisements. I’m a big fan of this model, as it allows users to try the service, and make some money from the users who would never pay for it in the first place. It also allows users who find it valuable to pay for it, and clear up some of the valuable screen space (incredibly valuable on a handheld device) that would have been taken up by ads.

However, getting a critical mass of users to beat the big guy to the punch is not the only way to make money, nor is it the best. The best way is to make a superior product, and people will have no problem paying for it. I know this for a fact, because I am in the middle of a 14-day trial period for some contact software for my Windows Mobile phone that is far superior to the built in stuff, and I’ll definitely pay the $30 after the trial is up.

So the takeaways from this are: 1) If you want to make some money, and the 800 pound gorilla is breathing down your neck with his free version, make a superior product, and serious users will pay for it. For the rest of the users, monetize them with ads. 2) Having the marginal cost of production of software be zero only means that it is a cheaper thing to manufacture than a physical good. Nothing else.

There’s always something in the fine print of the digital download services that are coming out these days that show the big media companies “Just Don’t Get It”, and Amazon Unboxed is no different.

I was looking into the Tivo/Amazon Unboxed integration, thinking how cool it is that you can remotely buy a movie, and it will be on your Tivo when you get home, when I spotted this gem:

What is the “Pay-TV Blackout Window”?
Due to restrictions from the video rights holders, most newly released movies will occasionally become temporarily unavailable for re-download from Your Media Library—even after they’ve already been purchased.

The video will be automatically replaced and made available to you through Your Media Library once the “Pay-TV Blackout Window” has ended.

Does this sound utterly ridiculous? That’s because it is.

This is the equivalent of buying a DVD, being able to watch it for a few weeks, then having a Showtime/HBO/Cinemax representative show up at your door and take away your DVD until their channel is done running that movie. I can see that the original intention was for the pay-TV channel to be able to secure exclusive rights to a movie via “digital distribution to a video signal-viewing device” (my legal mumbo-jumbo), but this goes a bit too far. As far as I can see, this doesn’t serve anyone’s best interest, and only serves to make the Unboxed service less attractive.

We’re becoming experts in troubleshooting MP3 album art problems with various MP3 players. This time, a listener of one of our podcasts informed us some of our shows were causing his Samsung YP-Z5AS MP3 player to lock up when it tried to play some of our MP3 files. We got the exact model number from the listener, and purchased an identical one online. It came via Fed Ex today, and we got down to business.

What we discovered was that it was the album art image we were using that was causing the problem. By removing the album art, the YP-Z5 played the file just fine. In a code editor, we opened the JPG file we were using as album art, and discovered something interesting:

What we’re seeing there is metadata embedded by Photoshop in the JPG file itself. Using Photoshop’s “Save for web” functionality, we produced a JPG file with no metadata in it. Using this “saved for web” file as album art in the MP3 file caused the YP-Z5 to work properly. The wildest thing is that we had been using the JPG with metadata as album art for a long time, and a lot of other MP3s with that JPG played just fine on the YP-Z5. There must be some combination of JPG file and other data in the MP3 that sets the YP-Z5 off.

The takeaway from this: always use the “Save for web” functionality in Photoshop if you are saving a JPG for use as album art in an MP3 file. Using the “Save as” functionality in Photoshop, then saving as a JPG embeds metadata in the JPG file, which can cause MP3 players to choke.

It appears that Yahoo Mail doesn't want you pulling in outside stylesheets. When our Trader Interviews email arrived in a Yahoo Mail account, the <link> tag to our CSS was replaced with an <xlink> tag, rendering it unusable. Googling around, it appears that xlink is a valid XHTML tag, but it appears that Yahoo is using it just to break links to outside stylesheets, since they also replace a <body> tag with <xbody>. Our workaround is to replace any <link> tags to outside stylesheets with the contents of that outside stylesheet, before an email is sent. Below is a test file with the function we use to do such a thing.

For the last two days, the SBC Global network has been having severe problems, cutting us off from our server for most of the business day:

We would love to have a redunadant cable modem link to the Net via Cox, except for one small problem; our landlord refuses to let Cox onto the premises. Cox has said they "don't have an agreement with the landlord", so they can't provide us service. We're guessing that the landlords have some sort of "agreement" (kickback) with SBC that they don't have with Cox, so they line their pockets, and we feel the pain. I wonder if the Public Utilities Commission would have some jurisdiction there? Has anyone else had this experience, where essentially a monopoly is created by your landlord's business practices?

You'll notice I don't blame SBC for this. I guess it's because I've come to accept flaky Internet service from any provider, and our solution has become to get redundant flaky links, in an attempt to create one good one.

Update: In WordPress 2.1.x, the code below is now in the file wp-includes/bookmark-template.php

I wanted to put an image in the sidebar of this blog, but the default code puts a border around the image, because it's also a link. I think that's generally unattractive, but even the link editor didn't allow me to set the border to 0, so into the code we go.

In wp-includes/links.php, lines 247-249, change this:

$output .= "<img src=\"$row->link_image\" $alt $title />";
else // If it's a relative path
$output .= "<img src=\"" . get_settings('siteurl') . "$row->link_image\" $alt $title />";

to this:

$output .= "<img src=\"$row->link_image\" $alt $title border=\"0\" />";
else // If it's a relative path
$output .= "<img src=\"" . get_settings('siteurl') . "$row->link_image\" $alt $title border=\"0\" />";

and now the images under the Links sidebar won't have a border around them. Yes, I understand the border is supposed to be a visual cue that the image is also a link, but these days, most people know that things in the sidebar are generally links, plus the visual cue of the pointer changing when a user hovers over the image seems to be enough.

When compiling mod_ruby under Fedora Core 5, and thus Apache 2.2, configure.rb assumes an incorrect path for the apr* files, and make kicked out the following errors:

# make
In file included from /usr/include/httpd/httpd.h:43,
from mod_ruby.h:49,
from mod_ruby.c:33:
/usr/include/httpd/ap_config.h:25:17: error: apr.h: No such file or directory
/usr/include/httpd/ap_config.h:26:23: error: apr_hooks.h: No such file or directory
/usr/include/httpd/ap_config.h:27:32: error: apr_optional_hooks.h: No such file or directory
...

The problem is that the apr* files are in /usr/include/apr-1, which is not where make is looking. (In order to compile mod_ruby, the httpd-devel, apr-devel, and apr-util-devel packages are required, so doing a "yum install httpd-devel" installs these three packages).

To fix the problem, run the configure.rb command like this:

./configure.rb --with-apr-includes=/usr/include/apr-1

and then the "make" command will run without error.

Scott Whitney had a question for us regarding the number of downloads of your RSS (XML) file versus the number of downloads of the actual audio file (Podcast) identified within it:

Do you have any data regarding the normal ratio between number of feed downloads (the XML file) versus the actual number of audio downloads? And, any explanation why there would be a measurable difference?

Our response covers a couple of the many reasons why it will be different:

The number of downloads of the XML file versus the audio file is almost always very different, for several reasons. In a perfect world, all RSS aggregators would make use of the feature in which the aggregator asks the web server “Has this feed changed since I last downloaded it at time X ?”. If there was no new audio program in the feed, the server would respond “No”, and the XML file would not be downloaded. Only when there was a new post/program would the XML file be downloaded, as would the audio file, and there would be a 1:1 ratio between the two.

However, many aggregators do not use this feature, and just blindly pull the XML file every time, new or not. This, coupled with the fact that most aggregators can be changed by the user as to how often they check the XML file (anywhere from every minute to once a day), leads to the XML file being downloaded many more times than the audio file itself. Also, things like people opening the XML file in a browser, etc., lead to many more hits on the XML file than the audio.

I don’t have any hard data on the ratio of XML versus audio downloads, because it is all over the map depending on which podcast, time-period, etc. is looked at.

On a related note, inferring subscriber statistics from the number of hits on the XML file is very inaccurate, because of the same reasons. The number of downloads of the audio file itself is more accurate, but still not completely accurate, because of multiple downloads of the file by the same aggregator/person (more downloads than real subscribers), and services like iTunes and Odeo that cache your audio file for their users (less downloads of the file from your server than actual subscribers).

I'm surprised to find out that Bloglines does not update the favicons (the small icons that appear next to the feed name) dynamically. After quickly Googling the subject, I saw that you had to manually request that your feeds be 'updated', so that the favicon would show up. Very strange, since most other feed readers or browsers check for the favicon each time they pull the page. My only guesses are that they are doing it for bandwidth reasons, or that they don't want your brand cluttering up 'their' page.

The email:

The results: