OSBC '07: Scaling and the Business of Open Source

I must confess, I didn’t catch what the official theme of OSBC was this year, or if there was an official theme. You know: conferences are often “on message” with a theme that tries to sum up the current State of Things.

What people kept saying though, was that it seemed like the open source companies here (or parts of mixed source companies that had open sourced) were figuring out how to “scale.” Which is a short way of saying “become a responsible adult, you know, like that pays it’s bills and has a steady job, maybe even gets rich.”

Part of that is the validation that open source as a business model has reached an important mile-stone of success: it can sustain a company and its customers. If a company can’t sustain itself at initial levels — compensating it’s employees adequately for the production, sale/distribution, and support of open source software — there’s no chance for it to worry about “scaling”: the company just folds or it’s employees eat oatmeal.

There are two thought-trains snarled up in this question of “scaling”:

• Support – As open source companies primary monetize on support, how do you scale up your staff to support more and more customers, esp. demanding enterprise software customers?
• Cashing Out – How are people going to make Exit Money off open source companies, esp. pre-Exit investors like VCs?

These two things are linked in one question: what are we going to charge for?

Support Staff, Support Poaching

The first question is, really, the same question any company faces, closed or open source. The answer is tried-and-true: assuming you’re providing an increasingly amount of support to your customers, you have to hire more people or write better code. We like to think that open source produces high quality software that doesn’t need a lot of support, or that “the community” will off-load a large amount of support. Either of those could be true on a case-by-case basis. But there are two problems:

• What if there are actually lots of people who want support with bugs in the code, figuring out how to use the software, production problems including deployment advice. That is, The Market actually does want a large quantity of support. This is the dream of open source companies selling support.
• On the other hand, if the software doesn’t really need that much support, how long are customers going to keep paying for support contracts they don’t use and, thus, don’t seem to need? Does the insurance model (you just buy support in case something goes wrong, but it rarely if ever does) work at the current prices being paid?

Assuming support is actually needed, signs point to the need to beef up support staffs at open source companies, which is fine. The only difference between open and closed source in this context is that open source companies will need to charge more for support since there’s (ostensibly) not an up-front license fee as closed source companies have.

As mentioned above, there’s also the chance that the software’s community can take care of support. Usually the assumption here is that that community is made up of the collection of people, archived email lists, and other “self-service” support that end-users will access or engage with. That is, instead of relying on a central core to draw support from, end-users will just use Google, IRC, or other channels to get, more or less, “free” support.

As a customers, if this option works in a timely fashion, it’s great: you don’t have to pay anyone. As the open source vendor, you don’t want the community to take care of every support case: otherwise, you have nothing to sell. Now, following the rising tide lifts all boats theory, the open source vendor only needs to get paid for a minority part of the over-all support provided to “the market”/community, but they need to collect money for providing some of that support.

Overall, going off my gut and past experience in closed source, enterprise software, I feel like there’s plenty of money and desire for support. Much to the dismay of 3rd level support staff on 6 hour long support calls, businesses always want to customize the crap out of their software. They rarely want to go down the cheap path, instead choosing to spend time and money crafting the software to fit their needs rather than waddle the business around the software. This is fine: the consequence is often that software rarely works “out of the box” and that the cheap answers to problems are often overlooked in favor of the highly customized and “cheap” option. It’s a dream for support-based revenue!

Here, we’re trailing into the subtleties of IT Doesn’t Matter:

• if a business is just using the same old software setup as everyone else, then,
• they’re not getting any differentiation from your software, and,
• if differentiation is the key tool for making money, then,
• IT isn’t helping you (directly) make money

To simplify it, if IT Doesn’t Matter it true, then support sales should decline significantly. Sort of paradoxically, if IT ever “just works” it’ll cease to “matter”…to open source vendors, at least, who’re looking for support sales.

This sort of tension is older than dirt: if I give you something that works perfectly and does everything you want for free, what else is there for me to charge you for? Why buy the cow when the milk’s free, as they say? Let’s move on.

You’ve got to have enough people who’ll trade money for their own time.

