Ivan Ristić

The death of dual-licensing as a commercial open source strategy

We are witnessing an interesting development: an alliance is being formed to execute a hostile take-over of a successful open source project. Yes, I am talking about MySQL. From the press release:

"Our goal with the Open Database Alliance is to provide a central clearinghouse for MySQL development, to encourage a true open development environment with community participation, and to ensure that MySQL code remains extremely high quality," noted Monty. "Participating members at this stage in the 'Alliance' will have a strong voice in how the organization is structured, and we look forward to collaborating with anyone in the industry that provides or depends on MySQL."

Dual-licensing has been a favourite commercial open source strategy for many, but what we are seeing now may be signalling the end of its popularity. The conventional wisdom, until now, was that people would not fork an open source project for as long its (commercial) owner did a decent job at maintaining it. Now we see that, once a project reaches a certain level of popularity, and the right mix of commercial and personal interests exists, the fork happens anyway. The community takes over, abandoning the project's commercial "host" and moving the code into a new phase of development.

One must not forget, on the other hand, that this is not the first time MySQL had been forked, but that you did not hear about those other forks simply because they were small in scope and generally uninteresting to a wider audience. They did not endanger the project. This time, with one of MySQL's founders participating in the forking effort, there is a real possibility that the fork starts to be perceived as the main development branch.

How did MySQL become so successful?

We often talk about business models, technology, open source and other similar topics that are unavoidable for anyone interested in starting a business today, but we sometimes forget the real reason why products become wildly successful. It's actually rather simple:

1. You have to have something that people really need.
2. You have to essentially be the only choice on the market.

Get those two things right, and everything else will follow. MySQL was there, in the right place and at the right time, to fill a critical gap that existed back in the early days of the Web: everyone needed a lightweight database engine that could be used to power Web sites. The fact that MySQL was not open source¹ did not matter, and neither did the fact that MySQL lacked many of the features needed to be a proper database². The features MySQL did have were right for the job and so people used it.

---

Footnotes:

1. MySQL was initially free for end-users, but you had to pay for redistribution; ISPs were in a grey zone.
2. The message from MySQL was, rather amusingly, that only wimps needed transactions (paraphrasing).

Security is difficult; open source security sometimes even more so

I have prepared a presentation on Open Source security for the Open Source Specialist Group of British Computer Society (BCS OSSG):

• A_Look_at_Open_Source_Security  (PDF)

