Which is to say an open source business model that will generate marginal revenue improvement for firms that employ it, at the cost of developer goodwill and participation. And, potentially, distribution. What open core is not is a model that will mitigate the commercial limitations of the model sufficiently to produce outsized returns similar to historical software producers. Nor is it a model that ideally aligns customer and vendor interests.

Which is not to say that there is much profit in debating its relative merits. Curiously, precisely zero of the model’s critics – smart people, all of them – have put forward potential remedies for the threat they perceive in open core. This is because none exist.

There are precisely zero mechanisms in either copyright or licensing to aid those who would oppose the open-core model. Leaving, as far as I can determine, proselytization and competition as the two main avenues for dissent.

Those who would pursue the first course, and ride like Paul Revere warning would be consumers of the dangers of open core are unlikely to be successful. The subtle nuances of open core versus pure open source are more likely than not to be lost in translation for customers, many of whom still struggle to understand that merely deploying GPL software does not mean they need to immediately open source their internal application catalog. Worse, warnings aimed at one type of open source software are likely to be misinterpreted as dangers to all open source software. Consequently, it would be no surprise to see anti-open core consumer campaigns that produced substantial collateral damage, counterintuitively benefiting closed source software.

Nor is it reasonable to expect, even should they be able to accurately and consistently perceive the distinctions between open core and pure play projects, that customers would care particularly. Call me a cynic, but in my experience, users of commercial open source software generally care more about whether or not software solves their problem than precisely how it solves their problem. Even if their open source software isn’t really, truly open source software.

We can and do argue, of course, whether or not they should care about things like software freedoms, but they don’t, by and large. If you doubt that, ask yourself what the most popular operating systems are in the world. Or the most popular browser. Or the most popular office software. Users have shown, time and time again, very little inclination to advantage software adoption on moral, ethical or – most problematically – practical grounds. Enterprises, like governments that run up massive deficits, are ever willing to trade a problem tomorrow for a solution today.

This is lamentable, admittedly. But it is also reality.

Those who would compete against the open core model, then, would be best served by doing what they have always done: competing. The open core model, as its critics are well aware, is no panacea for open source software revenue generation. It gains an edge, to be sure – the “unfair advantage” open core defender Mårten Mickos referred to – by introducing artificial purchasing triggers. But in replicating the revenue generating mechanisms of closed source software they inevitably carry forward the model’s disadvantages versus pure play alternatives.

Historically, remember, the largest open source projects in the world have been neither open core nor dual licensed. As popular as the dual licensed MySQL database is, Linux is yet more popular still. And as commercially prevalent as open core is today, none of the products sold in that fashion are remotely as popular as the Apache web server. The largest open source commercial institution, Red Hat, employs neither the open core model, nor the dual license. All things being equal, enterprises would typically prefer the more open alternative. The trick is getting to the point at which “all things” are “equal.”

Pure play open source software is today, and always has been, more popular. Which is why I categorically reject arguments that assert that open core-style mechanisms are necessary for the production of open source software. That they are beneficial from a revenue standpoint to organizations built to monetize open source software is indisputable; but open source is, of course, not strictly or even primarily authored for purposes of sale (coverage).

The key is, as it has always been, to more correctly align the revenue generating models with the greatest strength of open source software: its distribution and ubiquity. Mårten and other open core advocates – which include many of RedMonk’s own clients, it’s worth noting – are doing little more than seeking to run the most profitable businesses they can. Which, while I do not care for the open core model, I see no reason to quarrel with, so long as its advocates respect the boundaries of the licenses they operate under. More, I would strongly defend the right for those who build open source software to pursue this model so long as customers continue to choose it, even as I personally disapprove. Because that is what software freedom means to me: the right to select the model you believe best, even I don’t happen to agree with it. As in so many areas, in this I am laissez-faire, inclined to let the market make its own bed.

My hope, and to a certain extent, my expectation, is that we will shortly see firms begin to perceive the latent opportunities Spiceworks and others have identified and profited from; the value that accrues from massive distribution. That those seeking to make money from open source software, as opposed to making money with it (coverage), will transition to mutually beneficial revenue mechanisms such as telemetry (coverage) – that we have been suggesting since 2007 or so – over asymmetric models such as open core. That we will, in short, ultimately see a decline in the usage of open core much as we’ve seen a decline in the employment of dual licensing.

