BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Will Cloud Computing Kill Open Source Development?

Will Cloud Computing Kill Open Source Development?

Bookmarks

Key Takeaways

  • While open source development is not going to disappear, the future of commercial open source vendors is not very promising. Production support, tooling, and consulting opportunities have diminished with the rise of fully managed services.
  • Cloud providers are adopting open source software, and making it commercially available without necessarily adding value, or supporting future development. 
  • No industry consensus exists on the best way to fund open source development. Many continue to believe that open source software should be free.
  • Models such as "open core" or "dual licensing" seem to be the most promising approaches for supporting future commercial open source.
  • Open source licensing is probably going to become more restrictive about commercial use.
  • There is no guarantee that past commercial open source success stories will be replicated in the future.

Redis changed the licensing of some of their enterprise modules to be licensed under the Apache 2.0+ Common Clause. These modules cannot be used as stand-alone commercial SAAS. This was specifically aimed at cloud providers.

The surrounding controversy has raised an issue that has been lurking in the open source community for a while. The best case for open source has been with software infrastructure, rather than software application projects. If cloud computing companies become the infrastructure providers for software, their market control might allow them to take over open-source projects, and sell those software services at a lower price point than companies who market open source services.

If this scenario comes to pass, is there any future for open source companies?

Panelists

  1. Paul Dix - founder & CTO of InfluxData
  2. Matt Klein - software engineer at Lyft and creator of Envoy
  3. Heather J. Meeker - partner in O’Melveny & Myers’ Silicon Valley office and Portfolio Partner at OSS Capital

InfoQ: What is the business model behind developing open source software? Or to put it another way, what is the best way to fund open source development? What kind of software development is not a good match for open source?

Paul Dix: There are a number of models that I think can be successful. The first is what I call "open source exhaust." It's what comes out of a big company like Google, Microsoft, or Facebook when some software they're developing is deemed not a part of their key intellectual property. This kind of software can be thought of as a liability on the balance sheet. Infrastructure software that you require to run your business logic at scale is a good example of this. It doesn't provide the secret sauce that gives your business its value, but you can't operate without it. So larger companies can open source it in an attempt to get other large companies and developers on board to defray the cost of continuous improvement and bug fixes. The participating companies also benefit by having developers outside their organization pick up these skills. They can be great fodder later for the hiring pipeline. Of course, this method doesn't bode well for anyone attempting to create a business based on open source infrastructure software.

For businesses looking to have their primary revenue stream be associated with the development of some open source software project, their options are very limited. I believe the only proven model at this point is open core: the company develops closed source software that complements or adds new functionality to the open source software, which it then offers as either a hosted SaaS offering or as on-premise Enterprise software. Some OSS advocates would argue that companies that follow this model are not actually open source companies. Yet every open core example I can think of puts a much higher percentage of their development R&D budget to OSS than any of the big players. Elastic, Cloudera, RedisLabs, InfluxData and many others are open core, and a much higher percentage of their developers are creating OSS than the development teams at Google, Microsoft, Facebook, Netflix or any of the other large companies following the open source exhaust model are.

Open source infrastructure companies used to believe that they could monetize production support and tooling. However, the rise of the cloud providers and fully managed services has negatively impacted that model to the point that I don't think is viable. As more evidence of the cloud's continuing impact on open source infrastructure, see MongoDB's recent announcement about their license change.

Lastly, for building a business, there are services and support. This is the weakest method for funding OSS development. The economics of this looks like a consulting organization, yet if you build a consulting team, you want them to have a high percentage of billable hours. This is directly at odds with having your team develop OSS software. If they're writing OSS, they're not billing. Any consulting organization would be better off picking up an already popular OSS project and offering consulting on it.

The last method is through free volunteer community effort. This doesn't work well with large infrastructure projects. As a project gains popularity and complexity, it becomes too difficult to manage and push forward for a team of volunteers working during their nights and weekends. This model works for small libraries that can be built and mostly marked as done. Larger projects require some sort of sponsorship to survive and move forward.

Matt Klein: There are a variety of business models that have been tried. They all boil down to some variant of (the following are simplistic descriptions):

  • Open core: A portion of the SW is OSS, while a portion of the SW is behind a paywall.
  • SaaS: Run the OSS as a service on behalf of the customer.
  • Services/consulting/support: Charge for various ancillary support and development that a customer might need to use the OSS.

Some business models are a combination of the above methods, and there have been substantial success stories with all of the above models.

In reality, there is no "best way" to fund OSS development since, what works is typically project dependent. Unfortunately, no matter which method, it's not trivial to generate income on top of OSS because many users fundamentally believe that OSS should be free. In terms of what types of SW development are not a good match for OSS at all? The biggest thing that comes to mind are libraries. Some libraries are absolutely critical to modern systems, but it's extremely difficult to generate revenue from OSS library usage. This fact has had serious real world effects. For example, the lack of development and resources put into OpenSSL for many years has lead to critical Internet infrastructure being built on top of a poorly maintained yet fundamental piece of SW.

Heather J. Meeker:  The only thing you really can't do with open source software is sell licenses to exploit it.  But there is still plenty of room to make money in a private business developing open source software.  You just have to know what you are selling, and what you are giving away. Pure open source businesses are quite rare -- Red Hat is an incredibly successful exception.  A pure open source business sells services -- mainly maintenance and support. But it also sells quality control. Customers buy products, not licenses. You can make a business selling open source software packages if you put a lot of work into quality control and packaging.  But then, effectively, you are selling reliance on your reputation. Most open source businesses make money with some variation on the "razor blades" model (famously and perhaps apocryphally attributed King Gillette) -- give 'em the razor and sell 'em the blades. The razor is open source software.  The blades take lots of forms. Some are upsell modules (often called open core), some are alternative rights (dual licensing of the same software, like MySQL), some are "widget frosting" (selling hardware that runs on open source , like may iOT products, and some are early access (an "embargo" model that sells access to code before it is publicly released).  In a few of these models, you need to use other kinds of licenses, and that is where variations like Commons Clause come in.

InfoQ: Does open source software only make sense for enterprise developers, or is there a way for cloud vendors and open source providers to work together?

Dix: There might be, but it depends on the cloud vendor. There's no requirement for the cloud vendors to work with an open source project. Indeed, Amazon seems content to pick up open source projects and offer them as managed services with no commercial agreements or development efforts to push the OSS projects forward. Google and Microsoft have some partnerships, but I'm not sure what those look like. Also, what happens when they decide there's no need to continue to support some other company writing the open source? They can easily hire all the developers they need to push those projects forward. Their motivation to do so is to get developers paying for their hosting. Building out around open source is just a method to make sure that one of the other cloud providers doesn't build a big development community around proprietary, closed APIs. The big three cloud vendors are in a knife fight against each other where the OSS infrastructure companies may just turn out to be collateral damage. For instance, Microsoft and Google are going to continue to push Kubernetes forward as the standardized Cloud API because it helps them deposition AWS (the market leader) and commoditize cloud APIs. How will the startups fare that are attempting to turn Kubernetes into a business? If it plays out like the Open Stack ecosystem, those startups will have all closed up shop within the next three years (although consulting on Kubernetes will be alive and well).

Klein: I'm not sure that I completely understand the question. Popular OSS will inevitably be used by both enterprises and cloud vendors. Additionally, cloud vendors will likely offer hosted products built on top of popular OSS, without necessarily contributing in a substantial way back to the project. The larger question IMO, is how to properly fund OSS development in a way that leads to community first development, while still allowing value to be extracted on top (via either open core, SaaS, services/support, or some combination). Unfortunately there is no consensus on how to do this. Personally, I believe that in the future SW foundations will have to play a larger role in providing a neutral home for critical OSS. The foundation's additional responsibility will be to raise money to fund development and maintenance resources that can remain neutral while still supporting business interests on top (whether enterprise, cloud, etc.).

Meeker: The watershed moment we are experiencing, which resulted in Commons Clause and other alternative licensing models, is cloud providers adopting the software of smaller companies and making the software available commercially without adding material value, but not making any arrangement with the company to support development.  At least, this is the pain point that most developers express when they get frustrated with an open source model. They need to keep the doors open, pay their developers, and some of them are bleeding resources. For the foreseeable future, I think vendors of enterprise software that is useful for unmodified cloud deployment will be wary about releasing their code under open source licenses.   I expect we will see more commercial deals between cloud providers and enterprise developers, so the development costs can be shared. At least, that would be the most economically rational result.

InfoQ: Does the release of open source projects by Google, Netflix, or others enhance open source development, or do they have mixed motives?

Dix: I would say it's both. Having large organizations putting code out in the open under liberal licenses is good for everyone. However, it's a safe bet to say that they may have motives in mind other than just improving the state of free software in the world. It means that you have to be prepared that their goals for a project may not always align with your goals, but the same is true regardless of how an open source project is governed. As long as the software is in the open, you have options if the corporate sponsor diverges from where you think the project should go.

Klein: No company does anything out of good will. Large companies release OSS for many reasons. The big ones are recruiting/visibility as well as building platforms that will ultimately tie into cloud businesses. That's not to say that SW released by Google, Netflix, etc. have not had a profound effect on the industry. It certainly has, but it's important to keep in mind the ulterior motives of why any company is directly funding OSS development.

