The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems. If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential. Having viewed the operations of many such teams, I have summarized six common characteristics of successful open source programs:

1. Marketing is important. Never underestimate the power of a solid marketing plan and branding strategy.
2. Strategically invest in open source communities and ecosystems. Some communities are more in keeping with your technology goals than others.
3. Get strong legal counsel. Without the right legal counsel, an open source program office can end up placing undue risk on company management. They can also stifle innovation, so strike the right balance.
4. Align with product strategy. If your open source program office is not helping your product strategy, then it’s probably a wasted effort.
5. Formulate—and communicate—your end-user and developer community support strategies and guidelines. Anyone in your company who wants to start or participate in an existing project should understand what a well-run community looks like.
6. Hire a believer. Open source pragmatists are everywhere, but your innovative, forward-thinking, ambitious open source advocate is an extremely valuable rarity. Hire them to run your open source programs if you want to make a difference.

In this article, I’ll look at the evolution of the open source program office.

Defining open source success

Back when “open source” was a new thing, there was a rush to understand the ramifications of its success. From developers to admins to enterprise executives, everyone was struggling to make sense of a world in which code was given away for free. Including, of course, executives for software vendors and large, VC-funded startups: Would their business models go the way of the dinosaur? How could they take advantage of the open source trend?

At the time, some companies started creating departments designed to plot their open source strategies, most notably Google in 2004, although there were precedents at other companies, including IBM, Intel, Oracle, and others. Back then, I assumed that the need for these departments would go away once open source became mainstream. After all, who needs an open source vision or strategy when everyone’s using open source software?

That view turns out to have been a bit naive. Despite the popularity of open source, a dearth of experience remains with the ins and outs of open source development and ecosystems in the executive class at most tech companies, including startups. Most of the executives at tech companies never cut their teeth in open source communities. They still don’t understand many of the motivations for participants, nor do they understand the nuanced differences in licensing models, various types of productization and business models, or how proprietary and open source software can be used in conjunction to create a better product line. Many of them still have the dim (debunked) view that open source projects are used to get software development for free, without paying anyone. They might have an inkling that it’s useful for procuring top talent, but they don’t quite get that there’s a quid pro quo involved: To get something, you have to give something. They don’t understand that open source ecosystems are managed ecosystems with rules that members abide by for the sake of creating a level playing field.

As turns out, in 2016 companies need open source program offices more than ever. Such an office serves as the nexus for several ongoing simultaneous efforts that require an understanding of open source processes:

• Legal: Many companies have a mix of licenses, embedded or OEM third-party tools, a patent portfolio, and several trademarks and copyrighted works. This mesh of intellectual property requires planning and forethought when considering adopting a company-wide legal framework that balances immediate company interests (i.e., defending ownership of said IP) with long-term goals of open source initiatives.
• Marketing: Some people will tell you that open source initiatives don’t require marketing. They are wrong. However, the type of marketing required is different from traditional corporate marketing.
• Product management: Everything you release, whether open source or not, is a product, regardless of whether it drives direct revenue. Better to make sure that the open source products you release augment your overall product portfolio and strategy.
• Engineering: Do your engineering groups understand the requirements and rules for participating in open source communities? Do they have legal clearance to contribute code? Do they know not to send large patches as their first contribution?
• Customer support: Your products will require thought devoted to how you support them after release, regardless of whether they directly or indirectly lead to revenue. The open source products you release will need a reliable support model, even if it’s “self-serve.”
• Community development: How will you encourage others to participate in your open source communities? This is not just some Q&A forum, although that is certainly part of it. What’s the best governance model? Are you sure that incoming users and developers feel welcome?
• Ecosystem development: Not to be confused with the above, how will your open source efforts interact with other communities? Do you exist on an island unto yourself, or do you intend your communities to be part of an interconnected, holistic approach?

These and other categories of activities are only a few things to consider when evaluating how to execute open source initiatives. As open source software becomes more important in your product portfolio—as it almost certainly will—better to ensure that it augments your overall company strategy and leads to a magnifying effect.

Now let’s look at efforts from the past and how they led to the “best of breed” approach we have now.

The engineering group