In the meantime, however, I see little point in long term debate on the subject. Regardless of one’s opinions on open core, there is little that can be done to prevent it. So even those that would wish it away may as well get back to proving the superiority of their model with code, because the only people inclined to listen to debates on the viability of the model have likely already made up their minds one way or the other.

“Indeed, I would go so far as to say that very few open source startups will ever get anywhere near to $1 billion. Not because they are incompetent, or because open source will ‘fail’ in any sense. But because the economics of open source software – and therefore the business dynamics – are so different from those of traditional software that it simply won’t be possible in most markets.” – Glyn Moody, “Why No Billion-Dollar Open Source Companies?

The explanation of why zero pure play open source vendors have hit the one billion dollar revenue mark has never seemed, to me, particularly complicated. The economics of open source are, as Glyn notes above, fundamentally differentiated from the closed source models that preceded it. Open source as an application development model enjoys many advantages over proprietary, in-house development; distribution and usage among them. But revenue extraction has not traditionally been a strength, for obvious reasons. When payment is optional, as it is with most open source software, fewer users become commercial buyers. Next up, a study proving that objects further away are harder to see.

Faced with this economic weakness in the model, open source advocates will typically cite the value of community participation and user volume, and they are perfectly justified in this. While it is unquestionably true that non-commercial users can still represent massive value to a given project (see our coverage of the three types of customers here), however, they are particularly unhelpful when the metric is – as it is in this case – revenue. This was what led me to argue in 2006 that we wouldn’t see a billion dollar open source pure play any time soon and to reiterate that point three years later. And it is why I am not surprised, in 2010, that we still don’t have a single billion dollar open source entity.

All of this, however, is ground well trod: IBM, Microsoft and Oracle are substantially larger than Red Hat. And? This matters if your’re contemplating starting up an open source software business. Does it, or should it matter to anyone else?

To answer that, we need to look at two questions: first, can open source firms make more money, and if so how? Second, if they can’t, what does that say about the future of open source?

Can Open Source Make Even More Money?

I believe that it can. Whether or not it will depends, in large part, on the creativity of open source commercial vendors. To date, most have showed little inclination to adapt their business models to the differences in open source development models. Revenue is still overwhemlingly a function of support/service licenses, with other mechanisms such as dual licensing or hybrid/open-core packaging utilized in an effort to introduce some of the same purchasing triggers enjoyed by closed source software vendors. With ten plus years of history at our disposal, several things about these models are now clear:

• They can generate sustainable, viable businesses
• They can be profitable and generate growth
• They cannot replicate closed source pricing and/or margins
• They cannot produce growth trajectories similar to software businesses that preceded it

Part of the challenge for open source software vendors, of course, is the fundamental difference between open source software and proprietary alternatives, not to mention other tangible goods: the primary asset to be sold is (generally) freely available. But it is also clear that most revenue models are misaligned at basic levels with customer needs.

Consider the support and service revenue lifeblood. If open source advocates are correct, and software developed in this fashion is indeed better designed and architected than proprietary choices, the need for support and service must necessarily be less. No software is bug free, of course, but better software should theoretically mean fewer suppot requests. Or take open core style models, which basically replicate the commercial software licensing model with an open source foundation; this erases, for some customers, the benefits of working with open source software. Dual licensing, meanwhile, can not only be unfavorable to customers, it can actually be detrimental to the vendor as well: MySQL, for example, found itself shipping a version of the codebase technically inferior to community distributions due to copyright conflicts with the dual licensing model (coverage).

The question is whether there are revenue models available to open source vendors that better align customer and vendor needs. We suggested such a model four years ago in a piece entitled “Beyond Support/Service: Making More Money from Open Source.” The idea is straightforward: open source excels at distribution and volume, so logically the ideal revenue model should leverage that strength. Data is likely, in my view, to be more profitable longer term than mechanisms such as dual licensing (coverage). Telemetry (coverage) is the obvious next revenue source for open source entitites. Customers share data with the provider on an opt-in basis, and in return they receive a basic level of analytics on the aggregated telemetry across customers for free, with more sophisticated reporting offered on commercial terms. The vendor taps a potential revenue source, and the customer gets access to aggregated analytics that span far beyond the boundaries of their single organization.

This model, perhaps not by accident, looks far more like Google’s than, say, Oracle’s. Which brings us to the second question.

If Open Source Can’t Make Even More Money, Can It Survive?

If open source businesses today can’t replicate the models that made the likes of Oracle successful, what chance do they have? There is a line of thinking currently circulating amongst some in the industry that goes something like this: the MySQL exit aside, valuations of open source commercial entities are in clear decline. Adding insult to injury, legions of entrepreneurs that at one time would have concentrated on building out open source commercial organizations are instead defecting to cloud, software-as-a-service and other commercial entities with more predictable revenue mechanisms. Given this, venture capital investments into open source are in decline, with the end result that there is less oxygen in the form of revenue available to sustain the software ecosystem generally, and open source specifically.

There are any number of issues with this argument, of course; I’m sure many of you have spotted a few already. The most basic to me is this: the entire argument is predicated on the notion that the primary innovations in open source software are coming from vendors looking to sell open source software. It is not at all clear today that that is true. The database space is illustrative in this case: none of Cassandra, Hadoop, memcached, MongoDB, Redis, or Voldemort were written to be sold. They were written instead to solve problems, part of a larger trend which is seeing vendors return to roll-your-own software (coverage), and commercial organizations responded to the demand generated. That these and other innovations in the software space have been the product of organizations not in the business of selling software seems lost on those making wider predictions of a general decline in the relevance of open source software.

The fact is that open source is as healthy as it has ever been. If you’re attempting to measure the health of the ecosystem by the size of those selling it, you’re using the wrong metric. Open source faces challenges, certainly, from the cloud and related trends that obviate areas of customer choice that have traditionally advantaged open source software. But it’s equally clear that open source as a development model for non-differentiating software is gaining steam (coverage). The trend is most obvious in web native players collaboratively developing their infrastructure software, but it’s not difficult to project a future in which large enterprises face similar choices regarding software up the stack. How differentiating, for example, is the ability to provide online banking? Do the economics really justify each large bank separately implementing an online banking application? Or are there opportunities to amortize the development costs for application software via open source?

The Net

Regardless of the answer to that question, open source has a bright future. The question, remember, isn’t whether businesses and developers are consuming and producing open source software. They are, in droves. Nor are there questions as to whether or not the software can be sold successfully on a commercial basis: is is, every day. The only remaining questions really regarding the economics of open source are whether they can duplicate the margins of their proprietary predecessors, and frankly I think most customers hope they don’t. Either way, the lack of billion dollar open source firms is not likely to be at all predictive as long as web native firms and others increasingly turn to open source as a primary development methodology.

Every business is a subsidy business.

Ok, maybe not, but it certainly seems that way sometimes. The list of products that have been subsidized by other products is long and – mostly – honorable: OpenOffice.org, Gmail, any Microsoft product not called Office or Windows, desktop printers and, of course, newspapers. Or more accurately, the reporting contained within newspapers.

Which is why I find it surprising and a bit disappointing that as one subsidizing revenue stream – classified ads – is erased by the ever corrosive, big bad internet, the New York Times declines to pursue another subsidy in favor of direct monetization. As is their right, to be clear: my purpose is here is not to advance some idealistic “information must be free” campaign.

Nor will I attempt to claim that the economics here are simple or, as Jeff Jarvis puts it, “cockeyed.” When one of the most visible brand names in journalism is forced to borrow against its own headquarters, as the Times was forced to do little more than a year ago, it’s probably safe to conclude that its revenue stream is challenged.

That said, given the “fraught debate” chronicled by New York Magazine, it seems equally reasonable to assert that the addition of a paywall – whatever the form it ultimately takes – comes at a significant price. Nick Carr, a defender of the move, acknowledges as much, qualifying his characterization of the decision as a smart move with the following:

Saying it’s a smart move doesn’t necessarily mean it will work; it means that the risk of not trying it at all is higher than the risk of trying it and finding that it doesn’t work.

The common ground we all seem to share, then, is that the Times needs money. The kind of reporting the paper does is neither free nor cheap, regardless of how what kind of efficiencies can be driven into the operational aspects of the organization. Talent, as ever, costs real dollars.

The question, then, is where said dollars are to come from. Carr, clearly, is in favor of metered or version based pricing. Caroline McCarthy, meanwhile, suggests that such strategies can only be successful in coordinated efforts.

And perhaps they are right. But personally, I think the Times and other papers with sufficient traffic could address their revenue concerns at no impact to users by harnessing what readers already provide them: data. By engaging their primary asset – their audience – in a symbiotic revenue cycle. Readers get content for free, the Times, in return, learns more about them, analyzes the data and resells it.

In other words, turn the Visualization Lab from a cost center into a revenue source.

Consider OKCupid, the dating site. Using analytics, the folks over there can attempt to answer – using actual data, rather than opinions – difficult questions questions such as: does your race affect whether or not people write you back? What should you say in a first message? How do your looks correlate to message frequency? Should you or should you not show off your body in your profile? And so on.

But I can already here the howls of protest, “But that’s just a dating site, we’re talking about the NEW YORK TIMES.” To which I’d reply: exactly. If we can extract this kind of meaningful intelligence from a mere dating site, what kinds of questions can the Times answer for us? What if they leveraged their own user behavior in the way that they did, say, the Netflix rental data? I’d bet there are some interesting questions to be answered. And by interesting, I mean valuable. And by valuable, I mean a saleable asset.

What brands are people asking about, that end up at the Times? Are they trending up or down? How about relative to their competitors? What are the demographics (determined by profiles) – and related shifts – of the Times audience? What is the sentiment of the articles they’re reading, and what can we extrapolate about the zeitgeist locally, regionally and nationally from that? What percentage of the audience comes from the Fortune 500? When are they most actively reading? Where, geographically, are they reading from? What kind of device are they using to read?

And so on. These are all, in my view, answerable questions for the New York Times, and – if they had an analytics side to the business – data customers. Some of this data, to be sure, has historically been supplied, gratis, to advertisers as part of the sales process. But marketers – never more so than in these increasingly data driven days – need to be asking and answering deeper questions than, “how many pageviews did you the Times do this month?” Because, as Google proves, the real money isn’t just in marketing to a volume audience, but doing so meaningfully.

The audience may well extend beyond mere marketers, of course. Might not real estate developers, for example, value the New York Times readership trends on a hyperlocal basis, if you could prove with analytics a correlation between site traffic and economic growth? Retail outlets might similarly benefit. Or wired or wireless carriers. And so on. Think analytics is too distinct a business for a newspaper to get into? Fine: sell access to particular datasets to interested parties either directly or via a third party like Infochimps. It’d be a lower margin business, but low effort.

Knowing how many are reading the New York Times, who they are, where they are, what they’re reading, what they’re forwarding, what they’re cutting and pasting, and how much has value. Significant value, in my view, as I’ve argued before. Which is why I think we’re seeing Facebook and other high traffic properties move in this direction.

Is it reasonable to question how data, as an unproven but potential revenue source for the New York Times, would compare to the direct monetization scheme currently proposed? Of course. But given that one negatively impacts users, and one does not, I know which one I would try first. Not that they need be mutually exclusive, of course, but I would exhaust all of my options before embarking upon a course of action that might materially and permanently impact my relationship with my customer.

Maybe data as a product is the future of the newspaper industry, and maybe it is not. But considering that journalism is generally regarded these days as a race to the bottom, what do they have to lose by finding out?

“Years ago it occurred to me that Amazon.com was a software company. That’s not news to anybody any more now that they’ve turned pieces of their infrastructure into cloud computing products that they lease out, but I realized it long before Amazon announced their Web services products, and even before they started outsourcing their online store and logistics to other retailers like Borders and Toys R Us. Early on, Amazon was thought of as a retailer, but their retail strategy was based on building the best software for running an online retailer. My guess is that Amazon.com knew from the beginning that they were in the software business, but a lot of companies that expend a large share of their resources building software don’t.”
- Rafe Colburn, “Do you want to be in the software business?”

James and I tend to agree: Amazon is, in fact, a technology vendor. Even if you don’t subscribe to that idea, you should be planning as if they are. Because the evidence is mounting that the software vendors are facing a powerful new market competitor: their customers.

Why do you think Facebook would sponsor the Apache Foundation? Because, like Amazon, they’re in the business of producing software. Software like Cassandra. Why does Google run developer events at Moscone? Because they’re in the software business. Why is Yahoo the largest single committer to Hadoop? Because…well, you can see where I’m going with this.

The mainstream technology industry has, in recent years, eschewed specialization. Virtual appliances, each running a version of the operating system customized for an application or purpose, have entirely failed to dent the sales of general purpose alternatives such as RHEL or Windows. For better than twenty years, the answer to any application data persistence requirement has meant one thing: a relational database. If you were talking about enterprise application development, you were talking about Java. And so on.

The result is an effectively homogenous set of technologies upon which ran the majority of workloads.

A homogenous set of technologies that has largely been rejected by the businesses that have built themselves, in the last decade, on the web. That can, as Tim Bray puts it, “deploy better systems at less cost in less time at lower risk than we see in the Enterprise.”

Why? Because the general purpose stack wasn’t what they needed. From either the technology or cost perspectives. As Cloudera’s Jeff Hammerbacher related to Curt Monash, Hadoop enjoyed advantages over commercial relational alternatives for Facebook, from price to schema flexibility.

Nor is software production solely the province of the Web 2.0 giants: Ruby on Rails came out of 37Signals’ Basecamp, a Software-as-a-Service project management tool. Django? Extracted From the Lawrence Journal-World’s website. Crane? Derived from Flightcaster. Git? Written by Linus Torvalds to manage the Linux kernel tree.

None of this software, of course, would be all that interesting except for one important change: this in-house developed code is open source, and shared with others. Which has led to entirely new – and entirely unanticipated – business models. Or maybe you saw Github coming.

“Roll your own” as a software development approach isn’t new; if anything, it’s the original software development process. In days of yore when you wanted something built, you built it yourself. And fiercely guarded that code, because it could be, someday, even if you didn’t know how or why, a “competitive advantage.”

Eventually, of course, enterprises looked around and noticed that pretty much everyone had a customer relationship management system, or an enterprise resource planning system, so the opportunity for competitive advantage in general purpose – as opposed to, say, high volume trading – applications was increasingly slight. So why bother? Run on the same infrastructure as everyone else and get on with the more important things like running your business. Does IT Matter? et cetera, et cetera.

And so things went for a time: vendors built out extensive businesses and revenue structures around general purpose enterprise software, and customers bought into them in a big way. Even if, in many cases, the software wasn’t a great fit. The perceived risks to introducing new, unproven technology were greater than the pain of adapting general purpose software to the tasks at hand, so the equation favored the incumbents.

Until the last few years, when more accessible languages, cheaper hardware, and a growing catalog of open source software assets led firms small and large to question the status quo. To decide, on a volume basis, that the available frameworks, development tools, databases, operating systems, and so on weren’t quite right for their needs, and that rolling their own was preferable. And that, once built, they could amortize the costs of developing these assets if they made them publicly available. Which has led to Rackspace contributing to Facebook’s Cassandra, Facebook contributing to Yahoo’s Hadoop, and IBM contributing to all of the above. The days of rolling your own are back for some portion of the would-be enterprise software customers, if not for the same reasons as in the past. Many enterprises will lack the necessary skills to build their own Hadoop, obviously, but thanks to that project’s developers they don’t have to. Some will argue that the likes of Facebook and Google can’t be counted as potential enterprise software customers, because they were never likely to buy from traditional providers in the first place. I would respond that this is precisely the point. Having participated in the infrastructure build out of a lot of startups as a systems integrator from 2000-2003 or so, I can tell you that those I worked with overwhelmingly preferred the standard at-the-time enterprise infrastructure of BEA, Oracle, and Solaris. These days? Well, let’s just say that startups are making different choices.

Think about it. How many of the really interesting technologies of the last few years are the product of companies that primarily sell software? Which, in turn, begs the question: if the interesting code is not coming from the software vendors, what is a “software company?” My own view is simple: you are not a software company because you sell software, you are a software company because you build software. Which means, of course, that the field of “software companies” is much wider than is commonly realized. From which we may, in turn, conclude that the software competitive landscape is that much fiercer, because vendors are typically designed to compete with other vendors – not customers designing software for other customers.

In other words, you may want to consider Rafe’s original question very carefully: Do you want to be in the software business?

When asking why enterprise technology companies don’t succeed in consumer oriented spaces such as mobile or the desktop, my explanation is pretty simple: it’s all about the corporate DNA.

It’s generally not a lack of technical capability, which you would think would be the harder problem to solve. Enterprise companies, instead, either fundamentally don’t understand the consumer experience or actively don’t care, or both. Just look at their user experience. Or their marketing. Or their branding. Of course the reverse is true: Apple’s more or less completely uninterested in the corporate market, and Google’s recent forays into that world have been learning experiences, from what we hear.

None of which would be a problem if the enterprise and consumer spaces weren’t converging, rapidly. Cisco, HP, IBM, Microsoft, Oracle and the like have, after all, had little problem extracting profit from markets that advantage manageability at the expense of usability. Apple, Google and others, meanwhile, have decent looking balance sheets retailing hermetically sealed devices and small text ads, respectively.

