LinuxCon Japan: The business of contribution

Bdale Garbee has been involved in free software, particularly Debian, for a long time, but he's also been involved in the "corporate side" of open source at HP for quite some time as well. That gives him a good perspective on the interface between companies and free software projects. In a bit of a reprise of a talk that goes back to 2003 or 2004, he spoke at LinuxCon Japan on "The Business of Contribution"—how companies and free software projects can benefit from each other.

There are multiple ways that someone can become involved in the free and open source software (FOSS) ecosystem. They range from those who take the code and use it in some way all the way up to those that lead and manage a project or subsystem. Garbee said that he hoped to convince attendees to move their way up to higher levels of engagement in FOSS.

In general FOSS projects have certain things in common. They are developed and supported by the community, there is no single company in charge, and there is a wide range of contributions that come from people with a variety of interests, abilities, and motivations. The users of the software have flexibility in how they acquire support; they can become a developer or pay someone to do development for them. This puts them in control of their own destiny, which stands in contrast to license arrangements where users just get binaries.

The key to FOSS licensing is that "people we don't even know are empowered to build things we can't even imagine", Garbee said. Everyone can take advantage of those newly built things, both individuals and companies.

Business and community

Something that is probably immediately obvious, he said, are that the expectations are somewhat different for FOSS developers and companies. It is a bit difficult to characterize what FOSS developers are looking for because each project and developer is different, but there are some common elements.

Developers often want to scratch an itch and solve a problem that they are having. They also are generally not working to a particular schedule, something that is particularly true with Debian for example, he said. FOSS developers are looking for the fun that comes from a collaborative development project. Lastly, FOSS development is a means to develop and maintain a personal reputation, which is something that can be hard for companies to understand when hiring them.

On the other side of the coin, companies need to make money. In fact, in the US, companies are legally required to make decisions based on their revenue generation possibilities. Companies also must grow and expand to provide the financial return that investors expect. That means that companies want to be able to differentiate their products from their competitors' products. Corporate reputation is also important, but there are so many ways to lower a company's reputation, and seemingly few ways to increase it, which makes doing new things risky, he said.

But there is good news in that there is something that the community and companies can agree on: positive user experience. For the community, that will increase the number of people who want to use and benefit from what it has made. For companies, a great user experience will help motivate customers to want to give them money.

Licenses and business models

FOSS licenses have their basis in copyright law, which differs somewhat in various jurisdictions, but there is a lot of commonality. The choice of which license to use for a given project is made by the founder(s) and those that join the project later are explicitly accepting those terms for their contributions. That "very special and unique right" to set the license is an important decision as it can have a "really profound impact" on the nature of the community that forms. In addition, a particular choice of license can sometimes cause new projects to form using different license terms.

There are lots of different open source software licenses available—60 or so—which is a bit unfortunate. But, they break down into two basic types: reciprocal or permissive. Reciprocal licenses require that one pass on the same rights to the code to those you distribute it to, while permissive licenses do not require that. The reality is that each license type has its place, Garbee said. It is important for project founders to carefully consider the license they choose, while it is equally important for contributors and users to understand the license that is being used.

It is vital to recognize that "open source" is not a business model, it is, instead, a process for development. One can use open source to enable the sale of hardware—this is what HP does—by ensuring that Linux runs well on that hardware. That is one possible business model, but there are others.

Selling services, like training or support, is a common example of a business model around FOSS. One could also give the source away, but charge for access to the binaries. That may sound strange, but it is more or less what the enterprise Linux distributions do, he said. Another model is to open up the core of some large software system, perhaps a framework and a few sample modules, and build a business around selling add-ons. That model can work, but it sometimes becomes something of an arms race as FOSS developers create and contribute add-ons that compete with the ones that are sold.

Working with FOSS gives a company the "opportunity to harness the creativity of a very diverse community". There is no company on earth, or even a collection of companies, that can bring to bear the talents that exist in a community like that surrounding the Linux kernel. Finding a way to work with FOSS communities can be an enormous boon for a company.

Deciding to contribute

There are multiple benefits to a company for participating in open source. For one, the software has "zero marginal cost", which means that a second (or third ...) copy costs nothing extra. The web provides a low-cost collaboration and distribution mechanism, which also reduces costs. Most of tools are also available as free software, so building a product is less costly. There is an enormous amount of existing code in the form of libraries and tools that can be used to build a product more cheaply and with a faster time to market.

There are multiple levels of engagement with FOSS, starting with taking the code and running it. Those who do so are valid members of the FOSS community. Going beyond that and monitoring the development or user mailing lists makes you a bit more engaged. The next step might be to find and fix a bug or to answer a question on the list. Each step up gives a person more influence in the direction of the project.

There are more and less efficient ways to use open source in a product, he said. It is common that one or more OSS components will require some change before they can be used, and that is "completely legally OK". If there is a reciprocal license, the changes must be distributed, but that's not a big deal. The problem occurs when it is time to put out a new version of the product. If the changes have not gone upstream, they will need to be ported to any new version of that upstream project.

