How enterprise IT pros can contribute to open source projects

When I first wrote about open source software in the 1990s, I regularly had to explain its virtues. Many businesses—particularly large companies—were frightened by what they saw as open source’s weaknesses, such as the lack of “one neck to wring” and perceived security vulnerabilities. How quaint. Today, nearly every business uses open source software.

One thing hasn’t changed, though: corporate reluctance to contribute to open source projects. Or, more to the point, in too few enterprise organizations are programmers and tech staff granted the time and freedom to participate in the open source development process.

According to a recent Black Duck survey, 65 percent of companies contribute to open source. And a DigitalOcean report, "Developer Trends in the Cloud: Open Source Edition," found that more than half of the 300 international developers it surveyed contribute to open source. It might be more, but 30 percent of survey respondents said a primary barrier to them doing so (or doing so more) is that their company doesn't give them time to contribute.

Your company might rely on a given open source tool, whether it’s Grommet, Kubernetes, or Tensorflow. If you find a software defect, you might be free to fix it and submit the fix to the project owners. But you may get resistance (or a firm "no way") if an open source project does 90 percent of what you want and you want to propose writing the other 10 percent and perhaps become a committer.

If you want to change that attitude—at least in your own shop—follow our advice. It can help you take a lead in making your company an active participant in creating and maintaining the software it depends on.

Change your company's culture

Open source innovation has a methodology all its own, and it doesn’t follow traditional business processes. The big difference is that open source development is collaborative rather than competitive. This attitude may come naturally to IT people, but not to managers and rarely to people in the C-suite.

To make your company friendly to open source development, you need support from across the company.

"Individuals, not companies, change culture, and open source is ultimately a cultural thing, not a technology thing," writes Matt Asay, Adobe's head of developer ecosystem.

Any meaningful business change needs a champion. You probably have observed this in small technical realms, such as the programming lead who steps forward to say, “It’s time to change from tool A to tool B” or the IT manager who creates a presentation demonstrating why it’s time to consider adopting edge computing.

To change the culture, your company needs to establish someone to serve as its open source champion. That sounds as though it’s a cheerleading exercise—and to some small degree it is—but it’s more than that. The champion’s role is one of technical management and leading by doing, not just talking. The champion works to support open source software not just in the IT department but throughout the business.

Someone has to represent the company’s open source efforts to sell decision-makers on open source benefits and address friction between the “we’ve always done it this way” laggards and the techies drawn to the shiny and new. If the company has a fair-minded open source champion, technical staff can know who to call for help. However, the role doesn’t mean “always pick open source.” Rather, it’s a diplomacy mission to balance how much time can be reasonably devoted to projects that are “sort of but not quite” in the same knowledge domain, such as working on tech standards alongside competitors.

That someone is you. That may not be in your comfort zone, but it needs doing.

OK, perhaps that isn’t the job description you want, personally. For many introverted tech staff, that sounds way too far away from “just let me write code.”

However, if you want the business to become more open source-friendly, you need to do your best to ensure that someone picks up the role, formally or otherwise.

Don’t worry that there’s a secret design pattern you must conform to. No one can give you a perfect answer. As Jeff McAffer, director of Microsoft's Open Source Programs Office, says, "There isn’t a one-size-fits-all model. I can’t stand up in front of a crowd and say, ‘This is how you should do it.'"

Sell the benefits

To change the corporate attitude about permitting developers to be embedded in open source projects, you need to get other departments to see the benefits in their own terms.

One way to handle this is by finding allies outside software development circles. For instance, human resources execs could be on your side if you can convince them that companies that support open source development are more attractive to prospective employees. A CFO who is motivated by financial cost savings can “do the numbers” for you to, for argument’s sake, demonstrate that investing in a developer who spends 20 hours weekly working on an open source project is still more cost effective than purchasing a not-quite-right IT application.

One common concern across business units, for example, is whether a business that isn’t inherently a tech company should be in the business of writing software. The top brass may say, "We're not a software company." Yet companies like Walmart, perhaps the last business you'd think of as a software company, has a huge open source software investment.

