The original idea behind J2EE was as simple as it was compelling. “Write once, run anywhere” promised customers a layer of abstraction which would provide independence from underlying operating system and hardware layers, and thus, in theory, vendor substitutability. In practice, “write once, run anywhere” was as aspirational as not, with providers of J2EE middleware constantly in search of features that might provide the customer lock-in the market had trained them to crave. Aspirational or no, however, customers bought into the vision, as companies like BEA rode the middleware market to $8.5B valuations.

Oddly enough, however, multiple runtime PaaS platform providers like Red Hat (OpenShift) and VMware (Cloud Foundry) appear to be discinclined to borrow from the middleware playbook. While “write once, run anywhere” mantra may be a tired cliche, the similar functional goals would seem to offer the opportunity to more easily position PaaS platforms within enterprises. Overall, the idea behind PaaS is the same as it once was for J2EE: to containerize applications, thereby making them portable across different environments, regardless of the underlying infrastructure. Neither Cloud Foundry nor OpenShift seems eager for the comparison, however.

OpenShift.com, for example, says that users can “enjoy support for a broad choice of languages, frameworks, middleware, datasources, and developer tools” – the obvious implication being that OpenShift is not, itself, middleware. CloudFoundry.com even more aggressively disavows any relationship between itself and the term. From its FAQ page:

Cloud Foundry allows developers to focus on applications, not machines or middleware. Traditional application deployments require developers to configure and patch systems, maintain middleware and worry about network topologies. Cloud Foundry allows you to focus on your application, not infrastructure, and deploy and scale applications in seconds.

In spite of the functional similarities, then, neither Cloud Foundry nor OpenShift is positioning itself as middleware. To some extent, this may be explained by product portfolios as both Red Hat (JBoss) and VMware (Spring) have existing middleware lines of business, and terming their respective PaaS offerings as middleware would complicate marketing efforts. It is not clear, however, that an attempt to persuade customers to see PaaS as something other than middleware will be successful. Nor that this is the correct approach. Our old colleague Michael Cote’s “burger model” – which characterizes PaaS as middleware – has proven quite popular in various talks and webinars, because it’s easily understood. And technologies that are well understood are easier to sell.

Ultimately, if it looks like middleware and acts like middleware, it probably is middleware – whatever the vendors may assert. PaaS, in other words, is the new “write once, run anywhere.”

At the Ubuntu Developer Summit this week, Dell announced an effort they’re calling Project Sputnik. The basic idea was Dell’s latest and greatest XPS hardware pre-provisioned with developer infrastructure: a developer laptop, in other words. As Barton George discussed, this was in part – full disclosure – an idea of mine. One of the questions we’re fielding from the media following this announcement is why? What’s the point of a developer laptop? I cannot speak for Dell on their motivations or the project logistics, but there are two primary reasons I believe a developer laptop program broadly makes sense.

Most obviously, there’s the success of Apple. It’s easy to forget now with the iPad generating Fortune 500 revenue by itself, but developers played a not unimportant role in Apple’s ascent. To be sure, most of the credit belongs to Apple’s relentless execution, in the areas of aesthetics, industrial design, usability and even supply chain management. But developers had their part to play in Jobs’ comeback story.

Developer populations proved no more immune to Apple hardware’s charms than the average consumer. Even hard core open source developers couldn’t resist the siren song of ‘It Just Works’ married to a Unix kernel, and the result was more Macs at OSCON every year. Developers were more than just another market for Apple, however, because as a population they were disproportionately valuable: alone among customer segments, they had the unique ability to make Apple’s platform more compelling. Developers, after all, build for themselves as much as any external audience, and the result was a rich ecosystem of developer oriented tooling and applications – tooling and applications that were by and large more compelling than Linux and Windows alternatives. For Apple, it was the equivalent of renting out an apartment at a premium and having the occupants leave behind a home theater, new kitchens and bathrooms and a kegorator.

Given the importance of developers, then, it seemed logical that hardware vendors would attempt to specifically court them. But none did. As far as I’m aware, Dell is the only major hardware vendor delivering a machine – even in this experimental fashion – that is optimized for developers. Which seems as odd as it is unfortunate.

The second reason developer laptops make sense is the challenge of building developer environments. I’m not an active developer anymore – my work in R is about as close as I get these days – but I am regularly required to spin up environments for various languages from JavaScript to Ruby. Whether it’s to execute provided scripts, test new tooling or simply play with a new language, it happens frequently. In general, this is much more difficult than it needs to be. Part of it is basic questions. For a given programming language, am I better off finding packages, or leveraging runtime package management systems like CRAN, npm or rubygems? What is a reasonably current version of the libraries? And so on.

There is endless documentation for this on the web, of course. But where do I find it for each new community? How much of it is current and maintained? And who is behind the individual configurations? If I wanted to replicate Flip Kromer’s Ruby setup for example, or Ryan Dahl’s JavaScript environment, or Tim Bray’s Android configuration, could I do that? For the most part, the answer to that question is no. Or at least, not easily. Which is unfortunate, because as an industry, we’ve gotten very, very good at machine configuration. Tools like Chef and Puppet or Ubuntu’s Juju are excellent at scripting typical configuration tasks in an eminently repeatable fashion. Why aren’t these tools more commonly applied to desktop environments, then? And why aren’t there canonical – note the small C – images available for individual development environments?

One of our most important roles at RedMonk is to serve as an advocate for developers, who we believe are the most important single constituency in technology. For me, then, the question isn’t “why a developer laptop?” but “why not a developer laptop?” If we can help vendors understand how important developers are and that it’s worth making it easier for developers to set up their environments and share these configurations with each other, that seems like a win here. It will be interesting to see whether the market agrees.

Disclosure: Canonical and Dell are both RedMonk customers, while Apple is not.

In the wake of the Google vs Oracle trial and yesterday’s European Court of Justice ruling, there has been a substantial volume of debate first on whether APIs should be copyrightable, and second what the industry impact would be if they are. Because we’re getting a reasonable volume of inquiries on the subject, it’s probably worth documenting my position publicly here.

Regarding the first question, it will probably come as no surprise to those familiar with my positions on intellectual property mechanisms like patents [coverage] that I do not believe that APIs should be copyrightable. The original intent and purpose of intellectual property mechanisms such as copyrights, patents and trade secrets is to protect original inventors and thus provide the incentive for innovation. The non-trivial challenge is balancing the individual good versus the public good. With the authored code that creates APIs is already subject to copyright and the original inventions (regrettably) protected by patent, extending similar protections to the byproducts – the APIs – seems over-broad.

Irrespective of my opinion on the subject, what will the impact be should APIs prove copyrightable? It is likely to be extensive, cascading and a lesson in unintended consequences. Even parties with no intention of asserting their intellectual property rights concerning APIs – think authors of permissively licensed programming languages, as one example – will presumably be required to commit to non-enforcement, contractually. And obviously those parties wishing to realize another revenue stream, limit competition or both will ramp up legal actions around unlicensed usage of the APIs in question. It’s difficult to fully predict the downstream effects, but given the accelerating servicification of the world, a decision in favor of copyrightable APIs is likely to be at least as damaging as the patent system is today.

That said, it’s worth noting that many large entities are already behaving as if APIs are in fact copyrightable. The most obvious indication of this is Amazon. Most large vendors we have spoken with consider Amazon’s APIs a non-starter, given the legal uncertainties regarding the intellectual property involved. Vendors may in certain cases be willing to outsource that risk to a smaller third party – particularly one that’s explicitly licensed like a Eucalyptus [coverage]. But in general the low risk strategy for them has been to assume that Amazon would or could leverage their intellectual property rights – copyright or otherwise – around the APIs in question, and to avoid them as a result. Amazon, while having declined to assert itself directly on this basis, has also done nothing to discourage the perception that it has strict control of usage of its APIs. In doing so, it has effectively turned licensed access to the APIs into a negotiable asset, presumably an outcome that advocates of copyrightable APIs would like to see made common.

In general, it is increasingly apparent that the traditional legal mechanisms associated with intellectual property both cause more problems than they solve and inhibit more invention than they incent with respect to software. It is equally clear, unfortunately, that given the financial stakes involved, the status quo is likely to persist in more cases than not.

One final note, for those concerned that a decision that APIs are in fact not copyrightable renders the GPL invalid, I recommend this piece by John Bergmayer. It lays out the legal foundation – or lackthereof – to that argument nicely.

Disclosure: Eucalyptus is a RedMonk customer, while Amazon is not.

One of the most common misperceptions about Michael Lewis’ book Moneyball is that it’s a book about baseball. In reality, sport is just the backdrop for a story about the search for inefficiencies in a given market. With an asymmetric appreciation for an asset’s value, Billy Beane’s Oakland A’s were able to outperform their payroll because they had to spend less than their competitors. It is, in other words, a book about the search for a competitive advantage.

For decades, baseball teams were built on the idea that batting average was a metric that accurately reflected ability. But given that the most important thing a hitter can do is not make an out, Bill James, among others, was one of the first to challenge this orthodoxy as early as the 1970′s. His view was that batting average was a narrow metric, less important, in fact, than on base percentage (OBP). A metric which reflects nothing more or less than a hitter’s ability to not make an out.

Thirty years after Bill James’ research was published, this simple idea was still considered revolutionary. Which was why it constituted a major competitive advantage for the Moneyball era A’s. With the value of on base percentage not widely understood, Oakland could acquire on base skills for pennies on the dollar, and thus construct their roster more efficiently than competitors.

