In his recent blog posting, "Tenets of Transparency", Eric Sink says that if independent software vendors (ISVs) aren't willing to trust their customers, they won't have any. When customers buy software from you, they trust that:
your product will work on their machines;
you will help them if they have problems;
you will continue to improve the product;
you will provide them with a reasonable and fairly-priced way of getting those improved versions;
you are not going out of business anytime soon.
So, they have to trust you; Eric's question is, how do you show that you trust them in return? His answers are:
Have a corporate weblog, so that customers can keep track of what's really going on.
Offer web-based discussion forums, so that they can talk to you, and to each other.
Don't hide your product's problems.
Don't annoy honest people with measures designed to block the dishonest few.
Offer a painless demo download.
Offer a money-back guarantee.
Share a little about your financial standing.
Talk about your future plans.
I'm not an ISV, but I am involved with some open source projects, and university courses, so how do they measure up on this scale? Most open source projects now have a weblog of some kind, and they've always had discussion forums; their problems are out in the open, they don't include anti-piracy and licensing cruft, and the "demo" is the product itself.
But what about the money-back guarantee? As many people have observed, "free" software is only free if you think your time is worth nothing; you can easily waste hours or days trying to install, configure, and debug an open source package, and if you do, no one will give you that time back. As for Eric's last two points, they're mostly about giving people confidence that you'll still be around next month or next year, so they won't have to throw away what they've done and start over with some other package. Open source falls down here---except for very large projects (like Apache and Python), there's a very real risk that people will lose interest, have to go earn a living, or squabble, all of which can lead to the project suddenly being dead in the water. Take Groovy, for example: twelve months ago, it was the Next Big Thing in Java, but now---well, there's still a pulse, but I don't think anyone's expecting it to ever ship anything useful.
What about university courses? It may seem odd to compare them to commercial software, but I think it's helpful to think of courses as products, which are "bought" when students enrol in them. Most courses don't yet have a weblog, although Trac automatically generates one for my students' CSC49X projects, and I'll use one for course announcements the next time I teach a regular classroom course. Web-based discussion forums? Sure, we've all got those. Hiding the product's problems? Well, students usually find problems (errors in notes, ambiguities in assignments) before profs do, and they're encouraged to post their findings.
How about not annoying honest people for the sake of preventing dishonesty? I think this is one of the places where courses have to be measured differently from products. As instructors, our goal is to educate, but we're also responsible for assessing students; we can only do that fairly if plagiarism and cheating are i, even if it means making honest students' lives a little more difficult.
Offering a demo doesn't really apply (unless you count keeping last term's notes on-line, so that students can see what they're getting themselves into). Offering a money-back guarantee is an interesting idea: when I was a student, I thought universities should let each graduating class vote on what their worst course had been, and refund their tuition for it. Now that I'm an instructor, I can see a lot wrong with that idea... ;-)
Financial standing? I don't think it applies (although the next time I run a course, I'm going to keep track of how long it takes me to write lectures and create exercises, and post that on the course web site). Finally, I think it makes a lot of sense for instructors to talk about future plans, i.e., to tell students how the material they're learning fits into what they're going to do next term, next year, or after they graduate.
comments powered by Disqus