In my previous article, What is an open source program office? And why do you need one?, I introduced the idea of an open source program office (OSPO) and discussed what they do, why a company would want to create one, and how to optimize them. In that article I focused on technology vendors and for a good reason—they were the first to embrace open source program offices strategically. From IBM and Intel to Oracle and even Microsoft, open source program offices were all the rage at technology companies from 1999 through about 2005. At that time, open source program offices were a way for vendors to get a handle on this brave new open source world and coordinate activities through a centralized office. But the one company I held up as the definitive example, Google, was a harbinger of things to come.
Google was not a software vendor, at least not in the purest sense. Google was a provider of Internet search services and advertising, as this was before they became known for their mobile platform and services. Google’s ability to influence the direction of open source software development brought to mind one of the core tenets of open source development: Everyone has a seat at the table, and everyone can use it to exercise power. Google’s foray into open source politics made one thing crystal clear—software production was no longer controlled by software vendors. Since then, one commercial user after another made inroads into software development, in many cases wielding far more power than so-called software creators.
Since Google demonstrated that software development was an avenue to increasing industry influence, we’ve seen many other companies expand into the open source program world, including Yahoo!, Facebook, Twitter, PayPal, Netflix, GitHub, and scores of others. What do all of these companies have in common? None of them are known for creating software for general consumption—at least, they weren’t before. Sure, many of them are technology companies, but they were known for delivering services, not software for outside users. Since this rising tide first surfaced, how much influence these companies have on the software industry has dramatically increased, to the point in which many of their engineers and executives are the first to be listed as headline speakers and keynote speakers at technology conferences.
The Google example
Although many companies have created OSPOs and wield influence over open source communities and ecosystems, Google stands out for its open source efforts. Perhaps this is because all the other OSPOs feel very … utilitarian in comparison. This is not necessarily bad, but what differentiates Google from other organizations, aside from being the first to embrace the OSPO approach, is that Google embraces the mission of spreading free software to the world. And no it’s not altruistic, because the company garners acclaim and accolades for the greater glory of the Googleplex, but I’ve known many of Google’s OSPO staffers through the years, and there’s one thing I’ve never heard them say: “I’m an open source pragmatist.” I’ve heard lots of other people at the other OSPOs say those exact words, often with a sense of pride. Google’s open source program office staffers aren’t just enthusiastic about making Google software better—they seem enthusiastic about changing the world through open source.
How does Google benefit by embracing a mission that goes beyond wielding industry influence? The benefits are not easy to calculate, but there are metrics that are objective, such as perceived influence compared to actual engineering contributions. Google may not contribute the most code and, before Kubernetes, its open source projects were either small efforts or tightly constrained and not very open (e.g., Chrome, Android), but it carries great (one might say outsized) influence in open source developer circles, which gave it a great platform to launch Kubernetes and increase its chances of success. But Google did things like create Google Code, which at one time was a massive repository of the world’s open source code, and it created the Summer of Code. Although neither of these initiatives involved massive code contributions by Google, they enabled developers around the world to collaborate and write more code. To date, no other company—vendor, user, or otherwise—has embraced this mission to the same degree as Google. Although this is great for Google, one wonders when some other enterprising company will invest in a similar vision.
I suspect that the bottom line is risk: Why associate with an initiative not tightly coupled with a company’s business objectives? After all, Facebook’s business is not to build open source communities; its business is advertising. Someone looking at the books at Facebook would conclude that investing money in growing the world’s open source ecosystems is simply not in keeping with the goals of a publicly traded company. However, the counterpoint is that Google also is, at its core, an advertising company, and is able to leverage its open source efforts into real business advantages.
There also could be a sense of “been there, done that.” At the time that Google started its OSPO, how much of the world would end up running on open source software wasn’t clear yet. These days, open source quickly is taking over the software world, to the point in which all major areas of software innovation are happening on open source platforms. Perhaps these companies don’t see the need to embrace a larger mission, when that very mission seems quite capable of sustaining itself. In their thinking, the hard work of establishing open source as a viable methodology for creating the world’s best software has already been done. Why put time and money into something that doesn’t need a boost?
I would counter that there is still much to be done, especially for end-user facing software and platforms. Furthermore, expanding the open source mission to under-represented communities would lead to great gains for both the technology world and those communities. The benefits for those who solve that problem are immense—who’s going to expand their OSPO to take it on? The point is, if a core factor in Google’s uniqueness and success is its embrace of a problem space that’s larger than simply its immediate business objectives, isn’t there something to learn from that?
Technology vendors vs. other companies
Now that I’ve covered why an organization such as Google would create an open source program office, let’s consider tech company efforts. As I mentioned, software companies and other companies that don’t sell or support software as a primary business have different objectives and challenges to creating an OSPO. Whereas a primary software-development goal for organizations is to create better solutions for internal use, software development vendors often will see open source initiatives as a better way to distribute software products to the far reaches of the globe. This could also explain why some software development vendors have fallen behind when it comes to open source participation and influence—the fear of losing software (or software support) sales outweighs what they think they would gain by participating more aggressively in open source ecosystems.
This could be described as extreme risk-aversion from technology vendors. After all, if they’re making high-margin money from the sales of software products and services, why risk that just to influence open source ecosystems? After all, it’s easy for companies that don’t sell software to decide that they want to collaborate more deeply with open source ecosystems, and the subtext of that participation is one of avoiding vendors, so why would vendors help them along? The reason is because the market for old-fashioned vendor-supplied software deployed on premises is shrinking by the day. As you probably know, it’s an open source world now, and a company’s success can be directly tied to how much they participate in these ecosystems. So companies that get this continue to grow and expand whereas others, not so much. In this context, I have to wonder why a technology vendor in 2016 would not decide that strong investment into open source technologies is the right way forward.
In fact, think back to the late 1990s and early 2000s and IBM’s news splash around their $1-billion investment in Linux, with their “Peace, Love, and Linux” marketing campaign. Vendors must see themselves as between a rock and a hard place—investing in open source carries the risk of aiding other companies and losing potential sales, whereas not investing in open source carries the risk of being bypassed entirely by the technology world.
In the end, however, technology vendors have no choice—collaborate or die. They can willfully disregard trends as long as they want, but ultimately it’s to their detriment. They would do well to borrow a few pages from Google and other TODO Group participants and take a holistic approach to open source ecosystems: Which ones are of strategic importance, and how can participation help go to market more quickly with new products and services? And for an extra dash of magic, Google has shown that embracing a mission outside of a company’s primary product focus yields results as well. But hey, one step at a time.