A decade later, and virtually every club understands the importance of OBP. And with the skill now properly valued, it no longer represents a competitive advantage for clubs. Today, as the New York Times documents, baseball is an industry that’s in constant search for the new OBP, a new competitive edge, a new asymmetrically understood and appreciated skill.

In many respects, software is the new OBP.

Time was that software represented a competitive advantage. The first CRM implementers, for example, could reasonably expect to sell and service their customers better than competitors who’d strayed from their core competencies to build and maintain their own homegrown systems. Today, the penetration of packaged CRM implementations make it extremely unlikely that they will in any way be competitively differentiating. When everyone has Salesforce, what’s the competitive advantage to Salesforce usage? Even more recent technical developments such as Hadoop represent less of a competitive advantage than the people who run them, because their open source nature makes accessibility symmetrical. From CRM to ERP to operating systems to web servers to relational databases to virtualization, there are fewer and fewer software categories that offer a true competitive advantage.

The technology industry is a lot like major league baseball circa 2000: it shares widely held, but fundamentally incorrect, ideas about valuation. Vendors and buyers alike, for example, behave as if software were a competitive advantage, when this is only rarely the case. As GitHub’s Tom Preston-Werner writes, there are pieces of software that represent “core business value,” and these are assets worth seeking and protecting. But those are, in general, a fraction of an organization’s overall software investments. Most software simply does not represent a competitive advantage. Attitudes towards the value of software appear to be roughly generational in nature, as we’ve seen, but with a half trillion dollar industry built on assertions and assumptions of software’s value, the conventional wisdom is unlikely to change materially in the near future.

Like OBP, software is a necessary component to every organization. And like OBP, it is in most cases no longer a differentiator.

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.

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.

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.

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.

Previously, we’ve argued that the lack of breakout successes and the repositioning of vendors like Infochimps suggests that the data marketplace opportunity is years instead of months away. If we assume, for the sake of argument, that this is plausible (Edd Dumbill is more bullish), the question is what this means. The obvious answer is the frictions that are the inevitable consequence of marketplace inefficiencies, one result of which is decreased appetites for software ranging from data management to visualization and analytics. The logic is straightforward, if data remains hard to get, consumption will experience slower growth. Slower growth and less external data, means less demand for tools to process and analyze same.

The less obvious risk, however, may be content monopolies. While these are relatively uncommon at present, they represent an obvious barrier to entry to would be content oriented businesses. Content licensing for IBM’s work around Watson in the healthcare space was inefficient, for example, because the lack of wider marketplace valuations made each negotiation a one off. But as IBM demonstrates with its continued push into the space, the costs and effort are acceptable relative to the size of the opportunity. If IBM were to explore opportunities for Watson in the legal industry, on the other hand, the costs would likely be prohibitive. Unlike other industries, control of content in the legal vertical is largely consolidated in the hands of two players, LexisNexis and Westlaw. This control has allowed them to keep licensing costs for their product, and thereby margins, high. Bloomberg is attempting to compete as a lower cost offering at $450 per seat cost per month. And even Bloomberg, with its business and technical acumen, has an uncertain competitive path ahead of it. Superior technology or no, its access to content will be asymmetrical, limited by the exclusive licensing agreements enjoyed by LexisNexis and Westlaw.

It may be that would be content monopolists in other sectors find market sentiment a significant impediment to their efforts to consolidate control. Reed Elsevier – the parent company of LexisNexis – is facing a boycott of better than 8400 researchers for its business practices relating to scientific journal subscriptions. But the economic incentives are high enough that speculators, at least, are likely to try and anticipate some of the content areas that will be in demand. From real estate to science, data will be at a premium. And without efficient markets to smooth distribution, it is probable not only that overall costs will be higher, but that certain areas will look a lot like legal: sufficiently costly so as to make data oriented businesses and greater competition impractical.

The asymmetry of open source technologies’ ability to penetrate the enterprise datacenter is not difficult to understand. Besides questions of maturity, the fact is that different product categories carry different risk profiles, a major factor for enterprises more afraid of making the wrong choice than interested in the right one. Red Hat’s sustained growth, for example, indicates that operating systems are experiencing minimal friction in terms of adoption. Non-relational databases, on the other hand, while widely used aren’t trusted by corporate buyers yet in quite the same way, with Hadoop a notable exception.

One area that hasn’t endured the same level of skepticism is open source configuration management software. While there are many options, system adminstrators and developers are advantaging Chef and Puppet at the expense of competing solutions. But with that success comes an obvious question: which do I pick, and why?

Although discussions of the platforms’ relative technical merits can be interesting – the comments on this HN thread display the usual range of opinions on the subject – we’re typically more interested in usage patterns. Quality of implementation is an important consideration in technology selection, but history demonstrates adequately that technically inferior solutions can and often do outperform competitors. Because there is no single canonical source for usage, we instead examine a variety of proxy metrics, looking for patterns that indicate a broader narrative at work. Here’s a non-comprehensive run through some of the metrics that we regularly evaluate.

Debian

Update: Spoke with Opscode’s Jesse Robbins who wanted me to be aware that Chef’s under-representation on Debian is likely due in part to the fact that they run and manage their own repositories, but also because they recommend deployment via the RubyGems package manager over Debian’s apt-get. So consider yourselves caveated; the charts otherwise remain untouched.

Each running instance of the Linux distribution Debian has the ability to phone home telemetry of the packages installed on the system. Called Popularity Contest, this provides insight into what the relative adoption rates of various software packages are within the subset of the Debian community that has elected to self-report application information. This graph, then, reflects adoption of Chef relative to Puppet within the Debian community.

As you can see, Puppet substantially outperforms Chef in this context. Part of this is the fact that Puppet is by four years the older project, and thus has had additional years to build adoption numbers. But if we look more closely at the data, however, there are indications that adoption may also be a function of packaging issues. In mid-July of last year, Opscode (the company behind Chef) made updated packages available for Debian and related distributions. Almost immediately thereafter, according to Debian Popularity Contest data, adoption spiked on that platform.

More interestingly, the adoption of Chef enabled by the new packages may have led to a transient decline in reported Puppet adoption. If we examine a three month period of Puppet adoption beginning in July, the impact to the overall trajectory is apparent.

From a macro perspective, the data indicates Puppet still remains more broadly adopted within the Debian community than Chef. But Chef is growing, and the evidence does seem to confirm growth for one is negatively correlated with growth from the other.

GitHub

As one of the largest and most important developer communities in existence, we track individual project performance on GitHub closely. With author backed repositories for both Chef and Puppet available, it’s possible to compare the performance of the two projects in basic fashion. GitHub gives a slight edge to Puppet in terms of total contributors; 121-118. Puppet also saw more pageviews on GitHub over the past 90 days, 30735 to 22361.

But in metrics relating to explicit interest in the project – specifically the numbers of forks and watchers per project – Chef outperformed Puppet.

The results from GitHub then, are relatively inconclusive. Implicit metrics like pageviews point one way, explitic metrics like forks another. There is no clear winner of this category.

Hacker News

On Hacker News, neither Chef nor Puppet are dominant from a discussion perspective. Mentions of one tend to closely track discussion of its counterpart, in fact, according the Hacker News search APIs.

The correlation is unsurprising except for the timeframe; Chef shows substantial traction in discussion on Hacker News well in advance of its 2009 availability. This suggests artifacts in the returned data, because mailing list traffic archives only date back to 2009.

Shared Scripts

One of the concepts shared by both Chef and Puppet is scripts that implement common patterns. In Chef, these are called cookbooks, for Puppet users, modules. While it’s impossible to effectively measure the number of scripts per project – their library size, so to speak – we can attempt to evaluate first how many each company hosts themselves. Second, we may attempt to imperfectly infer community size by comparing query returns for both projects on GitHub, as it is, not surprisingly, common practice to host cookbooks and modules on the site.

For the former, here are the returns. As a side note for those interested, these results were obtained by Puppet’s forge site and Opcode’s Cookbook Site API, respectively.

As you can see, Opscode currently hosts approximately thirty percent more scripts than does Puppet Labs, though to what extent either vendor is focusing their attention on these sites versus their efforts on GitHub is not entirely clear. Comparing general GitHub query results, meanwhile, we see that the lead has changed hands.

As measured by general GitHub queries, Puppet enjoys a slight (~10%) advantage in returns over Chef. It’s a rough metric because it includes all matching repos, but as a broad indicator of traction it has some utility.

The Gist

Ultimately, the data we’ve looked at – aside from the Debian usage information – doesn’t prove the case for either platform. Puppet backers can take heart in its dominance on Debian as well as its GitHub pageview lead and repo traction. Chef advocates, on the other hand, may take comfort in the fact that a project that’s four year younger is outperforming more mature competition in some metrics. For our part, we have (full disclosure) worked with and admire both companies.

And while there is understandably friction between the two communities at times given the functional overlap, it is likely that there’s more than enough oxygen to support both projects indefinitely. Apart from the various community numbers discussed above, both can point to impressive customer rosters and partner bases. Given the opportunity size and scope, however, as well as the legitimate traction behind both projects, the ultimate leadership role for the category may not be who can create the best software but who can best leverage the data it generates. With software valuations in decline, data should increasingly be a product focus.

In the meantime, it will be interesting to watch these projects compete with each other moving forward.

Afterword: In case anyone’s curious, we did look at StackOverflow metrics as well, but the differences were slight enough that we omitted them from the above.