Posted on 13 Comments

Does “Dual Licensing” have a scaling issue/ceiling?

I was reading Colin Charles’ write-up of Does Open Source need to be “Organic”? (with Brian Aker, Rob Lanphier, Stephen O’Grady, Theodore Ts’o). I’ve been thinking about this a bit, and I’m going to put out a hypohesis here…. see what you think:

I think that overall, dual licensing as a large scale business model has failed. So, this is about either selling non-GPL licenses for certain uses, or having a “professional/enterprise” version of a product which contains more feature, one way or another. On a small scale, it has worked very well, and for decades. Think of shareware with extras for registered users. I used to run my business in The Netherlands along those lines for some products, and it was doing just fine, for years. But it was a “small” operation, not a huge growth business.

Mind you, “small” is relative. I’ll explain. For instance, Andrew Milner long ago wrote BBS software called RemoteAccess. It was hugely successful in the FidoNet world in the late 80s, and young Andrew made a bundle. He settled back in his native Australia, finished uni, started an ISP which he later sold to iiNet; look up the board there, he’s a bit older now and (iirc) a director there. So, plenty of money and success. But still, his RemoteAccess software business was a small operation, not a big company.

I think that there’s might be a ceiling to the viability of the dual licensing model. One reason might be that beyond a certain size, there’s generally more non-developer overhead in a business (sales, admin, etc) which changes the cost structure and therefore the revenue/growth need of the organisation. The bigger you are, the more hungry. These days you can use new marketing techniques effectively, have highly automated online sales and self-service (forums, etc), but again that means that in terms of manpower your company is smaller. So with small I primarily mean in terms of number of non-developer personnel, not financial size as such.

A related issue is that a more money-hungry business with sales people, they need to go after bigger fish. Bigger fish have different demands, so the roadmap gets tweaked in that direction. And the price of features rises accordingly or in any case the overall offering. That’s where the business model becomes incompatible with the marketplace, because the open source marketplace simply does not tolerate high prices. The natural pressure for pricing is downward (yes, towards zero and getting quite close, relatively). It’s ok to charge a bit, but not too much. It mustn’t appear greedy. Otherwise it’s a more difficult sell, which takes additional effort (and for that you need a sales person). Simple compelling offers really do sell themselves.

So, working our way back now, I’m suggestion that once you create a structure that needs a large non-development aparatus (particularly a sales organisation), you will no longer be able to operate (effectively) in the Open Source marketplace. The company will through these actions (not necessarily by choice) alienate itself from that environment. It really becomes incompatible. See this as an similar situation to The Innovator’s Dilemma where dilemma disruptors float upward in their market space until another disruptor pops up. The original company can live on quite succesfully in many cases, but they cannot operate downwards. Their cost structure doesn’t allow it, their management will naturally make decisions that prevent exerting energy in that direction. The simplest example of this is that if you have a sales person with a $1mln sales target, that sales person is not going to talk to a $1k customer, or even a $10k customer. He or she will be chasing the $100k customers, because otherwise there’s just no way they can reach the sales target at the end of the period.

By the way, this “greed” doesn’t scale on the client side either. The vendor will have to charge based on some arbitrary invented scale of “size” of the customer, so that a “bigger” customer has to pay more. With MySQL, which charges per server per year, this fails fundamentally because a large deployment with lots of servers does not mean the business is big, right? And even if the operation using MySQL is part of a big enterprise company, the division responsible for MySQL is commonly very small and will not have a large budget. So at least in the case of MySQL, the invented methodology for scaling the pricing is fundamentally flawed and thus has failed.
Similarly, others at OSCON (I’m not there this year, unfortunately, just tracking the blogs and talking with people!) have observed that non-OSS licensing does not work in a cloud or other rapid deployment environment. You simply cannot afford to even worry about the licensing, so anything not absolutely free (cost) at the basic deployment level cannot be used. In that realm, you cannot charge based on deployment “size”. It’s impossible.

So what’s the alternative? Well, first of all, I could be completely wrong. Who knows!
But if I’m on a reasonable track here… I already described a possible alternative trajectory above, namely structuring the business differently as it grows; by making use of new technologies, reducing the need for expensive people and thus not gaining the critical mass of overhead. Actually, writing about it this way gives me an idea; perhaps it’s possible to, using data from past and existing companies, derive a critical ratio nondeveloper:developer beyond which companies tend to not be able to make the dual licensing or shareware models work?

