Skip to content

Apple, Google and Privacy


On the surface, Apple WWDC and Google I/O are exactly what they seem to be: showcases for the company’s respective audiences. The ever longer keynotes are meticulously scripted and rehearsed to dramatically unveil increasingly bloated product portfolios and feature catalogs whose purpose in turn is to create excitement if not outright lust. The perfect show for either firm is one where an audience member would happily trample the person sitting next to them to get their hands on the latest object of desire debuted on stage.

On another level, however, these shows are implicit statements of direction. As Mahatma Gandhi put it in a very different context, “action expresses priorities.” Google’s I/O show, as described, made its priorities clear: Google is still intent on organizing the world’s information. The win for Google is more data to refine its advertising model, which represents 89% of the company’s total revenue. The win for users is services such as Google Photos – at the cost, arguably, of their privacy. By leveraging its access to so many users and so many photos, Google’s machine learning algorithms are good enough now to tell that one picture of a teenager and another of an infant are, in fact, the same person.

The service is made possible, of course, by tremendously intelligent algorithms created by tremendously intelligent engineers. But its lifeblood, ultimately, is data. As Anand Rajaraman wrote years ago, more data usually beats better algorithms. Which implies that the single most important assset for Google is not in fact software, but access.

Which is why Benedict Evans’ assertion that what keeps Google up at night is reach rings true. In a world absent Android, and where mobile’s corrosive erosion of PC usage continues, Google would be uncomfortably dependent on Apple, at a minimum, for the reach it requires to function. From search to maps to photos, Apple would be in a position to control, on a granular level, what Google had access to.

Because this future was not hard to predict, however, Google not only built Android, but saw it blossom into a popular, volume platform – one that is compared to Windows on a volume basis, in fact. Reach must still be a concern for the company, for as popular as Android is iOS is a massive platform in its own right and far more opaque to the search giant. But at least in Android it has guaranteed itself unfettered access to a large subset of the market’s available telemetry.

Which is essential, because Google’s vision for computing is clearly cloud centric, and more particularly driven by the aggregated of value of millions of users living in the same cloud. The same way that Google can determine where traffic is congested by noticing that thousands of GPS-enabled Android devices are slowing down is the same way that the company can determine that because a million fans of obscure band A have liked obscure band B means that there’s a reasonable chance you will too. “Did you mean?” is incredible when you own the majority of the world’s search traffic, not so much for a single user.

It’s not that Google has given up innovating on the device itself – see Project Soli, for example – but it correctly understands that services is where the company is strongest. Assuming, of course, that its pipeline of user telemetry is never jeopardized.

But if that’s Google’s existential concern, what is Apple’s? According to Evans, it is the fear that developers leave. This is, to me, less plausible. First, there is the fact that Apple developers and users have a reputation for being fanatically loyal. That could always change, of course, but the fact that iOS generates more revenue on a per user basis than Android gives developers an additional financial incentive to stick around. My concern, if I were Apple, would not be the retention of loyal and (relatively) well compensated developers.

If we assume that Apple’s actions express its priorities, and by extension its fears, then, what does Apple fear? My bet would be services.

Many have noted that Apple has substantially cranked up its rhetoric around privacy lately. At WWDC, for example, Apple made a point of noting that its “Proactive” update to Siri – one intended to match some features of Google Now – operates off of on device data only. A week prior to that, Tim Cook was even more explicit, saying that Apple doesn’t want user data and that users shouldn’t be forced to trade access to information for a free service. To give you an idea of tone, his speech was characterized as “blistering.”

The obvious question is: why is Apple making such an issue of privacy now? The simplest and most charitable explanation, if one that is potentially naive, is that Apple as a corporation is genuinely concerned with user privacy. It is equally plausible, however, that Apple’s attitude here is simply a reflection of its revenue model, a manifestation of its issues trying to build services, or both.

Regarding the former, clearly Apple’s primary revenue engine is not user data, as with Google. Apple generates its unparalleled margins instead by selling a polished hardware and software combination. Cook is, in this sense, being entirely truthful: the Apple of today doesn’t want or need user data. Skeptics, however, will argue that Apple’s primary and overriding concern is its bottom line, and that sentiment has little to do with the current privacy-as-a-feature approach.

With the general elevation of user privacy to mainstream issue in the wake of the Snowden revelations, however, Apple certainly couldn’t be faulted for highlighting its lack of interest in user data and its competitor’s corresponding reliance on it. All’s fair in love in war, as they say. The important question for Apple, however, is whether it can keep these promises to its users.

As Om Malik writes in the New Yorker:

Apple was rather short on details in explaining how it will achieve its goal of using, learning, and building better services without collecting data on a global scale.

Certainly Apple will be able to infer certain information from the device itself. It seems clear, however, that single device inference will always be limited when measured against algorithms that can run against hundreds of thousands or millions of similar devices. More data beats better algorithms, remember.

Which means that Apple has explicitly and publicly committed itself to not leveraging one of the most important ingredients in building the kinds of proactive services its own product development track acknowledges are in demand. More problematically, services are not an area in which Apple has distinguished itself historically, so operating in this space with a self-imposed handicap is unlikely to be helpful.

Apple in the form of Tim Cook, then, seem to be making a bet that users will value their privacy over new functionality and new capabilities. That they will voluntarily choose a less capable platform if it means they don’t have sacrifice user information. This is certainly possible, but if we assume that the average developer is more attuned to privacy concerns than the average citizen, charts like these would concern me. They would be, in fact, what kept me up at night if I worked at Apple.

Categories: Mobile, Privacy, Services.

What is OpenStack?

In the wake of the OpenStack Summit, held in Vancouver this year, two major questions remained. First and perhaps most obviously, why in the holy hell aren’t there more technology conferences held in Vancouver? Sure, it’s marginally more difficult to get into than San Francisco by air – at least if your primary carrier is JetBlue, which doesn’t service Vancouver. But this is the view from the conference center, which is itself quite impressive.

(click to embiggen)

Not that I have anything against California as a conference destination, mind. If Las Vegas is Mos Eisely, San Francisco is Shangri-La. But there is not a venue in San Francisco that can hold a candle to the Vancouver Conference Center and its absurd backdrop of mountains, water and lazily circling float planes.

Aside from the interesting but ultimately trivial question of venue, however, there was one big question following the Summit: what does the future hold for OpenStack?

