Blogs

RedMonk

Skip to content

Untappd: Pay for What You Love

Two years, one month and three days ago I checked into Untappd for the first time. My first checkin, naturally, was an Allagash Curieux. For those unfamiliar with the application, Untappd – besides being the official social network of the Monktoberfest and Monki Gras – is essentially a Foursquare for beer. Each new craft beer you try can be checked in, with the option to record a variety of other details like location, rating and so on.

Built by Greg Avola and Tim Mather, Untappd is entirely bootstrapped, since, oddly enough, the venture capital community hasn’t yet perceived the obvious data revenue opportunity the startup presents. Untappd for now is an evening/weekend affair, as both of the founders have day jobs to pay the bills.

Last Wednesday, Untappd announced the availability of a “Supporter” subscription. At the cost of $5 a month or $50 per year, Untappd would unlock for users a special badge (like Foursquare, Untappd leverages badges heavily), make available a stats page and permit the direct download of your checkin history in several formats.

Like many Untappd fans, becoming a Supporter was an easy decision for me. The features were useful: while the export data was already available via Untappd’s free public API, the ability to simply download it as a CSV was welcome. But even if the subscription included no new features, I’d have signed up.

As my own interest and that of many of my friends and family in craft beer has grown, Untappd’s made the critical leap for me from trival to home screen application. Both for tracking my own history – which beers I have enjoyed, which I haven’t, and where – as well as following my friends’ own rare beer finds and such. One of the reasons we had Greg speak at the first Monktoberfest and subsequently at the Monki Gras is that Untappd is at the heart of the intersection of social and technology: it’s fundamentally altering consumption and social interaction patterns with technology. Just as Foursquare incents users to frequent new establishments or build their loyalty with a single venue, so too does Untappd encourage an entirely different set of behaviors amongst its users. And given the generally higher margins associated with the craft beer commercial ecosystem, revenue shifts are coming – just ask the large domestic brewers.

The venture capital community, I have confidence, will see the attendant economic opportunities in these behavioral shifts eventually and provide the funding necessary to take the Untappd business to the next level. Until then, however, I’ve wanted to do whatever possible to ensure that Untappd not only remains viable as a service, but grows, adds new features and more. Which is why the Supporter subscription was, to me, a welcome development. While the actual cost to me was marginal – less than the price of an average craft beer draft – the hope was that in aggregate, Supporter revenues would at a minimum help offset the costs of running the service.

Which are, in all probability, substantial. On their second birthday in October, Untappd had over 300,000 users who collectively had checked in 14,000,000 beers. Keeping the service up and running during holiday or festival related spikes, not to mention the development of both web and native (via PhoneGap) Android and iOS clients, is presumably expensive in both dollars and hours. It’s likely, in fact, that at a contribution level of $5 per month, I’m stealing from Greg and Tim.

A subset of users didn’t see it that way, however. Some predictably failed to actually read the announcement, reacting angrily to Untappd suddenly “charging” their users, in spite of the fact that every feature of the application available prior to the announcement remained free. Complaints born of simple ignorance, however, were easy enough to dismiss. More troubling was the segment of the Untappd userbase that believes itself entitled to functionality, for free, forever. This segment appeared to be, in part, the reason Untappd had to follow up with a post explaining that, in fact, nothing had changed for those users that didn’t wish to pay, that they weren’t holding your data hostage, and so on.

As with the outrage that accompanies outages or changes to other free services like Facebook, Gmail or Twitter, developers are essentially put in a no win position. While costs of development and for software, hardware and bandwidth have and continue to come down substantially, applications are neither free to build nor to maintain. But users have become expect the costs to be born by an alternative revenue model, advertising-oriented or otherwise. Oh, and they don’t just expect the service for free, they expect the service level to be no outages, ever.

This is, in all likelihood, an unsustainable expectation moving forward. Many services will remain free, but others – particularly the bootstrapped – will need help, particularly if venture capital dollars become harder to come by for consumer web companies. Some of that help will likely come from the leveraging of aggregated user telemetry (just imagine how much Untappd knows about the craft beer community right now) but with data markets systemically inefficient at present, direct user contributions will be an important source of revenue.

If there’s an application you enjoy using then, please consider kicking in a few dollars to support the developers behind it. They’re very often making your life better at the cost of their free time and money. A few bucks that you probably won’t miss can add up for them, and result in a better, more innovative application for you.

Pay for what you love, and everybody wins.

Disclosure: I know Greg, the co-founder of Untappd, personally.

3 Comments

Categories: Startups.

Tags:

By sogrady
— December 10, 2012 at 10:40 pm

The Importance of Software to Microsoft

In October of 2005, then CTO of Microsoft Ray Ozzie issued a seven thousand word memo to his direct reports entitled “The Internet Services Disruption.” Addressing the dynamic landscape around internet based services impacting traditionally distributed software, it spoke of both opportunity and threat for Microsoft. “As much as ever, it’s clear that if we fail to [respond to the challenge], our business as we know it is at risk,” Ozzie cautioned.

Seven years later, perceptions of the role of software as a revenue engine are largely unchanged. While delivery models for software have shifted, incorporating new mechanisms such as open source and SaaS, the business models behind them have evolved little. Most software revenue is still derived from a combination of license, support and maintenance fees, as opposed to, for example, application generated data and analytics. At Microsoft, for example, approximately 83% of the revenue is derived from the business units principally (if not exclusively) associated with software: Windows & Windows Live (Windows), Server and Tools (Windows Server, SQL Server, etc) and Microsoft Business (Office). While each of those business units incorporates non-traditional software components – e.g. Azure or Windows Live – the primary revenue engines remain Office and Windows.