What happens when the twain shall meet?

The dinner was at the Waldorf-Astoria on Thursday night, but I caught up with Mr. Anderson earlier for a preview of his after-dinner performance. One of his predictions, in particular, caught my attention. “Except for gaming, it is ‘game over’ for Microsoft in the consumer market,” he said. “It’s time to declare Microsoft a loser in phones. Just get out of Dodge.”

Regardless of Microsoft’s performance, amid the rise of Apple’s iPhone and phones using Google’s Android software, it seems unlikely Microsoft will heed Mr. Anderson’s advice. The smartphone is becoming the innovative hub of software development and applications, far more so than the personal computer. If Microsoft loses in smartphones, Mr. Anderson noted, “It is pretty grim. Those applications are going to move upstream.”

The underlying problem, Mr. Anderson said, is cultural. “Phones are consumer items, and Microsoft doesn’t have consumer DNA,” he said.

I think Mr. Anderson may be underestimating Microsoft’s drive, but he understands the problem precisely. Because mobile isn’t a space won by drive, or aggressiveness. It’s won with consumer DNA.

How many businesses are there, globally, that service with equal facility enterprise and consumer markets? You could make the case for Cisco, maybe, with their Linksys and Flip brands, or HP with printers and such. But that’s less than convincing, given that the “consumer” products they’re selling have a lot more in common with the unfortunate printer above than, say, an iPhone. Microsoft’s Xbox, which is profitable these days but a rounding error relative to the Office and Windows franchises, is the only real exception I can think of: most consumer products coming from enterprise vendors seem are just that.

As any geek that’s been asked to configure a Linksys router for his family could tell you.

All of which makes the future of this industry interesting. When was the last time you saw an enterprise talk about their mobility story without an iPhone icon?

The interesting question will be whether it’s easier to use gene therapy to graft consumer DNA on to enterprises, or the reverse. Or it’s even possible at all, because history indicates that it is not, though too few vendors have tried the hands off acquisition as a means of solving that problem. Still, vendors are going to try. For tactical reasons, like the aforementioned Microsoft in the mobile space, but for strategic reasons as well: enterprise vendors would benefit from consumer volume, and consumer vendors would like to tap enterprise margins.

Money, as ever, makes the world go round.

Disclosure: HP, IBM, Microsoft and Oracle are RedMonk clients. Apple and Google are not.

“Like most open-source companies, MySQL’s sales, tied to support deals, never matched the astronomical number of downloads for its product, about 60,000 a day. In January 2008, the founders decided to sell the company for $1 billion to Sun Microsystems. And this year, Sun agreed to sell itself to Oracle, which makes database software aimed at larger companies and tougher jobs, for $7.4 billion.

Now, disagreement over the value of MySQL — both as a stand-alone entity and as part of a big company — lies at the heart of a bitter public battle between Oracle and the European Union over the Sun acquisition. The fight illuminates a larger truth about open-source companies: their societal and strategic importance far exceeds their financial value as operating businesses.” – Ashlee Vance, “Open Source as a Model for Business Is Elusive”

For four or five years now, those of us with experience running, analyzing or working with open source businesses both individually and at scale have been collectively debating the merits of open source in economic terms. Which is a testament to the strengths of open source, on some level: its strengths as a development model and distribution mechanism are more or less accepted as a given these days.

The difficulty that I have with much of the debate on the subject of open source economics is that it asks the wrong question: are open source and business concerns mutually exclusive, as the headline on Vance’s piece implies? This is the wrong question, in my opinion, because the evidence that open source as a model for business is anything but elusive is overwhelming.

If you want to explore whether open source is a reasonable foundation for a big business, on the other hand, that’s a better question. Still not the one I would ask, but better.

Me, in July of 2006: “At this point, however, I do not expect any of the major pure open source firms to challenge the billion dollar threshold any time soon.” Three and a half years later the largest open source pure play, Red Hat, is still three hundred plus million away from the billion dollar yardstick. And Red Hat is, in my view, a very well run company.

It is also, of course, a traditional software and services vendor – emphasis on the former. As are most of the other vendors mentioned in Vance’s piece: Citrix, Cloudera, Microsoft, MySQL, Oracle, Sun, VMware and so on. Mentioned only peripherally, both in this article and the broader debate, are those firms that make money with open source as opposed to from open source. Companies like Google, for whom the billion dollar threshold is a distant memory. But what if we didn’t artificially narrow our definition?

