First public OpenGamma Platform release

Remember that whole thing about the OpenGamma Platform being available Open Source?

Yeah. It is..

Open Core, Natural Feature Divisions, and OpenGamma

I've written in the past on Open Core strategies for Open Source technology-based businesses. I've been following this debate for quite some time, and have at least a little bit more to say about it.

Open Core has gotten a bit of a bad name recently, largely due to two major recent events:

• SugarCRM's new version and licensing going so far beyond any other established Open Source technology-based company that I hesitate to even group them into that category;
• Eucalyptus' rumor of a refusal to merge NASA-provided patches to their Open Source licensed core, by a community perception that it would make the Open Source core more competitive with the proprietary version, leading to the creation of the OpenStack initiative.

People who want a lot more backstory on the arguments in the blogosphere should turn to the 451 CAOS Theory writeups (from Matt Aslett - Post The First, and Post The Second).

Personally, I believe that Open Core business strategies can work quite effectively where there are at least two conditions that hold true:

• The core version is useful to a large subset of the target audience, without any requirement to purchase any features or services to achieve its utility; and
• There is a natural split between features/components/modules that are licensed under the Open Source core, and the proprietary extensions.

The key thing to me is that the split has to be natural. An artificial split happens when someone looks at a distinction between an Open Source part of the overall offering and a proprietary part, and can't figure out what rationale might have been used to determine which was which, except for revenue defensibility. If your user base can't look at a feature and instinctively tell you whether it belongs in the Open Source version or the proprietary version it's artificial.

OpenGamma, the company I founded which is building an Open Source Platform for financial analytics and risk management, has from its inception planned on an Open Core strategy for part of its business model. Based on all the controversy, I've clarified our position, and how we naturally divide up features, in a new blog post on our web site. That's the official company statement.

This post is to explain my personal beliefs, and how we divided up the world. Just to make it abundantly clear, let me spell it out: I will not reject a community-generated patch just to maintain the defensibility of our revenue model.

Comments and questions more than welcome, either on the OpenGamma specific story (on the OpenGamma post) or my personal take (on this one).

Update 2010-07-26

Just to be clear, people should be aware of the changes made above about Eucalyptus: they never actually rejected contributions, but there was a rumor of it leading to massive perceptional issues that flowed through into debates about Open Core, regardless of the truth of these allegations. Thanks to some very wise birds who clarified to me back-channel, leading me to make sure that this is very very clear here.

Monty, Stallman, MySQL, Oracle, and Sun: Open Letter Wars

I've tried to confine my ranting about the current state of the Sun/Oracle/MySQL debates to my Twitter feed, but I think I need to do more than the 140 character limit allows.

Background On Recent Moves

In case you haven't been following the state of play, we've got two recent open letters sent to the EU competition commissioner:

• RMS, Knowledge Ecology International, and the Open Rights Group came out as strongly opposed to allowing the Sun/Oracle acquisition to proceed as long as MySQL was part of the acquisition.
• Monty suggested that Oracle be forced to sell MySQL as part of the Sun acquisition.

If you've been following either of my posts on the subject, you'll know I'm not a dispassionate observer in this matter, particularly where Mr. Widenius is involved.

Competition and Acquisition

First of all, let's directly address the core matter at hand, which is that Monty, RMS, and the various others appear to believe that the Database market is hopelessly consolidated and were Oracle to get its hands on the copyright to the MySQL source code that would be bad for competition.

This, to be honest, completely and utterly disregards the actual history of the database market, which has always been one of consolidation and benefits to the consumer:

• Illustra, a Berkeley spin-out, was bought by Informix
• Informix was bought by IBM
• RedBrick was bought by IBM
• RDB was bought by Oracle

While this consolidation has reduced the number of vendors in the market, as of 2007 there was still pretty hefty competition with Oracle even then only with a 44.1% share of the paid database market. As someone who has had to work professionally with Oracle, DB/2, Sybase, and Microsoft SQL/Server, I can say this is almost certainly because it's the best overall product.