For open source software, 1998 and 1999 were milestone years. This was when the growth of Linux became impossible to ignore, and a few companies started investing in development for the burgeoning Linux platform. In the case of IBM and Intel, they started an engineering effort to make sure that Linux would work on their signature platforms. They each created engineering groups designed to ensure two things:

1. Increase their relevance in developer communities of strategic importance, and
2. deliver existing products more efficiently as a direct result of their community participation.

Over time, they both evolved models that allowed the companies to decide which open source projects and initiatives to invest in, and they allocated engineering resources to their open source teams to take on those initiatives, working hand-in-hand with internal product groups. Basically, as long as there was a sustained revenue model, they worked out the engineering resources to contribute to those efforts.

As engineering efforts go, these were smashing successes. Intel’s contributions to Linux and other open source ecosystems are well-known. IBM is still famous for its “$1 Billion investment in Linux” and the “Peace, Love and Linux” marketing campaign, not to mention its own efforts around establishing the Eclipse Foundation and significant contributions to the Apache Software Foundation. Both companies also armed themselves quite well with attorneys who were well-versed in intellectual property law, especially as it pertains to copyright and trademark laws that affect open source software. These efforts paved the way for a wider understanding of IP law in an open source context.

There are, however, limitations with the engineering-first approach. There seems to be much to be gained from a holistic view of centralized open source initiatives, as I’ll outline below.

The Google experiment

By 2004, that open source was here to stay was becoming apparent, and benefits were available to companies that actively participated in communities. But many in the tech industry still doubted the long-term potential of open source growth. Enter Google and its Open Source Programs Office (OSPO).

Not content simply to contribute open source code and use it in their products, Google took the extra step of hosting much of the world’s open source code on Google Code and creating the highly influential Google Summer of Code, which paid students stipends for working on—and completing—open source software projects over the summer. In hindsight, this was a visionary step forward by an innovative company looking to make its mark on the technology world, and the company clearly saw “open source influence” as a path toward its goal. Credit must be given to the talented members of the team and its visionary manager, Chris DiBona.

That the lessons learned from Google’s experiment didn’t immediately take hold, however, is somewhat disappointing. Twelve years after Google’s Open Source Programs Office began, few companies have embraced all the facets of open source engagement as much as Google did in 2004. Over the years, Google has reaped significant rewards from its OSPO ambition, including broad influence in large open source communities, good will from thousands of developers around the world, and a channel for its ongoing engineer recruiting efforts. Much of the credit goes to Chris DiBona, who had a vision that went beyond what many others thought possible.

The open source way

As I look at the spectrum of open source programs, enough efforts have been made to gauge their relative successes and failures and come up with something that resembles best practices, or at least what not to do. One thing that seems abundantly clear is that ambition and budget are directly related to ultimate success. If you have only one or the other, success will be inherently limited. If neither, then you’re constructing a system to fail. Ultimately, much can be gleaned from all of the above efforts to help construct the ideal program for your company.

Leading an open source program effort takes equal parts intellectual property smarts, marketing savvy, desire for innovation, entrepreneurship, and ambition to spare. These efforts are often at the center of a company’s core strategies—from developer relations and community marketing, to product development and cutting-edge engineering. As such, the teams that lead these efforts should be nimble, lean, plugged into multiple departments within the company, and perhaps most importantly, aligned with the company’s core strategies.

The big person theory of open source programs

(Or “open source pragmatists need not apply”)

One does not need a close reading of the preceding paragraphs to know that I think highly of Google’s approach. Even so, Google isn’t perfect, but one thing they did right was to start with a leader who had a burning desire to see open source flourish. At this point, open source is so commonplace that everyone in tech-related roles to some degree participates in open source ecosystems. But open source believers, those who think open source methodologies are superior and should be advanced in all areas of technology? Those people are relatively rare, and they’re exactly the kind of person you want advocating your open source efforts.

Engineering is important