The main aim of the presentation is to give an overview of the current state of security in open source projects. I discuss why security is difficult (hint: it's because few people care), and why security in open source is sometimes even more difficult. At the end, I give a simple 3-point strategy for quick evaluation of the security posture of open source projects.

Signing the ModSecurity Contribution Agreement

Two months after leaving it, I went back: I signed the ModSecurity Contribution Agreement. If you read my blog post on open source dual licensing from a few days ago, the one where I explain how it is difficult to get user contributions to a dual-licensed open source project, you may wonder if I had told the truth. I had. I had said it was difficult to get contributions, but not impossible.

This is an interesting position for me to be in because I used to be on the other side, explaining to others why dual-licensing should not be a barrier to their contributing. It's only fair that I sign on the dotted line, isn't it? But—with the discussion on dual licensing in mind—why did I do it? It all comes down to motivation.

When you have big ideas it makes sense to start your own project, work hard, and benefit from your work. But when your ideas are not of the new-project sort, and generally not worth changing your life for, then the best thing to do is share your ideas (in the form of a code contribution) to a well-established project. By doing that you scratch your itch and get other people to benefit from your work.

And I don't feel bad about giving my time and code to Breach Security (who owns ModSecurity). Not in the slightest. After all, many man-years have been invested in ModSecurity. What do you think my contributions are going to be worth compared to what has already been given away to me?

A taxonomy of open source business models

If you liked my previous post, where I shared my experience with the use of dual licensing in open source, you'll love the taxonomy of open source business models that was recently published by Conecta (via 451 CAOS Theory) .

Dual-licensing for open source businesses

When I started to build a business around ModSecurity, back in 2004, I chose to keep complete ownership of the ModSecurity code base.  This business model is better known as dual-licensing. Keeping ownership of the code has the following advantages:

1. The product becomes (or remains) an asset; it increases the value of your business.
2. You can license the product under a different licence. For example, you can sell a version under a closed-source licence to the companies who are not fond of (or familiar with) open source licences. Similarly, you can sell OEM licences, which may be quite an interesting possibility, depending on the type of product you have.
3. Finally, you can bundle your open source product with another closed-source component and release the whole as a commercial closed-source product. This is quite a common strategy today.

Dual-licensing only makes sense when combined a viral licence such a GPLv2, in which case it helps you make your software freely available to your users, simultaneously creating a shield to guard you from your competitors—with only the open source licence to work with, the only way for them to benefit from your code is to embrace open source (which seldom happens).

As you can see, the advantages are many. But they are not free.

In return for the above benefits, you create a community of users rather than of a community of users and developers. The people interested in joining an open source project will largely do so for the reasons of passion, but the asymmetrical relationship of dual-licensed projects often stands in the way. Not only they have to justify giving you something (code rights) for nothing, but they can never hope to truly become part of the development team.

End result? You may end up with no contributors at all.

On the other hand, if you give everything away for free, you may find it difficult to pay for further development.

I spent months and years thinking about the above conundrum, and ended up believing that dual-licensing is an acceptable compromise and a viable business approach. At the end of the day, the approach probably won't give you that warm and fuzzy feeling only the participation in the open source community can, but, if successful, your project will be made available to everyone for free and it will pay you salary to keep on doing what you love.

Is that open source project secure (enough)?

Type the words "open source security" into a search engine and you will get dozens of links to articles, blog posts, emails, forum messages, and research papers. You can try to read them all, but I don't think you should bother. The opinions mostly fall under one of the following categories:

1. Having access to source code is better than not having access to source code.
2. Community-produced software is better than vendor-produced software.
3. The freedom to modify source code is a fundamental right of every software user.
4. Open source developers are careless, disorganised and fickle.
5. Commercial vendors only care about money.
6. Who are you going to blame when an open source product fails?
7. Open source is dangerous, but you can pay us to help you deal with it.

Most of these claims have a grain of truth in them, but they almost always miss the point in trying to distil complex realities into simple convenient truths. That just doesn't work. The simple truth is that every single project is unique, and must be observed on its own merits. But therein lies the difficulty: how do you determine if a given software product is secure?

I know the proper answer: design an assessment methodology (or use one that already exists—the Software Assurance Maturity Model is nearing completion; Building Security In Maturity Model is expected in a week or so), then use it to make informed decisions. While this approach is suitable for academia, it is too inefficient in real life, where you need to make your decisions quickly and effectively. So what do you do?

Did I mention that I spent almost 6 years of my life working on a fairly popular open source project? In that time I struggled to use my limited resources to do what's best for the project, security being only one of my concerns. I did reasonably well, but made many mistakes along the way. That experience (along with a similar experience in developing closed-source software) has given me an insight into what makes software developers tick and, especially, what makes open source software tick.

So I came up with an idea to avoid measuring the quality of code itself (because that's too difficult and time consuming), instead focusing on the external manifestations of good and bad practices. I call it a Project Security Posture Review. A review might focuses on the following aspects:

1. Does the organisation follow good software development practices?
2. How are security issues handled?
3. Are there any public-facing services available (e.g. source code repository, issue tracking, wiki, etc.)?
4. Is the source code tidy?
5. Is the project mature and popular?
6. Does the project have a reputation for quality?

The idea is that you can answer most of the questions by simply looking at the project's web site, browsing through its code and documentation, and looking at the experiences of other people with it. The obvious advantage of this approach is that it is quick, even though it may be somewhat inaccurate.

If you think the above list is, well, vague—you are absolutely right. I am currently working on a comprehensive list, which I will present during the Open Source Security talk for the Open Source Specialist Group (OSSG) on March 30th.

Update (March 5th): BSSIM is available at http://bsi-mm.com.

Open Source lesson: SpringSource falling from grace

I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am sure it has bugs, but I am yet to encounter one). The licence, Apache Software License version 2, was right too. I had even been a step away from joining the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.

Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) deciding small and focused is not beautiful after all. In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.

Then, the inevitable happened. The success of Spring became too tempting. Interface21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company in good standing with the community.

My fear, when I heard the news of funding, was the same as Corby's (from the post at InfoQ):

If anyone had the ability to grow organically, I thought Interface21 did. VC don't give you money unless they're going to grow you 20X. I am very concerned about seeing an explosion of Spring subprojects that lack the quality or the relevance of Spring core. And VC don't give you money unless you're going to cash out. I don't see Interface21 operating as a standalone IPO, so that means they will be actively seeking acquisition. I hate to see one of the big guys get ahold of this very independent entity. I wish the Interface21 folks great financial success, but I hope Spring does not turn into a bloated, slow-release monster. I have already heard rumors that Benchmark Capital is pressuring Rod Johnson to change his name to something more kid-friendly.

