Enterprise, Open Source, and Why Better is not Enough

TL;DR: 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 strive to be the serious competitor they wish to be treated as.

4 minute read

“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.” ¹

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.” ² Yet for many, such is the typical reaction to experiencing a new technology. ³

What is it about technological progress that sends many running for their digital security blankets? ⁴ For some reason, much of the resistance appears to be uniformed doubt (For example, “It’s different”), rather than calculated avoidance (For example, “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, ⁵ 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. ⁶ </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.

Notes:

Penenberg, Adam L. (2009–09–25). ViralLoop: From Facebook to Twitter, How Today (p. 220). Hyperion. Kindle Edition. ↩
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, Gawker, Twitter. ↩
Full disclosure, some may argue that I myself risk falling off the bleeding edge of the technology adoption curve, after all, I text in beta, browse in canary, and publish in trunk. ↩
See, for example, Facebook using PHP, Twitter using Hadoop, and Google supporting Android and Chrome. ↩
See, for example, bloodletting. ↩

Originally published August 31, 2011 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit