The Open Road

Everyone hates patent trolls (except, perhaps, the patent trolls' mothers). But it's easier to despise patent trolls when you either have a lot of patents, or none. What if your company were awarded a significant patent that could be used to shake down Google and the rest of the industry for corporate benefit.

Or buy food for your family?

Is it your fiduciary duty to exercise that patent? Is it a personal duty? And do you have the legal right to do so?

The first two questions are tricky, but the last one is currently being considered by the U.S. Supreme Court. Consider yourself lucky that you don't have to decide it.

Bilski and business method patents

Recently, the U.S. Supreme Court heard oral arguments in the controversial Bilski case where IBM, typically friendly to open source and innovation, backed the wrong horse. According to The Wall Street Journal's coverage of the arguments, the justices were skeptical--if not contemptuous--of the case put forward by Bilski and the proponents of business method patents.

Chief Justice John Roberts quipped that business method patents are akin to patenting the idea that "I buy low and sell high. That's my patent for maximizing wealth."

Silly when presented in this way. But perhaps silly when presented in just about any way.

Business method patents came into being 20 years ago with the Federal Circuit's State Street decision, the case that spawned Bilski. Two of the best-known technology examples of such patents are Amazon's one-click checkout and Priceline's reverse auction.

In a September blog I took IBM to the woodshed for its stance on Bilski. Big Blue filed an amicus brief (PDF) that I argued was disingenuous at best. IBM argued:

Patent protection has promoted the free sharing of source code...which has fueled the explosive growth of open source software development.

Really?!?

IBM was not alone. Novartis, the big pharmaceutical company, also filed a supporting brief.

The industry's moment of (in)decision

I think that the Bilski case is a divider of wheat from chaff, a moment that forces technology companies to take sides on a critical issue that goes to the heart of innovation in our economy.

On one side, companies such as IBM and Novartis maintain that patents should not be tied to "primitive physical technology" but should also embrace a broader range of modern business activities.

But other companies, including Google and Symantec, took the other side and filed briefs (PDF) with the Supreme Court arguing that expanded business method patents would open them up to infringement lawsuits over the "very mental processes and ideas that are the building blocks of innovation."

What would you do? LogLogic and Sponster examples...

I was reminded of this issue by an announcement today from LogLogic, a log management and security company I wrote about last year as an example of the pervasive use of embedded Linux.

LogLogic was granted a patent in October that appears to be rather sweeping in its scope, covering the collection of logs and the management of the data in those logs.

Imagine if LogLogic went "troll" with this patent....

At a minimum it could be a nuisance to its competitors and at a maximum it could possibly shake down any company that sold a product that relied on log collection (describing hundreds, if not thousands, of products on the market today).

Or how about this one? Sponster has a patent on a system for delivering contextual ads against electronic messages like e-mail, SMS, tweets, etc. Google filed for a similar patent, but over a year after Sponster, and while Sponster's patent was recently granted in October, Google's was denied. (Disclosure: I know and am friends with one of the Sponster executives.)

On the one hand, Sponster could go troll and sue just about everyone on the Web. On the other hand, I know from talking with the executives that they have no desire to do so. The fact that the company has not sued anyone in its six-plus years of existence is a clear indication of this. Sponster wants to build its business around the patent, but Google or Microsoft with their heft can squash that desire.

Should Sponster fight or capitulate? It's easy when you think of patent trolls as trolls that create no real value. But what about when they are real people and real companies like Sponster and LogLogic?

LogLogic makes its choice

LogLogic appears to have made its decision. In a company blog on Wednesday, a LogLogic executive points out the potential harm they see in a Bilski decision by the Supreme Court that would allow broader business patent methods.

LogLogic also (correctly, in my view) argues that the anti-business method lobby of Google et al "represent[s] the true innovative spirit of Silicon Valley where entrepreneurs are rewarded for risk taking and embrace the thinking of Austrian economist Joseph Schumpeter and creative destruction."

LogLogic decided to take a defensive posture with this sweeping patent rather than go troll. Who knows what Sponster will do, or should do. Presumably it worked just as hard on its technology as Google: shouldn't it get paid?

More broadly, do you agree with IBM that business methods should be upheld, or with Google that they should be crushed? What would your company decide to do? Where do you stand?

In the past week, the open-source business community appears to have reached consensus: making money from open-source software is a bad model, but making money with open source is golden.

This can't be good for Microsoft.

Microsoft has long maintained that as the open-source industry has matured, it has become more and more like the commercial world it sought to leave behind. Fundamental freedoms of open source, like the right to modify source code, are signed away to secure a support contract with Red Hat or another vendor.

In many ways, Microsoft was right. Unfortunately for the Redmond giant, however, the new consensus should lead to less commercialization of open source, and more commercialization around open source. There's a big difference, and it's one that threatens to seriously undermine Microsoft and every other traditional software vendor.

That is, unless Microsoft responds in kind.

The new consensus

This consensus has been articulated by TechDirt, Redmonk's Stephen O'Grady, GigaOm, and here on The Open Road.

In fact, it's a drum I've been beating for over a year as Tim O'Reilly's wisdom on the topic finally caught up with my 33MHz brain.

There are fundamental, strategic benefits to open source: ease of distribution, friction-less adoption, costs, etc. There are also serious downsides when it comes to selling it: people chafe at paying for something if they can get it, or something similar to it, for free.

Such problems don't plague companies like Google, which distributes open-source software to drive more adoption of its proprietary advertising or SaaS services. Even Red Hat isn't really in the software business: not with its Linux distribution, anyway. It's in the business of providing certification and update services; of managing the complexity of an operating system.

It's a great business, but if you had to choose between Google's sales or Red Hat's, it's a no-brainer.

Microsoft's response

As this lightbulb goes on across the industry, companies like Microsoft, which insist on direct monetization of software, with little in the way of open-source complements to fuel adoption (or simply undermine competitors), are going to struggle. More and more companies will give away Microsoft's core business as open-source complements to their own.

So, here's a suggestion for Microsoft as just one good way to respond: open-source Internet Explorer.

Forget Office. Forget Windows. Forget all those other billion-dollar cash cows. Microsoft has no revenue directly tied to Internet Explorer, but IE is the gateway to the next phase of Microsoft's growth. Open-source it.

Cut Google's Chrome and Chrome OS off at the knees. Undermine Mozilla Firefox's raison d'etre. Give the European Commission a reason to love you.

More importantly, give developers something to embrace and extend. Microsoft has been steadily losing browser market share as Firefox eats into it. In some countries, like Germany, Firefox has even surpassed IE's market share.

Fight fire with fire. IE is still the world's most popular browser. Make it the world's most open browser, too.

Every Microsoft business could benefit from this move. Even if one assumes that Microsoft isn't ready to take the plunge and fully open up the development process around IE, here's some comfort: neither has Google around Chrome. Microsoft can still steer the IE ship, even if it were open source.

Microsoft needs a proactive open-source strategy, rather than the reactive policy it has had to date. Open source is a threat, yes, but it's a threat to everyone, especially as the industry collectively comes to grips with open source as a business enabler, rather than as a product to sell.

If Microsoft wants to win big in the new world of Web-based software, it needs a bold strategy. Open-sourcing IE is the starting point.

Follow me on Twitter @mjasay.

With open-source software businesses, you have two options. Actually, three, but the third belongs to Red Hat, and it applies to roughly no one else.

The first option is to sell support for open-source software. This option is generally advocated by those who have never grown a business beyond $10 million. It's a terrible model unless your only aspiration in life is to run a services company.

Hence, the support model might be good for Accenture or systems integrator, if they want to take on the burden of support, but it's a poor model for Red Hat, MindTouch, Microsoft, or other software company.

The second option is to contribute heavily to open source but not build your revenue model around monetizing that software directly. This is what the New York Times points to in its Sunday expose of allegedly fizzling open-source business models.

Open source can drive adoption like little else. It's not, however, necessarily a great driver of revenue. For that, you need to be selling something beyond the source code, and that "something" is often going to be proprietary, be it hardware, software, or a service.

Google is the master of this model. It gets roundly criticized for its half-open, half-closed open-source efforts, but the reality is that Google's products--Chrome OS, Android, etc.--are open enough to facilitate adoption without giving away the keys to the car, which drives wherever Google wants it to go.

That's the way successful companies are run: they take ownership of what they ship. They are influenced by but not controlled by the mystical whims of The Community.

Even Red Hat, which piggybacks on a lot of Linux kernel development, increasingly includes more home-grown software in its distribution and takes great pains to certify its Red Hat Enterprise Linux will work in the most demanding environments before putting its brand on the label.

Some, including me, have wrongly concluded that Red Hat's business model would apply to other product markets beyond the operating system. It doesn't. It only applies where the moving parts in the product are complex, multitudinous, and frequently changing.

For everything else, there's Option 1 (if you want a business that doesn't scale well or possibly at all) or Option 2 (which is really no different from the old proprietary model except that it effectively uses open-source complements to lower engineering costs and possibly sales/marketing costs).

