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.