Blogs

RedMonk

Skip to content

The Prisoner’s Dilemma and the Folly of Keeping Technology Adoption Secret

There are very few businesses today – maybe none – that are not technology customers. Every business large and small has made decisions about what technologies to use. Whether that’s buying a few Apple laptops for a kindergarten or ten thousand Linux based servers from an ODM in Taiwan for a service provider, businesses choose technologies constantly.

But while the individual decisions themselves may vary, the one thing most businesses – the larger ones, anyway – have in common is that said decisions must be kept secret. Large enterprises are famously secretive about their technology stacks. The vendors that work with them are prohibitied, typically contractually, from disclosing that a given enterprise is, in fact, a customer of theirs.

Which is ironic given that this usage is something of an open secret. As anyone who’s been briefed by a vendor is aware, the one thing that is in every briefing deck is a slide full of customer logos. While the slides used with the press may only contain the customer logos that are allowed to be there, the ones used with analysts frequently contain all the relevant customers, public or private. The secret usage history is safe, then, only from the press and from the businesses themselves.

There are many reasons for this practice. Some customers, such as those in government, are not allowed to disclose whether someone’s a customer for fear of appearing to endorse a given vendor. Other customers withhold their asset – the right to use their name publically – in search of an economic return; price discounts, more lenient licensing terms or other similar perks. And still others believe that their technology selection constitutes a competitive advantage.

It seems increasingly clear, however, that whatever the expected returns, the costs of this practice outweigh them. Here are three reasons to consider dropping the policy of secrecy regarding technology usage.

It Helps With Recruiting

It’s no secret that the market for development talent is historically tight. Recruitment, therefore, is both a challenge and – for those that identify inefficiencies – a potential competitive advantage. Today, your average Fortune 500 organization is, or at least aspires to be, a black box. Words like “agile” and “innovative” are tossed around, but there’s very little discussion of what actually goes on and what is actually used.

In this seller’s market, however, developers are generally free to pick and choose opportunities based on the technologies that they want to work with. If they want to learn and work with something new and interesting like Nginx, for example, they’re likely to find an opportunity to do so.

If ten businesses are using Nginx, then, but nine keep that a secret while one is public about that usage, which has the best chance at recruiting said developer?

Secrets Cost Money

One of the common justifications for keeping usage information confidential are the commercial returns mentioned above; pricing discounts and the like in return for the right disclose. The question businesses should be asking, however, is what the costs are to this approach.

As in the prisoner’s dilemma, enterprises’ refusal to cooperate with one another with the free exchange of information hurts everyone involved. Tyicallly, the only party that enterprises freely disclose usage to are industry analysts. These analysts then happily aggregate and anonymize this previously private information, then sell it back to the businesses that could have shared it freely with each other. Because each business jealously guards information about its technology selection, then, it is compelled to pay for the secrets that it and its counterparts are keeping.

It’s Not a Competitive Advantage

Unless you’re Google or Facebook, technology selection is unlikely to be a competitive advantage. In a world full of webinars and whitepapers, the days of asymmetrical technology adoption are, for all intents and purposes, over. The competitive edge is likely to derive instead from people.

Access to and awareness of Hadoop, for example, is generally symmetrical within a given industry. Access to resources with the business knowledge to understand what questions to ask and the technical skills to answer them, however, is very uneven. As we’ve seen, keeping technology investments private may negatively impacting recruiting. By not disclosing Hadoop usage, then, enterprises are effectively preserving a non-existent competitive advantage at the expense of the one thing that could improve their businesses: better people.

by-nc-sa

Categories: Enterprisey.

The Open Source Implications of the CloudStack Announcement

Most of the commentary regarding the donation of the CloudStack assets to the Apache Software Foundation by Citrix yesterday has centered around the landscape implications. This is understandable, because CloudStack’s break from OpenStack has an impact on multiple communities.

Given the stakes involved with the cloud market, the growing number of market entrants is no surprise. Incumbents like Microsoft and VMware cannot afford to be locked out of the cloud; what’s more, each vendor’s leaership understands the financial opportunities associated with owning the platform. Amazon, which is for all practical purposes the Microsoft or VMware of the cloud, can and will leverage their position to simultaneously undermine competitors and preemptively defend lines of attack. If this means creating ancillary private cloud markets and leaving money on the table in the process – as they may with Eucalyptus and now CloudStack – so be it. Everyone who’s not Amazon or aligned with them, meanwhile, from Joyent to Rackspace, is intent on ensuring that Amazon’s tenure as the Microsoft of the cloud is as short as possible. If that means open sourcing what would have been considered core software in the process – as with Rackspace and OpenStack – so be it.

That landscape, as convoluted as it appears, is fairly well understood within the industry. While everyone wants to predict outcomes on project and API futures, the fact is that it’s too early in most cases to project accurately. The CloudStack transaction, however, does make obvious certain facts regarding the licensing mechanisms and governance models employed by the various projects.

Permissive Licensing Continues to Make Gains

Since 2009 we’ve been predicting (and observing) gains for permissive licensing at the expense of copyleft or reciprocal alternatives. Reciprocal licenses, which require that any changes to a licensed asset that are distributed be made available under the exact same terms, have in the past been employed to disincent forks and to create artificial purchase triggers (e.g. dual licensing). As forks have become something to encourage rather than fight, however, one justification for the usage of copyleft licenses has faded.

Faded to the point that permissive licenses are increasingly seen as a license of choice for maximizing participation and community size. It’s not true that copyleft licenses are unable to form large communities; Linux and MySQL are two of the largest open source communities in existence, and both assets are reciprocally licensed. But the case can be made that this will in future be perceived as anachronistic behavior.

Commerical entities in particular favor permissive licenses like the Apache Software Foundation’s , because they impose very little overhead. As Cloudera CEO Mike Olson – whose first business was built around reciprocal licensing, but whose Hadoop business is built around Apache – says of permissive licenses, “There’s very little legal complexity for people to deal with.” Permissively licensed assets can be repackaged and sold as closed source software, for example, per the terms of the license itself. For projects, then, that wish to encourage the participation and engagement of commerical vendors, the permissive license can be a good, differentiating, choice.

Citrix is being less than explicit about this, but it is probable that as they continue to build an ecosystem around CloudStack, one of the “features” they’ll cite is the permissive license which allows would be players to leverage the code however they see fit. Contrast this, for example, with Eucalyptus, which is at present governed by the reciprocal GPLv3 license.

The same license, in fact, that CloudStack left behind in favor of the ASF’s more permissive license.

The Asymmetry of Permissive vs Reciprocal

Permissive licensing isn’t an unequivocal win for the CloudStack project, however. Underreported is the licensing asymmetry created by Citrix’s relicensing of the CloudStack assets. Because of the licensing mechanisms involved, the Eucalyptus project will now be able to incorporate code from CloudStack – or OpenStack, for that matter – at will. Technical innovations within Eucalyptus, meanwhile, are protected from usage by permissively licensed cloud stacks. Code sharing, in this case, is unidirectional towards Eucalyptus. CloudStack also forfeits similar protections from the OpenStack project; anything that OpenStack wishes to consume from CloudStack, they will now be able to, per the terms of the new licensing scheme.

Historically, this has not been a particularly important dynamic. MySQL, for example, has no major history of incorporating code from the more permissively licensed PostgreSQL. But with the cloud stack projects’ broader scope and mandate, it is not out of the realm of possibility to believe that Eucalyptus may opportunistically incorporate features or components from CloudStack, OpenStack or both.

You Won’t Get Fired for Using Apache

In the wake of GitHub’s meteoric ascension, there have been many questions about the role of open source foundations like Apache or Eclipse today. There are those who argue, in fact, that they have outlived their original purpose; see, for example, Mikeal Rogers’ “Apache Considered Harmful.” But while it is certain that foundations will need to adapt to changing needs, there are many reasons yet to justify their existence [coverage]. One of which is branding.

Citrix was very careful to put the Apache Software Foundation front and center in their announcement. This does two things. First, it allows them to benefit from the halo effect of the Apache brand and the goodwill of becoming a sponsor. Second, it differentiates them from two of the more visible alternative open source cloud stacks. Eucalyptus is primarily a single vendor initiative, much as MySQL once was. OpenStack is developed by a broader community of participants, and is being transitioned to a foundation. But that process has not been without its growing pains, with one of the co-founders questioning the governance structure.

Contrast that with CloudStack and the ASF. The latter is a known quantity, and vendors like IBM have historically advantaged Apache at the expense of independent foundations (e.g. their OpenOffice.org participation). What the ultimate impact of the Apache brand will be on CloudStack’s visibility and traction remains to be seen, but it’s undeniable that the Apache brand is being positioned as a feature for the project.

Disclosure: The ASF, Citrix, Eclipse Foundation, Eucalyptus, GitHub, Joyent, Microsoft, and VMware are clients. Rackspace has been a client in the past. Amazon is not a RedMonk client.

by-nc-sa

Categories: Cloud, Open Source.

Eucalyptus Doubles Down on its Amazon Bet

Born as a research project in the computer science department at UCSB, Eucalyptus the company was founded in January of 2009. Originally intended to replicate a subset of the Amazon cloud’s featureset in software that could be run locally, one of the project’s primary differentiators was its compatibility with the Amazon API. Importantly, however, this support was unofficial: Amazon neither supported nor legally blessed this feature. Which meant that its appeal was throttled by the uncertainty of Eucalyptus’ legal footing. More than one large vendor has privately characterized the Amazon API as a “non-starter” because their legal departments could not be assured of Amazon’s intent with respect to the intellectual property issues involved.

Meanwhile, a year and a half after Eucalyptus was commercialized, NASA and Rackspace jointly launched their own cloud project, OpenStack. While the initial versions were closer to a set of tools than the stack the name implies, OpenStack had an impressive partner roster at launch. And industry skepticism of the level of commitment of those partners has been offset with sustained momentum. Due in part to its more permissive licensing – OpenStack is Apache licensed, while Eucalyptus is reciprocally licensed under version 3 of the GPL – the NASA/Rackspace effort has enjoyed wide corporate interest and support. From AT&T to Dell to HP, OpenStack’s traction has been such that even skeptics like IBM and Red Hat have lately appeared to be moving towards acceptance of the project.