Nor is Microsoft alone in its reliance on software models; the majority of large software suppliers (e.g. Oracle) remain primarily oriented around software revenue streams, and have demonstrated minimal interest in diversifying their businesses to hedge against potential challenges to software margins: Exadata is an exception rather than the rule.

What’s unclear is whether the commonly perceived viability of software revenue models is correct, or Ozzie is. Having spent time over the past several years working with software firms and examining the fundamentals of the revenue model, the causes for concern to me are obvious. But what does Microsoft’s actual performance suggest to us?

Microsoft’s revenue figures suggest that they remain able to grow their revenue, if not as quickly as in years past. Revenue growth from 2010 to 2011 was 11%, and from 2011 to 2012 the figure was 5%. Microsoft’s revenue model may be impacted by disruptive services on an ongoing basis, but it has not been crippled as a result.

How reliant is Microsoft on software as a revenue engine, however? What impact can be seen on Microsoft’s revenue picture from Ozzie’s efforts to steer Microsoft towards the leveraging of services as a source of revenue alongside software?

While Microsoft’s Entertainment and Devices and Online Services divisions are able to generate revenue, as demonstrated above (12.4B collectively in 2012), they are thus far unable to impact Microsoft’s bottom line in a positive manner. Over the last three years, Entertainment has been responsible for around 2.4% of Microsoft’s operating income. Online services, meanwhile, has been an anchor, financially speaking: the operating income for the division over the last three years beginning in 2010 was (2.4B), (2.7), (8.1). In 2011, it cost Microsoft 9% more than it did in 2010, and in 2012 Online Services cost Microsoft 67% more than the year prior.

In short, while Microsoft has grown its services business and generated real revenue from them, it has not been able to do so profitably. To date the company’s core software businesses have been able to subsidize this growth without a material negative impact to the company’s share price, though they might be contributing to the stagnancy there, but the financial trendlines are obviously not sustainable over a longer term.

These losses have convinced some investors that Microsoft should decommit from the businesses behind them, by sale or otherwise. This is a reasonable contention if you believe that the margins extractable from software will remain substantial indefinitely. Ozzie was clearly concerned about this prospect moving forward, and I have argued that the realizable margins from software are, in fact, in decline.

Microsoft itself, as it happens, offers some evidence that this may be true.

Peaking just prior to the year 2000, Microsoft’s margins have been in steady decline since. It’s possible, of course, that this is merely execution on Microsoft’s part as opposed to a broader industry trend. IBM’s consistent ability to grow profit in its software division is one contradictory datapoint. But considering the wider industry trends, from open source to cloud to SaaS to bring your own device, it’s not clear that Microsoft could or should consider a return to a purely software based revenue model.

Its losses otherwise notwithstanding, Microsoft is probably best served identifying the specific failures of its non-core software businesses rather than jettisoning the models entirely. If our assertions about the longer term direction of software licensing are correct, in fact, they may have no other choice.

For the foreseeable future, it will remain possible to monetize, at a healthy margin, software. But it is getting more difficult to do this every year, as the competitive threats multiply from unanticipated directions. While software is critically important to Microsoft, then, the company’s future could depend on it becoming less so.

2 Comments

Categories: Economics.

By sogrady
— December 6, 2012 at 6:13 pm

Ten Years of RedMonk

Ten years ago today the DARPA funded paper describing REST was six months old. There was no Firefox. No Eclipse Foundation. No Facebook. No Amazon Web Services. No Twitter. No LinkedIn. No YouTube. No Etsy. No Gmail. No Hadoop. No iPhone. Apple, in fact, was worth $5.143B, or about what they made every month and a half in 2012.

Much of what we take for granted today didn’t exist then. Like the industry’s affection for developers.

When James and I officially incorporated RedMonk ten years ago yesterday, the technology industry cared little for what developers thought – all of the focus was on “enterprise” buyers. Which we never understood. It seemed self-evident to us that with access to technology steadily being democratized by open source and later cloud, SaaS and other wider industry trends, developers were increasingly in charge, not the erstwhile “IT decision makers.”

This is our understanding of the world.

For the last ten years, then, we’ve been paying the most attention not to what CIOs want to buy, or what software vendors think they want to buy, but what developers are using.

From our perspective, if you want to understand where the industry is headed, your best answers will come from those who are actively determining that path. Our time with developers – or more precisely, practitioners of any one of a dozen or more different technical disciplines – has gifted us with a reasonable ability to predict where the industry is headed. Granted, not always with a high degree of temporal precision.

If there’s one thing we at RedMonk have learned over the past decade, it’s that the ability of the technology industry to change substantially outpaces the industry’s own ability to understand and adapt to that change. What we understand at RedMonk to be true today might take as many as five years or more to be widely understood. Hence our saying “we can tell you what will happen, we just can’t tell you when.”