Support Poaching

An interesting, and highly contemporary wrinkle in all this is what several people and I talked about at length: the Unbreakable Linux move. The problem here is: if your revenue is based off support, what happens when someone else is successful at “winning” (or “stealing” if you prefer) support contracts from you? RedHat and Oracle are examples, but Spring and numerous other companies are an up-and-coming example as well.

I always think of this as the software equivalent of dumping.

RedHat as the Cash Key-stone

Getting specific for a moment, it was interesting at OSBC to hear how many people thought of RedHat as the sort of market success key-stone for open source businesses, if not the software industry in general. If RedHat tanked, the thought would go, we’d all suffer, because:

• Investors would no longer believe in an open source business as a good investment
• There would be no more investment in new or existing open source companies
• You’d have no new business-led innovations in open source (or software in general some suggest)
• Software would sort of stall out since we’ve got so many eggs in the open source basket

I’m not positive I fully buy into the gloom and doom there. But, I do certainly believe that something different would happen should RedHat tank. Same as with Google or any other “yet to fall” high-flyer, of course.

Evaluating Who to Buy Support From

Generalizing, the question in the case of support poaching becomes: what company is best suited to provide the best support? (The assumption is that buyers will tend to buy from those best suited.)

At the moment, the prime metric for figuring out how “good” any entity will be at supporting a given piece of open source software is how many commiters or “core members” that entity has on the project. This matters because when fixing bugs or introducing new features, you want the fix rolled back into the mainline of the project, not just “patched” for your instance. You want to avoid forks and duct-tape.

Put another way, as Steve and I discussed with EnterpriseDB’s Andy Astor awhile ago, a large part of providing support for an open source project is being an advocate for your customers in the community. While it’s certainly possible to be an advocate without being a core part of that community, being part of the project certainly gives the support provider the highest chance to get what the customer wants. (That’s not a locked in chance, just a higher chance.)

So, controlling the community as much as possible is the best path for companies wanting to make money (beyond consulting) off providing support for any given open source project. Though it seems like a pretty safe bet, this isn’t a sure path for safety: if rainbow-and-sandals ethics evade large company execs, I think we’ll still see smaller open source companies porked by larger ones who can effectively spend-seige those smaller companies into a starvation. That is, “dumping.”

History

Of course, the closed source world is littered with stories of companies who either didn’t take out young up-and-comers while they could or otherwise let those threats whiz by and blossom into peers.

Another look-back to draw from: does Microsoft make the most money in the market of Windows support, or are there better and richer people who provide Windows support?

The MySQL, Single-entity Gambit

I’m quite sure Eben Moglen’s keynote about lunch eating touched on some of the poaching points above. Indeed, in the numerous conversations I had about support poaching, MySQL was regarded as essentially immune from poachery because their dual GPL licensing, control of all the IP, and project commiters gives MySQL exclusive control over the code-base. This model goes by the name of “single-entity open source” meaning that a single entity (here, the MySQL company) controls and “owns” the source and, thus, the heart of the project and community.

The alternative to this setup is a “multi-entity” in which any number of different entities work on and “own” the source and operate in the community. Apache projects are (or can be) multi-entity, Linux is multi-entity, Spring is (right?), and so forth. I hope to see OpenJDK go multi-entity as soon as possible: the interim governance board is a hopeful start. (Though, it’s worth pointing out McGovern’s comment that there are no enterprise reps on the interim board.)

One is often drawn to give any open source operative a rating of “how open source” they are. I get the feel that this single- vs. multi-entity discussion is partly a run to make another measuring stick for that favorite parlor game (which, you’ll recall, I find boring).

More tactically, the single- vs. multi-entity discussion is instructive for the open source business model you’re drawing around an open source project. I don’t have it figured out, but at the moment it seems that maintaining MySQL like control over the project is the easiest way to provide profit runway.

Something to Charge For

To throw out a theory, successful open source business models need to either:

• Create the desire for customers to spend money rather than time, e.g., by providing faster support than any other source, or
• Put up (legal?) constraints that customers want to buy their way out of if desired, e.g., attribution clauses, or the GPL’s reciprocal “benefits”

Branding

One point that I haven’t brought up and that wasn’t covered too in-depth at OSBC (from the participation I had, at least) was the role that traditional brand-tacticts could (maybe) play in open source businesses. The word “brand” has a bad wrap for software people as it connotes the sort of snake-oil huckstery that we think only “users” would succumb to, not us smart-y coders. That is, it feels like the words “lie” and “deception.” Pulling that crud off, some contemporary brand-think strikes an almost 1:1 mapping with what we’d call “community management” in the open source world: establishing co-creating relationships with your customers. To put it in base terms, it’s the difference between being comfortable vs uncomfortable with the word “consumer.”

Ultimately, all tooth-paste is pretty much the same, but we tooth brushers have our tooth-paste crushes and hates. Open source operates this way in many cases, but I’m not sure the methods of establishing consumer-BFF have been implemented on a wide-scale in open source businesses. Some interesting brands to think of here: GNU, Ubuntu, Firefox, and Spring. In each of those cases, and others, in addition to the technology itself, the ideas and culture of those brands motivate people (consumers, users, customers…however you like saying it) to frequent the respective products. Of course, Google is a great example: is it really so much better than other options that I use it all the time, without thinking? (James could expound on how Google’s success as a brand has fogged up people’s thinking of Google as a privacy threat.

I mention brand because it connects back to my main conclusion from OSBC: really, the business of open source software is panning out to be pretty much the same as closed source software. Sure, the legal mumbo-jumbo is different, and we call people “community managers” instead of “product managers,” but you’re sort of doing the same things when it comes to innovating, taking care of your ecosystem, and then charging for something, probably support and services. Thus, when it comes to branding and marketing open source, I often feel like it’ll be the same old story: be nice, responsive, and be sure to show up. A lucky rabbit foot seems to help too.

Exits: What is Success?

One thing I didn’t explicitly touch on is the question of what success is. Clearly, if you’re an investor in an open source business, success is making as much money as possible: success is getting the company acquired for millions or IPO’ing. Success is not just plodding along, paying the bills, with slow but steady, perhaps platauing revenue.

In the case of investors, the trick is figuring out how make money off the weird ways open source is successful. Think of Eclipse or Firefox. I don’t think a traditional way of investing would work there. On the other hand, IBM and many others who “invest” in Eclipse clearly benefit from Eclipse. Firefox actually makes good money, but how does “an investor” do something with that?

There are three views to take on this:

1. Potential acquirers of open source companies are looking at open source businesses as off-the-rack innovation. Large companies don’t like to do all (or even most) of their own innovation. It’s costly, risky, and doesn’t result in quarterly revenue until you’re actually done. Better to let all manner of small companies take all the risk and then skim the cream off the top, even at a premium if you know you can take that innovation and grow it’s value. Under this model, investing in open source businesses is fine: you’re looking for a buy out exit. There’s of course the private equity carrousel as well: passing the company off to another set of “investors” who hope to shape the company up to be finally bought by the last buyer.
2. Open source businesses will actually become self-sustaining, and steadily growing companies that can be traded on the public market. RedHat! Again, this investment is fine.
3. Open source businesses won’t bring in the same amount of revenue as quickly as past software companies. And here’s the one I feel weirded out about: can open source companies actually become valuable enough, quickly enough, for the desires of traditional investors (like VCs)?

I feel like most high-flying open source businesses (like Interface21) fall solidly under the first category. On the second point, it’ll be interesting to watch MySQL and VMWare as each goes public and figures out what that means in the near future. The point is that we have an open and closed source vendor, each at the Morlock layer of IT. On the third point: well, that’s just the plain old risk of doin’ bid’ness, right?

I mean, is it just me, or is it feeling like open source businesses are pretty much like closed source ones? (Which would be a mostly good thing, mind you!)

Disclaimer: MySQL and EnterpriseDB is a client.

Technorati Tags: gnu, support, osbc, osbc07, brand, oracle, redhat, linux