The OpenStack project has always been a fascinating exercise in contradictions. On the one hand, it has attracted the kind of broad industry support and investment that other projects would kill for, and outlasted would be competitors like CloudStack and Eucalyptus. Both of which had distinct and theoretically marketable technical advantages over the offspring of NASA and Rackspace, notably. On the other hand, it is simultaneously and continually maligned by technologists from a variety of quarters. Much of this criticism is naturally the result of competitive messaging; in spite of its participation in the project, for example, VMware’s vCloud/vSphere teams predictably have less than kind things to say about OpenStack’s track record for success. But the criticism of OpenStack is hardly limited to competitors. Some of today’s largest contributors, in fact, initially passed on participating in the project after evaluating the first incarnation. And even significant OpenStack players today acknowledge that OpenStack has a lot of work to do moving forward.

None of which helps answer the question of where OpenStack is headed as a project, unfortunately. Technology is criticized all the time, frequently with merit, but the correlation of criticism with lack of adoption has not been strong, historically. Engineering quality matters, but not as much as the industry would like to believe. For better and, frequently, for worse.

The first question that needs to be unpacked when considering the fate of OpenStack is also one of the least interesting. Many critics of the OpenStack project build their arguments on fundamental questions of the economics of private versus public infrastructure. The arguments essentially boil down to an assertion that private infrastructure makes little sense for most companies – or any but the very largest internet companies, if you’re in the business of providing public infrastructure. These arguments tend to be built on macro-economic foundations: most private companies won’t be able to compete with the economies of scale realized by the public infrastructure providers, public cloud players will achieve outsized technical advantages through deeper vertical integration, and so on. I have made these arguments myself many times: see here for an example.

The simple fact is, however, that even if we assume, counter-examples like Etsy notwithstanding, these arguments to be entirely correct with the math unassailable and the downside risk of private investment perfectly understood, private infrastructure will be a fact of life for the foreseeable future. Whether or not it should be based on a rational, dispassionate evaluation of the variables is just not relevant.

Without descending into micro-economics in the form of the rational choice theory, the market evidence available to date is that in spite of subtantial and frankly unprecedented growth for cloud services, private infrastructure is a preferred strategy for many organizations that on paper would appear to be perfect fits for public alternatives. Whether these choices are rational or correct in an academic sense is, again, besides the point. The cloud is growing at an incredible rate, and the hits to x86 server manufacturers amongst others underscores that point, but there are still more businesses treating servers like pets than cattle. More importantly, there are legions of IT staffers that will be protecting what they believe is their livelihood – the private infrastructure – at all costs. Unless technical leadership is willing to wage total war on its own infrastructure, then, private infrastructure will continue to be a thing.

If we assume, therefore, that private infrastructure will remain a market – if one facing more competitive pressure than at any other time in its existence – the question is whether or not you want your private infrastructure to resemble public infrastructure in the feature sense. Do you want the provisioning of an instance to take a week or ninety seconds, in other words?

The answer to that question hopefully being self-evident, we’re left with two conclusions.

  • First, that there will be private infrastructure on some reasonable scale.
  • Second, that that infrastructure must be or become competitive with base level features of public clouds.

Which implies that there will be a market for private cloud software. This is the market that VMware has been steadily monetizing, and the market in which OpenStack is, with all due respect to Apache CloudStack, the last open source project left standing from a visibility standpoint.

All of which seems to be good news for the OpenStack project, and is, to some extent. There is competition on the way, certainly, from newer combinations such as Docker/Mesos and other private infrastructure fabric alternatives (in spite of complementary use cases today), but at least at present they require users to conceptualize their environment in ways the average OpenStack user may not be ready for. For today, anyway, the most likely t-shirt a customer wears to a meeting with an OpenStack vendor is one from VMworld. OpenStack has a window, in other words. How big that window is depends in part on one’s estimation of cloud growth and the downside impact to private competition, but it is difficult to build the case that the entire world will transition away from its private infrastructure to public alternatives in the short to medium term.

But keeping that window open depends on the answer to a fundamental question OpenStack has, and continues to, struggle with: what is OpenStack? The confusion around this subject manifests itself on several levels. Most obviously there is project composition: while OpenStack is typically referred to as if it were a single project, it is better described as a (growing) collection of independent sub-projects – some of which compete with one another. This in turn has several implications.

  • The independent nature of the projects has made installation and upgrades problematic, historically.
  • It is a burden for OpenStack vendors and marketers, who must educate would-be users of OpenStack on the nature of the project and the choices available to them.
  • And finally it’s meant that defining what – precisely – a canonical OpenStack instance consists of has been a hard enough question that answering it has been a project of its own.

Those issues, however, are solvable problems. Or more correctly, they should be, except for the other major manifestation of definitional issues. OpenStack has assembled one of the most impressive rosters of member companies in the industry. The good news is that this has ensured a growing, vibrant community and excellent project visibility. The bad news is that the number of member companies guarantees that members will inevitably have different, and often competing, visions for the project’s future. It’s not difficult to understand that what a carrier might require from OpenStack, for example, could look very different from what an implementer would like to see. Neither of which is likely to be what an operating system vendor expects. And so on.

OpenStack is hardly the first open source project to be the center of broad-based, cross-category investment and collaboration, of course. Linux has been successful on this front for years. But successful projects have typically had a clear sense of purpose and identity: to be an operating system kernel, for example. OpenStack’s raison d’être, by comparison, has been less clear. On a high level, it’s been a mechanism for building an IaaS-type private cloud, but there have been major disagreements between project participants on how to get there, what to build it from and more. In some circumstances, this diversity can be a strength: the ability of OpenStack to substitute different storage subsystems based either on issues with the default choices, customer preferences or both has been useful. Abruptly attempting to redefine the IaaS vision to suddenly extend into PaaS, less so.

This existential crisis notwithstanding, if it is true that private infrastructure investments will be sustained over time, and that said infrastructure should borrow features from today’s public infrastructure, it is necessary to conclude that OpenStack has a market opportunity. Certainly the large system incumbents believe this. On the heels of 2014’s acquisitions of Cloudscaling (EMC), eNovance (Red Hat) and Metacloud (Cisco) – not to mention related pickups like Eucalyptus (HP), Inktank (Red Hat) and Nebula (Oracle) – consolidation continues in 2015. A few short weeks after the OpenStack Summit, Cisco and IBM announced separate OpenStack acquisitions within hours of each other in Piston and Blue Box respectively.

For these strategies to pay off, however, the OpenStack project and its members need an answer to the fundamental question of what is OpenStack. Without that, the project will have a difficult time improving the developer experience and will leave itself vulnerable to more focused projects with a clear sense of identity and purpose. Many in the industry laugh at the idea that Mesos, for example, is an OpenStack competitor, but the Mesophere tagline of “an operating system for your datacenter” would seem to put it squarely in contention for the private infrastructure opportunity OpenStack was built to address. OpenStack may today be more easy to adopt for enterprises given its resemblance to traditional infrastructure versus Mesos’ more forward vision of knitting many resources into a single large instance, but is that advantage sustainable?

This is but one of many questions OpenStack should be considering as it attempts to discover what, in fact, it is. The answers need to come soon, however, because the window will not remain open indefinitely.

Disclosure: Multiple vendors involved in the OpenStack project, including Cisco, HP, IBM, Oracle and Red Hat are RedMonk customers. VMware, which is both a participant in the OpenStack community and a competitor to it, is a customer. Mesosphere is not a customer, nor is the OpenStack Foundation.

Categories: Cloud, Open Source.

The Software Paradox – Available Now

One of the things you do as an analyst is talk to companies. A lot of companies, potentially, depending on what you cover. In between talking to companies, you’re also doing research on them. What do the trajectories of their products look like relative to one another, as measured by a variety of proxy metrics? What story are their financials telling us? And so on. When you do this for years, the hundreds of conversations and the hours of research, unsurprisingly, begin to reveal patterns. The primary job of analysts, in fact, is to notice such things.

One such pattern I noticed five years ago or so was that companies were having a harder time making money from software. Not a hard time, precisely – Microsoft and others were effectively still printing money through the up-front sale of bits – but harder. Traditional software companies were facing stiff competition from SaaS-players and open source. Commercial open source organizations, for their part, were cycling through models from dual licensing to open core in an effort to try and find a reliable mechanism that would convince customers to pay for something they otherwise could obtain for free. The companies making some of the most interesting and technically sophisticated software, meanwhile, not to mention generating the most revenue and achieving the highest market caps, were not in the business of selling software. Many even made their innovative internal software assets available as open source, implying that they saw more commercial benefit to simply making the code available for free than they would have trying to monetize it.

The evidence suggested, then, that software’s intrinsic commercial value – at least in the traditional, perpetual license sense – was declining. This was the message I discussed with the audience in May of 2011 at the Open Source Business Conference.

The odd thing was that even as software was becoming more difficult to sell, it was simultaneously becoming more strategically important. Less than three months after I spoke to the OSBC audience about the observable transition in market valuations of software companies, Marc Andreessen’s op-ed “Why Software is Eating the World” made its appearance in the Wall Street Journal. Its reception was such that the title has since become a cliché. In the piece, Andreessen succinctly articulated a position that many now take for granted: that software was transforming entire industries, and that non-technology companies were either becoming or being replaced by technology companies at an accelerating rate.

This seeming paradox has occupied a lot of my time over the past five years. Looking at the financials of software companies, SaaS companies and technology companies that don’t sell technology. Talking to companies with very different perspectives on software, from commercial open source to proprietary software to IaaS. And of course speaking with and reading the writings of a lot of developers along the way, to get a sense for where they see things headed, and what they value. It’s all been an attempt to answer a simple question: how is it that software’s strategic importance could be on an opposite trajectory from its commercial value? How could software be more important but worth less?

One output from this work has been “The Software Paradox,” an O’Reilly title that launched last week and which a few of you have been kind enough to notice. It’s available as a free download from O’Reilly, courtesy Paypal, right now. If you prefer to get it via your Kindle, it should be available there in a few weeks. If you have other questions or want to see the Table of Contents, those are at

Either way, my hope is that for anyone in the software business, or those competing with it, the book will help challenge your understanding of the software industry and the economics behind it – particularly on a going forward basis. Even if you disagree with the premise or your business is currently an exception to it – and there are many, to be sure – it’s worth considering the idea, because many that assumed they were exceptions were caught scrambling.

Lest I forget, I need to thank Kate for putting up with the time it took for me to put this together, and for those of you I will not out here who took the time to not only read the book but provide feedback ahead of time – your feedback was invaluable.

Thanks, also, for those of you who have taken the time to read it already or will in future. Whatever your take on the argument, there is nothing more valuable than your time so I appreciate you spending it on this.

Categories: Books, Economics.

What Google I/O Was About

There were other technologies discussed at Google I/O this week, but more so than in years past this was an Android show. So much so that even non-Android projects were either a derivative of Android (Brillo), impacted Android applications (Chrome Custom Tabs) or run on top of the mobile operating system (Photos). Which tells us that Google, like the rest of the industry, believes that this is a mobile world, and we’re just living in it. Which is neither news nor interesting. What is worth noting is precisely how Google is attacking this market.

Back in November of 2012, one of the original iPad engineers made the argument that Google was getting better at design faster than Apple was improving its web service capabilities. Setting aside the often subjective question of design, this year’s I/O made it clear that Google is doubling down on services.

Consider that the theme for the forthcoming Android M release is user experience and usability. To that end, Google has made some useful changes to the stock Android interface, from the way privacy settings are handled to the volume sliders. But the real leaps in user experience are not going to come from the interface, but rather the services it connects to. If it seems counterintuitive that something like machine learning could positively impact user experience, you haven’t been paying attention.

The various digital assistants – Cortana, Siri and, well, Ok Google – suggest that the best mobile user interface may be the one that can be bypassed most effectively. To accomplish this trick, of course, you need two types of data. Bulk telemetry to train the algorithms for tasks like speech recognition, and contextual data to let a given user’s habits and preferences inform a platform’s interactions with them.

Google explicitly acknowledged this at the show when discussing its voice recognition error rate, down to 8% from 23% in less than two years. But it was also implicit in the most important service announced, Google Now On Tap. Announced in 2012, Now – which was reportedly a 20% time project originally – was Google’s first attempt to proactively leverage available contextual data on the Android platform. It knows where you live, and will alert you unsolicited about traffic backups on your commute home from the office. It will keep you up to date on the scores of your favorite teams, tell you when to leave for the airport to catch your flight and attempt to pick out links to content you’ll find interesting. All of which is useful if you visit the standalone Google Now launcher page.

What Google has done with Now On Tap is extend the reach of Now’s contextual data and understanding into any application on the phone. If you’re reading email and don’t understand a reference, Now will explain it to you. If you get a text from your spouse reminding you to do something, it will be there to create a reminder for you. And so on.

Now On Tap is important for two reasons. Most obviously, it’s potentially a big productivity win for users because instead of shifting context from a given app to look something up on Wikipedia or create a reminder, they’ll be able to do so without going anywhere. While Now On Tap is important for users, however, it’s a potential gold mine for Google. Previously, Google’s contextual awareness was limited to the applications it directly managed: it learned from your search history, it mined your Gmail Inbox and so on. With On Tap, Google stands to gain an important new channel into behaviors and actions previously opaque to it, specifically your interactions with third party applications.

None of this is even possible, of course, without deep investment in machine learning and proto-artificial intelligence. Google Photos, for example, ingested the archive from my phone, which includes dozens of photographed receipts for Expensify. There are no tags applied to these images, no categorization or labels – the word “receipts” is entirely absent from them, in fact. But when I query Google Photos, it’s intelligent enough to return pages and pages of nothing but receipts. This is, in computer science terms, dark magic. And it is this dark magic that Google has clearly identified as its differentiator in mobile moving forward.

Which is why one decision of Google’s in the mobile arena is so perplexing: its complete lack of a messaging strategy. The market has accorded messaging a high degree of importance. WhatsApp – conspicuously featured on stage at I/O – was valued at $19 billion. Slack more than doubled its valuation over a six month period to almost $3 billion. And iMessage is so much a part of the iPhone experience that discrimination against so-called “green bubble” users – i.e. anyone without an iPhone – is a thing.

What is Google’s response to this surge in messaging client importance? Crickets. The Android Hangouts client attempts to converge Google Talk-style IM and SMS in one place, but is extraordinarily awkward to use, because it does not, in fact, converge them. Google Voice, meanwhile, was at one point a credible SMS and voice service, but appears to have been effectively orphaned. Asked about this at Google I/O, the official response was “we have nothing to announce at this time.” For a conference that was first about Android and second about improving the user experience for the platform, then, the lack of any news or roadmap about what Google’s messaging strategy will be was baffling. Maybe Google can satisfy its back-end telemetry needs by introspecting a variety of clients from TenCent to WhatsApp via Google Now On Tap, but the users are left without a service comparable to what Apple, Facebook or a variety of third party platforms offer.

The odd lack of messaging news notwithstanding, however, I/O has been an impressive, if subtle, look at Google’s ability to put information to work at scale to deliver services sufficiently advanced so as to be indistinguishable from magic. Google may or may not ever match Apple’s design prowess, and the show may have lacked the surprise “One More Thing,” but the company is second to none when building the kinds of artificially intelligent services users will increasingly come to rely on. If it accomplished nothing else, then, I/O was a useful reminder of that fact.

Categories: Conferences & Shows.

Three Questions from the Cloud Foundry Summit

Cloud Foundry LEGO!

Six months ago there was no Cloud Foundry Foundation. This week, its biggest problem at the user conference was the fire marshal. At 1,500 reported attendees the event was a multiple of the project’s inaugural Platform event. To the point that it’s hard to see the Summit going back to the Santa Clara conference center. Enthusiasm will make people patient with standing room only events with seating along the walls two deep, but there are limits.

For an event reportedly put together in a little over two months, execution was solid. From HP’s magician/carnival barker to the Restoration Hardware furniture strewn liberally across the partner pavilion – excuse me, “Foundry” – walking the show floor had a different feel to it. Sessions were a reasonable mix of customer case studies and technical how to’s, which was fortunate because the attendees were an unusual mix of corporate and very pointedly non-corporate.

The conference comes at an interesting point in the Cloud Foundry project’s lifecycle. The first time we at RedMonk heard about it, as best I can recall, was a conversation with VMware about this project they’d written in Ruby a week or two before its release in 2011 – two years after the acquisition of Cloud Foundry. There are two things I remember about that call. First, that I was staying at the Intercontinental Boston at the time. Second, that I spent most of the briefing trying to imagine what kind of internal battles had been fought and won for a company like VMware to release that project as open source software.

By the end of that year, the project had enough traction to validate one of my 2011 predictions. Still, Cloud Foundry, like all would-be PaaS platforms, faced a substantial headwind. Disappointment in PaaS ran deep, back all the way to the original anemic adoption of the first generation of Google’s App Engine and Saleforce’s – released in April of 2008 and September of 2007, respectively. All anyone wanted to buy, it was argued, was infrastructure. Platform-as-a-Service was one too many compromises, for developers and their employers both. AWS surged while PaaS offerings stagnated.

Or so it appeared. Heroku, founded June 2007, required less compromise from developers. Built off of standard and externally available pieces such as Git, Ruby and Rails, Heroku was rewarded by growing developer adoption. Which was why Salesforce paid $212M to bring the company into the fold. And presumably why, when Cloud Foundry eventually emerged, it was open source. Given that one of the impediments to the adoption of and GAE in their initial incarnations was the prospect of being locked in to proprietary technologies, the logical alternative was a platform that was itself open source.

Fast forward to 2015. After some stops and starts, Cloud Foundry is now managed by an external foundation, a standard mechanism allowing erstwhile competitors to collaborate on a common core. The project has one foot in the old world with participation from traditional enterprise vendors such as EMC, HP and IBM and another in the future with its front and center “Cloud Native” messaging. How it manages to bridge that divide will be, to some degree, the determining factor in the project’s success. Because as Allstate’s Andrew Zitney discussed on Monday, changing the way enterprises build software is as hard as it is necessary. This is, in fact, one of three important questions facing the Cloud Foundry project in the wake of the Summit.

Is the Cloud Native label Useful or a Liability?

There are several advantages to the Cloud Native terminology. First, it’s novel and thus unencumbered by the baggage of prior expectations. Unlike terms such as “agile” which even one of the originators acknowledges has become “sloganized; meaningless at best, jingoist at worst,” Cloud Native gets to start fresh. Second, it’s aspirational. As evidenced by the growth of various cloud platforms, growing numbers of enterprises
are hyper-aware that the cloud is going to play a strategic role moving forward, and Cloud Native is a means of seizing the marketing high ground for businesses looking to get out in front of that transition. Third, it’s simple in concept. Microservices, for example, requires explanation where Cloud Native is comparatively self-descriptive. By using Cloud Native, Cloud Foundry can postpone more complicated, and potentilly fraught, conversations about what, precisely, that means. Lastly, the term itself explicitly disavows potentially fatal application compromises. The obvious implication of the term “native,” of course, is that there are non-native cloud applications, which is another way of saying applications not designed for the cloud. While it might seem counterintuitive, acknowledging a project’s limitations is a recommended practice, as customers will inevitably discover them anyway. Saving them this disappointment and frustration has value.

All of that being said, much depends on timing. Being exclusionary is an appropriate approach if a sufficient proportion of the market is ready. If it’s too early, Cloud Native could tilt towards liability instead of asset, as substantial portions of the slower moving market self-select themselves out of consideration by determining – correctly or not – that while they’re ready to tactically embrace the cloud, going native is too big a step. Even if the timing is perfect, in fact, conservative businesses are likely to be cautious about Cloud Native.

Cloud Native is a term then with upside, but not without costs.

How will the various Cloud Foundry players compete with one another?

The standard answer to questions of this type, whether it’s Cloud Foundry or other large collaborative projects, is that the players will collaborative on the core and compete above it. Or, as IBM’s Angel Diaz put it to Barb Darrow, “We will cooperate on interoperability and compete on execution.” From a high level, this is a simple, digestible approach. On the ground, temptations can be more difficult to resist. The history of the software industry has taught us, repeatedly, that profit is a function of switching costs. Which is where the incentive for ecosystem players to be interoperable enough to sell a customer and yet proprietary enough to lock them in, comes from.

Which is why the role of a foundation is critical. With individual project participants motivated by their own self-interest, it is the foundation’s responsibility to ensure that these do not subvert the purpose, and thus value, of the project itself. The Cloud Foundry Foundation’s primary responsibility should ultimately be to the users, which means ensuring maximum interoperation between competing instances of the project. All of which explains why will be interesting to watch.

How will the Cloud Foundry ecosystem compete with orthogonal projects such as Docker, Kubernetes, Mesos, OpenStack and so on?

On the one hand, Cloud Foundry and projects like Docker, Kubernetes, Mesos and OpenStack are very different technologies with very different ambitions and scope. Comparing them directly with one another, therefore, would be foolish. On the other hand, there is overlap between many of these projects at points and customers are faced with an increasingly complicated landscape of choices to make about what their infrastructure will look like moving forward.

While there have been obvious periods of transition, historically we’ve had generally accepted patterns of hardware and software deployment, whether the underlying platform was mainframe, minicomputer, client/server, or, more recently, commodity-driven scale-out. Increasingly, howevever, customers will be compelled to make difficult choices with profound long term ramifications about their future infrastructure. Public or private infrastructure? What is their approach to managing hardware, virtual machines and containers? What is the role of containers, and where and how does it overlap with PaaS, if at all? Does Cloud Foundry obviate the need for all of these projects? And the classic, rhetorical question of one-stop-shopping versus best-of-breed.

While Cloud Foundry may not be directly competing against any of the above, then, and certainly is not on an apples to apples basis, every project in the infrastructure space is on some level fighting with every other project for mindshare and visibility. The inevitable outcome of which, much as we saw in the NoSQL space with customers struggling to understand the difference between key-value stores, graph databases and MapReduce engines, will be customer confusion. One advantage that Cloud Foundry possesses here is available service implementations. Instead of trying to make sense of the various infrastructure software options available to them, and determining from there a path forward, enterprises can essentially punt by embracing Cloud Foundry-as-a-Service.

Still, the premium in the infrastructure is going to be on vision. Not just a project’s own, but how it competes – or complements – other existing pieces of infrastructure. Because the problem that a given project solves is always just one of many for a customer.

Categories: Cloud, Configuration Management, Containers, Platform-as-a-Service.

Is Collaborative Software Development the Next Big Thing?

Working Hard

For all of the technology industry’s historical focus on collaboration tooling, the vision of collaboration they espoused was typically narrow. When vendors talked about collaborating, what they meant was collaborating within your organization. The idea of working with those outside the corporate firewall was an afterthought, when it was thought about at all. Scheduling and calendar applications are perhaps the best evidence of this. Some 22 years after the introduction of Microsoft Exchange and nine after the release of Google Calendar, the simple act of scheduling a meeting with someone who doesn’t work directly with you remains a cache invalidation-level problem.

While this is baffling on the one hand, because it does seem like a solvable problem from an engineering perspective, it is at the same time unsurprising. The tools we get are the tools we demand, eventually. For the better part of the history of the technology industry, infrastructure software development involved very little collaboration. Instead, the creation of everything from databases to application or web servers to operating systems was outsourced by enterprises to third parties such as HP, IBM, Microsoft or Oracle. These suppliers built from within and sold to buyers unable or unwilling to create the software internally, and the closed nature of this system demanded very little low level collaboration between the individual suppliers, buyers or both. Buyer or seller, organizations were inwardly focused.

With the rise of the internet, however, came not just new opportunities but an entirely new class of problems. Problems that, in many cases, the existing technology suppliers were ill equipped to solve, because scaling an individual bank’s transactions is less difficult than, say, scaling the world’s largest online retail site in the weeks leading up to Christmas. Forced by need and by economics to develop their own software infrastructure, internet pioneers like Amazon, Facebook, Google, LinkedIn and Twitter evolved not only different software, but distinct attitudes towards its value.

These have been discussed at length in this space in the past. What’s interesting is that in comments like the one below, or projects like WebScaleSQL, we can see the possibility of a shift towards greater inter-organizational collaboration.

The industry has had large collaboratively developed projects for some time, of course: Linux is the most obvious example. But to a large extent, projects such as Linux or more recently Cloud Foundry and OpenStack have been the exception that proved the rule. They were notable outliers of cross-organizational projects in a sea of proprietary, single entity initiatives. For commercial software organizations, Linux was a commodity or standard, and the higher margin revenue opportunities lay above that commonly-held, owned-by-no-one substrate. In other words, software vendors were and are content to collaborate on one project if it meant they could introduce multiple proprietary products to run on top of the open source base.

What if a higher and higher percentage of the infrastructure software portfolio was developed by organizations with no commercial ambitions for the software, however? What if a growing portion of the projects used to build modern infrastructure came instead from Facebook, Netflix or Twitter, who behaved as if software was non-differentiating and saw more benefit than cost to sharing it as open source software?

In theory, that would remove one of the more important barriers to inter-organizational collaboration. If Facebook intended to sell PrestoDB as a commercial product, or Google Bazel, it would be natural for them to protect those assets and shun opportunities to collaborate with would be competitors. But given that the software being produced by Facebook, Google, Twitter and so on is not built for sale, it would be logical for these organizations to centrally collaborate on common problem areas – just as they do with Linux, just as they do with WebScaleSQL, and just as they do with the Open Compute Project. Logic isn’t enough by itself to overcome NIH, of course, but collectively distributing the burden of scalable infrastructure promises enough financial benefit that the economic incentives should eventually win out. Particularly if people such as Chris Aniszczyk or James Pearce have anything to say about it.

We could, in short, be looking at the emergence of a new attitude towards software development.

  1. 1960: IBM: “Software is For Selling Hardware”
  2. 1981: Microsoft: “Software is For Making Money”
  3. 1994: Amazon: “Software is Used for Services That Make Money and Worth Protecting”
  4. 2004: Facebook: “Software is Used for Services That Make Money and Not Worth Protecting”

To which we might now add:

  1. 2015: TBD: “If We’re A) All Building Similar Software, and B) It’s Not Competitively Differentiating, Why Are We Not Building it Together?”

The best part? If organizations finally decide to collaborate at scale across company boundaries, maybe, at long last, the end of our scheduling nightmare will come into view.

Categories: Collaboration, Open Source.

Who’s Contributing to Configuration Management Projects?

One of the more common areas of inquiry around open source for us at RedMonk concerns project contributors. Who is contributing to what project? What are the relative rates of contribution from contributor to contributor? How do the contributions to a project compare to contributions from competitive projects?

In many cases, this is a difficult if not impossible question to answer because the identities and affiliations of project contributors are obscure, whether by design or simply because developers prefer the individual identities independent from their employer. But just because a question is difficult to answer and may return imperfect results does not mean that it’s not worth asking.

With my colleague having updated some of the basic community metrics from Hacker News and Stack Overflow that we track on the configuration management space, we’ll take a look here at the top 5 contributors by domain to the Ansible, Chef, Puppet and SaltStack projects. CFEngine is omitted here because their GitHub repository for Version 3 is not backwards compatible with Version 2 and thus doesn’t accurately represent total project traction.

To set the context, however, here are a few charts comparing the surveyed projects to one another. First, we’ll look at the number of accepted pull requests across the four projects.

(Click to embiggen any of the below charts)

As noted by Donnie, Salt is disproportionately represented because pull requests are the sole contribution mechanism, but as Ansible’s Greg DeKoenigsberg observes it’s important to caveat both this metric and the following two by noting that Ansible and Salt are GitHub native and thus can be expected to outperform in that context.

With that said, here is how the projects compare relative to one another in terms of GitHub stars accumulated.

Even with the aforementioned qualifiers attached, Ansible’s performance here is notable. This trend is not new; the project has been popular on GitHub at least since 2013 when we added it to the projects in this space we track. Ansible is also the leader on GitHub in the number of forks, although its lead is less substantial in that category.

As noted, the fact that Ansible and Salt are the leaders in these categories is unsurprising given their relationship with GitHub the platform. But these metrics are, as mentioned, opaque. Who, precisely, is contributing to the projects?

