“One of the biggest changes in open source in our lifetimes,” noted Sam Ramji, chief strategy officer at DataStax, is cross-industry, open source collaboration in every industry. Open source has become the default way we work, whereas it was once isolated to relatively few developers and a smattering of tech companies, like Red Hat. But how companies embrace and enable it is still more art than science. In an interview on the Under the Hood of Developer Marketing podcast moderated by Ramji, he teased out the principles and practices informing how Google, Comcast, and Microsoft work with open source, which may well work with your company, too.

SEE: Linux file and directory management commands (TechRepublic Premium)

Is it strategic?

When considering whether to open source code, “developers make the decision” at Comcast, said Nithya Ruff, who runs Comcast’s open source program office. The company doesn’t impose mountains of bureaucracy to stop code from being open sourced. Rather, Ruff’s “advisory council is purely advisory. Our job is to make the whole process as easy as possible, and to help them do it right.”

Chris DiBona, who runs the open source office at Google, agreed:

I like to think of myself as a very, very efficient bureaucrat. And my bureaucracy is one that is so easy to use that you’ll always want to talk to us when open sourcing, or look at our internal website, or even our external one. And you’ll get all these great tips. And we’re just trying to get out of the developer’s way most of the time.

But surely sometimes these companies have a more involved process when strategic code is involved? Yes, said Ruff: “The time management gets involved if it’s a strategic contribution…[like our] CDN, and we want to contribute it outside the company for a very strategic reason, either to create a standard or to create an ecosystem or maybe to commoditize a certain area.” For Google, added DiBona, projects like Go, Chromium, and Android require “a lot more high touch time, considering the issues, considering the developer impact, considering the impact on the company and the individuals who work on it.”

But I loved what he said next: “But I know that if I don’t [take care of] the engineer who just wants to fix something, or release a patch, or release a small project…then when we want to go do those really big things, it’s very, very difficult. There’s too much stop action.”

So perhaps lesson #1 is this: For companies that want to manage big, strategic open source initiatives, they first need to ensure they’re taking care of the more mundane, day-to-day activities. 

A seat at the table

In the musical “Hamilton,” the actors sing about being in “the room where it happens,” but for companies considering why they should contribute and not merely consume open source, “The language that appeals to enterprises in general is ‘you have a seat at the table,'” said Ruff. She added: 

You actually get to influence things if you contribute back. If you don’t contribute back, you have no say in what happens at the table. And they get that, because it’s very similar to standards bodies, which a lot of companies know how to work with. You need to be at the table to put your two cents in. And the way it works in the open-source community is by contribution of any kind. 

Such contributions include code, of course, but, as Microsoft’s Stormy Peters suggested, code isn’t sufficient. Beyond code contributors, “Any good software project has lots of people that participate in it, from users to people that are writing documentation, to people at the conferences actually spreading the word and talking to other people.” In addition, she noted, corporations can add functions like product managers or people looking out for accessibility needs.

On that note about code being insufficient, the code isn’t useful if no one knows about the project, or knows about it but doesn’t know how to use it (which is where great documentation and operationalization of the software come into play). As the panelists stressed, we need to stop thinking of open source as just a matter of code–and code tends to be written by a relatively homogeneous population of white, middle-aged males, as DiBona lamented in the interview. 

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic) 

And for those companies that are trying to figure out their open source program office to help them navigate this decades old but still nascent open source thing? Peters had a very practical suggestion:

Here’s the secret….Go out and make your virtual team across your organization. I’m sure there’s someone in your company, in the legal team, who thinks open source software is fascinating. Go find that person and recruit them to help you. I’m sure there’s someone in the CIO or IT department who thinks open source software is fascinating. Go find them. There’s probably somebody who’s already brought open source software into parts of your organization. Find them.

Find them and form them into a virtual, cross-company team–which is, of course, how cross-industry open source collaboration happens, too.

Disclosure: I work for AWS, but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see