Open source is nothing new, but bringing open source to your company still requires building a strong foundation.
That foundation rests on open source culture, Arun Gupta, VP and GM of the Open Ecosystem at Intel, says. He should know: Sun Microsystems*, Oracle*, Red Hat*, Couchbase*, Amazon Web Services* and “the fruit company” have all counted on his open source expertise.
“The best way to solve the world's toughest problems is through open collaboration,” he says in a recent keynote at SCaLE 20x. “Open gives you diversity, open gives you inclusion, open gives you transparency, open gives you effective problem solving and open gives you that trust in the solution.”
The pillars? There are seven: Building a business case, an open source program office (OSPO), inner source, internal events, participation in open source foundations, advocacy, and “chop wood, carry water” (abbreviated as CW^2) — or all the unglamorous maintenance work. You can start small, but make sure the starting place isn’t seen as a hobbyist niche.
“The strategy is the culture, the explicit force you need to bring down to the engineer level. That's what defines a culture,” he says. It’s not just a question of principle, either. “After having worked in multiple companies, open source needs to be tied to the business case of the company. It can happen on fringes but then it stays on fringes, it doesn't become critical to the company. Otherwise it’s not sustainable.”
That first step can be to create an OSPO. To spark that open source culture in your company, setting up and establishing an open source program office is fundamental, Gupta says, even if it’s just one or two people. “Start small, let it grow from there because the whole role of an OSPO is to foster an open source culture in an organization.”
When he joined the Cupertino company, for example, there was no OSPO. His first move was to set that up, bringing people together in a central place to voice open source concerns. “It really defines how you're going to consume and going to produce open source — and work with the engineering, legal, marketing and PR teams. All of that discussion is super important.”
Internal coordination is a major plus, but the OSPO also guides work with upstream communities, streamlining the contribution process, identifying the bottlenecks and possibly introducing tools that make easier to contribute to open source.
Infographic courtesy Linux Foundation* Research.
The building block after the OSPO? Inner Source, or applying open source principles and best practices to closed source software. In practice, that means having things like a unified code base with visibility and transparency, an issue tracker, GitOps methodology, continuous integration and development (CI/CD). (For more details, he suggests checking out docs.gitlab.com.)
“You discover that you don't need to start from ground up, 80% of your needs are already met — pretty much the same open source principles can now be applied within the context of your enterprise software,” he says. The key reasons an inner source strategy should be adopted inside your company include:
- Discovery
Find what solutions already work in the company, instead of siloed teams re-creating the same ones - Collaboration
Open source-type solutions allow teams from all corners of the globe and company to work together - Quality
Projects that survive in the open are the strongest, with the best testing and security practices - Infrastructure
Establishes a bedrock for “how we do code” at the company and allows for practices like CI/CD, corporate wide
There are four more key elements for shoring up open source at your company: Internal events, participation in open source foundations, advocacy and CW^2. Internal events foster cross-team collaboration, provide visibility to projects, act as a recruiting tool and provide a low-key environment for people to talk about what they’re working on. It’s a classic case of “left hand, meet the right” Gupta says. Once you know what the engineering teams are working, he adds, in conversation with the leaders “one source is born and then you know you can do a lot more collaboration.”
As for foundations, they advance open ecosystems because they thrive on the principles of open transparency, collaboration, diversity and inclusion. “By participating in these foundations you're really at the forefront of defining and maintaining technologies and standards,” he notes, even if you aren’t able to participate in the staggering number — over 700 — that Intel collaborates with. Internal advocacy is another often overlooked but important element. Internal evangelists who work in different parts of the company can help ensure business needs are met by influencing policies, raising awareness and boosting education, and prepare better business cases with the OSPO.
Finally, CW^2 is a Zen proverb: “Before enlightenment, chop wood and carry water. After enlightenment, chop wood, carry water.” How does this translate to open source?
“People think open source means all the glorified work of sending the pull request, creating a brand-new feature, becoming a maintainer and that's the end of it. That's probably 20% of the work.” Taking example from a project like Kubernetes*, he notes that a lot of the work involves helping behind the scenes, logging in the hours to get the “unglamorous” tasks done. Someone sent a pull request, then someone needs to do the code review, someone has to debug, someone has to give it the ‘looks good to me’ and OK it. There’s a lot more work than just the actual code contribution.
People need to be incentivized to do this work, he says, they need to know “this work is valued and I'm going to count that work that you're doing in the community…otherwise, it becomes like a dying hobby.”
Catch the whole 55-minute talk on YouTube.