Another part of that alternative is of course to not do dual licensing at all, but wholly focus on services. This has a very important advantage, and a very serious challenge to it.

  • The advantage is that the company has no leverage over the customer, and this creates an opportunity for a genuine trust relationship based on equality. If you have trust (or rather, no intrinsic mistrust), this makes a potential sale easier. So the viable pricerange might actually lie a bit higher in this case (contrarily, in a condition of less trust, you have to charge less; with no trust or active mistrust, the acceptable pricepoint is truly 0 or perhaps even negative; but you don’t want to pay your customers to make them use your stuff now do you 😉
  • The challenge is that the company has no leverage over the customer (sounds familiar? ;-), so it must have a compelling offering that provides true value for the customer and not just for the company. Otherwise alternatives will have an excellent opportunity for competition.

Of course there’s the usual factors of marketshare, mindshare, level of annoyance with an existing vendor before customer actively consider switching, and so on. But fundamentally, it will be about true customer service, on an ongoing basis. KEEP the customer satisfied.

Posted on 13 Comments

13 thoughts on “Does “Dual Licensing” have a scaling issue/ceiling?

  1. So what do you suggest:

    1. That MySQL not provide OEMs with a proprietary version but instead forces them to use the same version as Community Edition or Enterprise customers and release their proprietary code under the GPL? Or more likely, push them to go elsewhere?

    2. That MySQL stops providing GPL Community Edition and GPL Enterprise and makes them both proprietary, becoming a closed source company?

    I’m not keen on removing either of those licenses.

    Your premise about bigger paying more is not great either: Enterprise Unlimited is a major discount for large customers who want support. Got ten thousand servers? Or two hundred? Have a look at that Enterprise Unlimited pricing. Then laugh at the prices some database companies charge.

    Keeping the customer satisfied matters a great deal. Have a look at the testimonials from MySQL Enterprise customers. Those using the Community Edition benefit from this as well, partly because that support team is doing the bug verification work and partly because the support team is busily suggesting documentation improvements, feature changes and bug priorities based on what is actually causing people trouble.

    Did you know that MySQL’s support team now sees almost no MyISAM corruption problems except those after crashes or user error? That’s because the support team went on a hunt to find the remaining bugs so they could be fixed. Statement-based replication is similar: problems involving bugs are now rare unless people are using old versions. The Community Edition users get those benefits… courtesy of the Community/Enterprise split that has helped to pay for the extra support team members and developers to get these things fixed.

    The Community/Enterprise split is going to be controversial as long as it’s around but it’s been doing a great job of paying the bills so the server gets improved for all of the people who use it.

  2. This is Mark C:

    The comment about licensing on the cloud was not that non-OSS doesn’t work it was that inflexible licensing doesn’t work. The commenter works for RightScale which sells software that manages servers on AWS. I don’t think they are OSS. I don’t mind. AWS makes it very easy to sell non-OSS. I can put up an AMI there and charge others who want to use it.

    I think it is good for customers that Enterprise is building glue that makes it easier to manage and monitor servers. I think they have a long way to go and will get a lot of competition from Maatkit and others. Enterprise will require hooks in the server to get more data, and those hooks will benefit all of us. I would like some of those hooks to be the SHOW USER_STATISTICS, SHOW TABLE_STATISTICS and SHOW INDEX_STATISTICS commands from the Google patch.

  3. James, this is Mark C

    I want everyone using the same branch. Publish the source for all and the binaries for Enterprise. I want the community to find bugs in a version before I try it.

    If the community is good enough to debug 5.1 (there was a public call for help) and good enough to provide use cases for 5.1 (there was another public call for that) then they should be good enough to get the same branches.

  4. James, support does some great things. But that has nothing to do with sales. In fact I would suggest that mysql support would sell more support to more people if it didn’t have a borked pricing model and a sales apparatus around it.

    Yes, I think that indeed the course of action would be (for instance) one of the options you describe.

    MarkC made the relevant points on the MySQL Enterprise split and how that actually affects the overall code quality. In addition, I’d make more bugreports and if I thought it would actually be useful. I’m still tracking bugs from my time at MySQL, and they’re still not fixed. It’s largely a wasted effort. I’ve got more productive things to do.

    Regarding MySQL Enterprise “Unlimited”, you are just plain wrong. First of all, like I said, some seemingly large MySQL deployments do not actually have a big company (or company with a MySQL section with a big budget) behind them.
    Secondly, the unlimited offering is introductory bait. It’s only for the first few years, then it clicks over into the regular pricing. So you cannot possibly claim that it’s a fabulous offering *over time*.

    Regarding dual licensing sales; note that one MySQL sales person some months ago actually sold a license for writing a proprietary client library.
    On what legal basis, you may wonder? We both know there was none.
    MySQL sales people will sell anything to anyone, just to make their sales target. Marketing and Community are well aware of this, yet choose to turn a blind eye in the form of “sales needs freedom to operate”.
    This is where your salary comes from, this way of operating is what is providing those lovely profits.

  5. Yep sorry I think I took a shortcut there.
    I was projecting that comment specifically onto the MySQL way of scaling its enterprise (support) offering (and in some cases licensing): per installation.

    Indeed, the tooling is inadequate. There’s now the query analyser thing that Rob Young just announced; but it doesn’t solve the auditing/logging problem inside the server, instead it’s external enterprise-only stuff. It just serves a few users and, of course, MySQL itself 😉

  6. Yes, I agree that that is the way that will produce the lowest chance of surprises for those with production systems, particularly a reduction in the risk of bugs introduced by bug fixes.

    I’ve been trying to find ways to get more of the community testing benefit without trying to completely change the current model. There are some things that might be done, like releasing Community Edition binaries of the version that will be the base version of the next Enterprise Quarterly Service Pack, so that would get a few months of broader use. Same for quarterly Enterprise source releases. Neither is perfect but each would be a bit better than the current situation for those who put stability first.

    On the sales side, many of the constraints do seem to be needed to generate the revenue to pay for the development work and there’s still a large backlog of lower severity bugs to fix that accumulated during 4.0, 4.1 and 5.0 development. So I’m expecting it to be a while yet before MySQL can get back to being as fast with development as it needs to be long term. That’s a short or medium term opportunity for community-based forks to establish a place, before MySQL incorporates everything of broad use. Lots of good things coming from you and other community people but they introduce an ethical conflict of resources: the obligation to fix the bug backlog while also trying get in the most useful outside contributions. So we’re currently being very selective about what we include.

    20% time would be of value here, since developers work time is currently constrained by the bug obligations. So even if they want to do it, work time can’t generally be used for integrating community features. My guess is that just about everyone in the support team wants those features – I do – but support also has to deal with the people who want the bug fixes so it’s an interesting problem for us.

    If I didn’t know that developers have to be paid I’d easily agree with you and Arjen. But they do, so I can’t just 100% agree, I have to listen to the sales side as well.

  7. MarkC is right about short term code quality: more users will find bugs faster. I’m not so sure that he’s right about medium term code quality because that takes paying more developers. Or a more radical development model change. MySQL is also doing some things along the development model side but it’ll be a while before we see how those do.

    You’re right that Enterprise Unlimited published pricing has time limits. There’s still nothing to prevent potential customers asking for a deal that saves them money compared to what they could get elsewhere. It’s very likely that MySQL can do that. Someone with 10,000 servers running one application is likely to get a better price than someone with 10,000 servers and 10,000 applications just because the second case is likely to involve much more work.

    The customer with the client library license bought something of significant value: certainty. I assume that they thought that was worthwhile to them. MySQL Enterprise offers an option to buy indemnification from source code risks and any Enterprise customer who doesn’t want a GPL license can ask for and get a commercial version of the MySQL server with a non-GPL license. Some customers want those options because they offer them more certainty; I’m happy enough to see them available regardless of what I think about the chance of the negative uncertainties happening.

    On a somewhat related note, personally I’m not keen on the arguments that some GPL proponents make that merely linking should create a derivative work. I look at how that would apply in the Windows world and see that most Windows programs end up as derivative works of Windows and that’s not a result that seems to be sensible. But that’s my personal view, others may differ and some may just want to buy insurance and forget about it.

  8. Sales has not actually made an empirically tested argument to you, have they?
    They merely state these “facts”, and for lack of will to try a different method, you just have to assume that they’re correct.
    However, the environment is not quite the same as others, and even in other existing markets it works differently.
    So basically, it’s about fear and scare-logic; the person more likely to lose their job is, in fact, the sales person, not the developer. The sales person is overhead for the developers, not the other way round 😉 And the sales person is driven by their quarterly goals. If they fail those, they lose their jobs. That doesn’t leave a whole lot of manouvering space, or incentive to experiment.

    But no worries in the long run, Sun has a different way of operating.

  9. This was before your time at MySQL, but MySQL used to have it right.
    Then, because of the venture capital investments, more sales was needed to generate the increased revenue and growth necessary to gain the size and growth numbers to either IPO or sell. There’s huge overhead in MySQL currently, with its salesforce and related admin.

    I’m rather bit disappointed with your “certainty” argument. It’s not a valid approach. However, it is the exact argument that MySQL sales uses. It’s FUD and it doesn’t belong in this business.
    The argument would mean that through the HTTP protocol, Apache links with Internet Explorer. Go on, pull the other one, will you?
    Certainty? BAH!

  10. The MySQL sales and marketing people I’ve met seem entirely capable, so I do accept that they are asking for what they find successful.

    It’ll be interesting to watch what the Sun and MySQL mixture does.

  11. I don’t know MySQL or Sun’s current view on whether simply implementing the protocol would require a license and since I don’t know it I can’t give it. Kaj, David or Zack would be better people to ask than me.

    It’s tough for me to comment on that specific case because I just don’t know the facts. If they don’t think that what they got was reasonable do feel free to give them my email address and I’ll ask one of the sales managers to get them to take a look. For all I know they got development help and other services as part of the deal and I expect that if they did you’d find that reasonable enough.

  12. The appropriate people have been talked to. If I ever hear about any such deal again there’ll be trouble.
    This falls under what Kaj used to call the freedom that a salesperson needs to have to make deals. I call it deception.

    Apart from the basic “needing a license” for this is bollocks, it’s too close to a line that MySQL should not ever have started to walk and even less cross.
    This is one of the things that have cost MySQL a lot of respect in the community, and in fact also users. People do like clarity, not deceptive blah. In some cases, that has meant people choosing for instance PostgreSQL. That’s fine in itself, except that you do have to consider that all other things being equal they would’ve chosen MySQL. So it was the licensing fuzz that flipped the decision.

  13. What’s your measure for ‘capable’? High(er) revenues? Sorry, I’d disagree with equating those, the two have no intrinsic connection.

    I appreciate I’m just guessing at the measure here and don’t meant to put words in your mouth – so if you have another measure, please tell. Thanks

Comments are closed.