 Hello, I'm Heather Meeker. I'm glad to be speaking to you today on the topic of from project to profit, business models for startups developing open source software. I'm a lawyer in private practice and a venture capitalist. And in both of those roles, I focus on helping companies succeed by developing open source software. My venture fund is called Open Source Software Capital or OSSC, and we invest exclusively in early stage startups developing open source software. My law firm is called O'Malvony and Myers, and it's an international law firm where I lead the technology licensing practice. I've been working in the area of open source software licensing for over 20 years. I started as a programmer in the early 1980s, so I've been in the tech business a long time, and I've been working for my entire legal career in Silicon Valley. I'm speaking to you today from Oakland, California, and I've prerecorded my talk, but I want to encourage you to follow up with any questions that you might have. I'd like to thank the Linux Foundation for inviting me to speak at Open Source Summit Japan 2020. At the end of my talk, I will provide some information on how to get a free electronic copy of my book, Open Source for Business, which is now in its third edition. That book is a handbook for engineers, business persons, and lawyers who want to learn more about open source software licensing. Also, in the long days of this pandemic, I have recorded and released on YouTube a series of narrated presentations on various open source software licensing topics that are aimed at people who are interested in using open source software in business and want to learn about it in bite-sized pieces. Now, let's get started and let's talk about the intersection between open source software development and business. When you talk about open source and business, it's easy to fall into a false dichotomy. Is open source a selfless collaboration or is it business? Of course it is both. Some open source projects are labors of love and truly selfless gifts to the world, but some of it is also business and that usually happens when developers who love open source want to combine their passions with their jobs. In fact, most commercial open source software businesses grow out of non-commercial projects, hobby projects, experimental work, or projects within companies who dedicate programmers to do open source R&D. So the line between the two is never entirely clear, but without doubt, some projects are primarily not for profit and some develop into the basis for a for-profit business. This presentation is about some of the licensing and legal considerations of moving from a project to a product and then to profit. In fact, the last few years have demonstrated without doubt that open source can be big business. It is also particularly vibrant during bad economic times. And while some of the dire economic predictions at the outset of the pandemic have not come to pass, our post-pandemic economy is certainly unusual and uncertain. Historically, lots of great open source projects are started when the programmers are between jobs, shoring up their resumes or reassessing their career choices, all of which happens a lot in times of economic upheaval. One element of good news today is that open source development has always been geographically dispersed and socially distanced. So it's likely that right now, some great open source software is being written. Though we may expect bright things in the future, open source is already today an important tool for business strategy. This index, which is called the Koski Index, and that stands for Commercial Open Source Software Company Index, is maintained by my partner JJ at OSS Capital. And it shows the top commercial open source businesses and notes their business models and the projects that they're based on. Here's the Koski on a slide. Now I know this is small and hard to see, but you can take a look and find it easily online if you search for C-O-S-S-C-I. This is maintained as a publicly available Google Sheets document. And as you'll see when you can look at it better, it lists the top companies that are commercial open source companies. And it says something about them such as notes on their business model and their valuation and how the valuation was come to. Also, when the company was created and when the project was created. This document's very interesting to see how the most successful open source companies and some of their characteristics. Now what is a commercial open source company? It's defined as a company that would not exist except for the existence of an open source project. For instance, Red Hat is based on Linux and Confluent is based on Kafka. And though they are very different companies, they are both commercial open source software companies. Particularly in 2018 and 2019, there were a lot of big exits in the open source space. And what we mean by exits is acquisitions and public offerings. As you can see some of these companies have extremely high valuations. So if you're interested in turning your open source project into a company, a commercial open source software company, how do you go about it? How do you get your company to be successful and get it on this list? I'm going to talk today about three topics that will help you get there. The first is, and it's the most important one, to know your business model. And with your business model, you'll have to understand your licensing model as well. The second topic is about branding and trademarks. And the third topic is a grab bag of subjects about how to get your project ready for prime time. Okay, first let's talk about business models and licensing models. We talk about them together because the licensing model serves the business model. In other words, you figure out what your business is going to look like and then you use the licenses as tools to get you where you want to be in terms of your business goals. The most important lesson for an emerging commercial open source company is, don't be the underpants gnomes. Now, if you are not a South Park fan, maybe you haven't seen this, but it's very funny. Trude lesson about planning. The gnomes steal people's underpants from bedroom cupboards at night. When they're asked why, the gnomes say that they have a three fades plan. Collect underpants is phase one, profit is phase three, but they can't explain the second phase in between. And of course, the whole thing makes no sense. Now, some open source companies tend to fall into this trap. Lots of stars or downloads on GitHub do not make a company. They make a project. It might be a great project, but to make a company, you need a product and you need people willing to buy it for money. For that, you need a business model. And this is mainly about defining what your product is. If I say product, I mean that in a very broad sense. A product could be software, hardware, services, really anything you want it to be, but it has to be something people will buy or you don't have a business model. So that's lesson one. Don't be the underpants gnomes. You need to have a business model or you won't have a company. With commercial open source businesses, there are a lot of variations on open source business models. Most of them are also variations on licensing models because the licenses are the tools you use to build a business. Also, a business and licensing model can change over time. What works in the early stages of your company may not scale and you may need to adapt to your circumstances over time. As you can see, there are a lot of examples and I'm going to go through each of the major examples so you'll get an idea of what these business models look like. But I'd like to say something about them overall. You have to be selling something and what you're selling is not the open source software by definition because open source licenses allow people to do things free of charge. So you have to have something that you're selling along with the open source software. Now, sometimes this is referred to in business as a razor blades model. And what that means is that you sell people the razor blades but you give them the razor. In other words, you're giving away something in order to sell something else. And this is one of the wonderful things about commercial open source companies. They create a great deal of value. They create a lot more value than they capture in their revenue. But you have to capture some revenue in order to have a company. So your job, figuring out your business model, is to figure out what's your razor and what are your razor blades? In other words, what are you giving away to the world and what are you selling? The first model we're going to talk about is the model of maintenance and support. Now, this is the most familiar model for a commercial open source company. When most people think of this model, they think of Red Hat, but it's probably more accurate to say that this model accounts for the most small or the newest commercial open source software companies. In this model, there is no licensed model other than the open source license. The commercial open source company offers maintenance and support services which are provided under a services contract. If you choose this model, it may be difficult for you to find capital. Any business that relies primarily on professional services is hard to scale because the costs of its main resource, which is people, increases as service sales increase. Such a business never achieves any meaningful economies of scale. So it works well if you want to self-finance or if you don't want to scale your business. For example, if you just want your business to basically provide you with an income, this model works really well. But one of the problems with this from a business perspective is that there are zero barriers to entry for your competitors because one of the objectives of open source software is no vendor lock-in. That means anyone can work at maintenance and support. In your business like this, your most crucial asset is people, preferably the people who are actively involved in maintaining the project. When I think of Red Hat, I actually think of a different model. I think more about quality control. My example here is the Pet Rock. Now, this is a joke, of course. It was a big fad for a joke gift in the 1970s. And yes, it was just a rock with eyes glued on to it. But think about this more carefully. Rocks are free of charge in nature, but the rocks used for this product were round and of a certain size. In fact, a bit of trivia. The official Pet Rocks were the smooth stones from Mexico's Rosarito Beach. And they were packaged up nicely with a box and a logo. They came with an instruction manual. Does that sound a little bit like support? What was actually being sold here was quality control and brand recognition. You weren't buying the rock. You were buying the fact that the rock was what you expected it to be. And that's kind of like the businesses of Red Hat and other companies that have a so-called pure open source model. Red Hat, of course, sells Linux, but it performs a great deal of quality control, particularly in building and packaging, in addition to support. Now, all of that business is executed via a support agreement. While Red Hat does not use any proprietary license, it has a very important piece of intellectual property and that is its trademark. That trademark represents the quality control of its products. In fact, all commercial open source companies need trademark protection and brand management and we'll talk about that more soon. But for this kind of model, quality insurance is actually most of what you are selling a customer. After all, they could get the open source software anywhere for free, but they're willing to pay for quality control. And that's very important. Another straight forward model for commercial open source software is online services. In this model, the company provides a hosted platform for its software. And while the software is separately available under an open source license, the business enters into service or software as a service or SaaS agreements. In this model, the business is selling the fact that it knows how to deploy the software at scale better than anyone else. The examples on this slide are GitHub and WordPress. These are two very different pieces of software, of course, and very different companies. GitHub makes available access to the GPL Git software and leverages the value of a ubiquitous platform. It's not only a place to manage software repositories, but functions as a kind of a proxy for a social media platform too. So one of the valuable things about it is that everybody's on GitHub. WordPress is the commercial deployment of the GPL WordPress software. It's business works because many of its users are small businesses or individuals who don't wanna bother to deploy their own instance of the famous blogging and website development software. In fact, I personally use this for my website because although I could set up an instance of WordPress for myself, I would rather have someone else do it for me. Again, in this model, there are few barriers to entry because anyone can deploy the software as a service and no open source license will prevent that. Companies like these are successful for different reasons. For example, with GitHub, it's successful because it has a critical mass of developers and it was an early mover in the business of providing online services using Git even though there are other companies also doing that. For WordPress, it's been successful mainly because it sells to small and medium businesses and individuals who don't want to set up the software on their own and also because it's leveraging the original developer of the software who actually owns the commercial company as well. And that anyone can deploy the software as a service and that no license will prevent that resulted in a lot of infrastructure development moving to an open core model a couple of years ago. We'll discuss a little bit more of that soon. Example of a business model in the pure services category is professional services. Some companies develop custom versions of open source software for their clients. For example, there are a lot of small development shops that do custom Linux development for embedded software deployment. But again, this model has the same scalability problems of any professional services business. It mostly depends on its human resources and those don't scale into economies of scale. Businesses in this category have come and gone over the years and there aren't very many that are very big mainly because of the scalability issues. Now we move on to the next variation which combines open source software not with services but with hardware. This has sometimes been called widget frosting. Examples of this model lie mostly in the IoT and embedded space. For example, Digium makes voice over IP systems running on the open source asterisk software and plenty of Android IoT OEMs make money selling devices that run primarily with open source software. As a corollary, many hardware manufacturers lay open Linux drivers for their peripheral devices but I wouldn't really call those open source businesses. Those are businesses where they're using open source as a tool to leverage sales but they're not really commercial open source software businesses. This kind of model where the company sells hardware and gives away open source software as almost all hardware businesses has low margins because it relies on the sale of tangible devices. It is scalable but its scale will be limited because the margins on hardware sales tend to be lower than the margins on software license sales. Tangible devices can achieve significant economies of scale once manufacturing reaches an inflection point where the costs can be reduced. In this model there is often no license of proprietary IP. These kinds of companies actually mostly rely on patent for their main IP protection and the patent is on the devices not on the software. The central legal transaction in a model like this is usually a traditional sales agreement rather than a license. One interesting variation on commercial open source software models is called the embargo model and it's sometimes referred to as sell the present free the future. In this model, software is released to paying customers under a limited license, a proprietary license, often on a beta or pre-release basis. The software is later released to the world as open source. In this model, there are two licenses but they're shifted in time. Paying customers get a proprietary license, usually accompanied by maintenance and support and possibly professional services as well. And then everyone gets an open source license at a later date. One company well known for this model is MariaDB which effectuates its model via a single license, the business source license. That license sets a conversion date on which the software is automatically made available under a GPL compatible open source license. But most other companies use two separate licenses for this kind of model. This model works particularly well when you're selling to OEMs who want to get to market quickly with the latest improvements. They will pay a lot for having the software available to them before anyone else gets a hold of it because that means they can launch products earlier and get a first mover advantage. By the way, some people have criticized this model saying it's not really open source. But of course it is. Once the software is released under the open source license it's open source. But what people mean when they say that is that the development of the open source software doesn't take place entirely in the open. The development is staged in such a fashion that early testing versions are made available only to certain people. This model is called dual licensing or sometimes multi-licensing. This model's becoming rarer every year but it is one of the original commercial open source software business models. It was championed by MySQL in the 1990s. On this slide you'll see illustrations of two kinds of dual licensing. They're like identical or fraternal twins. MySQL's model was the identical twin model and it is the classic dual licensing model. In this model the software is made available under two licensing options, open source and proprietary. Importantly the software made available under each is identical. In this model it is rare for a company to use anything other than GPL or maybe a Faro GPL for its open source license. This business has sometimes been referred to as selling exceptions and of course that does not make sense for permissive licenses. No customer needs an exception to a permissive license. This model worked well for MySQL because in order to use the MySQL software in an application, one had to integrate its connector libraries with one's application. Distributing the two together would violate GPL unless the application was also an open source application so customers who were developing applications were willing to buy exceptions. Of course those exceptions usually also included maintenance and support but the sale required both a proprietary license and a services agreement. Over time this model changed from the identical twin model to the fraternal twin model and arguably has been almost entirely eclipsed by the open core model which we're going to talk about soon. In fact it's probably accurate to say this model evolved into open core. In the fraternal twin model the software available under the open source license is usually called a community edition and contains basic features. The proprietary product contains not only the open source edition code but also more features, often those that are necessary to deploy the software at scale or in large enterprises. Those versions are appropriately often called enterprise editions. And a license usually includes maintenance and support as well or perhaps even access to new features before they are released under the open source license. Dual license software is usually developed and maintained primarily by the company alone rather than having contributions from its community. Now let's talk about the open core model. The open core model separates the software that is in the company's product into two or more buckets. The core project is an open source project and it is run for the benefit of the community and with community participation. The company usually contributes heavily to that development as well. In fact it's very common for the leader of that project to be somebody working at the company. But the company also develops add-on features which are only available under proprietary licensing terms. This model uses two different licenses and for the open source core and one for the proprietary elements. The customer agreement for this model usually includes support for both of these buckets but this model can get more complicated too. Sometimes there are three or even more buckets that include open source software, source available software, binary only software and software as a service. And of course software as a service isn't a license at all but a services agreement. This model however is by far the most popular commercial open source software business model today. Now I have to explain a little bit about source available licensing. In 2018 and 2019, a number of successful commercial open source companies as well as some up and coming open source companies started to adjust their licensing to roll out a new kind of model. Actually most of them were open core models but they were using a new kind of license or at least a kind of license that had a new name attached to it. Many of them wanted to keep the source code access features of open source in their proprietary buckets so they had an open core for example and proprietary upsell modules but they wanted those proprietary upsell modules to make source code available as opposed to being binary only licenses. This was partly in response to a perception that the cloud services providers were quote unquote strip mining the value of these companies by using their software to provide cloud services and not contributing back to the open source project. These companies wanted to capture more of the value that they were giving away instead of ceding it to the larger cloud services companies. When these companies look for a proprietary license for their non-core elements they found little to choose from. And the reason for that is that proprietary licensing has historically been not standardized at all. So after seeing many companies go down this road in 2019 I started a project called Polyform to write some standardized licenses that made source code available but contained license limitations that would allow companies to sell exceptions. These licenses include a menu of options like non-commercial, free trial, small business, and non-compete. Anyone who wants to use the software for a restricted purpose has to negotiate for a commercial license. And that ability to sell exceptions is what helps create the business model. These licenses are free for anyone to use and they're drafted by a team of lawyers who peer review them. So now I'll explain why that's important. For companies that are deploying an open-core model some of them would like to use an open-source license for the core and a Polyform license for its non-core elements. In the slide here you can see an example and this is not uncommon of a company that has created a core and released it under a permissive license, Apache 2.0, and then releases its upsell proprietary modules under the Polyform non-commercial license. That means that anyone who wants to use the add-ons for commercial purposes has to go negotiate a license with the company. Of course the company also needs a commercial license and services agreement for anything it's negotiating with customers. So such a company would be using three licenses, an open-source license, a Polyform license, and a custom negotiated customer agreement. Now I won't get too far into the details on this but there are many small variations on the open-core model. They come in a lot of varieties. For some the core is relatively big and the add-ons are relatively small. That's represented by the orange. For example, this might be a situation where the core does some heavy-duty processing and the upsell elements, which are relatively smaller, are glue that allows you to use that processing within a technology stack. In contrast, in some the core is smaller and the add-ons are bigger and that's represented here by the avocado. And for some, the elements are interspersed. That's the pomegranate. In these models, the company is giving away certain elements and certain value and that's represented by the core that's under the open-source license. And it's trying to recoup the value in the upsell elements that it's created and that it makes available under a proprietary license or a limited source available license like Polyform. So all of the companies that are deploying variations like this are trying to set the right mix between the value they're creating and the value they're capturing. Now you saw this slide before but I'm showing it to you again because now you can see why I spent so much time talking about open-core. It is the single most popular business and licensing model for new commercial open-source software companies. And you can see on this index that an overwhelming majority of the most successful companies on the index use open-core as their business model. Now that's not to say that it's the only business model available but you might consider that it's a good model for your company if you want to follow the example of some of these very successful companies. Now we're going to turn to a new topic which is the question of branding. And from a legal point of view branding is tied up with trademarks. For any commercial open-source company trademarks and branding are some of the most important assets of the company. Actually that's true of any company by the way but commercial open-source software companies give away a lot of the value in their IP in the form of open-source software. However, even if you allow others to use your software freely that doesn't mean they can use your name. You can think of the trademark right as a right to say what the software actually is. For example, if you develop the project called AwesomeSoft and release it under an open-source license others can use the code however they like subject only to the requirements of the open-source license but only you can develop a project that's called AwesomeSoft. In other words, if they develop their own version that's not AwesomeSoft because you get to say what that is. A lot of commercial open-source companies maintain their own commercial brands that are entirely separate from the name of the open-source project that drives them. This is actually a good business practice. Open-source projects don't always steward their brands properly. So the best commercial open-source software companies establish their own brand identity in addition to the name of the project. And as you can see on this slide there are a lot of examples. These are just some of the examples out there and these are all very successful companies. Red Hat Enterprise Linux is the brand of Red Hat but Fedora is the name of the open-source project that they maintain. Confluent is the name of that company but the open-source project is called Kafka and is run by the Apache Foundation. Cloudera is the name of that company and the project that it's based on is Hadoop and GitHub is the name of that company but the project it's based on is Git. So as you can see all of these companies have distinguishing brands for their own products and those brands represent their quality control. Now if you're a brand new company it can be difficult to establish your own brand identity separate from the open-source project but if you think you can do it it is definitely worth it because at the end of the day you will have your own brand and that's going to create a lot of value in your company. Now there are a few last things to talk about in the category of getting your project ready for prime time to turn it into a product and into a successful company. Of course there are quite a few legal and business concerns to attend to when you run a business but here are just a few to consider that are specific to commercial open-source software companies. First, good documentation is one of the features that separates hobby projects from professional projects. Put enough effort into your documentation to make sure that new community members know how to work with you and with your product. Next, plan to involve others outside your company in the operation of the project. Yes, they should earn their participation with effort but outside participation is one of the elements that distinguishes a true community open-source project from a corporate vanity project. And finally, consider governance and succession planning. As it stands today, you might be running the project on your own and that might seem enough for the time being but you have to involve others in the project so that it has continuity. That's going to be important to your customers and all of your community members. In other words, you've got to give away a little bit of the control in order to make a successful project. Now this is a separate topic and it's a legal topic but it's one you need to deal with early in your project. Do you need a contributor license agreement or a CLA for your project? I have a video available on how to make this decision if you want to know more. The link is in these slides here but you can also find this among a series of videos on my website. To make a long analysis short, if your open-source project is being run under a permissive license, you probably don't need a CLA but if you are executing an open-core model and running a project under a copy left license like GPL, you will not be able to use any of the contributions to that project in proprietary elements without a CLA. And no matter what you decide, you absolutely need to make it clear. So when someone goes to your project webpage, they should see very clearly what the terms are for contributing. You can't just leave it to the GitHub terms of service or to implication because that will cause you problems in your business later on. Most GitHub projects have a contributing.md file that tells people what to do when they're contributing and what contributor terms they're using. So for example, if you're not using a CLA and you're just using a license in equals license out approach, the contributing file should specifically say that. If you're using a CLA, you're going to need some kind of process for people to indicate that they agree to the CLA terms. And there are plenty of tools for doing that, which I'll leave to you, but the overarching point is that it needs to be clear. It needs to be absolutely clear or else later when your company goes through a due diligence process, in other words, people reviewing the legal position of your project and your company, they're going to find that there's some lack of clarity about this and they may decide that you need to engineer out some of the contributions and that is not an outcome that you want. Adopt a code of conduct. Today it is not acceptable to manage a professional open source project in a way that alienates new participants or is hostile to particular groups. There are some very good examples out there like the Mozilla Community Participation Guidelines. And you'll see there's a link to these on the slide, but they're easy to find. Finally, you should adopt a trademark policy. You'll remember that I said that a trademark is extremely important to a commercial open source software business. A trademark policy will help you communicate the rules for others using the name of your project, particularly in their own commercial products. If you need an example of one of these, you can find one on my website. Just follow the same instructions for getting my book which will appear on the last slide. But adopting a code of conduct and a set of trademark guidelines will be a marker that your project that's being turned into a company is professional and understands what it's doing. Well, that's it for this brief presentation. I hope it's been helpful to you. If you have further questions, please don't hesitate to reach out to me. I'm very easy to reach and you'll see that my email address is on this slide. You can also see where to find my blog which is about issues relating to open source software licensing. Meanwhile, if you would like a free e-copy of my book and some related documents and tools, please feel free to go to my website, heathermeeker.com, and follow the instructions in the Useful Links tab. The electronic version of the book is free. If you prefer a paper version, you can buy it on amazon.com at a very reasonable price. I'm always very happy to talk to people who are starting open source companies and discuss strategy with them. It's my favorite topic. Thanks very much for watching. It was a pleasure to talk to you today.