Risking Innovation, And The Nature Of The "Should" - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Government // Enterprise Architecture
Commentary
1/23/2008
10:35 AM
Serdar Yegulalp
Serdar Yegulalp
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Risking Innovation, And The Nature Of The "Should"

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 sho

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

News
Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
News
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
Slideshows
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Slideshows
Flash Poll