For all of OpenStack’s momentum, however, Amazon remains the dominant player in public cloud, with one researcher estimating its datacenter size at just shy of a half a million servers. Amazon itself has validated external estimates of its growth trajectory, saying (PDF) “Every day Amazon Web Services adds enough new capacity to support all of Amazon.com’s global infrastructure through the company’s first 5 years, when it was a $2.76 billion annual revenue enterprise.”

The question facing Amazon was if, or perhaps when, interest in on premise functionality would become sufficient to incent its participation – whether through build or a partnership – in private cloud solutions. The answer to that question appears to be this year. In January, the retailer turned technology giant announced the availability of the Amazon Storage Gateway, a virtual machine run locally that bridges data to Amazon’s storage service, S3. And then this morning, Amazon announced a partnership with Eucalyptus. As Om Malik put it, “On paper it looks like one of those strategic agreements that large companies sign-up with small startups,” but the announcement belies the larger significance. Amazon is, for the first time, playing the intellectual property trump card it has been holding in reserve.

By strategically and selectively removing the uncertainty regarding its APIs, Amazon gains literally overnight a credible private cloud offering, minimizing that as an angle of attack for competitors who might otherwise attempt to sell against Amazon by emphasizing its public cloud-only technology story. Nor does it have to deviate from its public cloud orientation by creating a more traditional software organization. This deal instead effectively outsources that to Eucalyptus.

Eucalyptus, for its part, may now realize the full potential of its differentiated access to Amazon public clouds. As Amazon’s only approved platform, it can expect its attach rate within organizations consuming Amazon cloud resources to improve substantially. While the deal is apparently not exclusive, OpenStack is not likely to either ask for or receive the same blessing from Amazon that Eucalyptus received. Assuming that the API licensing would survive a transaction, Eucalyptus has with this announcement substantially increased its valuation. The success of one organization is the success of the other; wider Eucalyptus adoption poses no risk to Amazon’s growth, while its success would push Amazon’s APIs closer to becoming the de facto standards of the public cloud.

From a landscape perspective, this cements the perception that it’s Amazon and Eucalyptus versus OpenStack and everyone who’s not Amazon, with the notable exceptions of Joyent, Microsoft and VMware, each of whom owns and sells their own cloud stack. In general, betters would be best advised to take the field over any single vendor, but the cloud market is an exception: Amazon is that dominant. By virtue of being first to market as well as executing consistently for six years, Amazon made itself into the proverbial 600 pound gorilla in one of the most strategic markets in existence. If you’re going to pick sides, as Eucalyptus did more emphatically this morning, that’s not a bad choice to make.

Disclosure: Dell, Eucalyptus, Joyent, HP, IBM, Microsoft, Red Hat and VMware are RedMonk customers. Amazon is not a RedMonk customer.

by-sa

Categories: Cloud.

What Boundary and DTrace Have in Common

Is not – as Adam Leventhal, Jason Hoffman and Randy Bias hastened to point out – functionality. From a pure technology perspective, in fact, they could hardly be more distinct. Boundary is a SaaS based network monitoring service, DTrace an in kernel observation and tracing system. One is focused on the network at scale, the other on the performance and runtime characteristics of a single node.

In another sense, however, Boundary and DTrace have a great deal in common. Consider their purpose. Both tools are designed to provide visibility into architectural components that would otherwise be black boxes, opaque to debugging and performance optimization efforts. Prior to DTrace, in kernel behaviors were a mystery; debugging efforts essentially operated around the kernel, because it was entirely impenetrable. This is not dissimilar to the composition of some of today’s more complicated network infrastructures, which are increasingly composed of a variety of public and private pieces in a manner such that the performance of the whole is unmeasureable. As Bryan Cantrill has demonstrated individual JavaScript events firing inside the kernel while browsing Google Maps, for example, so too may Boundary provide a fine grained event stream for your public – or private – network infrastructure.

While they are indisputably very different tools, then, they are at the same time potentially useful to similar audiences: those who seek to understand (and manipulate) their performance characteristics at a very granular level. Which is perhaps a most important lesson for newly minted Boundary. As revolutionary as the DTrace technology was and is, understanding of its utility varies. Part of this is due to availability issues; Linux and Windows developers don’t have access to the tool, for one. But the uneven appreciation for DTrace is just as much a function of the target audience. DTrace requires not only a technical staff that can appreciate the observability functionality provided, but that also has the ability to both ask the right questions and to properly leverage the answers provided.

It seems logical to anticipate, then, that Boundary will have similar challenges with mainstream audiences. As Justin Sheehy put it in answer to my contention that the two have much in common, “I think that Boundary and DTrace both appeal to people with similar needs and desires, if that’s what you mean.” For both Boundary and DTrace, the trick is making sure those audiences are as large as possible, which means in turn that maximizing accessibility needs to be a priority.

Disclosure: Joyent, who employs a portion of the team that built DTrace, is a RedMonk client. Boundary is not a client.

by-sa

Categories: Observability.

Tags: ,