The majority of large IT vendors today are oriented around traditional command and control structures. Specifically, they are optimized to build for and sell to an executive audience whose responsibilities include the selection and purchase of new technologies. In these transactions, convenience is not a primary concern, because the purchaser more often than not isn’t the user, and thus is more likely to prioritize a different set of features.
Over the last decade plus, this procurement pattern has been increasingly challenged by a variety of disruptive technology adoption models: among them Open Source Software (OSS), cloud computing, Software-as-a-Service (SaaS) and Bring-Your-Own-Device (BYOD). Developers, as we have asserted previously, are increasingly the New Kingmakers.
One of the biggest challenges for vendors built around traditional procurement patterns is their tendency to undervalue convenience. Developers, in general, respond to very different incentives than do their executive purchasing counterparts. Where organizational buyers tend to be less price sensitive and more focused on issues relating to reliability and manageability, as one example, individual developers tend to be more concerned with cost and availability – convenience, in other words. Because you are who you build for, then, enterprise IT products tend to be more secure and compliant and less convenient than developer-oriented alternatives.
In many cases, this is appropriate. Security and compliance, to pick two enterprise features, are material concerns for many organizations across a range of industries. But with developers increasingly taking an active hand in procurement, convenience is a dangerous feature to ignore. Consider the following short list of technologies owing their success in part to convenience.
- AWS: Servers in 90 seconds via a credit card (compare to: IT provisioning speed)
- Chef/Puppet: OSS that dramatically cuts provisioning time (compare to: proprietary IT Management alternatives)
- Dynamic Languages: OSS, faster to learn and develop in (compare to: compiled alternatives)
- Eclipse: OSS providing a full development environment (compare to: Borland Enterprise Studio/Visual Studio)
- Git: OSS that enabled decentralized development (compare to: CVS/Subversion)
- Linux: OSS that offered a free, Unix-like kernel (compare to: Windows/Solaris/AIX/HP-UX)
- MongoDB: OSS that can be used immediately with no schema (compare to: RDBMS)
- MySQL: OSS that was lightweight, free and simple to use (compare to: DB2/Oracle/SQL Server)
- REST: Simple web services using existing standard protocols (compare to: WS-*)
Few if any of the above projects and services entered the world as the most impressive – let alone enterprise-ready – technologies. Many were, in fact, compromised in fundamental ways technically. What each had going for it was convenience. They were easy to get, easy to use and were either free or extremely low cost to employ on an ongoing basis. Whether by design or by accident, developers found each convenient, and most are considered developer staples today as a result.
Many vendors struggle to understand the lagging adoption of their offerings, focusing on the technical merits of their product versus the competition: it’s an industry bias. In general, they would do well to consider a wider context, one that considers the mechanics of technology adoption (related: Kohsuke Kawaguchi’s 2012 Monki Gras talk about the funnel of OSS community building) equally important to the technology itself. Examples of adoption friction:
- Cloud services or SaaS applications that require you to talk to a salesperson or do not take credit cards
- Free products or documentation that require users to register with contact information before download
- Free products that are functionally limited (e.g. CPU count, node size, etc)
- Free products that require the purchase of a separate product to function properly
None of these strategies are intrinsically bad, as long as the organizations employing them understand that they will be at a substantial disadvantage relative to competitive projects subject to none of the same restrictions. As Wikipedia administrator wrote of the Encyclopedia Britannica: “it’s hard to compete with free.” There are ways of competing, of course – data being one – but devaluing convenience is generally not a recommended approach.
Convenience does not trump all, as Matt Asay asserted, nor should it. Organizational development must balance convenience against traditional enterprise concerns. But with developers increasingly empowered within today’s enterprises (like it or not), expect that equation to be far more balanced, because for developers convenience trumps most other technology characteristics.