On the other hand, if the changes have been contributed upstream—and shepherded through the process of getting them merged—the features and bug fixes needed will be there in the next versions. That means that the work that was done once won't have to be repeated each time a new version of the product (which may require a new version of the upstream project) is built. That doesn't mean there is no work that needs to be done, as the new version may have new bugs that need to be addressed, but it is much more efficient to get changes upstream.

For the kernel, things like device drivers will be kept up to date as the internals of the kernel change over time. The kernel is a good example because it is such a fast moving and dynamic body of code, but the situation exists in other projects as well.

Choosing to use FOSS is a "first step to making the best use of resources", Garbee said. That allows a company to focus on differentiating its product. But maximizing community involvement helps to grow the body of technology that's available to be used in future products, without having to reinvest over and over again.

Using FOSS does not mean that a company has to give everything away for free. But it doesn't mean that the company gets everything it wants for free either. There will always be a small piece that the company will need to invest in, but in spite of that, working with FOSS projects is an "incredibly powerful model".

Getting more involved with a project can bring other advantages too. One can help influence the project's direction and learn about enhancements that others are working on. Learning about security vulnerabilities and other problems in the code earlier will also be useful. It will give insight into who is contributing to the project, which may lead to interesting information on what competitors are up to. Because of that, Garbee is surprised by the email he sometimes gets from people working at other companies who didn't expect some announcement that HP has made. Had they been paying attention to the projects that HP was working on, the announcement would probably have been less surprising.

One way to experiment with FOSS is to work with partners on a project without really committing the company to doing the work, but that will not build "FOSS equity". The technical accomplishments and the reputation that the project builds will not accrue to the company (and instead to the partner). A better way is to have company employees who work directly on FOSS projects. The expertise that they gain can be reapplied to other projects, and the company gets to help set the direction for the project. In addition, the company can take credit for the work it is doing.

One important thing to recognize, however, is that reputation is built by individuals. Getting code accepted involves a combination of technical prowess and reputation within the community. In that case, the reputation that matters is that of the individual. Linus Torvalds has said that he doesn't really know the corporate affiliation of most kernel developers. In order for the company to be successful in the community, it must allow individuals to gain reputation in that community. It is important for managers to understand this, he said, and to make it a part of the career development of the employee.

Garbee noted that he once was talking to a peer at a competitor who asked about how he should review a particular employee. That person had been tasked with getting some code upstream, but ran into a competing proposal. The employee then made sure that all of the company's needs were met in the alternative, which eventually was merged. The peer was wondering whether the employee should be rewarded for that, and Garbee's response was "give the guy a raise". He recognized that the alternative proposal was better, dealt with his ego, and ensured that the company's requirements were met. He achieved the desired result, rather than get his own code upstream, which fully met the objective. That is something that many managers have a hard time understanding, he said.

Does this really work?

Garbee then described HP's experiences with FOSS as something of a justification for what he had been saying. In the last ten years or so, HP has accomplished a great deal by trying to engage with FOSS projects "as best we can". That is one of the things that has led HP to be the world's largest IT company by many measures, he said.

One of the more significant recent decisions that HP made with regard to FOSS was for the HP Public Cloud, which is based on OpenStack and Ubuntu LTS. The company has made a "significant commitment" of HP resources to OpenStack. It is now one of the largest technical contributors to the project and hosts its build farm. In addition, HP is helping with the transition of OpenStack to a "foundation model", similar to that of Eclipse or Apache.

HP has recently completed an analysis of all of its products and found that the majority contain at least some FOSS. Any of those that do have FOSS components are increasing that percentage rapidly. It is the most efficient use of HP's software engineering effort, he said. All across HP, there is more and more direct engagement with FOSS projects, which is helping to make the company more successful.

As a consequence of the talk, Garbee said that he hoped the audience would find that becoming more directly engaged with FOSS projects made sense for them and their companies. He ended with a famous quote from Margaret Mead:

That is, he said, a strong statement of how things work in open source. If someday you look around and wonder why it is that something isn't fixed, remember that you are someone.

Garbee's talk was clearly aimed at the mostly Asian audience, and tried to assist those present with arguments to make to their management about the benefits of working more closely with FOSS projects. The arguments are useful for anyone trying to get their company more involved in FOSS projects, of course, but Asian companies have traditionally been less engaged with upstream projects. He also slipped some rocket slides into the talk, which, beyond bringing some of his hobby into view, also gave him an opportunity to show a more personal connection to open source.

One of those slides showed him carrying a rather large rocket to the launching pad (shown at right). That rocket was subsequently lost after reaching Mach 1.3 and attaining 5000m above the ground because of a malfunctioning closed-source altimeter. That led him and Keith Packard into a collaboration to create open hardware and software for rocket telemetry and control, which ultimately helps him "not lose rockets". So, not only is open source good for companies, it's good for rockets—and other hobbies too.