Another common worry regards working with competitors. Yet, when Dawn Foster, open source software strategy lead at Pivotal Software, did her PhD on Linux kernel developers, she found “rivals” working with each other every day. "When Linux kernel developers were working with other developers, they said they saw each other first as fellow programmers working on common problems rather than as competitors," Foster said at Open Source Summit Europe 2018. Clearly, a "team of rivals" can work.

One element in that argument, as software engineer Robert Kowalski observes, is that open source retains employees. Encouraging staff participation in open source projects increases employees’ practical technical skills and gives them a space where their work is publicly valued beyond the company. At a time when businesses struggle to find top-level software engineering talent, that's a big deal.

Organizing open source within your company

A verbal buy-in is a good starting point, but your next step should be to bring open source into your company's structure. Many Internet-scale companies have established formal open source programs—sometimes referred to as open source program offices—including Google, Facebook, and Twitter.

You should consider starting your own open source office. As John Mark Walker, founder of the Open Source Entrepreneur Network, explains, “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.”

Maybe your business isn't ready to make that jump. Fine. Start by creating an open source office that encourages, monitors, and manages open source software use within your company. An open source office lets businesses tie the software process directly to a company’s long-term business plans. It's one step closer to your company enabling its employees to contribute to open source projects.

Remember when IT departments kept inventory systems that recorded the proprietary applications the business used? In part, that was to track licenses, since you paid for 100 seats and didn’t want to get dinged if it turned out 250 people were using the software. Some of us still do that. But another reason for the software inventory was to help everyone stay on the same page with end-user applications and tool sets. The tools ensured that help desks and IT didn’t go wild maintaining three different versions of similar applications. An open source office can serve the same purpose. Had Equifax had such an office, it could have avoided its security fiasco, which resulted from using an out-of-date and thereby insecure version of Apache Struts.

Implementing the open source switchover

An open source office lets businesses tie the software process directly to a company’s long-term business plans. The TODO Group, a group of companies that collaborates on open source business project best practices and tools, recommends that an open source office's responsibility should include:

• Clearly communicating the open source strategy within and outside the company
• Owning and overseeing the strategy execution
• Facilitating the effective use of open source in commercial products and services
• Ensuring high-quality and frequent releases of code to open source communities
• Engaging with developer communities and seeing that the company contributes back to other projects effectively
• Fostering an open source culture within the organization
• Maintaining open source license compliance reviews and oversight

Regardless of your company's situation, moving to corporate open source always requires the following steps, according to Chris Aniszczyk, vice president of developer relations at the Linux Foundation:

• Choose a leader. This individual should have enough authority to champion open source's cause at the executive level. Fortunately, TODO Group provides a list of sample job descriptions.
• Define the open source office structure. That may mean placing the office within the legal department, within an engineering department or the marketing department.
• Set policies and processes. Standardize the methods for implementing your organization’s open source strategy.

Just as with open source software, you can build on the work of others. Some companies, such as Google, publish their policies publicly. TODO Group offers examples of corporate open source policies and how companies have integrated open source into their corporate structure.

If nothing else, the organization can help support open source champions with useful advice. For example, some communities are more in keeping with your technology goals than others. Sure, ideally, you might want your company to allow its developers to work on any project, but start by getting permission to work on programs that tie directly into your company's mission.

You might start out by thinking that the goal is to “convince my boss to let me spend 10 hours a week working on this open source tool.” While that solves today’s problem, the better long-term approach is to shift the company’s attitudes about participation in the open source ecosystem. The best way to accomplish that is to align with business process. You can convince your company to not merely use but invest in open source software.

Contributing to open source: Lessons for leaders

• Your company can benefit greatly not just by using open source, but by contributing to it as well.
• By embracing open source development within your enterprise, you gain a seat on how your primary programs are developed.
• Companies that work with open source keep their best and brightest employees.