Here are a few of the subjects we’ve covered since 2004, when we really began blogging in earnest.

  • In 2004:

    • We were advocating for REST support. Today, it’s the majority of tracked APIs.
    • We argued that there was room for Linux distributions besides Red Hat (and SUSE) in the enterprise. Today, Ubuntu is the most popular Linux distribution on AWS and HP supports the platform on its enterprise cloud.
  • In 2005:
    • We disputed the assertion that enterprises were not leveraging dynamic programming languages. Today, virtually every enterprise PaaS offering supports more than one.
    • We believed that relational databases needed to be supplemented by non-relational alternatives. Today, NoSQL and non-relational datastores are mainstream technologies.
  • In 2006:
    • We were bullish about Amazon’s Web Services platform. Today, AWS is almost as dominant in the cloud as Microsoft was in operating systems.
    • We predicted that no pure play open source vendor besides Red Hat would break the billion dollar revenue mark, and that Red Hat would do so in 2012. Today, no pure play open source vendors besides Red Hat have broken the billion dollar revenue barrier. Red Hat eclipsed $1B in revenue in 2012.
  • In 2007:
    • We recommended that commercial open source vendors augment service and support revenue streams with network and data models. Today, vendors such as 10gen (MMS) and Sonatype (Insight) are complementing open source revenues with network and data based revenue models.
    • We were surprised at the lack of attention paid to Decentralized Version Control Systems (DVCS) given the surging developer adoption. Today, DVCS accounts for nearly a third of the project traction on Ohloh, up from 14% in 2010. Git is the standard deployment mechanism for a variety of cloud platforms, and in July, GitHub was valued at three quarters of a billion dollars.
  • In 2008:
    • We argued that open source relational databases would eventually see substantial adoption in the enterprise. Today, Oracle owns MySQL and both Salesforce.com (via Heroku) and VMware are investing heavily in PostgreSQL.
    • We made the case that lock-in was one of the major obstacles to using Google App Engine. Today, Google allows GAE developers to leverage the MySQL-like Google Cloud SQL, and has added support for Java alongside the original Python to widen the addressable market. Later-to-market competitors such as Cloud Foundry, Engine Yard, Heroku or OpenShift, however, continue to take advantage of the limitations of GAE.
    • We recommended that everyone read Fivethirtyeight.com for election coverage. Today, well, you know.
  • In 2009:
    • We asked who was going to build the App Store for the enterprise? Today, the Google Apps Marketplace (03/10) and the Microsoft Office and SharePoint App Store (08/12) are two plausible answers.
    • We believed that programming language and platform fragmentation would have profound implications for vendors moving forward. Today, VMware’s determination in building Cloud Foundry (2011) – that it be open source software and support multiple programming languages from day one – are typical rather than revolutionary.
  • In 2010:
    • We observed that companies such as Facebook and Twitter tended to default to open source, embrace language heterogeneity and favor permissive licensing. Today, this attitude is perhaps best summarized by GitHub’s Tom Preston-Werner, who wrote in 2011: “Open Source (Almost) Everything.”
    • We summarized our long held beliefs by saying Developers are “The New Kingmakers.” Today, every major software vendor, every major consumer devices producer, the majority of enterprise hardware makers and even a number of chip manufacturers have programs designed to attract and engage with developers.
  • In 2011:
    • We predicted that ARM would emerge as a server player. Today, AMD has announced its intent to manufacture ARM servers for the 2014 market and Dell is already experimenting with 64 bit ARM server designs from AppliedMicro.
    • We took issue with claims from other analysts that Java was a dead end for enterprise application development. Today, we see a robust market for Java skills not just within enterprises, but consumer startups (e.g. Twitter) and open source projects (e.g. Hadoop).
  • And in 2012:
    • We wrote that software was the new On Base Percentage, an asset undervalued in the 1970s and 1980s that was overvalued in 2012. Today, Microsoft’s entry into the hardware business and its incorporation of an advertising model into Windows 8 seem to confirm that Microsoft, at least, is hedging against challenges to traditional software revenue streams.
    • We asserted that the market for a business is less important than the business model underlying it. Today, we’re waiting on more data to test this hypothesis.

And that is strictly my research, because it’s what I remember best. My colleagues have produced even better predictions and research over the last decade, and there are dozens more predictions we could point to that have subsequently been proven out: identifying Amazon as a credible enterprise threat, for example. Many more, such as our expectations with respect to software and data-based revenue models, are years away from becoming mainstream.

A lot has changed over the last decade. If you owned a thousand shares of Apple, for example, they’d be worth $576,750 more today than when we incorporated. RedMonk has changed as well. We’ve changed webhosts no fewer than six times. Domain registrars four. Email providers three. Content management systems three times. We’ve been through two recessions, maybe half a dozen offices between us, and the firm has moved its headquarters no fewer than three times.

We’ve also changed how we work. As more developer related data has become available, for example, we’ve aggressively embraced quantitative analysis. Whether it’s our research, or collaborating with third parties like Black Duck, Jaspersoft or New Relic on their own data, the “we-don’t-do-numbers” shop is all about the numbers today. We’ve added services around green and sustainability research in GreenMonk, and you’ve probably heard that we also now organize conferences in the Monktoberfest and the Monki Gras.

But what hasn’t changed about RedMonk is more important than what has. Ten years later, our culture is still family oriented – a good thing given the marriages, births and adoptions. Our focus, meanwhile, remains the same: we are still firmly convinced that developers are the most important constituency in technology, and that our ultimate purpose as a firm is to be their advocates within the wider technology community.

When we look back over the last decade, it’s as impossible to measure our effectiveness as developer champions as to count the MySQL instances in the world. If we’re lucky, the metric isn’t disk space: the bulk of our professional output is housed in a MySQL database that weighs in at a paltry 135.8MB.

We hope that developers have and continue to find our research useful. We hope that we’ve been able to help improve their lives, whether that’s helping them get new jobs, serving as their voice for vendors or even just buying them beers. Most of all we hope the industry eventually realizes what we at RedMonk know: that developers are the New Kingmakers.

In the meantime, I’d like to thank my colleague James for being a great partner for all of these years, Cote for all of his years of excellence, Tom for bringing RedMonk to new arenas, Donnie for picking right up where Cote left off, Marcia for being the most important person at RedMonk, my parents, Sheila and Steve, for helping to support me while we got RedMonk off the ground, and my wife Kate both for keeping us out of legal trouble and for being beyond patient with odd hours and worse travel schedules.

