Tuesday, July 22, 2008

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).
blog comments powered by Disqus
blog comments powered by Disqus