Things started to go wrong after SpringSource decided to experiment with their licensing choices. They introduced a number of proprietary products and started using other open source licences. Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL essentially allows businesses to retain control of the code base.) The changes made many members of the community feel insecure, and lead to heated exchanges on the forums. Prior to the changes the company was often called a darling of Open Source (it sounds like something I would have said), because they were a rare example of a business (the Interface21 consultancy) built around the restriction-less Apache Software Licence. I can only conclude that, under the changed circumstances, their business was not growing fast enough, and that they felt that they needed to do things differently.

This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts—today—but do you trust them they will continue to do so? SpringSource are saying they are on the same path they have always been. Maybe they believe it, but they are not on the same path, and the users see it. SpringSource are saying they will keep the Spring Framework alive and open source. I actually believe they are being honest when they say that. But I also know that people come and go and that, eventually, the prosperity of the company may matter more at some point in the future. There is no doubt that Rod Johnson cares deeply about the project, but there is also no doubt the VC company behind the funding cares only about the money.

Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It's the change of direction that's making everyone nervous. For many people open source is about freedom and certainty. They don't want to have vendors to depend on. They've chosen to work with Spring Framework on the basis it's vendor-free. So it's not surprising that they are starting to feel twitchy now that they've realised the company behind their favourite project is a vendor too. If SpringSource want to preserve their hard-earned credibility they need to act fast to insulate themselves from the core Spring Framework project. It's certainly a tough thing to do (convincing the VCs, I mean), but it's the only thing that would bring the user trust back and preserve the developer community (as in those developing the framework itself).

Ultimately, it may not matter. Spring Framework has already built a momentum. It is a very good product, so there is no reason to not use it. But there's no help but feel a bit cheated. We are never going to have the same warm feeling about Spring, as we did back in the old days.

No such thing as Open Source business model

I started my open source project, ModSecurity, back in 2002. It was initially just a hobby, something I did in my spare time. ModSecurity grew in popularity, so in 2004 I decided to form a business around it. Thinking Stone was born. I sold Thinking Stone to Breach Security in 2006, and that was the end of my first start-up. (But not the end of ModSecurity, which continues to flourish.)

I will freely admit that I didn't have a business plan. I knew instinctively that the product was good, and I generally focused on improving the product while supporting the growing user base. Everything else I let happen organically. This "strategy" worked out all right in my case, but, in retrospective, I should have invested more effort into commercialising the user base. My luck could have went the other way just as well.

In researching how Open Source relates to business today, I've discovered a very peculiar fact: there is no such thing as an Open Source business model. There are a few companies promoting themselves as open source, but if you dig deeper you uncover that, if they are making any money, it is coming from the proprietary bits, not from open source. If there are any companies making money today from supporting their open source products, chances are they are just in a transient phase moving away from that model because there's essentially no money in it.

A typical lifecycle of an open source company looks like this:

1. Build a product people want to use. Make it free and open source, because you want to grow the user base as quickly as possible.
2. Perfect lead generation and nurturing, which is the key skill you need to have in order to be able to convert users into customers.
3. Sell training and support, because that's easy to start with.
4. Sell subscriptions, because support does not scale well and is just not sticky enough.
5. Create proprietary versions/add-ons/tools, because everything else you did so far failed to make you any real money.

It seems to me that companies are now open sourcing products because it's an effective distribution strategy, and also because they have to—everyone else is doing it. However, because there's no money in true open source, they end up selling proprietary versions, and we (the consumers) are essentially back where we were prior to the open source revolution.

Open Source wants to ruin my life

One of the side effects of Open Source is that it effectively pushes the cost of software down to zero. You can argue that I can charge whatever I want for the software I license as open source, but that argument doesn't work very well. For as long as my licensees have the right to distribute my product free of charge, an informed market is not going to want to pay to get it. Open Source seems to be very good at preserving the rights of users, but not any good at preserving the rights of authors.

I can cheat, as many companies do these days, scaring people with words such as warranty, indemnification and support. I can also repackage my product as a subscription, which seems to work for some companies. But that just wouldn't feel right. It's essentially doing the same thing as before, just calling it something else. Furthermore, doing business this way creates an incentive to make the software just good enough to attract the user base, but not really solid to enable them to use it without my help. Other companies prefer to leave the critical piece out of the open source package for the same reason.

While I can do all these other things—I do not want to. It is just not the life I want to lead. You see, I believe in one's right to make a living by doing what they love. I love writing software and I am good at it—it's only natural to expect to be able to write (and sell) software for a living.

But Open Source wouldn't let me have none of that. I am condemned to a life of compromise instead.