Thank you to all of the developers that have taken the time to read our research, educate us or simply tell us why and where we’re wrong. You are why we exist.

Perhaps most of all, I’d like to thank our clients. A decade later, and we are still here. Your support is what makes that possible, and your engagement, your creativity and your willingness to really listen to us is what makes this job still fun a decade later.

Thank you all for a decade of RedMonk and here’s hoping we’ll have another ten years together.

Postscript: in anticipation of the question, yes, we will be doing a tenth birthday celebration, but conflicting with the holidays seemed like a poor idea. Stay tuned.

19 Comments

Categories: RedMonk Miscellaneous.

By sogrady
— December 2, 2012 at 9:58 pm

The Importance of Software at IBM

According to IBM’s 2011 Annual Report, by September 2015 fully 50% of IBM’s profit is expected to come from its software group (SWG). On the surface, this is surprising, because software is a distinct minority of IBM’s total revenue. In 2011, SWG’s $25B represented less than a quarter of IBM’s revenues earned. Here is IBM’s revenue broken down by business unit (Finance and Other are omitted here).

While software’s contributions to IBM’s bottom line have grown over the last seven years, software is less than half (23%) as valuable from a revenue standpoint as services (56%). Which, absent the profit narrative, would raise questions about the ultimate importance of software to IBM’s business. But revenue is a rough metric, one that neglects the costs of generating that revenue. When profit margin is taken into account, it’s at once easier to understand and appreciate the importance of IBM’s software group, and the longer term goal of having that unit generate half of IBM’s profits. Here are the reported gross margins, by business unit, over the same span.

In 2011, IBM’s reported gross margin for software was 88.5%. The actual number is less important than the context, because gross margin can exclude important and substantial costs such as sales. But whatever the actual margin realized on the product, software is more profitable – by a lot – than IBM’s other businesses. If we apply the reported gross margins to the individual revenue streams, here is each business unit’s respective contribution to IBM’s profit.

It is not, on balance, surprising that software’s contribution to profits are outsized: software scales better than people. But software is also more profitable at IBM than at many competing software businesses, which is more interesting. The sustained growth of reported margins is also worth noting; with the exception of 2007, when they held flat, IBM’s software margins have grown every year since 2005. This is true for neither of the two other major BU’s.

What we don’t know about IBM’s software business, however, may be the most important trend. Unlike Oracle, IBM does not appear to split out new license revenues from existing sales, support and service contracts. This means that while IBM’s growth is evident, the actual mechanisms are less so. At Oracle, software revenues are on a similar trajectory, but new licenses as a percentage of overall revenue are declining. If the same is true of IBM, it could be cause for concern.

In answer to the larger question of how important software is to IBM, it’s clear that SWG is core to the business moving forward. Its unique-to-IBM ability to extract outsized profits is the foundation upon which the company’s profit growth depends. Strengths, however, can also represent weaknesses if they open doors to disruption.

In IBM’s case, it’s important to consider the wider market context. Across a wide variety of software segments, the evidence suggests that the realizable margins attached to software are in decline. From collaboration software to middleware to databases, margin oriented revenue models are under attack from volume focused alternatives. The precise competitive mechanisms may vary – cloud, open source, SaaS – but the result is a more competitive pricing market for software. While demand for software is more or less inelastic, credible free or low cost options almost inevitably lower the realizable revenues for software. The resulting lower margins are perfectly acceptable for volume based businesses, but much less for those built upon high margins such as IBM.

As demonstrated above, the numbers show little impact to IBM from volume oriented businesses to date. But as its software group begins to compete more actively in lower margin areas such as SaaS, it will be interesting to see how its high margin expectations impact the operation and positioning of its offerings. Given the market context, in fact, it’s worth asking whether IBM should be attempting to aggressively grow one or more volume businesses as a hedge against potentially lower future margins. In its 2012 10-K, Apple cites the following as a concern:

The Company’s financial condition and operating results can be adversely affected by these and other industry-wide downward pressures on gross margins.

To date, this has not been a problem for IBM. But this doesn’t mean it will not be in future, and if IBM’s to avoid being disrupted, it would do well to have contingency plans in place for the lower margin future that seems probable.

4 Comments

Categories: Economics.

By sogrady
— November 30, 2012 at 4:00 pm

Does Enterprise vs Consumer Matter?

“The momentum/late stage investors have moved from consumer to enterprise. There is a large pool of money in the venture capital asset class that is opportunistic, momentum driven, and thesis agnostic. This pool is driven largely by the public markets. This pool of capital was “all in” on consumer web/social web in the 2009-2011 time frame. It drove a lot of activity throughout the venture capital markets because each layer of the VC stack (angel, seed, Srs A, Srs B, Srs C, etc) needs to be aware of what the next layer up wants to fund. when the momentum/late stage wanted web/social, the layers below gave them web/social. Now that the momentum/late stage wants enterprise, we should expect the layers below to give them enterprise.” – Fred Wilson

Fred Wilson is not alone in claiming that patterns of venture funding are shifting away from consumer startups towards enterprise oriented alternatives. Industry chatter has been concerned with this trend for some time, amplified in part by an industry analyst industry that has historically been over concerned with the enterprise at the expense of consumer technology trends.

But while context is important – as Wilson notes, consumer markets may be somewhat saturated – the difficulty with discussions of consumer versus enterprise models is that it presumes that the distinction between consumer and enterprise is an appropriate axis for investing or evaluation purposes.

To begin with, distinctions between consumer and enterprise are breaking down. The list of consumer technologies employed within enterprises is long: from instant messaging to webmail to social media to VOIP, consumer technologies are increasingly a staple within businesses large and small.

And even the enterprise startups that are being funded today show a clear consumer technology influence. Consider Yammer, a recent enterprise venture funding success story: it is essentially a replica of consumer technologies built for the enterprise. Its intended market may be businesses, but its pedigree is solidly consumer.

Or better, consider Apple. At their core, enterprise businesses have historically been margin oriented, while consumer focused businesses have been built upon volume sales. The margins on an Oracle database license, as one example, are orders of magnitude higher than an individual AdWord commission. Google’s consumer reach, however, enables it to sell enough AdWords to be worth 32% more than the database manufacturer as of yesterday. But the lesson here is not that consumer markets are inherently superior, but rather that both offer opportunities for profit. Apple, whose success was built on consumer markets but is increasingly becoming an enterprise seller, is worth more than Google and Oracle combined.

Besides the collapsing distinctions, there evidence to suggest that the revenue mechanism may be more determinative of success or failure than the target market. Investigating a claim that a billion dollar software company is founded every three months, the following crowd sourced list of billion dollar entities was assembled. With the twin caveats that these valuations are obviously imprecise and the list is undoubtedly incomplete, subsetting the list to entities of strictly one billion or more in valuation gives us this list (corrections welcome). Breaking that list down by revenue model, we find that 66% of these billion dollar entities do not derive the majority of their income from softare sales. And of the 34% that derive their income primarily from software, the majority (20%) monetize this software in a network contest, rather than shipping software directly to customers. Of all of the so-called software startups then, a mere 14% sell software directly to customers.

Few if any of the startups would or could exist absent investments – many of them substantial – in software development. But comparatively few of them are choosing software sales as a revenue source. They are choosing, in other words, to make money with software rather than from software. Investors, then, might do well to focus more on the mechanism than the market. Both consumer and enterprise markets will generate and support large businesses, but those businesses are going to have to be creative in terms of how the monetize their customers.

As we’ve written, the evidence suggests that generational attitudes towards software are shifting, and the most compelling businesses moving forward will not be built strictly on software monetization, but more defensible data based revenue streams. And from an investor standpoint, the timing of this realization is important, because as Apple is discovering in mapping, once you’re behind in data, it’s very difficult to make up that ground.

While the enterprise / consumer context makes for good copy, then, it is not obvious that it’s the most important consideration for investors looking to build the next big technology business. Mechanism looks more important than market.

1 Comment

Categories: Startups, Venture Capital.

By sogrady
— November 27, 2012 at 2:14 pm

Examining Programming Language Framework Popularity

Having concluded that an examination of the relative performance of programming languages on GitHub and StackOverflow yields interesting results, programming language frameworks are an obvious next step. Given the importance of frameworks in leading programming language adoption, understanding better the traction behind individual frameworks would be useful. With GitHub and StackOverflow representing obvious centers of gravity within the development world, they are clearly in a position to provide some insight into framework-related developer activity.

Before proceeding, a few caveats.

  • Unlike with programming languages, the correlation between GitHub and StackOverflow activity with respect to programming language frameworks is very weak – .28 to be precise. Which means that good traction on one property correlates only weakly with similar activity on the other. In practical terms, then, it’s important not to read too much into these charts.
  • By design, this analysis focuses only on those frameworks with a presence on GitHub. This obviously excludes frameworks such as ASP.net with no GitHub presence, and their omission should not be read as a comment on their popularity or lackthereof.
  • Within the pool of frameworks with a GitHub presence, the following is an incomplete list. It was compiled in part from the frameworks that are most visible to RedMonk and in part on developer requests.
  • The performance of frameworks on GitHub is influenced by whether the hosted project is official or a mirror. So bear in mind that the GitHub watcher count is particularly volatile.
  • Some of these frameworks are micro- in nature, others strictly web. This is an apples to oranges comparison.
  • In other words, the following is an unscientific examination of a narrow subset of total developer frameworks. No more than that, and no less.

With that said, here’s how the programming language framework charts work. As with our programming language rankings, StackOverflow’s tag volumes are used as the representative metric from that property. For each framework, the single most popular identified tag was used. For GitHub’s data, because there are no rankings available as with programming languages, the data here is based on the number of users “watching” a given project. This is used as a proxy for developer interest and engagement with a given framework. The sizing of the individual datapoints, meanwhile, is based on the total of GitHub watchers and StackOverflow tags for each project.

Using that process, we generate the following plot.


(Click for the full size chart)

Notable on this chart are the outperformance of jQuery and Bootstrap on StackOverflow and GitHub, respectively. Bootstrap’s performance is likely due in part to its GitHub native status, but jQuery’s overwhelming popularity on StackOverflow reflects its standing within a variety of JavaScript development communities. Ruby on Rails, meanwhile, has a relatively balanced performance, demonstrating traction on both GitHub and StackOverflow. Node.js for its part sees less traction on StackOverflow than Django, but is four times more visible on GitHub. All in all, however, the presence of these extreme or outlying values obscures the performance of less popular frameworks.

If we remove the five outperforming frameworks in Bootstrap, Django, jQuery, Node and Rails, we get the following plot.


(Click for the full size chart)

Within this subset, Spring’s strength on StackOverflow becomes apaprent, as do Flash and Sinatra’s popularity on GitHub. Play and Grails, meanwhile, show better than average traction on GitHub and StackOverflow, respectively. Beyond that, there’s little to differentiate Bottle, Dojo or Lift.