Furthermore, those numbers in terms of the database revenue are completely suspect (with the exception of Microsoft's). There's a huge amount of revenue for IBM and Oracle which are tied to services and software sitting on top of the database (such as Oracle applications and IBM services), and realistically the CFOs of each company can tune the percentage of the deal that goes to the underlying database based on what numbers they want to report. The overall deal may be $1MM, but the sales person has a lot of discretion on how they price the database component.

Is there so little competition in the market that it's hurting consumers? Hardly. The recent squabble over Oracle's TPC-C pseudo-announcements indicates that the vendors actively compete with each other. Furthermore, the rate of feature expansion has been truly dramatic. Finally, the ability of firms like Vertica to rapidly jump into the market indicates that this isn't a market that requires significant levels of competitive concern on the part of regulators.

The technology industry is based on larger firms buying smaller ones. Competition authorities should rightfully be concerned only if it harms consumers in general, not whether it harms a particular subset of users.

But MySQL Is Special

With all due respect, no it isn't.

Let's consider the pseudo-market for Open Source databases. We've got:

• MySQL and its various derivatives (like Drizzle)
• PostgreSQL and its various commercial/supported versions
• Ingres
• Firebird
• LucidDB

And that's just considering the relational ones. When you consider the NoSQL movement as potential competitors (which I, for example, most certainly do), MySQL just isn't that special anymore.

While it is possible that an Oracle acquisition might be bad for MySQL consumers, it doesn't follow that MySQL is so special and perfect and pure that it harms any general category of consumers. While databases aren't perfectly replaceable, if someone found that Oracle's stewardship of MySQL was so onerous that they wanted to move off of it, it wouldn't be impossible to move to another database, either commercial or Open Source.

What that means is that you're in a classic case where the acquisition of a particular company might be harmful to consumers of that company's products, but it doesn't generically affect the market in a negative way. IBM and Microsoft will continue to compete in the commercial space, and PostgreSQL, Ingres, and LucidDB will continue to compete in the Open Source space. There's no net harm to consumers as a whole from an acquisition, even if the result of the acquisition was the complete shutdown of all commercial support for MySQL.

Oracle Is A Bad Acquirer

First of all, let's get the obvious out of the way: Oracle bought BerkeleyDB, and continued to enhance it; Oracle bought InnoDB, and continued to enhance it. At no point did they crush them to drive Oracle database revenues, or change the licenses, or stop forward momentum. So when you look at the actual track record of the company, they're in the clear.

But they might do, because they're an evil, scary corporation that MySQL turned down once before (from the Stallman piece):

Oracle made an earlier effort to buy MySQL in 2006, but the management rejected Oracle's offer, in part because Oracle would not disclose its plan for MySQL, and some members of the MySQL management team were concerned that Oracle was only acquiring MySQL to curb its advances in the marketplace.

I know a number of people involved with MySQL when it was an independent organization. While there were people who worried about that fact, senior management wasn't. More importantly, Monty was willing to sell MySQL to Oracle in 2006 for the right price. The use of the words "in part" there are telling, because the primary consideration that MySQL's senior management had wasn't some happy-clappy love for the Libre Software Movement, it was money.

I'm sorry, but I fail to see what's changed in between 2006 and 2009 except that Monty is a whole heck of a lot richer. Why in 2005 and 2006 were offers ultimately rejected from Oracle based primarily on money, but now Oracle is an evil corporation that can't be trusted with MySQL? Larry's the same guy he was then, Oracle has bought BEA but they don't compete in any way with MySQL, it's the same company. Why would Monty trust Oracle back in 2006 but not now?

Force Oracle to Sell MySQL

This is Monty's solution. And it's cunning. It's particularly cunning that he says repeatedly that the obvious Monty-connected acquirer, Monty Program AB, lacks the funds to do such a purchase. Again, a half-truth.

MySQL was worth $1Bn in early 2008. Since then markets globally have tanked, but MySQL has had some good commercial strength recently within the Sun organization. So let's conservatively say that it's still worth $1Bn. Let's then say that Oracle values the acquisition of Sun highly enough to let MySQL go for less, and do a 20% haircut to $800MM. Who's got that kind of money to acquire?

• Microsoft. You think Stallman and Monty would be happy with that? No.
• IBM. #2 in the database market. Erm, raises same issues that Oracle would.
• Sybase has the market cap (super-recently) but not the cash.
• Red Hat has the market cap, but not the cash.
• Novell lacks the market cap and the cash.
• Computer Associates has the market cap and the cash, but is the place technology goes to die. They also have Ingres to work with.
• VMWare has the market cap and the cash and an acquisitive streak, but would MySQL really fit into their product strategy? I can see Spring driving people to vCloud, but can't even fathom the same kind of strategic benefit for MySQL.
• Symantec has the market cap and the cash, but their storage work has been pretty solidly focused on backup and low-level storage these days.

It doesn't look to me like there are that many companies out there that could really buy MySQL in cash and make Stallman and Monty happy.

But you don't actually need to have the cash yourself: you can use private equity money. It's happened before: BEA was funded by private equity originally to consolidate the Tuxedo market. That's why Monty's protestations ring hollow: his statement is explicitly "we don't have the money." But I think he could probably come up with it, and if he doesn't, then he needs to work with better financiers.

Finally, let's assume that Oracle really wants the rest of Sun, and considers carefully Monty's open statement that Sun is hemorrhaging $100MM of cash per month. Wouldn't it make sense for Oracle to actually just donate MySQL to pretty much anybody to make the EU issue go away? Oh, and lo and behold, Monty has two of those ready to go: Monty Program AB, and the Open Database Alliance.

To me, the current situation amounts to blackmail: we'll keep blocking your acquisition of Sun until you do what we want.

Consider The Sources

So let's look at the motivations of the major current players.

Stallman is irrelevant to any commercial discussion. His press release essentially says "I don't like the GPLv2 anymore, even though I wrote it, and it would be better if MySQL was under the GPLv3." Tough. Furthermore, RMS has no commercial experience of any kind. I fail to see how someone who has never even worked for a profitable commercial enterprise could be considered knowledgeable about how an acquisition would affect the marketplace in an anti-competitive way that harms consumers.

Furthermore, RMS' press release completely belies his previous positions regarding the possibilities for commercialization of GPL projects. He's stated in the past that offering dual licensing is only one of many ways that you can make money with the GPL being the dominant licensing model. Why all of a sudden does he believe that this is the only possibility for MySQL? Why is he so adamant that without that ability, there's no ability to derive commercial revenue from MySQL?

Monty has been slinging FUD about this acquisition for months. He was such a disruptive element inside Sun that they released him from his Non-Compete just to make him go away. Given that he's an extremely rich, disgruntled ex-employee and project founder, he has personal reasons and financial ones (under the Monty Program AB umbrella) to cause as much disruption to this deal as possible.

I've said it before and I'll say it again: Monty has been playing a long game here, and I think he'll be obstructive to any potential move that Oracle would make with MySQL until the IP is under his control.

Personal Opinions Should Not Drive Competition Policy

Ultimately, you can sum up the entire argument against the Oracle/Sun acqusition due to the MySQL situation as:

• We don't like Oracle owning the MySQL IP
• Therefore, don't let Oracle own the MySQL IP

Unfortunately, saying that you personally dislike something doesn't provide a valid reason to block an acquisition on competition grounds. Saying that you don't trust Oracle doesn't alter the marketplace in a way that disadvantages customers as a whole. Saying that nobody else could make money by selling commercial licenses for MySQL doesn't mean someone else must be allowed to.

The moment the MySQL founders, who have been handsomely rewarded, took VC money they turned MySQL from being a hobby project/company, and into a major technology company and an asset. The change happened years ago, it's just that they're only starting to wise up now.

But it's happened. It's done. It's no longer anybody's pet project; it's an asset that can and should be used by whomever is willing to pay the most for the IP. As a customer, under the GPLv2, you still have rights, including the right to fork. But don't go whining that a company that made massive amounts of money for its shareholders by commercializing a technology is no longer under your control.

Monty Bites The Hand That Fed Him: Part 2

(Take a look at Part One of my Monty-Watch for some background as to what I think about the situation).

So Monty Widenius and Peter Zaitsev did an interview with Matthew Aslett on the creation of the Open Database Alliance. It's well worth a read.

For the record, I don't want anybody to conflate my opinions on what Monty's done with anybody else associated with the Open Database Alliance. I actually think that having such an organization ex-Oracle to make sure that there's a unified voice for everybody working (and attempting to make money) from the MySQL ecosystem, outside the current corporate owner of the MySQL brand, is a Good Thing (and something I think other projects with a single major corporate sponsor may lead to in the future). As such, having a place for all the various consultancies and technology providers to work together to ensure their interests are looked after is a pretty useful and innovative thing.

However, let's play "Look At The Balls On That Guy"!

Actual Quote Time:

I have, however, offered Oracle a partnership with Monty Program Ab, under which Oracle could get access to some of the critical developer resources Monty Program Ab has available. Monty Program Ab could also help Oracle with their open source strategy and serve as a ‘trust creating’ entity between Oracle and the open source developer community. Oracle has however not yet responded to this.

Kirk's Translation:

I have hired all of the people that ever worked for me when I stormed off from Sun in a huff. Now you may have the MySQL brand name and core IP, but I have all the engineers. Furthermore, I've been sowing as much FUD as I possibly can when, quite frankly, you haven't done anything directly to harm the interests of the MySQL community. If you want me to publicly step down from the FUD-slinging, I have a bank account to which you can send some [more] money.

Anyone who doubts the actual motivations of Monty's recent efforts should read the real quotation (as well as my translation). I think it speaks volumes about what he's attempting to achieve here, which is quite simply to spread enough FUD about Oracle's relationship to MySQL that Oracle feels like it has to engage in some type of action to bring Monty back into the fold in some form, which would involve some type of cash money payment. There really is no other conclusion possible for someone who says, in no uncertain terms: I have all the core developers; I've damaged your relationship with the core community; You could pay me and make the problems go away.

How Many Times Can Monty Sell MySQL?

UPDATE 2009-05-27: Monty's spoken to Matt Aslett, and I've responded.

COMMENTARY UPDATE 2009-05-27: If you're just reading this for the first time, after posting this it became clear (through back-channel to me) that Sun did have Monty under an Non-Compete, and chose to allow Monty to get out of it. I've commented about that in the comments [which you should really read] and in the Proggit thread. I still think Monty's actions are pretty bad looking even given that, but you should understand that there was a Non-Compete, and Monty was let out of it by Sun, before you read the original article below.

I've been thinking this since it was announced, but Monty's current attempt to monetize MySQL by hamstringing the eventual owner of his original attempt is really quite, ahem, ballsy. For a much less ranty analysis with quotes from M-Dawg himself, see Stephen O'Grady of RedMonk's writeup.

Let me give the Kirk "worked for 3 database companies and founded one expressly to compete with MySQL" Wylie synopsis:

• Monty writes MySQL way back in the day, largely so that he has a database system which doesn't have any of the complex features of an RDBMS that make it work well (you know, referential integrity, transactions, views, proper metadata support).
• People start using it, largely because it's Free-as-in-Beer (this was back in the days of minimum $100K Oracle buys just to run a simple web site), but also because it's easy to setup and administer (which Oracle/Sybase/SQLServer/DB2 were not).
• Monty wants to get rich.
• In an effort to get rich, he takes a boat load of VC funding to push MySQL from being a small open source collective to a Real Company.
• VC funding requires a business model that has real revenue behind it.
• Company adopts a split licensing model (which pissed off a lot of people at the time), and starts being effective in attracting revenue and very, very smart people as executives.
• Monty's dreams of success are realized when Sun pays a king's ransom for MySQL.
• Monty wants to have his cake [1] and eat it too, and gets all pissy and storms off in a strop and founds an attempt to get rich a second time on the same project.
• Oracle buying Sun means people take this attempt even more seriously and he attracts people who never liked the post-VC-funding MySQL business model in the first place to the cause.

So here's the question that everybody should have on their minds: How many times will Monty attempt to get rich off the same project? [2]

Now I wasn't privy to any of the contractual arrangements around MySQL's incorporation, or his common stock stake, or the Sun buyout, or any of his employment agreements [3]. I will, however, postulate that if Monty doesn't have Fuck You money at this point given a $1Bn buyout of the firm he founded, he did something Seriously Wrong, and you probably shouldn't trust his business instincts.

So one of two things is going on here:

• f(Cake + Eating) == Cake
• He fundamentally doesn't agree with a split licensing model and thinks it's doomed to failure. I really hope this isn't the case, because if it is, he was acting disingenuously at best when working for the Original Monty MySQL-Based Get Rich Scheme, by supporting a model that he didn't believe in.

If it's the latter, why did he start down the path of taking VC money in the first place? Seriously, did he honestly believe that he could take a boat-load of risk capital, and not have to provide returns to the limited partners at the core of any risk capital facility? Did he lose some type of boardroom squabble over the direction of MySQL and has been nursing a grudge ever since? [4]

Here's something any founders of Open Source projects need to realize: VC money comes with strings attached; do not take that money if you don't want to take the strings. The strings are entirely financial: VC/risk capital requires a very hefty payout in a relatively short (5-10 years max) timeframe to the limited partners who provided the VC firm with its capital to invest. In order to ramp up revenues in a reasonable timeframe, you will need to have some facility to generate reproducible, cheap-to-deliver revenue in that timeframe. Open Core is one approach, Split Licensing is another, all manner of Services are a third, there are a whole host. But you have to come up with one. Otherwise there's no point in raising risk capital, which must have a hefty payout.

If you just want to have a lifestyle business (and many lifestyle businesses can, over time, still provide you with Fuck You money if you structure them properly), while constantly maintaining an environment where you can do what you want technically in a purely-Libre environment, don't take risk capital. Grow your business organically, and enjoy the life that you've created for yourself.

But the moment you accept that term sheet, you've crossed the barrier beyond a pure hacker coding for fun, and a company executive who must deliver returns to his investors (and that may require doing things that the hacker side of you finds distasteful). If you're not willing to sign up to the transition between pure Open Source techie and Business Executive, don't accept the term sheet. And for the love of the FSM's noodly appendage, don't accept the term sheet thinking that you're going to screw your investors in the long term by going back to your roots once you've got your payout. [5] Doing so screws it for the rest of us.

Here's the #1 problem Monty's move has caused for anyone attempting to make Fuck You money off Open Source: it should make VCs very nervous indeed about Open Source investments. Let's examine what I would consider to be a logical thought process:

• If we invest in an Open Source company, the most likely outcome is an acquisition by another firm.
• If founders of projects make it a habit of storming off to fork their invention because they don't like the monetization model they helped establish, other firms are very unlikely indeed to buy Open Source companies.
• If other companies are unlikely to buy Open Source companies, our return on investment in them will be much lower.
• Therefore, there's no point in looking at them.

None of this impacts Monty: he presumably already has his Fuck You money.

But if I were a VC looking to invest in an Open Source company, I would insist on an enforceable non-compete if I could [6], and I would make sure that my exits prevented the founders from being able to fork. Otherwise, my assets are really only there to make the founders enough money that they can pursue their dream of working on pure Open Source code with enough money that they no longer have to try to get rich. Which is great for them, but not for the rest of us who aren't rich but wish we were.

Remember: going for the brass ring and taking VC money requires that you compromise something. If you don't like it, don't take the money. But once you have, realize that you may need to walk away from your baby once you've got the money for the sake of everybody else.

Just as an aside, bear in mind that nothing should stop you from doing Open Source work, including starting an entirely new project on the same basic idea, once you have your payoff. It happens all the time in other industries (how many networking hardware companies have been founded by the exact same executives?). But resist the urge to fork your original project. It's unseemly at best, and flat-out unethical at worst. If Monty had started MariaDB from scratch, that would be one thing. But he didn't. And that's the thing that makes this all seem, well, just a little bit wrong to me.

Footnotes

[1]: By cake, I mean chedda/dead presidents/papa. Cash money, yo.
[2]: Clearly more than once.
[3]: Hence I am totally unqualified to comment here. I'm doing so anyway, because if you keep reading, this turns less Monty-directed and more general-parable.
[4]: There's a reason nobody ever saw the code for my Compete-with-MySQL Open Source Database startup.
[5]: I'm not actually accusing Monty of this, and nor do I believe it to be the case (believe it or not). I think there's something else going on here. But I could see that some people might think that unethically, and you really shouldn't.
[6]: Yes, there are ways to structure this, usually during the M&A stage, by having deferred payments to the founders which don't trigger if they fork for some period of time, that even comply with California and UK restraint-of-trade law.

OpenCore/Split Licensing: You Can Do It Wrong

Tarus Balog comes out with another salvo against what he calls Open Core licensing, and I've called Split Licensing. His general statement this time comes down to:

• Hyperic has a feature that the open source community would like;
• They have that feature in the commercial version;
• It would be stupid for them to take that feature and make it part of the Open Source version.

Ergo, Open Core is fundamentally flawed.

Almost at the same time, Zack Urlocker (M7 Alumni In Da Hizzy Yo!) has a new post where he provides the most interesting clue as to why Tarus doesn't fully understand how you can do it right:

Find a way to distinguish between capabilities that businesses want and individual community members may not even care about. For example, Scott Dietzen mentioned e-mail features related to archiving and compliance issues are really only relevant to larger companies. And as he noted, community members will even support the the idea that if you need those features, you should pay.

My Open Source Cookies stream has hit on this before. Just because one firm chose the wrong feature to be part of their cookie doesn't mean that the whole concept is flawed. That's like saying "McDonalds sells disgusting hamburgers; therefore, all hamburgers are rubbish."

Again, to continue my statements on this:

• Pursuing Split Licensing means that you have to be very careful about what you put in the Open Source vs Commercial versions;
• More importantly, it's a case of constant refinement as you discover some features that you thought were commercial only but should be migrated to the Open Source version;
• Targetting features that are only of use to committed commercial users is the key.

It may be that you have a product which is so generic that you can't come up with something that satisfies the Cookie requirement. If it is, you shouldn't be trying Split Licensing at all. Not every business model suits every Open Source project. Choose the right one.

Open Source: It's All About The Community

I wanted to take a look at an open source project/product yesterday evening (I'm not going to name them for obvious reasons). In order for me to look at anything other than marketing-ware provided by the company looking to commercialize it, I had to:

• Register with an account in their Confluence instance.
• Run through an email validation step so that they were sure I gave a real email address.
• Register again, giving them my full contact details (name, email address, and a valid phone number), a company name, company sector, and title.
• I then got an email from their system that they had automatically added my email address to a mailing list so that they could, presumably, spam me.
• I expect a phone call from a sales rep any day now (or else why would they have required a valid phone number in the first place?).
  

Once I had done this, I could look at their documentation. Yay!

Next step: I want to grab it and take a look. Oops, only binary download format is a Windows-only installer (seriously? You couldn't just do a tarball? I don't run Windows. At all.).

Okay, so maybe I can take a look at their source code quickly. Oops, no online source code browsing. Rather, I had to do a search on their confluence, and then that showed me how to do an SVN pull.

Really? You think this is the way to build a community? By putting this many barriers in front of someone who just wants to have a poke around?

A firm like this, to me, would be much better suited as a closed-source, source-code-available firm (and lots of firms do this; for example, at an Enterprise price point, you get the source code to most Atlassian products, which helped me to debug some problems I had with an early Bamboo 2.0 build). Building a community requires that you be more than willing to actually embrace Open Source as a way of life, with an emphasis on the Open side.

They should be doing everything they can to get code in the hands of developers, and to get binaries in the hands of potential evaluators. They shouldn't make me feel like I'm going to have to talk to an Enterprise Sales Guy just to see what their system actually does.

Focus on the community and the rest should follow. Don't make people feel like Open Source is just a marketing angle.

Qt Going LGPL: The Java Angle

(One of Many articles on Qt allowing LGPL licensing). Assuming that this includes the Jambi components (Java/Qt bindings), which I can't find any reference to positively or negatively, but since it's part of the language bindings and not the value-add tools I can't imagine they wouldn't, I think this is a great move for the Java community in terms of rich GUIs.

No, I'm not going to talk JavaFX. Ignore that as a distraction at the moment.

Right now, if you want to roll a thick/rich client (and yes, there are still a lot of applications that are (shock! horror!) not delivered through the browser, and that's going to stay that way) in Java, you've got a few choices:

• Swing. Gag. Even with Nimbus (only available if you've got 6u10 pushed to the desktop), it's ugly, and no matter how good the Windows L&F gets, it's never going to look native in any way. Swing is also an example of precisely why Java needs closures.
• SWT. SWT would be much better if JFaces was more advanced (I don't want my apps to look like ass, but I don't want to go back to AWT-level programming either), and SWT was more documented, and there were really people using it for things other than Eclipse plugins. Yes, I know there are some other uses, but not a ton to be fair, and so not a lot of example code to copy.
• Qt/Jambi. Very well done MVC programming model (signals and slots, but with no preprocessor, so it's all Java toolchain friendly), looks native. Oh, and you can embed WebKit.

Honestly, I think this is a really positive thing for Java to have a rich GUI framework that's easy to work with, and looks good. Lord knows we've been waiting long enough for it....

Some Interactions Are Only Indirectly Profitable

I met with Ari Zilka from Terracotta Technologies yesterday in their offices in San Francisco for a follow-up meeting from a series of meetings I had had with Ari and our sales representative over the course of the past year. My interaction with Terracotta has largely been one of "This technology really is a game-changer; I just have to find my personal game that it changes," and I've been working with Ari ever since on the first entrance path for Terracotta into my company's infrastructure.

Ari's a busy guy. He's a founder and CTO of a software startup, and having been there, I know how difficult it is for him to devote time to anyone. And I've now had three meetings with him over the course of about 9 months. And my employer has not given them a single dollar as of yet, and there's no guarantee that even if we end up rolling into production on top of Terracotta, that my employer will stump up cash to them for an open source technology (FTR, this is the company that inspired the original Open Source Cookies post). This is probably a frustrating situation for the sales guy, because sales guys have numbers and targets and need to make money, and the sales guy needs to dole out his fraction of Ari's time in the way that's going to maximize his commission. I'm clearly not that as of yet. And yet there I was for the third time.

Why?

What's the rationale for his wasting yet more time talking to me?

Having discussed some similar issues with Laura Khalil from Atlassian yesterday when I met with her earlier in the day (more on that meeting anon), I think things started to gel in a more concrete way, because they face these problems as well from a non-Open Source perspective.

The rationale here is that some interactions are only indirectly profitable, but the indirect benefits potentially vastly outweigh the direct ones. So you pursue them anyway if you're an open company; a closed company won't.

Traditional Sales Model
Consider the traditional Enterprise Software (deal supporting direct sales force, or > $100k licensing) sales model:

1. Company sends out feelers to vendors
2. Vendors send representatives
3. Company goes ahead with due diligence/POC with one or more vendors
4. Company starts negotiations
5. Deal is signed
6. All vendors move on

In this model, you have a discrete lifecycle of a particular sale, and most players are only around for the sale; after the cash changes hands, you're into support land, which is at least partially an insurance business. The company projects to the vendors its rough budget, the vendors determine how to maximize their portion of the budget and whether the deal is even worth pursuing. Knowledge is largely gained by the customers interacting directly with the vendors, or maybe checking with some research firms.

Note here that the vendors themselves pull out of the conversation the moment they realize that they don't want the particular deal: it's too small, they're not the right solution, whatever. Then they go back to their closed external appearance, and go back into information embargo. If they can't make a sale, why waste anybody's time on the interaction?

I think any company that thinks this way and is trying to sell to technologists is going to fail and fail hard. And I think split open/closed source companies are best suited to be able to leverage this.

I'm A Bad Customer
For any commercial software company, from a sales perspective, my employer is not their ideal customer. We're not that big for a financial services company (our parent company is, but we have our own technology stack and purchasing departments). We don't buy way more than we need. We don't like shelfware. We like best-of-breed, and don't buy whole software stacks (we will never buy a Service Oriented Architecture Solution). Our technologists are massively involved in sales decisions, even when it's really a business-facing application. We constantly evaluate software in build-vs-buy mentality (and we as a culture like writing software). We're small fry, and we're an expensive (from the vendor's perspective) sale.

But, that being said, we probably are a good candidate for a sale that influences others. We are passionate about technology. We have lots of technical contacts (friends, ex-coworkers) with people at much larger companies. We have people who are involved with lots of online technical communities. We have people who do open source work in their spare time. We have people who blog, both positively and negatively. We go to user groups. We engage vendors constantly on product improvements. We take betas and alphas and developer cuts all the time.

That means that ultimately getting us on your side (even when we don't give you a single dollar in revenue) ends up influencing a lot more people than even a single larger sale would.

So when you look at the overall picture, it starts to make sense for Ari to spend time talking with me, even without a Big Ticket Sale right in front of him. And I think that would be true of any open source technology.

Turn Indirect Profit To Direct Revenue
If you're selling anything commercial having to do with an open source product, I think you'll find that a significant proportion of your most technically savvy users are ones who will never pay you anything. They're working at home; they're in academia; they're smart but working for a poor company; they come from a less developed country. They're a massive source of improvements and knowledge and they get passionate about what they're doing, but they're not going to pay you. But they're a pretty good reason why you'll eventually get revenue from other people: they may go work for a bigger/richer company, or one which prefers Buy in Build-vs-Buy; they talk with the world constantly about what they're doing; they speak at conferences and write books and make your platform far more compelling than it otherwise would be. And so if you want to be successful, you view supporting them and interacting with them as indirectly profitable: no revenue comes from it, but it increases the profit potential of your ecosystem dramatically.

So where's the relevance with Atlassian here? They're not open source. They sell software. How have they leveraged these principles to end up with Laura wasting her time meeting with me?

• They give away licenses all the time. You're open source? Free license (this is how I originally found out about Jira way back in the day). You're working for a non-profit? Free license. You just want to use it for your own personal stuff? Free license. This builds a passionate ecosystem and doesn't stop you extracting revenue from companies that will pay you.
  
• They work with open source programmers. They have a plug-in ecosystem that they actively nurture, and many of those people are doing it open source. Those same passionate people making their ecosystem more attractive and more conducive to extracting revenue from others.
• They engage their customers. Laura knew I'd blog about at least part of what we talked about (that's how she found me in the first place). That increases the sum knowledge that the world has about Atlassian products, and makes for free marketing.
• They differentiate their customers. Some customers are a lot of dumb money, and some customers are a small amount of smart money. I'd like to think my firm is more of the latter, given the amount of time we devote to trying in any way to help make the products we use better.

If you're familiar with the classical Tactical/Strategic Sale quadrant, there are a whole host of people who are so tactically worthless sales wise that they're going to give you nothing. But strategically they're useful. Pursue them.

If you're a technology company and you're trying to play the old closed-information game, the every-interaction-must-be-profitable game, the "no you can't have the manuals unless you're a customer" game, the "no you can't download our whitepapers from a gmail.com email address" game, you're losing out a lot. Engage people who are only indirectly profitable and you'll find more that are directly profitable.

More on Open Source Cookie Delivery

Matthew Aslett did a write-up where he's starting to call what I called Split Licensing "Open Core Licensing" (which by the way, I think is a little silly, because this whole "core" thing in enterprise software makes me think of multi-core per-processor discounts, so it's yet another suitably overloaded word, but that's neither here nor there), and did a shout out to my previous article on open source business strategies.

One thing that he mentions is that it's difficult to figure out what the cookie should be. I don't think it's that particularly hard if you come from a traditional marketing background: it's all about market segmentation. (non-Joel-specific writeup from the Borgmind here). The only distinction here is that many (if not most) of your customers in an Open Source context aren't actually paying you anything, so essentially you have "customers" who pay you nothing, and you're trying to convert them to give you some money. Any money. For anything.

So what should the cookie be?

I recommend starting from the position that there are two user bases:

• Users who will never give you a single penny, no matter what you do for them, under any circumstances. This is the vast majority of all open source users, and you just have to accept that they are who they are, and that they provide community and network benefits that are extremely valuable to the project over time.
• Users who might give you some money iff you had the right cookie.

It may look like we're no closer to figuring out what the cookie is, but we're closer than you might think. What does the second group look like?

I would posit that they're people who have money to spend on IT, and aren't running a shoestring budget (the shoestring group aren't going to be paying you for anything if they can get away with Open Source + Google for support).

I would also posit that they are usually either dumb enough that they're going to pay for support and "insurance" [sic] (gag me) no matter what just because That's What They Do, or they're intelligent enough that they won't. If they won't, I would also posit that they're more technically advanced than the first group, and thus are working with more advanced technologies than the former, either because they face problems that require them to, or because they are just smart people who like to work with that type of stuff.

I would finally posit that anybody who claims that they have an ideological reason why they would never run non-Free software is a complete red herring: they don't exist in the Real World, and by the Real World, I mean the world of people who might ever pay you for anything, and they usually smell. (Seriously. You ever met RMS? Dude: Body wash may not be Libre, but instructions to make Soap are public domain, and no matter what, both are bloody cheap. Buy some. And then use it. Particularly if you want to have passionate awareness of a woman.)

There's a reason why Financial Services firms were always the holy grail of early adopters in Silicon Valley: they tend to fit this profile. But there are other, nimble, advanced firms across the world who also fit it that aren't in financial services.

So how might you work all this together? I'd say that these firms usually are:

• Dealing with issues of scale. Big budget usually means big problems. That usually also implies some type of standardization, which usually means that if they go with your product, they're going to go for a single point POC, and then roll it out for a lot of stuff.
• Dealing with complex support and availability scenarios. Things Go Wrong == Job Loss. That implies a lot of work is going to go into management and support of anything they're doing, that the "heck, it's down, just bounce it" people aren't going to get involved in. Think JMX/SNMP, Active/Active, visualization.
  
• Dealing with advanced/expensive technologies. An example might be Infiniband for an enterprise software product. I'm sorry, but it's fringe and expensive and complex enough that the pure-shoestring peeps aren't going to have it (unless they're doing supercomputer stuff, but then the only real reason they have it is for their MPI implementation). GPGPUs are on the advanced side, in that they're still pretty fringe outside certain areas (although that's starting to change over time). RAMSANs and other esoteric high-performance storage systems are in there as well (as are anything having to do with a proper FC fabric bizarrely).
• Dealing with fringe platforms. You're not running on Linux on Intel/AMD? You're now in the realm of Stuff People Might Pay You For. AIX? HP-UX? Itanium? Solaris x86? Power Architecture? All stuff you're going to find in a lot of enterprises, and if you actually know what you're doing there (and just getting your code to compile doesn't really qualify you as knowing what you're actually doing), there's scope there.
• Dealing with compliance. You're in financial services or health care or government? You have compliance issues. Those compliance issues you will gladly pay someone to take off your hands. Zantaz integration? HIPAA certification? All scope for money.
  

So let's put it all together. Let's say you're a new AMQP company that wants to sell an AMQP broker. You produce a core product that's your basic AMQP engine. You then produce an Enterprise version that:

• Allows RDMA publication of messages in zero-copy mode over Infiniband;
• Working on Power architecture machines running AIX; and
• Blades with Cell processors; and
• Logs all messages to Zantaz optionally; and
• Has built-in configuration for dozens of similarly configured brokers; and
• Publishes alerts to my whacked out network management software; and
• Has built-in/native support for RAMSANs (as opposed to any arbitrarily fast FC-based storage pool); and
• Auto-configures itself into an N+1 redundancy configuration; and
• Provides feedback on application connections and use cases that are relatively slow with implementation-specific alternatives and suggestions.
  

(Note: Feature list only partially pull right out of my ass). You get the drift. For any type of software you can similarly come up with some type of list of features that is only ever really going to appeal to the group that might pay you money. Focus on the problems that only affect them (hint if you're in the business app and not infrastructure space: look at the compliance and retention and data protection stuff; the people who aren't going to pay you won't do it properly, but those of us who have to will gladly pay to make the problems disappear). There are a lot of them, and if you see someone complaining that a Free As In Beer product won't integrate automatically with their 7-Figure-Commercial-Software-Package, you can tell them to shove it. Seriously, that's just crass.

Now you've got the idea going on. Cookies galore.

Are there things in there that the non-fee-paying users might find useful? Sure. But you pack enough of them into one package and you've got something that starts to make logical sense between the Open Core version and the Pay Me Money version.

P.S. I take royalty payments in actual cookies. Seriously. Millie me up, yo.

Open Source Business Strategies

Or, Find A Way To Get My CTO To Pay You

A couple of months ago I was meeting with the CTO of a tech startup and one of his sales guys trying to sell me on their latest and greatest Silver Bullet (and yes, I'm going to post about it, but not for this particular entry). I had already done some background evaluation on the technology and the founding team (Silicon Valley is a remarkably small place, even 4 years divorced from it; I managed to get two opinions from two people who had worked directly with said CTO in a matter of hours), and had already kicked the tires a little bit. Not enough to sign up to use it in production, but enough to feel that it actually did something useful, and enough to warrant my actually doing some technical POCs.

So we went through quite a bit of technical detail, and the CTO and I got along well, because he was an actual technologist (and had written much of the code for their go-live technology), not just a marketing droid with a technical title. Good sign. The sales guy shut up, quite rightly realizing that his speaking would be counter-productive for this part of the sale for this type of company. Another good sign.

[I don't like dealing with sales people: I don't have signing authority, so I'm useless to them; they have no technical knowledge whatsoever, so they're useless to me. A good software sales guy, trying to sell to me, does nothing but sit there and make sure that nobody's saying the wrong thing at the wrong time.]

So then the sales guy pipes up. "Wow, sounds like you like this, why don't you write me a big cheque?"

Uhm, for what?

Look, the technology may be fundamentally radical, it may change the world, in the immortal words of JWZ, it might even get me laid, but you haven't convinced me to pay you a single pound yet.

"We're selling insurance. Surely you want insurance on your production systems, right? You wouldn't fail to insure your home, would you?"

Sorry, wrong analogy. We don't insure things like that. That's not how we roll.

[And for the record, you're not selling insurance. Insurance is a contract where, if your technology fails, you pay us a monstrous amount of money; that's called Indemnification, and you'll be lying if your lawyers haven't written in a clause against implicit or explicit Indemnification in your contracts. What you're selling is Pre-Paid Technology Phone Relations.]

My firm hires as near to super-star status as we can. Yes, I know many firms think that, but there's a lot of dreck getting by in software engineering in general, and in the city in particular. I don't think we have a 100% success factor (we don't; nobody does; if you think you do, you're wrong), but we do pretty well.

As part of that, if you support a production system, you support that system. That means that you have to understand the technologies that you're working with to a really low depth, enough to solve really tricky problems when they arise. Because the simple fact is that no matter how good your SLA is, getting someone to remote diagnose a problem over a telephone line during a production outage with traders yelling at you is impossible. From thorough, deep understanding of your technology stack and how it's rolled out, you can solve most problems far faster than you ever could if you just said, "I don't need to know how X works, if it goes wrong in production, I can just call the vendor and they'll hold my hand." I suppose you could do that if you suck, but I don't suck.

This means that support is mostly useful pre-production, and post-outage post-mortem. In the middle of the crisis, it's less than useless. If you can't fix it, you shouldn't be running it.

Plus, this intentionally limits the scope of technologies that you can reasonably roll out into our production environments. You want to use Technology X? First, you have to understand it well enough to know that if you're the only person using it, if it ever goes wrong, you get woken up. Doesn't matter where you are, what time it is, you get woken up. And then someone really yells at you. So now you have to convince at least one other senior technical staff member that this technology is so good that they should use it on their projects so that there's a bigger base of knowledge. Good luck.

So only the cream rises (mostly: we've ended up as well with a lot of "I have a hammer and only a hammer, so I'm gonna hit stuff" syndrome; we also miss out on some really exceptional technologies because if I get to add a screwdriver, you get to add an adze, and Bob over there gets to add a hack saw, and pretty soon we all wish we just had hammers again).

Anyway, back to the vendor.

I explain this to them, and say, "look, I come from an open source background. Heck, I even founded an open source company [IP locked in purgatory forever, don't bother looking for it]; I believe in the tragedy of the commons. But I'm not signing contracts. I make technical recommendations. My CTO signs contracts. Give me something to go to him with other than charity, which is what a production support agreement fundamentally is." They really didn't have a good answer for that at the time.

And that's the thing. Assume I were to go to him; he's a smart guy (which is why he shits more than my salary). Imaginary Conversation:
Kirk: "Here's a really cool Open Source technology. Let's give the authors money."
CTO: "Why?"
Kirk: "Tragedy of the Commons, yo!"
CTO: "Huh? Dude, quit being a commie. We're heartless financial bastards here."
Kirk: "Uhm, the tragedy of the commons is at its heart one of the most positively capitalist fables ever, particularly since it speaks of the result of costless negative externalities..."
CTO: "Save it for the economists. You're a geek. Why should I sign a cheque?" [Ed. Note: he speaks in Bri'ish, notwithstanding his use of the Californism "dude"]
Kirk: "Uhm, insurance?"
CTO: "I pay you far more than you're worth if you + source code can't figure out a production outage faster than some support muppet on the phone can."
Kirk: "Righto. Please allow me to exit before you question the size of my next bonus."

So here's the deal. Let's say you're an open source company, and you're trying to figure out how to sell yourself to me in the Money (rather than the "hey, Kirk, try out Technology X") way. What you have to do is give me something tangible iff I give you money. It's just that simple. Split licensing doesn't work for us (and don't give me any crap about how there are multiple companies in any financial services organization and tech crossing financial boundaries and blah blah blah; it gets old for anything other than the most insane organizations). Support doesn't work for us.

Give me a cookie.

Seriously. Give me something I only get if I pay you.

[And, seriously, give me a cookie. I really like cookies. Millies down at Liverpool Street station are my favorite, but you can also go to Bens in Leadenhall Market. Some of my less American coworkers like them, but they're like muffintops and not cookies. Next vendor to meet me with a couple of packs of Millies Cookies gets massive props.]

It might be development tools (which I'm not going to use anyway, but I can pitch to grads or somebody who cares about that stuff). It might be support tools (which I really really like; see note above that our technologists also do a lot of support). It might be domain-specific functionality relating to the Insane Technology Stack I have to run at work and optimizations for that. Heck, figure out how to leverage GPGPUs or Infiniband or whatever. Just find something that I'm going to have to pay you for, and make sure it's of merit to me. Then sell me that with my support contract.

Now, you're not going to get the sale first-off, because now it's going to run like this:
Kirk: "Here's a really cool technology. Let's give them money.
CTO: "Why?"
Kirk: "Support, and they give us Really Cool Stuff if we pay them. I mean, we can use them no matter what, but Really Cool Stuff is really cool and I'd like it. Plus, the vendor gave the whole FOTech team cookies, so I'm going to pimp whatever they're selling."
CTO: "Use it in anger first, then tell me if you still like it. Don't talk to me until you've had your first production crisis with it and still like it after that."
Kirk: "Yessir, I'm off to code!"

See? There's the option for a sale. You ain't getting it day-one (it's a long sales process), but by the time we're ready for the sale, we're already in production with multiple projects. You can't even possibly hope for a better qualified lead than that. And if you can't convert someone with multiple production systems relying on your technology, then you're hopeless, and as an organization you should die, and thank Jebus you're Open Source.

[By Production Crisis I mean some production crisis, and that may not mean full loss of service, which is touching your technology. In that event, you're either causing it (at which point you're out the door most likely), or you're helping deal with it, or you're neutral. But I need to know what you're like to work with as a technology when traders are yelling, and they're only yelling when things are down or sub-optimal, and you can never simulate that kind of adrenaline rush.]

Oh, yeah, and we still haven't covered out a Collaborative Negotiating Environment (our CTO is notorious for getting everything we want for much less than the software company wants to sell it for; this is rubbish and useless in an Open Source environment, and I don't have a solution to this yet).