Having a written strategy for your open source projects and contributions is often the difference between being successful in the years to come or constantly fighting to keep people and resources allocated to your project. The most important place to start is to align your open source strategy with the overall business goals for your company. This alignment will help you make the case to senior management and company executives who aren’t likely to be involved in the low-level details of your projects. By having written documents that explain how your open source contributions support the goals of the company, you can help the executive team understand the importance of this work while also helping your employees understand how their day-to-day work contributes to the competitive advantage of the company.
One element of the strategy is to decide where to contribute. Which open source projects are strategic for your company? Is there a project that your operations team uses to run your critical enterprise infrastructure? Are there development or deployment tools that impact your ability to release revenue-generating products? Is there software that is important for your ability to deliver customer-facing products or services? All of these questions should be considered when deciding which open source project to participate in.
Next, you’ll need to figure out how many people you need and what skills are required. In some cases, you might have employees with the right skills. However, you need to keep in mind that contributing to open source projects requires different skills than participating in internal projects. These people need to be comfortable in an ambiguous ecosystem where they will receive feedback—possibly difficult or negative feedback—and be expected to respond to this feedback publicly and professionally. Keep in mind that not every developer wants to work under a public spotlight.
If you don’t have the skills internally for open source, you might be able to find existing contributors that you can hire, but you need to be careful because you don’t want to get a reputation for aggressively poaching employees from other companies. It requires a bit of nuance to make it known that you are interested in hiring people to work on an open source initiative without aggressively hiring them away from other employers developing open source technology.
Your business strategy should also include developing guidelines or processes to help people engage in open source development in ways that connect to your overall business objectives. These often contain guidance about open source license information, avoiding accidental disclosure of confidential information (which we discuss here) and internal review processes. My caution about guidelines and processes is that they can be written in ways that discourage contributions when they use scary legal jargon with an emphasis on punishment for mistakes. Instead, you’re often better off writing the guidelines in ways that help engineers understand what you need them to do and why in language that can be easily understood. These guidelines and processes should live in a strategy document to make it easy for your employees to contribute to an open source project.
If you are planning to have a lot of open source collaboration across many projects, then it might make sense to build an open source program office to help manage the process and to be a resource for your contributors to get help and guidance. An open source strategy forum can provide your contributors with a platform to share ideas, collaborate with other developers and spark innovation as well.
As with any good business strategy, the outcome and results should be measurable so that you can tell whether your efforts were successful. But, how do you decide what metrics to use? What you measure depends on what you are trying to achieve. Ultimately, you need to look at your strategies and plans to come up with criteria that will help you measure whether or not you are successful. For example, if you want to improve the performance of a particular piece of software (including open source software), you’ll want to have success criteria and measurement based on specific types of performance. If you want to gain influence within an open source project, maybe you measure increases in contributions or the number of employees moving into positions of influence within the open source community.
Once you determine the criteria, you need to ensure that you have the data required to measure it and start measuring it now to get a good baseline. There are many of open source tools available to gather contribution data about projects. Some of the commonly used tools can be found in the Linux Foundation’s CHAOSS project. I also recommend over-measuring and gathering as much data as you can about your participation so that if your strategy shifts in the future, you’re more likely to have some baseline data to start out with. Having some extra data can also help you investigate other ideas for how you might want to improve your participation in the project.
In summary, build your open source strategy by clearly showing how it helps your company achieve its overall goals, and then create metrics that allow you to measure whether you are successfully implementing your strategy. By having a clear strategy with success measurements, you can justify your open source projects to “the suits” and continue to do great work in the years to come.