In terms of the data collected here, then, this is how the assessed frameworks rank in terms of their GitHub and StackOverflow counts:

  1. jQuery
  2. Rails
  3. Django
  4. Bootstrap
  5. Node.js
  6. Spring
  7. Grails
  8. Sinatra
  9. Play
  10. Flask
  11. Dojo
  12. Bottle
  13. Lift

Again, because we are generally comparing apples to oranges, little should be read into the above list, as the frameworks all have varying goals and intended markets. It is, however, interesting to see how they compare in broad terms with one another. And in certain cases where projects are directly competitive, such as with Dojo and jQuery, the numbers may be more meaningful.

3 Comments

Categories: Programming Languages.

Tags: , , , , , , , , , , , ,

By sogrady
— November 8, 2012 at 7:52 pm

Centralized vs Decentralized Version Control: 2010 vs 2012

A growing number of the inquiries we field at RedMonk center around the need for quantitative guidance on technology uptake. Even with technologies on clear growth trajectories, developers, enterprises and vendors alike frequently want better, more detailed data on growth. How fast is it growing? What impact is this having on competitive projects or products? And so on.

Recently, the inquiry volume regarding decentralized or distributed version control technologies such as Git has spiked. Some organizations are considering migrations to such technologies, others have committed to the move but require data to justify their decisions internally.

Interested as we are in developer behaviors and usage trends, we recently examined the question of DVCS usage via Ohloh. Before proceeding, it’s necessary to note that the following analysis does not attempt to claim that Ohloh data is representative of the wider software development market. It is nothing more or less than an attempt to examine one specific dataset, and how it has changed over time. That said, given Ohloh’s focus on open source repositories, the case can be made that its data is likely to be more predictive than other mainstream sources might be.

In November of 2010, Ohloh was tracking 238,000 projects. Of these, the breakdown of code by version control system was as follows (all charts based on Ohloh data).

Notable on this chart are the overwhelming Subversion traction, the surprisingly robust performance of CVS (CVS was 24 years old in 2010) and the lesser but still visible usage of Git.

Two years later, a few things have changed. Here is Ohloh’s November 2012 data.

The two most obvious changes are the decline in CVS traction and the growth of Git. Git’s share, in particular, almost tripled in two years, while CVS declined by better than 50%. The fall off in Subversion usage was much less dramatic at -5.3%, but still visibile.

Here are the relative growth/decline numbers for all of the surveyed repostories between 2010 and 2012.

This chart makes two simple points evident. First, that each decentralized repository demonstrated growth while the two centralized systems declined. Second, that Git substantially outperformed both Bazaar and Mercurial from a growth perspective.

As obvious as it may be, however, that decentralized systems are growing and centralized declining, it is equally apparent that there is yet substantial room for growth. Here is the Centralized vs Decentralized split for the 2010 repository numbers.

A full 86% of Ohloh surveyed repositories were centralized in nature two years ago, although the majority of them as described above were at least on the more modern Subversion. The mentioned growth for DVCS projects is evident in the aggregated numbers for November 2012.

Clearly, DVCS – led by Git – has made substantial gains in overall usage. Nearly a third of all projects are now employing DVCS, versus 14% two years ago. And yet almost 70% of projects remain in centralized version control.

How you view this data likely depends on your perspective. Defenders of centralized version control can point to the still subtantial amount of code that is governed by systems like CVS or Subversion. Advocates of DVCS, meanwhile, can point to the growth trajectory of the platform, not to mention highly visible implementation like GitHub, recently valued at three quarters of a billion dollars. However one interprets the data, however, the clear winner over the past two years has been Git. Almost half of the total change over the past two years is Git alone. If you’re looking for bets, then, based on this slice of version control system usage, DVCS generally and Git specifically would be the most obvious.

Disclosure: Black Duck, the parent company of Ohloh, is a RedMonk customer. Black Duck was not consulted concerning this analysis, however.

7 Comments

Categories: Version Control.

Tags: , , , , ,

By sogrady
— November 5, 2012 at 9:40 pm

Just Because HTML5 Was Bad For Facebook Doesn’t Mean It’s Bad For You

“The biggest mistake we made as a company was betting too much on HTML5 instead of native…We burnt two years.”
- Mark Zuckerberg, September 11, 2012

In the months leading up to the Monktobefest, we received around a half dozen offers to build a mobile application for the conference. The majority were the digital equivalent of cold calls, but a few were detailed proposals for real, rich multi-platform native applications with detailed capabilities.

We considered none of these offers.

Aside from the cost, which at least in one case was significant, my personal experience with native conference applications has been relatively poor. The applications have tended to be bloated, constantly updating and, not surprisingly for a one time app, bug-ridden.

More importantly, however, we already had an application for Monktoberfest, courtesy of our friends at Lanyrd.

While obviously at a disadvantage to native alternatives in some respects, our Lanyrd-based application had session schedules, venue information, maps and an attendee/speaker directory. And it could even be made available offline. It had, in other words, the majority of the features scheduled to be included in the native applications third parties wished to build for us. For the bargain price of free, then, we created and made available a mobile application compatible with, according to Lanyrd, “Android, Windows, iPhone, Blackberry (even really old ones), Kindle and Older devices via Opera Mini.” From the perspective of a conference organizer, this is an excellent deal, even without the other features Lanyrd offers in non-mobile settings.

There are, of course, many applications that cannot be currently satisified – or satisifed well – by HTML5 based technologies, and in such cases native or hybrid approaches are quite appropriate. But the dismissiveness towards web based mobile applications, fueled in part by Zuckerberg’s September comments, seems short-sighted. In an industry with little appreciation for either history or nuance, it is perhaps unsurprising that attitudes towards mobile/native tend to be so binary.

But it was once thought that webmail would never be a realistic threat to native email applications, and that the idea that enterprises would ever consume applications like CRM or ERP through a browser was folly. If time didn’t make fools of those convinced of those truths, it certainly exposed the truths as foolish.

If our experience is any guide, HTML5 is more capable today than is commonly realized. And it is likely to be more capable in future than anyone currently realizes.

3 Comments

Categories: Mobile.

By sogrady
— October 24, 2012 at 9:55 pm

Monktoberfest 2012

When we decided, in the spite of the fact that it began as a joke, to create the first Monktoberfest, the most important question we had to answer was: why? Apart from incorporating craft beer into an event, why did a world with no shortage of conferences need another conference? How would we justify asking people to take time out of their schedule to be with us, not to mention travel up to us in Portland, Maine?

In the end, the reasoning was no different than that which created RedMonk, almost a decade ago. We wanted to build something different. A conference where we took the user experience very seriously. A conference populated by talks that would not be heard anywhere else. A conference full of smart, engaged people who were there by choice rather than geographical convenience. And a conference, of course, that converged the world of craft beer and the craft of software development.

Our attendees are ultimately the best judges of where and whether we have succeeded, but I am confident that for better or for worse, we have created in the Monktoberfest something very different.

Perhaps the best example of this is the two minute and thirty second video above featuring Sam Calagione, CEO of Dogfish Head Beer, talking to the Monktoberfest audience about how collaborating with your erstwhile competitors makes business sense. A lesson I wish the technology industry would absorb.

It’s notable not just because of the content, but because it didn’t come from us. Mike Maney, a longtime Friend of RedMonk, arranged and shot the video for the conference on his own. He and his colleague Matt Helmke turned their travel to the Monktoberfest into an epic 7 state roadtrip, featuring stops at craft breweries all the way from Delaware to Maine. From Riverhorse to Olde Burnside to Harpoon, they went from brewery to brewery, collecting stories and – thanks to some very gracious donations – beer.

How many conferences see attendees make that kind of an effort to make the event better, and more special? People like Mike Maney, then, are part of what makes the Monktoberfest different. A difference, we believe, that makes for a better conference.

Which is why reactions like the following are so gratifying.











Reviews like these from Kelly Smith, Craig Cmehil or Alex King are, meanwhile, why we do the conference in the first place.

And just as rewarding as the knowledge that people enjoyed the experience is the understanding that they’ll be benefitting from it moving forward, via the new connections that are made between people, and by extension, the companies they work for.

Salesforce, meet Etsy. Alcatel, meet IBM. VMware, meet Cisco. Red Hat, meet Outercurve. And on and on.

Mistakes

Lest we make it sound like everything was perfect, rest assured that we had our share of hiccups. Everyone was unbelievably patient with our cramped facilities Friday, but that needs to be and will be fixed. Likewise, we’ll keep working on the wireless to get you all the bandwidth you crave. It’s worth noting as well that what mistakes were made were made by me, not our staff.

Thanks

The simple fact of the matter is that as a smaller organization, we could not bring you the Monktoberfest without help. It’s something of a laundry list because we had so much of it.

We would like to thank the following people for helping to make the event possible.

  • Our Sponsors (there’s no conference without them):
    • IBM’s Puresystems, the lead sponsor for both the Monktoberfest and the Monki Gras (the London version), stepped up in a major way to not only provide the financial support necessary to make this conference possible – including touches like the massage chair – but the London iteration as well.
    • Adobe and its PhoneGap team, as an Abbot sponsor, also helped to bring you the Monktoberfest by underwriting the finer aspects of the experience.
    • Thanks to CloudSpokes, we have full video of every session.
    • SAP, meanwhile, is bringing you follow up interviews with our speakers.
    • Basho, for its part, helped to bring you the lobster, steak or veggie kabobs you had for dinner.
    • Heroku was no slouch and offset three rounds of drinks.
    • Another round came from the good folks at Zendesk, who along with Telegraph also helped bring you the finest doughnuts and breakfast sandwiches that Portland has to offer.
    • Crowd Favorite helped us keep the wireless up for a full two hours longer than last year – yay! And FYI – the failure of the wireless is our fault, not theirs.
    • O’Reilly bought free ebooks for everyone in the audience.
    • Dell gave out three free Sputnik developer laptops to the open source contributors in the audience.
  • Our Speakers: As last year, our speakers took their responsibilities at the conference very seriously. The presentations were equal parts thought provoking, amusing and practically useful. We can’t thank them enough for the effort that they put into the talks. We’re thrilled that this year they’ll be preserved for a wider audience.
  • Ryan and Leigh: Following their role in the inaugural Monktoberfest last year, our good friends Ryan and Leigh left Maine to open Of Love and Regret in Baltimore, MD in conjunction with the craft brewer Stillwater Ales. It was only after they very graciously agreed to take a few days off and fly up for the Monktoberfest that I committed doing it; they’re that important. As I told the audience last week, Ryan and Leigh are not just in the conversation for the finest craft beer experts in the US, they’re one the best teams in the world. Even better, they’re not just world class experts, they’re friendly, accessible and enthusiastic world class experts. We are honored that they were willing to sacrifice their time to be with us. Incidentally, if you appreciated their work, Ryan is up for an award here and we strongly encourage you to vote on his behalf.
  • The staff: Putting on even a small conference is an incredible amount of work. Without the efforts of Anna, Kate, Kim and Marcia, we would have had no caterer, no facility, no swag, no beer and thus no event. They did their jobs so well that most attendees weren’t even aware of the minor crises that occur behind the scenes at every conference, and I can tell you that they worked incredibly hard to bring you the event. The credit for the conference is by rights theirs.
  • My wife: Not only did she put in long hours preparing for the conference and longer hours at the conference, she put up with the toll that the conference took on my free time. She’s the best.
  • Oxbow Brewing: Many thanks to Tim and Geoff for hooking us with kegs fresh off the fermenter, as well as the shipped-that-day Oxtoberfest. Special thanks alsp to Tim and Avery for taking time out of their schedules to be with us.
  • Allagash Brewing: Thanks to DeeDee and everyone else at Allagash for getting us some amazing beer. A note to our speakers: those bottles of Curieux came to you courtesy of Allagash’s generosity.
  • Dogfish Head: Many thanks to DFH for working with Mike to have Sam address our audience via video. Also, all of the donated beer, which has and will continue to go to good technical causes.
  • **Stillwater Ales: Thanks to Stillwater for their assistance in sourcing some difficult to obtain beers for us.
  • Harpoon, Olde Burnside, River Horse Brewing: Thanks for the donated beers, and taking the time to be interviewed.
  • Dan Turkenkop, Apprenda: Thanks for bringing us a case of fine New York craft beers from Ommegang.