To explore this question we turned to the actual Git commit logs for each project. More specifically, we extracted the email addresses per commit, and then looked at the contributions on a per domain basis. The following charts look at the top five contributors to each by domain. One quick caveat: no edits, corrections or consolidation has been made to these charts, so if there are multiple domains representing one company (e.g. and they are not consolidated here. We’ll revisit this approach in future, but the results are presented here without alteration, so it’s important to take that into consideration when evaluating relative contribution levels.



The dominant contributing domain to the Ansible project is, with a substantial majority coming from there. This potentially reflects the project’s age and permissive policies with respect to contributions, presumably regarding project contributions from internal employees as well. The strong presence here from Fedora is no surprise, given both Red Hat’s ties to the Ansible project as well as Fedora’s heavy usage of it. The remainder of the contributions are attributable to Ansible-related domains: and (James Cammarata, Ansible employee).



As might be expected for a project of Chef’s age and maturity, the majority of contributions to the project originate from Chef-owned domains ( and Independent addresses are a distant second place (~9X less), but it was interesting to see India-based Clogeny check in fourth place. Fifth place is rounded out by, which appears to be the personal domain of Matthew Kent, currently a Basecamp (née 37Signals) employee.



Much like Chef, the other elder stateman of this category, Puppet contributions are dominated by domains. There are 14X more contributions from that domain than, itself the URL of a company since acquired by Puppet. Third place, for its part, is the personal domain of Adrien Thebo, currently a Puppet Labs employee. After the fourth-largest contributor, contributions from gmail addresses, comes Days of Wonder, a board game manufacturer (e.g. Ticket to Ride). This seems to largely be the work of developer Brice Figureau, a major contributor to the project.



Following in Ansible’s footsteps, the younger Salt project is overwhelmingly composed of contributions from addresses. The number three and four contributing domains – and – effectively reflect company contributions, as Seth House is a SaltStack employee. The number two contributing domain, however, belongs to Pedro Algarvio, a Python developer with no formal affiliation with the project as documented by Matt Asay. The fifth largest contributing domain, meanwhile, is, no surprise given that university’s public usage of Salt.

The Net

In general, the findings from this project are mostly unsurprising. Older, more mature projects skew towards contributions from employees, while the younger would-be disruptors may or may not feature similar percentages of employee contributions, but if so are at least less formal in their contribution policies. It will be interesting to see whether or not Ansible or Salt’s contribution policies become more formal and employer-centric over time. It will likewise be necessary to monitor whether or how these relative contribution levels evolve; does it become more difficult for individual developers to rank amongst the top contributors? Do we see influxes of new contributions as the relative dynamics of project adoption shift? Can we expect changes in terms of the internal to external contribution ratios?

Either way, it’s interesting to go beyond strict contribution metrics to get a closer look at who the contributors are and where they’re coming from, even if it’s difficult or impossible to discover in some cases.

Disclosure: Ansible and Chef are RedMonk clients, while Puppet and Salt are not.

Categories: Configuration Management.

Who is Going to be the Ubuntu of Developer Infrastructure?

There were many things that made the early Linux desktop candidates difficult to manage. Lacking the vast catalog of drivers that Windows had at its disposal, for example, peripheral device support was a challenge. As was getting functionality like suspend working properly – not that Windows supported it flawlessly, of course. But assuming you could get these early builds up and running, at least, one of the most under-appreciated challenges of navigating the very different user interface was choice.

Or more accurately, the various distributions’ collective decision to not make any. Rather than risk offending a given community by selecting a competitive project, distributions instead shipped them all. So instead of one browser, you might have three. Looking for an Office equivalent, you might find five. While this decision was perhaps defensible from the distribution’s perspective, it was less than optimal from a usability standpoint.

Which the Ubuntu distribution, among others, recognized. Like Rails and other projects that followed, Ubuntu was “opinionated software,” though that term wouldn’t become popularized for another five years. Rather than attempting to appease all parties, the project attempted to make decisions on behalf of the user, decisions that would reduce the burden of choice. Instead of attempting to evaluate and select from multiple browsers, the distribution had evaluated the options for you and chosen Firefox. The distribution didn’t restrict users from installing an alternative, if that was their preference, it simply offered what it believed to be the best option at that time, in its opinion.

That packaging is a critical function within this industry is not exactly a revelation; my colleague, among many others, has discussed it at length. But if the experiences of developers today is any indication, opinionated packaging in the developer infrastructure space cannot come quickly enough.

As noted by Tim Bray and others, it’s difficult if not impossible for developers to understand in depth the infrastructure they rely on. Worse, it’s only getting more complicated as new projects arrive and existing projects extend their capabilities into adjacent areas.

Consider the questions surrounding even a project as popular as Docker. In spite of visibility growth that’s among the fastest we have ever seen at RedMonk, developers are still struggling to understand where it fits within their existing infrastructure options.

Wherever one looks in developer infrastructure today, choices are multiplying. Even in relatively stable markets like build systems, where Jenkins is what the numbers tell us developers prefer and complemented by credible alternatives like Bamboo, TeamCity or Travis, potentially interesting new competitors like Bazel – Google’s internal build tool, recently open sourced – continue to arrive.

For its part, it was not all that long ago that configuration management was considered a solved problem. Puppet appealed towards the systems administration end of the spectrum, while Chef built out a sizable audience of its own with more fans coming from the other, developer-end of the spectrum. It was at this point that Ansible and Salt arrived, and look where they are now.

If these are the choices for well established, well understood software categories, imagine how an average user will react when faced with understanding the role of and distinctions between software like Kubernetes, Mesos, Spark, Storm, Swarm, Yarn, etc – and then being forced to evaluate all of the above against public infrastructure alternatives.

For elite developers or organizations, choice is a positive, as they are more likely to have the time and ability to understand, evaluate and compare their options to determine best fit. The rest of the world, however, is going to need assistance in their technology selection process.

This assistance, in many cases, will arrive in the form of packaging. Much as Ubuntu attempted to make rational decisions on behalf of desktop users the world over, purveyors of developer infrastructure will be compelled to do the same for their customers. Best of breed is an ideal approach, but like many ideal approaches it scales poorly. In a perfect world the choices made by packagers will allow for substitution – to exchange Chef for Puppet, for example, or Ansible for Chef – but the simple fact is that as the complexity of infrastructure accelerates there are simply too many choices to be made.

Which is the point at which opinions, and opinionated infrastructure, becomes increasingly valuable. The question isn’t whether packaging will become an increasingly popular tactic, but rather who will employ it most efficiently. The best bets moving forward, for this reason, lie in service-based providers whose very nature abstracts their customers from the wide array of choices before them, presenting instead a single, unified service. But whether it’s on premise or as-a-service business models, becoming more opinionated is about to become more popular.

Categories: Choice, Containers, Devops.

Every Exit is an Entry Somewhere

A little over nine years ago, RedMonk made its first analyst hire. As an aside, if that number makes you feel old, well, you’re not alone. Anyway, our choice for the first non-founder analyst was a then little known BMC software developer based out of Austin, who was perhaps best recognized for his rather irreverent technology blog, Drunk and Retired. At the time, there was some consternation in the industry about the idea of hiring a developer to be an analyst. We fielded a lot of questions about the selection, but the quality of Cote’s work pretty quickly put those to rest.

It is probably in part due to Cote’s success – both with RedMonk and in his subsequent career at Dell, The 451 Group and now Pivotal – that we didn’t get nearly as many questions when we hired his replacement out of the Mayo Clinic. Superficially it might sound odd to hire as a technology industry analyst a Research Fellow doing drug discovery, but we’ve always been believers that we can teach someone to be an industry analyst – we’ve been in the business for thirty years collectively, after all. What we can’t do as easily is teach the skills necessary to be a good analyst: being creatively inquisitive, being able to communicate effectively or having an understanding and ability to grasp the macro trends shaping our industry.

When we find those, then, wherever they might be and whatever the background, we’re interested.

And find those we did in Donnie Berkholz. In spite of – or was it perhaps because of? – his non-traditional industry background, Donnie hit the ground running with us. With his background in statistical and quantitative analysis, he quickly made a name for himself exploring statistical trends, making predictions and that most important of RedMonk analyst duties: buying developers beers. He’s done nothing but prove us right in our initial belief that he could do this work at a high level, which is why we’re sad to be saying goodbye.

But like his predecessor, the time has come for Donnie to graduate from RedMonk. He’ll have more to tell you about his future plans shortly I’m sure, but suffice it to say you will still be seeing him around. His last day with us will be next Friday, as he wraps up a few projects with us. In the meantime, on behalf of all of us at RedMonk: we wish you all future success, Donnie, thank you for all of your efforts in helping RedMonk keep advancing the ball downfield. We’re happy to have played a small part in helping you transition into this industry.

As with any departure, the obvious next question is: what does this mean for RedMonk?

In the short term, more travel – they’re only making more conferences, and there are only so many of us. And we’re no more looking forward to filling Donnie’s shoes than we were to filling Cote’s. But over the longer term, our mission remains the same: we’re the analyst firm that is here for – and because of – developers. We will continue to fight the good fight on behalf of that constituency, even as market awareness of their importance adds more and more allies to our ranks. As a species we have a tendency to take progress for granted, but if you stop and think it really is amazing how different the reception our developer-centric message is today versus even four or five years ago.

Who will we hire? The best fit we can find. Like the Oakland A’s, we’ll think creatively about the opening and we’re already in the process of talking to some interesting candidates. That said, we’re open to all interested parties. And given our trajectory, we might even be adding more than one new analyst, but we’ll take it one step at a time.

Fair warning to all applicants: we will be very picky. You need to be able to communicate effectively, write well and be committed to rational discourse. You should have a reasonable online presence and a passion for developers and the tools they use. Other things we’ll look for include programming skills, economics and statistics training and experience with rich media. Previous experience as an analyst is a bonus, but absolutely not required. Interested? Send a CV and anything else you believe we should consider to hiring @

You will have big shoes to fill, whoever you are. The analysts that have come before you have done some incredible work, and we expect nothing less from you.

Why work here? The most obvious reason is that RedMonk remains, in my obviously biased opinion, an amazing place to work. There aren’t many too many jobs available that allow you to influence the strategic direction and decision making process of some of the biggest and most important technology companies in the world – as well as their disruptors, that give you a pulpit to produce public research for some of the best and brightest developers on the planet. Fewer jobs still let you work on things that are important, things that improve the day to day lives of developers, and by extension, the users they service. Tim O’Reilly says to “work on stuff that matters“; we think we do, almost every day. And as you might guess from conferences like the Monktoberfest, we try and have fun doing it.

Add in the flexibility that working for a small firm offers, from the ability to define your own research agenda to good hardware to variable vacation time to the option of working from home, and it’s a damn good gig. If any of that sounds interesting to you, drop us a line.

Last, to our clients and customers: if any of you have questions about this news, feel free to contact myself (sogrady @ or James (jgovernor @ if you like, or Juliane (juliane @ as always. We’re happy to answer anything we can.

So we wish you well, Donnie, and look forward to seeing who will step up in your place.

Categories: RedMonk Miscellaneous.

Open Source and the Rise of as-a-Service Businesses

I Want You To Open Source!

As discussed in my recap of the 2014 predictions from this space, it has been interesting to see Oracle’s SEC filings reflect the structural changes to both its business and the industry as a whole.

In 2012 and prior, Oracle reported on:

  • New software licenses
  • Software license updates and product support

By 2013, that became (additions in bold):

  • New software licenses and cloud software subscriptions
  • Software license updates and product support

And for the last fiscal year, Oracle expanded that into:

  • New software licenses
  • Cloud software-as-a-service and platform-as-a-service
  • Cloud infrastructure-as-a-service
  • Software license updates and product support

In just a few lines of a Consolidated Statement of Operations is writ the recent history of the software industry. Even companies that have efficiently extracted billions of dollars in profit from traditional, perpetual license software businesses are increasingly looking to cloud and service-enabled lines of business for future growth.

The numbers make it easy to see why. From 2012 to 2014, Oracle’s new software license revenue was down 0.37%. Over the same time period, its IaaS, PaaS and SaaS offerings combined reported growth of 75% – and if you exclude IaaS, which is a nascent business for the company – the growth rate jumps to 146%.

If we can accept for the sake of argument that this is not a unique adjustment of Oracle’s, but a pattern replicating itself across a wide range of businesses and industries, there are many questions to be answered about what the impacts will be to the industry around it. Of all of these questions, however, none is perhaps as important as the one I have discussed with members of the Eclipse and Linux Foundations over the past few weeks: what does the shift towards as-a-service businesses mean for open source? Is it good or bad for open source software in general?

The problem is that this question is difficult to answer precisely, because evidence can be found to support opposing arguments.

The Good News

On the positive front, the creation of services businesses has indirectly and directly led to an enormous portfolio of open source software. With the introduction and subsequent commercialization of the internet, a new class of problems demanded a new class of solutions. Prior to the internet, the types of scale-out architectures that are now standard within large service providers were relatively uncommon outside of specialized areas like HPC. The prevailing design assumption at the time, as Joe Gregorio observed, was N = 1, not the N > 1 fundamental assumption on which today’s platforms are built.

To satisfy the immediate demand for an enormous volume of new software written to solve new classes of problems, fundamental shifts were required. Most obviously, an unusually high percentage of this software was not written for purposes of sale. Unlike prior eras in which industry players lacking technical competencies effectively outsourced the job of software creation to third party commercial software organizations, companies like Amazon, Facebook and Google looked around and quickly determined that help was not coming from that direction – and even if it did, the economics of traditional software licensing would be a non-starter in scale-out environments.

Which is how this scale imperative led to a seismic shift in the way that software was designed and written. The decision by many of the original organizations to make these assets freely available as open source software consequently led to similarly titanic shifts in how software was distributed, marketed and sold.

The sheer number of companies not in the business of selling software who are releasing their creations as open source has dramatically inflated both the number and quality of available open source solutions. It has also put enormous competitive pressure on software vendors to either compete against open with a closed alternative or make their software similarly available.

The net, then, is that the rise of service-based businesses has directly and indirectly led to the creation of a lot of new open source software, which is positive for the industry – from a functional if not commercial standpoint – and customers alike. And having disrupted first the enterprise software industry and then compute, open source is now turning its eyes towards previously immune sectors like networking and storage.

The Bad News

One of the most important advantages open source enjoyed and continues to enjoy over proprietary alternatives is availability. As developers began to assert control over technical selection and direction in increasing numbers, even in situations where a proprietary alternative is technically superior, the sheer accessibility of open source software gave it an enormous market advantage. Choosing between adequate option A that could be downloaded instantly and theoretically superior option B gated by a salesperson was not in fact a choice. Thus Linux became the most widely adopted operating system on the cloud and MySQL the most popular relational database on the planet.

What is widely under-recognized, however, is the fact that from a convenience standpoint, open source does not enjoy the same advantages over its services counterparts that it did over proprietary competitors. Open source is typically less convenient than service-based alternatives, in fact. If it’s easier to download and spin up an open source database than talk to a salesperson, it’s even easier to download nothing at all and make setup, operation and backup of that database someone else’s problem.

If convenience is an increasingly important factor in technology adoption, then, and all of the available evidence suggests that it is, open source’s relative disadvantage in this area is a potential problem.

Particularly when you consider the motivations of vendors, who have not forgotten one of the primary lessons of the proprietary software market: locking in customers is good for business. As Shapiro and Varian put it 1999, “the profits you can earn from a customer – on a going-forward, present-value basis – exactly equal the total switching costs” (emphasis theirs). Put another way, then, the more it costs to switch, the more profits it is possible in theory to extract.

Among services companies, meanwhile, we see radically different attitudes towards the value of software, and thereby attitudes towards the act of open sourcing internal software. Facebook, at one end of the spectrum, is radically open, contributing everything from infrastructure software (e.g. Cassandra, HHVM, PrestoDB) to datacenter designs to the public knowledge pool. Amazon and Microsoft, however, are not major contributors of net new projects or packages to upstream projects.

The Net

There is little debate that to this point, the rise of service-based businesses has been a boon for open source. And for many of the pioneers of these scale-out businesses, open source is a competitive weapon in their biggest challenge: talent recruitment and retention. Developers evaluating open positions today are often faced with a choice: develop in a black box, where your work will touch thousands of other developers daily, but for which you’ll receive no external credit. Alternately, they can work on interesting problems and be given some latitude for sharing their work outside the firewall, improving their visibility and marketability moving forward.

To some extent, the lack of interest in the AGPL is a testament to the foundational role of open source in building out service-based businesses. If collaborative development and upstream contributions to key infrastructure projects was a major issue, the AGPL would probably be employed more frequently as a solution. Instead, it is an infrequently used license whose protections are widely regarded as unnecessary.

All of that being said, however, it is equally true that the future for open source in a services world is ambiguous. There are substantial incentives for vendors to drift towards non-open software, and the current trend towards permissive licensing, if anything, could accelerate this. By placing few if any restrictions on usage of open source software, permissive licenses present no barrier to any form of usage of open source software in proprietary contexts. It is true, however, that for services-based businesses, even copyleft licenses such as the GPL pose little threat because the distribution trigger is not tripped.

Taken as a whole, then, open source advocates would be wise to be appreciative of how far service businesses have gotten them to date, while being wary and watchful of their intentions moving forward.

Disclosure: Amazon, Microsoft and Oracle are RedMonk clients. Facebook is not.

Categories: Cloud, Hardware-as-a-Service, Open Source, Software-as-a-Service.