What if we weren’t just talking about those who sell and service open source software, but also those who’ve built businesses upon it? The 451 Group’s Matthew Aslett, an analyst colleague, quite efficiently articulates a number of open source models but omits the one that I personally consider most compelling: building other businesses on open source, businesses that may have nothing to do with selling software.

Or as Brian Aker more succinctly put it, “if you really want to make a lot of money from open source, then find a way to use it.”

Where you come down on the open source and business question, then, may simply depend on what you consider an open source business. At least until open source vendors begin aggressively realizing their next, largely untapped revenue source: data. Once that happens, we’ll all have to reexamine the economics of open source models.

Data is the next great revenue frontier, in my view. And I’ve long argued that open source is intrinsically differentiated in its ability to generate data, given its distribution and adoption advantages. Some will undoubtedly argue that privacy concerns will prohibit this practice: I am not one of those people. First because open source projects are already collecting data (Debian, Eclipse, NetBeans, Ubuntu, etc), but more because the data has value – potentially immense value – to users.

Will data power the software and service vendors to billion dollar revenue streams? Who knows. But it’ll be worth a lot. Just ask Google.

Since graduating college, I’ve never had a doctor. Seriously. Not for lack of insurance; from my first job post-college on I’ve never been without coverage, assuming that catastrophic plans like the one I have now count.

But while I’ve fortunately been relatively healthy in that span, that’s a bad way to go through life.

So why didn’t I have what’s, sadly, become known as a primary care physician? The aforementioned health, in part, but more because the current healthcare model simply didn’t work for me. Between not being able to pick from recommended doctors to paying exorbitant visit rates out-of-pocket due to bare bones healthcare policies, I simply worked on an as needed basis.

Which, while not cheap – a rusty nail through my foot cost me around a thousand dollars a few years ago, worked. More or less. But with the odds against it continuing to work indefinitely, I found myself in the market for an alternative. Ideally, an innovative alternative. While traditional small businesses such as coffee shops have been loathe to get creative with their business models, my hope was that the systemic failure in our healthcare approach would have driven some to adapt to the changing conditions. And so they have. They’ve adapted the model right back into the past, in fact, to the lamentably bygone era of GPs.

I found Doctor Christopher Bartlett via a flyer at my Portland gym, where he happens to work out himself. The part that caught my eye was the focus on high deductible healthcare plans; at $5,000, they don’t come much higher than mine. The model is very simple: cash-based, hourly service. In many respects, it’s much like legal or consulting businesses. The model in this case is instead applied to an industry that has become so byzantine in its regulations and procedures that it’s in danger of collapsing under its own weight.

Essentially Bartlett’s is a practice that cuts out the insurance layer. You can submit back to your provider if they accept out of network physicians, but ultimately this is a practice intentionally divorced from the traditional world of HMOs and primary care physicians. Which makes it suboptimal, clearly, if you’re an HMO participant. But for the rest of us, it really is the best of all worlds: reasonable and upfront pricing, no insurance company hassle, and outstanding quality of care.

Seriously outstanding quality, in fact. Doctor Bartlett’s webpage talks about the benefits of personalized medical care and direct access, and these have been obvious to me even on brief experience. A couple of weeks after getting a routine physical, I came down with my traditional late winter hacking bronchial cough. Contacting Doctor Bartlett via email, I received a recommended course of action a mere one hour and fifty minutes letter…in spite of the fact that he was in San Francisco at the time.

I could go on about the quality of care – his philosophy towards medicine is both progressive and open minded, and his manner is unparalleled – but the really interesting part to me is the model. Returning to the GP days of early might not sound like innovation, but compared to the reality of today’s healthcare system it can’t be anything else.

If you’re anywhere near Portland, ME, I can’t recommend Dr. Bartlett highly enough (the lawyer seconds that opinion), and if you’re not, you might want to look for a doctor like him your area. If the model works for me, it’ll pretty much work for anyone.

There are bigger questions to answer in the healthcare space, of course, but I’m leaving those in the hands of better minds than mine. Right now, I’m just happy to have found a doctor.

This was supposed to be a post about what I’d consider to be an obvious enterprise marketplace candidate, but between Firefox 3.5, Weave, and some tinkering with