Meeker: I think the result is more important than the motives.  I suspect most developers would say that the open source code released by these companies, and others, is hugely beneficial. But those companies are doing well by doing right.  Private companies have a legal duty to steward the capital of their shareholders by making decisions that are right for their business. But that doesn't mean that actions that help the community aren't also good for business.  Many large companies today have found that robust participation in the open source community is great for business. Software access is  not a zero-sum game.  Businesses may strategically limit access to technology they develop that gives them a market advantage.  But it's OK to give away what does not. Some software works best as a public good, in an economic sense, and some works best when kept private.   It makes sense to share the road but sell the cars that run on it. The opposite probably means unconnected roads and terrible cars.

InfoQ: Going forward, what are the viable licensing arrangements for open source companies?

Dix: For companies that are building a business primarily on an open source project they own, either they need to use restrictive licenses like AGPL or they need to have closed source software that complements the liberally licensed open source core. I prefer the latter model because for the code that is open source, it's clear that anyone can do anything they want with it. They can use it, build a business, ship it as part of their product. I prefer liberal licenses like MIT and Apache2 for open source. Then the company has closed source software that complements or enhances the functionality of the open source project. It's clear that this is their commercial offering. In truth, there's nothing stopping any other company from creating closed source products around the same open source project.

Klein: I think we will continue to see companies attempting to extract value out of OSS in a variety of different ways. Personally, I think that the most successful model moving forward will be the one I wrote about which I call "loose open core." The idea is to build an open core ecosystem in which the primary SW can remain community driven without having to alienate potential contributors by refusing to take patches that compete with paid offerings. Enterprise add-ons in this model might include UIs, auditing, security tooling, etc. Basically anything that can be built on top of the core OSS using a well known API.

Meeker: I think we are going to see a lot of variations.  The difference, I think, is that non-open source licensing will become more standardized.  Right now, it is almost completely ad hoc, and that's a net cost to everyone.

InfoQ: Ten to twenty years from now, how do you think software is going to be developed?

Dix: It'll continue to be a mix of closed and open. I don't think it'll swing significantly one way or another from the way things are now. It won't be entirely out in the open because companies will still need customers to have a compelling reason to buy, and the economics of support and consulting won't have changed. So companies will continue to have closed source software to drive the value. The percentage of companies running their own data centers will be significantly lower, but there will still be those that run their own because of economies of scale.

Klein: Probably not much different from how it is today. The majority of infrastructure SW will be OSS, while the majority of consumer systems will be proprietary. The big question on the infrastructure front is whether the major cloud providers will "eat the world" or whether independent companies can carve out a viable revenue model around OSS. IMO those companies that focus on the "loose open core" model will do best against cloud competition. This is because many of the value added services can still likely be run on top of basic cloud SaaS offerings.

Meeker: I started programming more than 20 years ago, and the difference between then and today has a few aspects.  First, development tools are better, so humans can avoid some of the tedium of lower level tasks when they are developing applications.  Second, there is much more modularization of coding, so there is less need to reinvent the wheel. Open source has turbo-charged that second aspect. Third, software is developed collaboratively, and that's because we now have tools to do that.  I expect the next 20 years will be more of the same trajectory; more code will be automated or standardized, or even written by computers, allowing human programmers to focus on higher level user functionality. Also, I hope, there will be more emphasis on the quality of user interaction.  I think right now we have far too few UI experts. Software should be usable, not just functional.

Conclusion

Open source is not going away; the question is, can companies based on open source development continue to thrive?

New licensing and funding models need to be created if significant open source development is to continue.

About the Panelists


Matt Klein is a software engineer at Lyft and the creator of Envoy. He has been working on operating systems, virtualization, distributed systems, networking, and making systems easy to operate for more than 15 years across a variety of companies. Some highlights include leading the development of Twitter’s L7 edge proxy and working on high-performance computing and networking in Amazon’s EC2.


Paul Dix is the creator of InfluxDB. He has helped build software for startups, large companies and organizations like Microsoft, Google, McAfee, Thomson Reuters, and Air Force Space Command. He is the series editor for Addison Wesley’s Data & Analytics book and video series. In 2010 Dix wrote the book Service Oriented Design with Ruby and Rails for Addison Wesley. In 2009 he started the NYC Machine Learning Meetup, which now has over 12,000 members. Dix holds a degree in computer science from Columbia University.


Heather J. Meeker is a partner in O’Melveny & Myers’ Silicon Valley office and Portfolio Partner at OSS Capital. She advises clients on technology transactions and intellectual property matters.  She is an internationally-known specialist in open source software licensing. She received the prestigious IP Vanguard Award for private practice from the Intellectual Property Section of the California state bar for 2016.  Her latest book, Open Source for Business, is a definitive handbook for lawyers, engineers, and businesspersons on open source licensing in business.  Ms. Meeker is an advisor on the American
Law Institute’s ongoing project on the restatement of copyright law.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT