“In 1876, the president of Western Union brushed off Alexander Graham Bell’s telephone as little more than an “electric toy,” and the company called Bell’s proposal to put one in every home “utterly out of the question.” Oxford University professor Erasmus Wilson predicted that when the 1878 Paris Exhibition closed, the electric light would “close with it and no more will be heard of it.” A Michigan banker advised his client not to invest in Henry Ford’s company in 1903 because “the horse is here to stay, but the automobile is only a novelty.” …If there is one constant through out time, it’s that conventional wisdom often misses the mark, especially in the early days of technological transformation.” 1
I’ve never heard any individual, upon being asked what they thought of a recent automobile purchase respond, “well, it’s got this weird ‘new car’ smell, so it’s going to take some getting used to.” 2 Yet for many, such is the typical reaction to experiencing a new technology. 3
What is it about technological progress that sends many running for their digital security blankets? 4 For some reason, much of the resistance appears to be uniformed doubt (e.g., “It’s different”), rather than calculated avoidance (e.g., “It’s less secure because you can’t prevent X”). To be fair, the business world, and even more so CIO’s, see avoiding uncertainty and minimizing risk as a core competency, but I don’t think that’s the whole story.
The rapid pace of innovation has rendered many stakeholders and decision makers out of the loop when it comes to where a given technology stands in relation to their current practices, and for good reason: disruptive technology poses a risk not only on an organization level, but on a personal level as well.
- From a practical standpoint, all other things remaining constant, a firm’s move to the cloud, for example, brings into question the security of the sysadmin that has spent years building up a fiefdom of server farms.
- From a skills standpoint, there’s a whole generation out there that grew up on the Internet, and many of those in a position to make purchasing decisions or recommendation are simply not part of it. A young upstart consultant coming in and showing up the veteran can potentially be a recurring (and realistic) nightmare for many baby boomers.
- From a professional standpoint, at its most basic level, risk is taken by individuals (who propose a new system, procedure, etc.), which in many organizations may have an incentive to adopt a “don’t rock the boat” mentality for their own career’s sake, rather than risk being wrong.
If technological innovation were simply a matter of calculated risk and switching costs, one would expect firms to be equally as unlikely to upgrade an existing technology as they would be to switch to a new one. Mathematically, upgrading in-house servers to the next version of Microsoft Exchange may far outweigh a move to the cloud. Yet, large firms have been slow to make the change.
There’s a whole world out there of distributed, open innovation that, with the exception of a few startups, 5 has been widely ignored by IT departments, and as Yochai Benkler argues in The Wealth of Networks, if history suggests anything, it is that the proprietary model is on its way to the endangered species list.
So what’s the answer? How can open source fanatics and other early adopters rescue the change averse from their self-perpetuated anachronisms?
- Talk about solutions not technology – Geeks love shiny new things. It’s in our DNA. Yet rarely are geeks the one making the decisions. Decision makers could often care less which acronym powers something, but rather than dumb things down (“this thingy talks to that thingy”), translate the situation in terms of organizational change (“it will wholly eliminate the need for paper forms”). Rarely does technology change without the organization following suit. Approach the situation as a human problem, not a technical one.
- *Move past “If it ain’t broke, don’t fix it” – “It’s good enough” should never be a persuasive argument for stagnation. Just because something has been used in the past, does not mean that it should. 6 </em>In software development, changes fit into one of two categories: bugs and enhancements. Saying that something “works” ignores exactly half of the equation.
- Broadcast excellence - If you ask me why an organization should use SharePoint, I have at my fingertips focus-group tested ammunition. Ask my why you should use WordPress, and I’m left to pretty much fend for myself. Curators of innovative technology need to make themselves known, and give those empowered to affect change, the tools to do so.
The future’s coming. That’s for sure. Change is inevitable. Firms looking to seek a competitive advantage will begin to look past “it has to be expensive and complicated” and start looking toward open-source software, not as a misfit alternative, but as a viable player in the software space, but before that can happen the open-source community must step it up, and strive to be the serious competitor they wish to be treated as.
Update (9/1): Not quite “focus-group tested ammunition,” but in a sort of meta-dogfooding, I took a stab at articulating “Why WordPress.” Edits welcome.
This could arguably be, because the automobile industry has seen little innovation in the past 40 years. Beyond keyless entry and GPS, cars today are in many ways functionally equivalent to their 1970′s counterparts. ↩
See, e.g., Facebook using PHP, Twitter using Hadoop, and Google supporting Android and Chrome. ↩
Named one of the top 25 most influential people in government and technology and Fed50’s Disruptor of the Year, described by the US Chief Technology Officer as one of “the baddest of the badass innovators,” and winner of the Open Source People’s Choice Award, Ben Balter is a Product Manager at GitHub, the world’s largest software development network, where he oversees the company’s community and safety efforts. Previously, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage government at all levels to adopt open source philosophies for code, for data, and for policy development. More about the author →