To maximize industry influence, engineering excellence is key. The massive code contributions from IBM, Intel, and Red Hat have played a major role in their ability both to deliver products more quickly and to increase their respective adoption rates once they’ve been released. IBM made an early bet on the Apache Web Server as a key component for its WebSphere product, in addition to its bet on Linux as the platform of the future (at the time) for x86-based servers. Its creation of the Eclipse Foundation has long been a success story that has spawned a quite large ecosystem. Intel has also clearly bet on Linux as the go-to platform for devices and its IoT strategy, having made major contributions to the Linux kernel for years, in addition to a smattering of contributions in other areas, including graphics drivers, big data (Hadoop), and storage (Ceph, CoprHD). Red Hat, having bet its entire product strategy on open source software, is a major contributor to the Linux kernel, OpenStack, and many other projects.

To maximize the impact of code contributions, open source programs can recommend the right ecosystems to invest in, ensure that other groups within the company are fulfilling their legal obligations and following the rules, and train other groups on how to participate in open source communities. With strong open source program leadership, these teams can help steer the ship in the right direction, making sure that their engineering efforts align with other departments. Without strong leadership, many departments within a company may find themselves duplicating efforts, or worse, contradicting the engineering efforts made by others. With centralized efforts in this area, companies increase efficiency and maximize their open source impact, both internally and externally.

Legal eagles and intellectual property law

The success of open source begins and ends with the modern concept of intellectual property law, especially pertaining to trademarks and copyright. Without IP law, open source doesn’t succeed. The open source definition itself requires that a software project’s copyright license meet certain criteria in order to qualify as officially “open source.” Thus, open source program success also depends on good attorneys who deeply understand both the open source way and the role that intellectual property law plays. The trick is finding that rare attorney who understands risk mitigation but doesn’t stifle innovation. The ones with strong legal leadership understand the value of license compliance, can clearly communicate the risks of any particular open source activity, and help educate other internal legal counsel on the role of IP law in open source software.

When open sourcing your code, there’s no more pretense about being the sole arbiter of features. You’re not. The code is out there, and so are all the features and functionality that it enables. This means that the things of inherent value you have are:

1. Brand, which is governed by trademark law,
2. ownership, which is governed by copyright law, and
3. license, which dictates how others can interact with your code and community.

There are, of course, many other levels of value in the software supply chain, but often they’re not as obvious. Thus, that your legal counsel be top notch is imperative.

Which brings us to licensing. Too much time is spent hand-wringing over license choice, but compliance with licensing is especially important for a company that wants to be known as an influencer in one or more areas of software development. Hence the need for the centralized open source program with the requisite legal team to ensure compliance and clear any legal roadblocks to innovation.

Strategic alignment (it’s not just for MBAs)

Another area in which the open source program team is essential is product strategy. Open source programs drive efficiency, innovation, and industry influence. These objectives are sometimes at odds, increasing the chance that, left to different departments in the same company, open source strategies also will be at odds. Open source programs ultimately should serve the company’s interests, although that may not be as intuitive as it sounds. In some companies, open source efforts can directly contradict each other, giving the impression of no centralized planning, whereas other companies restrict their open source efforts to the point of rendering them completely ineffective.

A company may release project X, which is a whiz-bang newfangled project aimed at container orchestration. Later, that same company decides to release project Y, which is… a whiz-bang newfangled project aimed at container orchestration. The key to a good open source program team is not necessarily preventing that from occurring—although that may be the best option—but to ensure that if this occurs, the company communicates a clear reason why this happened and why it was necessary. This means that the open source program team must communicate with whatever engineering team is releasing code (and in some cases, informing each of their existence if necessary). There are plenty of examples in which a group “went rogue” deciding to open source a project without telling other groups within a company, causing confusion with company executives and external communities, ultimately leading to a failed effort. Striking that fine line between innovation and chaos can be difficult, but one should try.

This points to, once again, the need for an agreed-upon central location where open source strategic alignment happens. This also means that when a group wants to bring its open source project to the world, the open source program team needs the resources to address incoming requests, allowing them to release said project in a reasonable time frame. At least with this central coordination, there is the hope that the messaging will be clear, collaboration will ensue, and success will be enjoyed.

Follow the open source way

If well run, open source programs and the team(s) that manage them will influence many aspects of a software business, including customer support, engineering, product management, business development, and marketing. To focus on some of the above to the exclusion of others is to miss the point: Whether you know it yet or not, open source is very much at the center of your business. A centralized open source program office is simply the realization of that reality, and the best way to yield the most benefits from open source participation.