Beer List

Several people have inquired after the official beer list of the Monktoberfest. This is what we served (officially).

Lunch:
* Allagash (ME) White
* Oxbow (ME) FPA
* Stillwater (MD) Of Love and Regret / Premium

Dinner:
* Allagash Fluxus / Curieux
* Alvinne (Belgium) Melchior Zymatore
* Oxbow Loretta Grisette / Oxtoberfest
* Piccolo Birrificio (Italy) Seson
* Stillwater As Follows / Existent

After-Dinner
* Alchemist (VT) Heady Topper

Sessions

Our full session listing and the majority of the slides are available on our Lanyrd page.

Video

We have captured full video to the show, and it will be linked to here as soon as it’s available or look for it at redmonk.com/tv.

5 Comments

Categories: Conferences & Shows.

By sogrady
— October 10, 2012 at 7:02 pm

The Apple Maps Lesson: Build a Data Moat Around Your Business

By all accounts, the new Maps software in iOS 6 is well designed, an aesthetic improvement over the previous version, one that introduces welcome new features such as integrated turn by turn navigation and flyover. By most accounts, with the notable exception of reviewers granted early access, the new Maps application is also a disaster. From disappeared towns to phantom airports, the Maps application has been taking heavy criticism from users. The issues with the application are severe enough, in fact, that multiple parody accounts have already been already begun popping up on Tumblr and Twitter.

A secret, this is not. Nor is the problem difficult to identify; the problem is not the software, it’s the data.

As documented by the Atlantic, Google’s corpus of map data is the product of years of effort, with its maps curated from a mix of third party sources and data collected by either Google itself or – unbeknownst to most – every user of its Maps applications.

Depending on who you believe, this body of data puts Apple somewhere between “quite some time” and “400 years” behind Google in maps. It seems probable that Apple would agree, given that their transition away from Google Maps likely began well before the acquisition of Placebase in July of 2009, let alone the the Poly9 (7/2010) and C3 (8/2011) transactions. Three or more years after one of the best resourced companies in the world made the decision to build out mapping capabilities in advance of this move, Apple’s software is technically impressive but betrayed by a lack of quality data.

Data, unlike software, cannot be generated quickly. Which makes it, in business terms, an excellent barrier to entry. As Apple is discovering.

Fortunately for Apple, they appear well prepared to weather this storm with minimal damage. As has become typical with iPhone releases, Apple’s primary concern isn’t Maps but manufacturing enough devices to meet the demand. And while Maps will remain a problem for the foreseeable future, the combination of brand loyalty and ecosystem lock-in will keep platform defections to acceptable limits.

Most businesses, of course, are not Apple. And yet most software businesses today are competing on the same basis; competing as if the sales of software alone is a sufficiently compelling and projectable revenue model. Even without considering the value of the data, this is a problematic assumption. Open source, software-as-a-service and cloud are lowering costs for customers, and in so doing, lowering the revenue pool available to vendors. Prior to 2009, Apple was able to charge customers $129 for an upgrade to their operating system. Today the cost is $19.99. The operating system, it seems reasonable to assume, has not gotten six times easier to build. It’s simply worth less, as most software is these days.

What Apple’s current difficulty with Maps should highlight for every software business is both the importance of data and the difficulty of competing with it. Because even in cases where a competitor’s software is functionally superior – as in the case of Apple Maps – the company with the better data is likely to offer a superior overall experience. It’s not quite as simple as “he who has the most data wins,” because capturing data does not immediately confer the ability to use it, but it is increasingly clear that data based revenue models are not just here to stay, but the most likely avenue for revenue growth for technology companies moving forward.

The days of software being viewed as a standalone entity, separate and distinct from related data and telemetry, are numbered. Vendors that strategically leverage data to improve their software experience will enjoy not just a significant competitive advantage, but insulation from competition, open source or no. Data becomes the moat around your business. Those in the software industry, then, would do well to at least begin collecting data, even if the ability to leverage it isn’t yet developed. Because the alternative is being in Apple’s position a few years hence, and not in a good way: finding yourself ahead in software, but years behind in data. If Apple’s having trouble catching up, where will you be?

2 Comments

Categories: Data.

Tags: , ,

By sogrady
— September 24, 2012 at 8:13 pm
Fast WordPress Hosting