Even Option 2 won't work if you under-invest in marketing and development, as Symbian is learning to its hurt. It turns out that there is no free lunch, even in the land of free software. It always takes work. And money. Lots of both, actually.

Google CEO Eric Schmidt argues that competition is just a "click away." By opening up Google's access to personal data as well as the software that collects it, Google is adding substance to that claim.

It won't work to write better software than Google, because Google is not a software company. The only way to beat Google is through superior execution; through better operations.

The way to lose to Google? That's easy: try to sell software that Google is shoveling out the door as free (open source) software.

This thought hit me last week as Google announced the open-sourcing of its Closure tools. These are JavaScript compression tools that Google uses to build its own Web services like Gmail. Basically, Google was saying, "Here's how we build our software services. You can, too."

This follows on the heels of Google open-sourcing other software like Android ("Here's a free mobile operating system to help more people connect to our services"), Gears ("Here's how to run Google-like services offline"), and more, each opening up windows into the software that runs Google's services.

In many ways, Google is giving away the recipe to those that would like to build a Google clone.

The problem? Google is so much more than software.

In fact, one of the primary reasons that Google can write and open-source so much software is that it isn't a software company. Not even remotely. I could have every line of Google's software, both open source and proprietary, and I couldn't hope to compete with Google.

Google is what Google does with the software, and not the software itself.

