An article ran a couple of days ago in the New York Times (whose coverage of technology can be spotty), entitled "The Risk of Innovation: Will Anyone Embrace It?" by G. Pascal Zachary, a Stanford journalism professor.  The thesis was pretty straightforward: "Great innovations have foundered over human stubbornness."  Just because you build it, that doesn't mean they will come.  (And should they?)

Most of the article deals with introducing a new technological development to those who don't have anything of the kind yet, such as how the cassette-player version of the Walkman essentially created the market for portable music (and portable music players).  But it also touches on how tough it can be to introduce innovation into a field where there's already been a degree of same.  To wit: the iPod, as opposed to the existing Walkman or the first generation of digital music players.  The 'Pod was actually pooh-poohed pretty widely when it first appeared, but now it's widely seen as the model for how digital music players should work.

The key word there is should.  When you innovate, you're trying to change how things should work; you're attacking some key assumptions about what you're working with.  People are naturally going to resist anything that normative, especially if it means ditching a whole slew of habits and preconceptions -- like, say, charging an upfront cost for your product.

Working with open source has some of this attached to it, especially if you don't already work with open source.  If you're a company and are preparing to open source a software product, the most likely way to do that and stay in business is to sell services, content, and support as the replacement for selling the product itself.  If you haven't already done that, though, it can be a scary transition, but there are good examples to draw on all over the place.  The other week I was looking at the open-source 3-D graphics application Blender -- which has quickly become a staple application on my machine; I'm a bit of a CGI buff -- and part of how the project is funded is not just through the sale of things like Peach, the "open movie", their tutorial DVD, and their game development kit, but also training and classes.  These are things you could probably get in some form from someone else, maybe even cheaper, but the Blender folks supply them because they're banking on the notion that you'll want to get those things from the people who know the product best: its originators.

People who start off on this foot seem to be a lot less fearful of what might go wrong than people who take an existing product and open it up, probably because they're not getting the feeling they're putting as much at risk.  (An open source product can be better than its closed-source counterparts, but that doesn't mean it automatically is.)With the latter, if your "gambit" fails -- that's a term I seem to hear used a lot when a company chooses to go open source -- your product is now in everyone's hands -- but you and your employees are no longer reaping any immediate tangible benefit.  The same hesitancy also manifests with people who put open source to work in a given environment; they want some guarantee that they will not be left to fend for themselves if it breaks, and the closed-source products they've used before have come with at least some guarantee in that regard.

I mentioned should as the key word in all this, and what's important is how these changes are spurring a lot of deep and important discussion about the nature of the should.  What should be done; what should you charge money for; what should someone expect?  Suddenly, these things aren't so obvious anymore.  Scary, and risky, but it opens up possibilities that simply didn't exist before.