Foundations, bright lines, and building successful open source ecosystems

Image by:

Opensource.com

What licenses do the "big" projects use? What are the community implications?

These questions came to mind after I saw Martin Fink, Hewlett Packard Enterprise CTO, give a great keynote at Linuxcon Europe in Dublin last year. After discussing license evolution in the free and open source license community, he began his wrap-up with the following:

We've got copyleft; we['ve] got permissive. And today the problem is we are defaulting as an industry—we have taken the default and made it permissive. And so my callout to all of you and to the rest of the open source community is change your default. And make your default a copyleft license, such as the GPL. ... Copyleft is good. and it brings that sense of community and really enables what we're all trying to get done.

Henrik Ingo did a great bit of analysis five years ago, which demonstrated that the nine most vibrant open source communities had foundations supporting them. The tenth most vibrant was an order of magnitude smaller. He's a good engineer, and as well as laying out his data and assumptions, he was careful to not claim causality. Henrik continues to update the work [1][2][3].

Foundations are an important piece of the puzzle, but we'll get there in a few paragraphs. First, how do licenses land on the nine projects?

Project	License
Linux	GPLv2
KDE	GPL+LGPL
Apache	ASL2
Eclipse	[ICE]PL
Perl+CPAN	Artistic+GPLv2
Mozilla+Addons	MPL
Gnome	GPL+LGPL
Drupal	GPL
GNU Project	GPL

With the exception of the Apache projects, the core of six of the most vibrant open source communities are licensed under the GPL, and two more are still copyleft licenses. I met with Ross Gardler, current ASF president, to consider why we had one non-copyleft anomaly. Our "a-ha" was the Apache incubator. The incubator exists to provide one known successful process and structure to open source projects, and it takes a project 6-18 months to graduate into a full Apache project. One of the side benefits of incubation is that all commercial competitive confusion and discussion is driven from the project community during the incubation. What's left is a vibrant collaborative community with strong process (e.g., Apache Hadoop), out of which companies build products and offer services in an ecosystem (e.g., Cloudera, Hortonworks). Eclipse drives a similar incubation process for new projects wanting to join the Eclipse community (as well as supporting a copyleft license).

Using a copyleft license as the social contract in a community—or using the Apache incubation process—provides a bright line around the project. Everyone, especially a corporate player, understands the explicit relationship and what happens to their contributions.

I believe foundations also play an additional key role.

Foundations

I was the Technical Director at the Outercurve Foundation a number of years ago, working with Paula Hunter as Executive Director. It was a fascinating experiment in open source foundations. (Microsoft sponsored a 501(c)6 into existence by itself to help open source projects relating to Microsoft technologies grow.) Circumstances forced Paula and me to define a business model for open source software foundations. Why would you bring a project to a foundation? Why would you sponsor such a foundation? Why the Outercurve Foundation versus the Apache Software Foundation, the Eclipse Foundation, or the Free Software Foundation?

This isn't just the simple question of services provided by a foundation. We needed to help folks understand the underlying economic and motivational drivers for foundations. We described our model for foundations in a number of places [4][5]. One of the early useful numbers studies we used in the space was Henrik's work, which had just been published, and it led to early insight for us.

The one thing every foundation had to get right for its community is the IP management question. The history of open source foundations until a few years ago is one of successfully run open source projects evolving to the point that companies are interested and want to participate. Foundations provide clarity and risk mitigation around the IP management, allowing companies to add dedicated investment as they contribute to the project for their own needs around products and services. This goes all the way back to the Free Software Foundation, and can be seen in the IP ring fence the OSDL created around the Linux project in a variety of interesting ways.

We're seeing an accelerating rise of open source foundations over this past 4-5 years from launches such as the Outercurve Foundation and the OpenStack Foundation, to a growing number of sub-foundations being launched through the Linux Foundation. Simon Phipps gave a great OSCON talk in Amsterdam last fall, in which he calls for an end to new open source foundations with lots of valuable questions, many of them around bad corporate actors. Bryan Cantrill gave an excellent talk in 2014 on Corporate Open Source Anti-patterns relating his experiences in the OpenSolaris world, but at one point he claims one doesn't need foundations. I can't agree with either of them that all new open source foundations have no value. We've certainly seen catastrophic failures in things such as the Symbian Foundation, but I believe well-built foundations can provide the neutral space for open source projects, and through that space encourage markets to grow around successful projects.

Bright lines

Bright lines are needed for ecosystems to form. They set transparent expectations on behavior. They create neutral space in which to collaborate. Get the right IP management around a successfully run project, and corporate participants dedicate resources for contribution growth. Get the competitive confusion out of the project, and markets can grow around the project.

Healthy markets have a number of things in common. Information flows smoothly. People can be trusted to live up to their promises. Competition is fostered. Property rights are protected (but not overly so.) Damaging side effects from third parties are curtailed.

The Apache license has always been perceived as the "business-friendly" license because anyone (including companies) can do anything they want with the code, including closing the software, living with the economic costs of a fork, and the loss of trust in community. And the success of the Apache Way and its incubator is easy to see. Greg Stein observed that the roughly 332 Apache projects encompass some 177,229,680 lines of code for an approximate "value" of US$7.5 billion.

But maybe, at first blush, copyleft licenses are the more "market-friendly" licenses that help grow ecosystems. A copyleft license is an early declaration in reciprocity around which healthy markets can grow. It's a very bright line.

As we continue to create new open source foundations, we need to be thoughtful in the how-and-why of such foundations. Founding members need to be thoughtful in how they consider motives and metrics. What bright lines are needed? What markets do we want to grow?