Ditto for Red Hat. The company used to retain significant chunks of proprietary code in its Red Hat Network offering, but it has released that software under and open-source license in the last year. Doing so hasn't had any effect--positive or negative--on Red Hat's sales, because Red Hat isn't in the business of selling software anymore.

Red Hat, like Google, is in the business of providing services to customers, services enabled by software but which are much more dependent on IT operations and overall efficiency of execution.

And while both companies rely on open-source software to fuel those operations, Google, more than Red Hat, realizes that the conversation has moved on from open-source licenses to higher-order value, a theme that is going mainstream. Cloudera CEO Mike Olson captures this theme well:

The license terms attached to products have become secondary to the value it offers. People now are much more rational about how they adopt technology across the board. Open source is a detail, not a defining characteristic. At Sleepy Cat, we were proud to be an open source company. At Cloudera, I think of us as an enterprise software company that happens to be built on open source software.

Such sentiment would resonate well within the walls of Google's Mountain View headquarters, I suspect.

Even within their respective open-source communities, neither Google nor Red Hat company is particularly saintly. Red Hat has never waited on the Linux Standards Base or industry efforts to coordinate Linux distributions (like United Linux), but instead forged ahead with its own efforts...until the LSB simply adopted Red Hat's distribution as the standard.

Google, for its part, takes flak for dominating its open-source project communities like Android. Google's contributions (or lack thereof) to outside projects, like Linux, don't always mesh well with others in the industry.

To open-source community critics of Red Hat and Google, some advice: get over it.

The companies that spend the most time chumming around, talking up interoperability and the need for everyone to work together are usually the ones losing the race, a race whose rules may be written in software but whose victory depends upon execution.

Google and Red Hat have moved beyond software. Software enables their operations, but software doesn't define such operations. Google, for its part, is open sourcing Microsoft, one line of code at a time, and Microsoft hasn't a clue as to how to respond, because it only knows the old world: competition through better IP.

That world is gone. Open source has killed it. The new world is built on execution and superior IT operations. Google gets this. Red Hat gets this. Microsoft? Not so much.

Some of us take longer than others. Tim O'Reilly moved on years ago from talking about open-source licenses and instead focused on the importance of data to business success. In the open-source industry, we heard his words but clearly didn't understand them.

We kept selling software through our "awkward teenage years," even as Google, 37Signals, Facebook, and others gave it away.

Years later, as Google pays for mountains of open-source code by aggregating data and selling data-rich services, we're starting to grok O'Reilly's message. It's what makes companies like Path Intelligence so interesting.

Redmonk's Stephen O'Grady notes:

Much has been made of the lack of an obvious revenue model for properties like Twitter, and to a lesser extent, Facebook. But when looking at the organizations' balance sheets...it seems self-evident that the value of the data assets involved is seriously underreported...

The economic value being assigned to data helps to explain why, while being sympathetic to questions about Twitter business models, I've never been overwhelmingly concerned. Where the revenue model for the dot-com era "eyeballs" strategy was equal parts indistinct and aspirational, the Web 2.0 businesses are being built out in an era of customers increasingly predisposed to analytics and data driven decision making. In other words, there's a market for their most valuable asset.

As Microsoft's Windows, Office, Xbox, and SharePoint businesses demonstrate, the real money is in the platform business, which is, or which can be, a data business. The more businesses and developers that build upon your software, the more valuable that software becomes. Even systems like Twitter are being turned into platforms.

But how you build the platform is increasingly important. Microsoft is Platform 1.0. Open source is Platform 2.0. It's a more efficient way to build community around a core, which is why Google and other savvy companies increasingly turn to open source as a fundamental way to entice developers, which developers create more software which invites more adoption which yields more data...you get the picture.

It's also why I believe Google Android, in its platform battle with Apple's iPhone, will ultimately prevail, so long as it can work in peaceful coexistence with the developer community (which has not always been the case).

Unlike many open-source companies, however, Google et al. have the singular benefit that since their business is data, not software, they can shepherd open-source development without taking a heavy hand in community management. More open source leads to more adoption, which leads to more data, which leads to the Googles of the world being able to give away even more software for "less than free."

It's genius. And it's amazing that it took so many of us so long to heed the counsel O'Reilly offered years ago.

In sum, this isn't a suggestion that companies should forgo profits in exchange for mindless popularity contests, as 37Signals' Jason Fried rightly pillories.

Instead, it's a call to look for ways to fund open-source development with rich, data-driven businesses. Most open-source companies focus too much on software, and most Web 2.0 companies focus too much on data. It's the blend of the two that makes a company successful.

Just ask Google.

(As an end note, I think Gartner's Brian Prentice is on to something when he speculates that enterprise applications may increasingly be communally developed by IT end users, though perhaps coordinated by vendors. It's a very interesting prospect, one that will enable even more open-source development in an area where data may not fund it.)

Open source offers a fantastic way to reach developers and users of one's technology. Ironically, however, the very group most inclined to adopt open source is the least likely to pay for it.

Therefore, to make an open-source business thrive in enterprise software, vendors must learn to distinguish between developer-users and IT operations-buyers. As I'll explain, however, open-source companies may need to guard against becoming too successful in order to preserve their exit opportunities.

It is, of course, quite possible to make money in open source. Lots of it. Red Hat, for example, is approaching $1 billion in annual revenue. MySQL had generated more than $90 million in sales the year it was acquired by Sun Microsystems for $1 billion.

That's real money.

It doesn't, however, come from the developers that download open-source code. Developers, in former MySQL CEO Marten Mickos' words, "spend time to save money."

Hardly the ideal customer.

Developers download software, which a great way to initial a buying conversation but a terrible way to finish it. Open-source companies talk about selling support, but this is a losing proposition. Developers, after all, are highly likely to support themselves through online forums or other means. They don't pay for software, and they don't buy support. Not most of them, anyway.

This is one reason that pure-play support models simply don't scale in open source. They focus on the exact wrong audience.

Sure, there's a honeymoon period for new open-source companies that launch support offerings around established community-led projects. Some developers buy support, either through personal need or corporate requirements. After that initial rush for support, however, it's a tough slog selling support to developers. It's like selling ice to Eskimos.

This brings us back to a real dilemma in open-source companies: how to monetize popularity (i.e., downloads).

Developers are the most efficient way to spread adoption of one's product but perhaps the least efficient way to monetize it. To get paid, vendors must learn to separate IT developers from IT operations, and build offerings for both.

Red Hat is a classic example. People think that Red Hat sells support. It doesn't. Not really.

The primary reason enterprises buy a Red Hat Enterprise Linux (RHEL) subscription isn't for Linux support, and certainly isn't for the bits: you can get the bits free from CentOS, and support comes heavily discounted from Oracle.

No, the reason companies purchase a RHEL subscription comes down to certification that RHEL works with a wide variety of hardware and software, as well as with the Red Hat Network, which delivers updates to an enterprise's RHEL servers.

In other words, IT operations pay Red Hat to help manage their Linux servers in production. The money is in operations.

Red Hat isn't alone. Look at JBoss. The company started minting money, once it licensed Hyperic's software to build the JBoss Operations Network.

SpringSource took it one step further and actually bought Hyperic, the company, as the foundation for its Build-Run-Manage message, a message founded in selling to IT operations, not developers. (Rob Bearden, chief operating officer at SpringSource, was deeply involved in both decisions and remains one of the smartest people in the industry on building open-source businesses. If there's any wisdom in this post, it is his.)

For new open-source companies grappling with how to supercharge sales, the answer is operations. It may not be a systems-monitoring tool like Hyperic or Zenoss, but it likely is about systems management, as operations need and pays for it.

There you have it: the secret to your billion-dollar open-source opportunity. Except for one niggling fact: despite the value of IT operations to make sales, it's really developers who create the most company value, from an asset perspective. SpringSource's sales didn't justify its $420 million valuation. Its developer base did. Developers have strategic value, in terms of IT operations and creating tactical value.

In fact, SpringSource's valuation might well have gone down, had it been making more money, just as TechCrunch's Michael Arrington astutely argues could happen with Twitter. Sales provide a measurable, tangible valuation. Developer traction creates an amorphous, strategic value.

Hence, while IT operations is the crux of making sales in open source, it might well be that open-source companies should focus on community development and avoid making too much money so that they can maintain a healthy valuation. But not too healthy: there isn't an incredible amount of IT vendors that can swallow $1 billion acquisitions, the IPO era seems to be over.

Is this the new open-source entrepreneur's dilemma?

Follow me on Twitter @mjasay.

Each year InfoWorld sets out to rate the "best open source products" with its Bossie awards. Too bad it has decided to cloud the voting with open-source politics, as well.

The politics reveal themselves when InfoWorld tries to settle on a winner between Zenoss and OpenNMS. (Why Hyperic isn't also in that mix, or Reductive Labs' Puppet, I can't fathom, but...)

The editors write (note: the emphasis is mine):

Although Zenoss clearly has the more developed feature set, our Bossie goes to OpenNMS. The reason boils down to business models. OpenNMS is a purely open source software project, meaning that customers get the complete set of features available for free as open source. There is no "enterprise" version. OpenNMS makes its money strictly by selling support and training services.

Zenoss uses a common business model in the open source world: it provides an open source version of its software with a limited feature set for free, and it sells a more extensive "enterprise" version of the software with support through an annual subscription. So while Zenoss may be a good value compared to HP or IBM or CA, it's not a good value compared to OpenNMS.

If only enterprise IT could cavalierly discard superfluous things like "features" in favor of licensing ideology. But it can't, which is why Agilent, Telstra, Accenture, MySpace, and other companies that need enterprise-grade network management systems have been opting for Zenoss. They seem to need those pesky "features" that InfoWorld glosses over. They're buying a product, not a political platform.

Regardless, if we allow business model to be a valid factor in InfoWorld's decision criteria, how are we to explain its contradictory decision to judge Intalio the winner in the Business Process Management (BPM) category? The editors reason:

Intalio has been criticized regarding its open source claims, most likely because the company does not provide source code on its Web site (where binaries of the free community edition can be downloaded). However, Intalio's enterprise edition customers do get full access to source code, and the source code of community edition components -- which fall under Apache and Eclipse licenses -- are obtainable from their community-based repositories....

However, new beta features reflect enterprise needs, including a business rules engine, Ajax-driven forms for easier editing, and a more streamlined deployment interface. The full enterprise edition also includes BAM (business activity monitoring), a portal interface, ECM (enterprise content management) based on Alfresco, fail-over clustering, and support for application servers beyond Apache Geronimo.

I think Intalio is great, but I can't understand why Zenoss' business model is considered a demerit but for Intalio, which has the same model, it's a non-factor. Zenoss also provides source code to its enterprise customers, so why is Intalio right because it provides an enterprise-class experience with an Open Core model but Zenoss is wrong for doing the exact same thing?

Personally, I think awards should be given based on the merits that will most appeal to IT buyers, and such will have little to nothing to do with business model nuances and everything to do with solving business problems at a compelling price. If Zenoss is the better enterprise IT bet, shouldn't it get the Bossie, regardless of OpenNMS' licensing model?

InfoWorld set out to name the "top open source products." By deciding, instead, to name the top open-source products and business models, it has failed to serve its audience as well as it has in the past. The Bossies are still a good resource, but it's best to read the reasons behind some votes carefully, as they may have nothing to do with the products at all.

Follow me on Twitter @mjasay

Drupal is a fantastic Web publishing platform that derives much of its value from a disparate community of contributors, as Xconomy recently wrote. With more than 4,000 contributed modules from over 3,000 active contributors (741 of which contribute to Drupal Core), Drupal has something for everyone, which is both its greatest asset and biggest liability.

Choice is good. Too much choice, however, can be bad.

The same holds true for Red Hat, which charges a premium for its Red Hat Enterprise Linux distribution to enterprises that want to tap into Linux but don't want the bother of rolling their own version of Linux from Kernel.org.

The problem, however, is that such a business model depends upon the complexity of the underlying platform. If that complexity goes away, does the business model?

The Drupal-focused company Acquia is thriving because deploying Drupal, what with its myriad of choices, can be complex. Ditto for Red Hat. There are thousands of packages that comprise Linux, making it worthwhile to pay a trusted guide like Red Hat.

But Red Hat CTO Brian Stevens suggests that "you need product complexity" to make its model work. Does this mean that Red Hat and Acquia will be hitting the unemployment lines if they do their jobs too well, and Drupal and Linux become too easy to use?

I don't believe so, but that is certainly one way to read IDC data that shows unpaid Linux adoption is now outpacing commercial Linux adoption, which has the potential to disrupt Red Hat, Novell, Canonical, and other Linux vendors.

It's less an issue, however, for Acquia, which has been rolling out for-free software and services to augment Drupal, including enterprise-class search. Acquia's Drupal distribution teases the complexity out of Drupal, but it also extends beyond Drupal with enterprise-only features. It is therefore well-positioned to foster the Drupal community while simultaneously feeding its top and bottom lines.

For this reason, I believe Acquia's model has more staying power, though it has a long way to go before it generates Red Hat's nearly $1 billion in annual revenues. Acquia's model allows it to thrive even if Drupal becomes easy, and also affords the company greater latitude to enter new markets, like the application market, where product complexity is not as much of an issue.

Red Hat, on the other hand, must resolutely focus on core infrastructure, an area of the software stack that is naturally prone to such complexity, because of its adherence to its complexity-dependent business model.

Both models are generating impressive returns. But Acquia's open-source model seems to offer more potential in the long term than Red Hat's does.

Follow me on Twitter @mjasay.

For all the value that open-source development provides, Red Hat CEO Jim Whitehurst recently reminded the industry that open source may be more potent as a business model than as a development model:

Open-source development is great and all that, but I think more of the value of Red Hat comes from our open-source business model than from the development model.

The truth of this statement came home clearly to me in a conversation with Michael Mullany, vice president of marketing at Engine Yard, a cool company that provides on-demand deployment and management solutions for Ruby on Rails applications. Mullany walked me through some calculations he has been running to determine optimum business models for Engine Yard and others in the industry.

As Mullany tells it, despite all the chatter about free and freemium business models, the debates have yielded a paucity of valuable, actionable information. A mostly free business model like Craigslist rocks. A free but poorly-monetizable business model like YouTube does not. There's more to "free" than a price tag. But how do you determine when, where, or whether to use "free" as part of your business model?

After running a variety of models, Mullany filtered down the free (or freemium) vs. non-free debate to just four factors:

• The cost of marketing and selling to a user in a paid model
• The cost of serving a free user
• The cost of acquiring a free user
• How successful you are at converting users from free to paid (whether it's a cross-sell or a premium offer)

If these factors trend one way, in Mullany's math, free or freemium is a good idea. If the factors trend another way, then paid-only is a better idea. (Free trials are practically always a good idea--that's not what this debate is about.)

So how does this work? Here's where Mullany's mathematics background kicks in, so follow his formulae carefully.

Before we talk about free, we should talk about "paid," where the basic formula is: Sales - Costs = Profit. Or in long form:

Price Paid By User - Cost of Providing the Service - Cost of Selling & Marketing to Signup a User = Profit Per User.

Or in formula form:

PP - PC - PS&M = PPU

Free or freemium models are more complicated, however. Generally, you have a free offering that comes with restrictions and limitations, and a premium, paid offering that you sell as an upgrade. On one side, you spend money to get free users to sign up to a basic level of service (SEO and PR aren't free!), and then you spend more money to provide that free service.

On the other hand, you usually get to convert some percentage of those users to premium users with minimal additional costs in sales and marketing.

With this in mind, Mullany's equation for freemium businesses looks like this:

Price Paid by Premium User - Cost of Proving the Service to the Premium User - [ (1/Ratio of Premium:Free Users) * (Cost of Free Service Per User + Cost of Marketing to get a Free User) ] = Profit Per Premium User

Then in formula form (labeling the percentage of Premium to Total Users the Conversion Rate (CVR)):

PremP - PremC - 1/CVR * (FreeC + FreeS&M) = PremPU

So...to figure out which is the better model for your business, compare the two profits. Freemium is better than a paid model if:

PremP-PremC - 1/CVR * (FreeC+Free S&M) > PP-PC -PS&M

As an English major, I was asking Mullany for some simplification at this point. Fortunately, he provided it because, as it turns out, the price and cost to serve a premium versus a paid user will be fairly close, allowing us to cancel out on both sides.

This leaves the formula looking like:

1/CVR x (FreeC+Free S&M) > PS&M

With a little algebra you get a magic formula of sorts. Namely, freemium will be a better choice when:

Conversion Rate % > (Cost to Serve a Free User + Cost to Acquire a Free User)/Cost to Acquire a Paid User

From some informal surveys, it seems like best-in-class freemium conversion rates are anywhere from 2 to 8 percent (at the very high end). The implication of this, as Mullany noted, is that for free or freemium to make sense, your cost to serve and acquire a free user has to be from between one-twelfth and one-fiftieth the cost of acquiring a customer under an alternative paid model. (This is one reason why successful freemium businesses have a laser focus on conversion rates.)

Based on this (perhaps overly simple formula), it becomes clear why freemium models make sense when a business has either very strong word-of-mouth marketing, a very low cost to support a free user, or where the cost of sales and marketing to acquire a paid user is relatively very high. If your marketing costs are high, it can be either because it's an audience that's really hard to target or because it's a very new product category that requires a lot of education and assistance for a potential paying user to understand.

I really like the framework Mullany brings to open source, in particular, where "freemium" translates to Open Core and other business models.

His formula removes some of the dogma from open-source debates. The question is how to solve customer problems at the lowest possible cost/highest possible value, not whether one should join the Church of Free Software.

Sometimes "free" is absolutely the right way to provide customer value. And sometimes it is not. Mullany's formula helps to elucidate the decision-making process.

Follow me on Twitter @mjasay.