Posts

Open Source Leadership

Building leadership in the community is key to establishing trust, enabling collaboration, and fostering the cultural understanding required to be effective in open source.

How important is leadership for evolving open source projects and communities? According to the most recent Open Source Guide for the Enterprise from The Linux Foundation and the TODO Group, building leadership in the community is key to establishing trust, enabling collaboration, and fostering the cultural understanding required to be effective in open source.

The new Building Leadership in an Open Source Community guide provides practical advice that can help organizations build leadership and influence within open source projects.

“Contributing code is just one aspect of creating a successful open source project,” says this Linux Foundation article introducing the latest guide. “The open source culture is fundamentally collaborative, and active involvement in shaping a project’s direction is equally important. The path toward leadership is not always straightforward, however, so the latest Open Source Guide for the Enterprise from The TODO Group provides practical advice for building leadership in open source projects and communities.” 

Indeed, the role of leadership in open source is often misunderstood, precisely because open source projects and communities are often structured to encourage highly distributed contribution models. Their distributed structure can obscure the need for central leaders who set goals and measure progress.

More Resources

In addition to the new guide, previous Open Source Guides for Enterprise explore related aspects of open source leadership. Here are some good ones to investigate:

  • Creating an Open Source Program. Open source program offices are emerging as critical to providing good leadership, and this free guide delves into how they can become designated places where open source is supported, nurtured, shared, explained, and grown inside a company.
  • Measuring Your Open Source Program’s Success. Good leaders of all types are skilled at measuring progress, and they stay on top of the right tools for working with metrics and project management. This free guide lays out a clear path for open source leaders to measure progress and set goals.
  • Recruiting Open Source Developers. Guy Martin, Director, Open at Autodesk, has noted that when interviewing developers, he is frequently asked how the company will help the developer build his or her own open source brand. Today, leadership calls for strategically appealing to developers and this free guide includes many best practices.
  • Improving Your Open Source Development Impact also delves into these topics. It examines various ways organizations can improve their internal development processes and prepare to contribute to open source projects.

Building Leadership in an Open Source Community, which features contributions from Gil Yehuda of Oath and Guy Martin of Autodesk, looks at how decisions are made, how to attract talent, when to join vs. when to create an open source project, and it offers specific approaches to becoming a good leader in open source communities.

“Companies often go through a phase of thinking ‘Oh, well, we’re huge. Why can’t we pound our fist on the table and just make the community do what we want?’ They soon come to realize that tactic won’t work,” writes Martin, in the guide. “They come to understand that the only way to gain leadership is to earn the role within the community. And the only way to do that is to gain credibility and make contributions.”

You’ll find the complete guide here, and you can browse an entire list of free Open Source Guides here.

Open Source Guides

The Open Source Guides for the Enterprise are now available in Chinese.

The popular Open Source Guides for the Enterprise, developed by The Linux Foundation in collaboration with the TODO Group, are now available in Chinese. This set of guides provides industry-proven best practices to help organizations successfully leverage open source.

“Making these resources available to Chinese audiences in their native language will encourage even greater adoption of and participation with open source projects,” said Chris Aniszczyk, CTO of Cloud Native Computing Foundation and co-founder of the TODO Group. The guides span various stages of the open source project lifecycle, from initial planning and formation to winding down a project.

The 10 guides now available in Mandarin include topics such as:

  • Creating an Open Source Program by Chris Aniszczyk, Cloud Native Computing Foundation; Jeff McAffer, Microsoft; Will Norris, Google; and Andrew Spyker, Netflix
  • Using Open Source Code by Ibrahim Haddad, Samsung Research America
  • Participating in Open Source Communities by Stormy Peters, Red Hat; and Nithya Ruff, Comcast
  • Recruiting Open Source Developers by Guy Martin, Autodesk; Jeff Osier-Mixon, Intel Corporation; Nithya Ruff; and Gil Yehuda, Oath
  • Measuring Your Open Source Program’s Success by Christine Abernathy, Facebook; Chris Aniszczyk; Joe Beda, Heptio; Sarah Novotny, Google; and Gil Yehuda

The translated guides were launched at the LinuxCon + ContainerCon + CloudOpen China conference in Beijing, where The Linux Foundation also welcomed Chinese Internet giant Tencent as a Platinum Member. 

Capital One Open Source

Lessons Learned on Our Open Source Journey at Capital One.

Most people know Capital One as one of the largest credit card companies in the U.S. Some also know that we’re one of the nation’s largest banks — number 8 in the U.S. by assets. But Capital One is also a technology-focused digital bank that is proud to be disrupting the financial services industrythrough our commitment to cutting edge technologies and innovative digital products. Like all U.S. banks, Capital One operates in a highly regulated environment that prioritizes the protection of our consumers and their financial data. This sets us apart from many companies who don’t operate under the same level of oversight and responsibility.

Our goal to reimagine banking is attracting amazing engineers that want to be part of the movement to reinvent the financial technology industry. During interviews, they are often surprised to find we want them to use open source project and contribute back to the open source community. Even more are blown away that we sponsor open source projects built by our engineers.

People expect that kind of behavior at a start-up, not a top bank. There is nothing traditional about Capital One and our approach to technology.

When we see opportunities, especially in technology, we deliberately pursue them. Our approach to managing technology, guided by general industry regulations and company-specific policies, provide the guardrails for using, contributing to, and launching open source software projects. The Open Source Office adopted a comprehensive risk management approach wherein we have identified clear risk ownership around when to use, contribute to, and launch open source projects.

Our journey to managing open source risk and implementing this strategic approach followed this trajectory:

  • Engineers wanted to use and contribute to open source projects.
  • Risks were identified, analyzed, and a path to managing them was mapped out with the Open Source Office, Legal, and Security teams.
  • Focus on education, with external partnerships providing guidance (Linux, TODO, etc.).
  • Momentum increased as we matured our internal partnerships with Engineering, Legal, Security, and Audit Teams.
  • Explaining and demonstrating our risk management approach to leaders secured sponsorship and resources.

Organizing Into an Office

With strong leadership support, in 2015 we formalized oversight and governance through the creation of Capital One’s Open Source Office (OSO). With strong partnerships in Legal and Security, resources accountable for advising and overseeing open source activities were established within the OSO.

Through these partnerships, the OSO team manages the company’s open source contributions, including these three crucial pillars:

  • Manage direction — Policy, guidance, and education.
  • Manage connections — Internal and external, as well as partnerships with Legal, Security, and other stakeholders.
  • Manage technologies — Support open source processes and community needs.

As a horizontal function, OSO manages the direction and risk-based approach Capital One takes with open source. We collaborated to define a corporate level policy for Open Source Software and developed educational materials and videos to guide teams and individual developers on how to manage defined risks. On a daily basis, OSO team members, along with our partners in Legal and Security, work with engineers and data scientists to understand use cases and provide guidance on how to appropriately manage risk.

In addition to OSO managing internal connections with various teams in Capital One (Engineering, Legal, Trademarks, Security, Brand, Corporate Communications, Risk Management, Audit etc.), we actively manage our relationships with external communities such as the Linux and ApacheFoundations. We are also active members in the Open API InitiativeCloud Native Computing Foundation (CNCF) and the TODO Group. We are also actively interacting with members of our own open source project communities (e.g. Hygieia and Cloud Custodian).

Formalizing Guardrails Through a Corporate Policy and Standard

In 2016, the OSO defined a corporate level Open Source Software Policy and Open Source Software Standard based upon an example from the Linux Foundation. The policy addresses three use cases and calls out the requirements to manage risk when:

  1. Using open source software projects.
  2. Contributing to open source projects.
  3. Sponsoring open source projects

The policy also formalizes accountabilities for the three main open source stakeholders at Capital One, including:

  1. The developer/engineering community.
  2. Establishes a new strategic partnership between from diverse groups called the Open Source Steering Committee.
  3. Defines the tactical partnership between OSO, Legal, and Security within an Open Source Review Board.

image alt text

As we developed this policy and formalized accountabilities, we established the tactical partnership between OSO, Legal, and Security as the OSRB. This tactical team works to guide open source activities with the development community. We also established a strategic leadership committee named the OSS Steering Committee, a group comprised of a dozen leaders who provide strategic direction for the development community.

Taking it to the Next Level

As we look ahead in our open source journey, we plan to focus on:

  • Continue to educate our growing technology organization.
  • Strike a balance between managing risks and minimizing development bottlenecks.
  • Further automate license and security scanning and integrate it into our build process.
  • Establish and grow a robust governance function.

Specifically, in 2018 we’re focusing on education, strengthening awareness in the development community, and establishing our role as an advisor.

image alt text

Collaboration among the multiple stakeholders has been key to navigating our open source journey. Capital One is a technology driven company and we are unified across our organization on taking our open source activities to the next level in 2018.

At the end of the day, we strongly believe in the benefits of involvement in open source projects. By managing the associated risks through policies, standards, and cross-departmental collaboration, the OSO allows Capital One to fully leverage our involvement in this community.

Acknowledgments

Thank you to Nadine Hoffman and the Capital One OSPO for contributing this guide based on this original article.

This article originally appeared on GitHub as part of the TODO Group’s open source program case studies.

open source and standards

Red Hat is a testament to the success of open source, but it still benefited from some organization and goal-setting in its community efforts.

Red Hat is, by its very nature, a deviation from the norm in this series of profiles. It is not a company with an open source program, but rather an open source company with an open source and standards office and an engineering team dedicated to curating communities and tending upstream contributions. In essence, Red Hat is a living, breathing testament to the success of open source. However, it still benefited from some organization and goal-setting in its community efforts.

“The Open Source and Standards office, or what some would refer to as an open source program office, was established six years ago to create a consistent way to support communities which Red Hat is actively participating. We created a centralized organization of expertise and resource to support our goals by flanking the considerable upstream engineering efforts ,” explained Deborah Bryant, senior director, Open Source and Standards, in the office of the CTO at Red Hat.

However, there wasn’t any need to advocate open source or push for its adoption internally. Red Hat started from day one as an open source company rather than approaching open source later, so everyone on board was already firmly in the open source camp.

“Most open source program offices are chartered to encourage and enable engineers to contribute to open source, or to educate people on what open source is, or to assist in choosing an open source license. These are things that are a done deal at Red Hat,” says Bryant.

“Rather than just seeing how we can use open source to improve our business, or be more flexible in operational efficiencies, or bringing more money to the bottom line, we are at the level of maturity where open source is our actual business practice and model. And because we work first upstream (in the open source project) of our products first, community success is critical.”

Therefore, the focus is supporting open source projects and the ecosystem rather than on transitioning to open source.

“For us, open source is an important part of our business model, and our business goals are to make sure that those communities that we rely upon are healthy and thriving,” said Bryant.

In Red Hat’s open source toolbox

Having goals is one thing, achieving them is quite another. Several tools can be used to measure progress and results. Red Hat uses a range of tools to make sure to, and communications-based tools top the Red Hat list of must-haves.

“Collaboration tools are a very big deal for us, because we have a high degree of collaboration across engineering and product and business lines. I know I’m probably understating that, but collaboration across Red Hat is huge,” Bryant said.

The company also uses the kinds of open source project, program and community tools you would expect, as well as Kanban boards for organizing tasks.

“A lot of these are developed organically, independently through the communities that we support – they pick the tools that work for them. We use Kanban boards to track progress. We measure using metrics that are established community by community and also in terms of what Red Hat’s hoping to influence through contribution. We use both publicly published metrics and internal metrics for custom boards,” says Bryant.

The team also started using OKRs, or Objectives and Key Results. The framework is used to define and track business objectives and outcomes. Red Hat plans to use OKRs across projects to connect the business side of Red Hat with the work of product managers and engineering to better support long term objectives.

Bryant says that “probably the most essential communications tool we use is IRC.” The acronym stands for Internet Relay Chat and it’s a system used for real-time communications between people anywhere on the planet.

“Most of us are working virtually over five or six or different time zones. IRC is our virtual building, our team is there and collaborating on a conventional level,” she said. “We use a tool called Telegram to do logistics and coordination when we are traveling at big events.”

Measuring Success

At Red Hat, success is defined differently for each open source project.

“When you talk about measuring upstream contributions and such, we actually go through a formal process on an annual basis, and then we refresh it several times a year to define what the success criteria are with the folks here at Red Hat who have the biggest stake in the project,” says Bryant.

“But in other cases, such as Fedora, where we have a lot of Red Hat contributors, we’ve started to measure the number of upstream contributions from other organizations, and not just from our own. For us, healthy ecosystems are a key goal, so we measure our successes partly by measuring how many other contributors there are.”

Dave Neary, a senior principal software engineer working on SDN and NFV in the Open Source and Standards office, added another example in OpenDaylight.

“There is already an ecosystem of companies that contribute to OpenDaylight, and there is a developer team inside Red Hat. Our goal could be to increase the adoption of OpenDaylight as an SDN backend for OpenStack, for example. Or, it could be to increase the awareness of OpenDaylight as an end-to-end network management solution. That is a very different goal, with different stakeholders, and you would measure different things,” he said.

“The goals are going to be different from one project to another. One project may care much more about developing the user community, while another project may care much more about growing a vendor ecosystem.”

Acknowledgements

We would like to thank Dave Neary (senior principal software engineer working on SDN and NFV in the Open Source and Standards office and CTO’s office) and Deb Bryant (senior director, Open Source and Standards, in the office of the CTO at Red Hat) for contributing content to this article, along with Pam Baker who performed the interviews.

open source program

Gil Yehuda, Senior Director of Open Source at Oath (which owns the Yahoo and AOL brands), describes the company’s open source goals.

For seven years and counting, Gil Yehuda, Senior Director of Open Source at Oath Inc. (which owns the Yahoo and AOL brands), has led the open source program at Yahoo. Now with an expanded scope, he is gearing up to grow his team and improve the program. The company’s formal open source program office serves as a hub to connect all open source activities across the company, he says, but it didn’t start out that way.

As with many other companies, the open source program started informally with a group of diligent engineers and a few legal people. But the ad hoc group soon realized it needed a more formal program if it was going to be able to scale to address more issues and achieve specific business goals. With a formal program in place, they are poised to achieve its goals.

The top five of Oath’s numerous open source goals, according to Yehuda, are:

  1. Keep aligned with the industry on open source technology standards by avoiding creating unique tech stacks that Oath alone would have to manage at its own expense.
  2. Make it easy for engineers to interact with open source as users and as contributors.
  3. Be viewed as an open source friendly company for partnerships and collaborations.
  4. Be known as a great place for engineers to work on open source projects.
  5. Give back to the Open Source community by sharing code and practices.

Measuring and monitoring success requires the right tools and attitudes. Yehuda says at Oath they actively solicit and listen to the needs of their many engineering teams, track all their work transparently in Jira, and spread the work across many teams who help with the process.

“We have custom tools we use to check code and manage projects, but we’re hoping to work more with our peers in the TODO Group on tooling we can share across many of our peer open source program offices,” he said.

Success comes from being open, at scale

Yahoo helped make Apache Hadoop the cornerstone of the big data revolution when it took the early code and created a team around it to help it scale to Internet-scale. They agreed to publish it all as open source. When the need for real-time processing came to the forefront, Yahoo created S4 and open sourced it too, but then discovered Storm was just published, too, and it looked more promising. The team ditched their own code and put their efforts into helping make Storm even better.  

“We applied to Apache Storm what we learned from Hadoop and S4,” Yehuda said. “Our goal was to make it great, even though it kind of competed with our own first stab.”

Storm is a success today, and the company runs it alongside Hadoop to power many of its products. They added machine learning and high-scale data serving capabilities by adding Vespa Engine, to their platforms, and then published that too. And they helped other machine learning projects scale better too, all by publishing open source.

“We’ve leveraged our expertise with Storm to help both Caffe and TensorFlow achieve better scalability. We don’t own these solutions exclusively. Rather we share our code and help others — all the while we get to leverage our expertise to build one of the industry’s most scalable platforms for our use,” he said. “This saves us money while making us a fantastic place to work on projects that impact hundreds of millions of people.”

The program office worked on strategy, legalities, and execution of these and similar projects. Leveraging open source licensing and processes effectively was a key element throughout. Now as Oath, this work continues and expands.

Yehuda cited three key lessons he learned managing an open source program:

  1. Be a service to the engineers, not a barrier.
  2. Accept that challenges will be never-ending.
  3. Run the program office like you run an open source project: Be transparent in the way decisions are made and be open to input and collaboration from everyone.

“There are so many edge cases that come up — partnerships, acquisitions, unclear contract terms — and we simply need to be open to learn, explore, and come up with an answer to every open source related question. But the most rewarding part of my job is when people tell me they joined our company because they knew about our open source friendly culture. You know, we’re always looking for open source talent, and I’m hiring into the program office.” added Yehuda.

dropbox

One of the most important things when building an open source community is making sure that your own processes are open, according to Dropbox’s Luke Faraone.

The open source program at Dropbox was initially just a mailing list, where some interested engineers wanted to open source projects and develop with open source. Over time, things became more formalized, with a focus on ensuring that the company was consistent about what code it would release versus what code was best kept internal.

They also wanted to ensure that the things they were releasing were things that would actually provide value.

“We set minimum standards for what we would release as open source projects, including a review process, and our program just started to drive a lot of value,” said Luke Faraone, Security Engineer at Dropbox.

What drives Dropbox’s open source program

It’s important to ensure that the metrics and goals you track are not just related to volume, such as measuring the number of open source projects that you’re releasing or the number of lines of code you’re releasing. Those sort of metrics don’t necessarily provide business value or community value.

“We make sure to be thoughtful with our program’s goals, focusing on things that either provide back some business through external contributions or otherwise indicate that others are getting value out of our projects,” said Faraone. “We want to make sure that the community is connected back to us. Also, it is good to make sure to have fun and not have a process that is too onerous. We want people to feel comfortable working with us, and we want to be partners with folks as they work on projects. Ensuring that we have good relationships is really important.”

How Dropbox measures community success with open source

One of the most important things when building an open source community is making sure that your own processes are open.

“The more transparent you can make your decision-making processes, the more of a sense of ownership your community will have. You also want to make sure that your process doesn’t become a blocker. If your open source process for either inbound or outbound contributions is onerous, people will look to bypass the process or simply decide that contributing is too difficult,” said Faraone.

How Dropbox tracks contribution and release metrics with open source

It is important to track metrics related to contributions to projects, including such questions as:

  • What rate of contribution are you getting on a per-contributor basis?
  • Do people tend to come back to contribute to particular projects or would they also be interested in contributing to other projects that we are involved with?
  • How likely is a contributor who provides one patch to come back?

At Dropbox, according to Faraone, they also monitor the time between releases and the amount of churn that occurs between releases, where the goal is to encourage releases early and often. They also check in with teams if they have gone several months without committing to a new version.

Zulip stands out

Among Dropbox’s open source successes — if you look at the number of contributions — a project called Zulip stands out. Zulip was an open source chat system that the company acquired in 2014, but eventually they decided that they wanted to release it to the community.

“As an open source project, members of the community had set up hosting services for the chat system, and we eventually sunsetted our hosted service. We offered all of our users an opportunity to elect to have their data migrated to one of the community-operated hosting providers. What’s really impressive is that the Zulip open source project has a higher commitment velocity than it did when it had 10 or 15 employees working on it full time,” said Faraone.

Key lessons for open source program managers

Faraone offers the following tips to help ensure success when developing an open source program.

  • Community involvement can often give a project higher commitment velocity than dedicating a lot of full time employees to the project.
  • In driving community around projects, it is critical to make sure that your own processes and decisions are open and not too onerous.
  • Track metrics related to community contributions closely, including whether contributors participate in more than one project, and whether releases are arriving early and often.
  • When compared to tracking community ecosystem health and evaluating whether your program is creating business value, tracking metrics such as lines of code created has less value.
  • Evaluate whether you are choosing highly restrictive licenses, and if you are, what impact that will have as you start receiving external contributions.

You can read more TODO group case studies on GitHub.

Measure success

Measuring Your Open Source Program’s Success is a free guide to help any organization learn exactly how their open source program is driving business value.

Open source programs are proliferating within organizations of all types, and if yours is up and running, you may have arrived at the point where you want to measure the program’s success. Many open source program managers are required to demonstrate the ROI of their programs, but even if there is no such requirement, understanding the metrics that apply to your program can help optimize it. That is where the free Measuring Your Open Source Program’s Success guide comes in. It can help any organization measure program success and can help program managers articulate exactly how their programs are driving business value.

Once you know how to measure your program’s success, publicizing the results — including the good, the bad, and the ugly — increases your program’s transparency, accountability, and credibility in open source communities. To see this in action, check out example open source report cards from Facebook and Google.

Facebook’s open source program office periodically posts the month-over-month results from its open source projects internally and sends an executive report to management. “Reports are just a good way to raise awareness,” said Christine Abernathy, Open Source Developer Advocate at Facebook. “Even though Facebook places a high value on open source (as an organization), it’s still always a good thing to market yourself internally all the time and show your value.”

Existing tools can help you measure program success. You can begin by setting up the right tools for collecting data and make sure the data sources are clean and in a format that everyone can understand. Many organizations create a dashboard of metrics for their open source programs, to track all of the data in one place and provide project snapshots that can help assess progress at a glance. (See our guide on Tools for Managing Open Source Programs.)

Key metrics for measuring open source program success

There are countless ways to measure success and track progress for open source programs. Project health isn’t the only thing to track, but is important. “How do you actually get the smartest people in the world working at your company?” asks Chris Aniszczyk, Executive Director of the Open Container Initiative and COO of the Cloud Native Computing Foundation (and former head of open source programs at Twitter). “Well, you open source stuff and then you convince them to contribute to your projects.”

It helps to be able to quantify project health. GitHub’s guide on open source metrics gives a great overview of what project maintainers should pay attention to.  Some key project metrics to track are:

  • Number of contributors (and ratio of internal to external contributors)
  • Number of pull requests submitted, opened and accepted (and time remaining open)
  • Number of issues submitted (and length of time remaining open)
  • Number of commits per contributor (internal and external)
  • Number of external adopters
  • Number of projects created or contributed to (program wide)

Other metrics include popularity and awareness, influence, and program costs. As you delve into these metrics, you can concretely report everything from diversity of contributors to your projects to the number of followers you have across channels.

The Measuring Your Open Source Program’s Success guide can help you with all these initiatives and more, and it explores how to set program goals and measure whether or not they are being met. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

You can read more in previous articles, on How to Create an Open Source Program and Tools for Managing Open Source Programs. We encourage you to check out all the guides and stay tuned for more coverage of them.

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from.

Is your organization looking to build out an open source program? If so, you’re not alone, but not every organization has a holistic sense of the available tools that can help create a healthy program. A simple charter document and a few spreadsheets for tracking projects won’t cut it anymore in managing a truly robust open source program. That’s where the new Tools for Managing Open Source Programs guide comes in. It can help any organization launch and maintain a thriving open source program.

“If you have more than 100 code repositories or 100 people that you’re trying to manage, you really can’t have someone doing it manually with spreadsheets anymore,” notes Jeff McAffer, Director of the Open Source Programs Office at Microsoft, in the guide. “Obviously, people still do it that way. But it starts to become ad-hoc and laborious. That’s where tools come into play. They allow you to scale.”

While launching and maintaining an open source program does require dedicated, task-specific tools, it is a mistake to assume that your organization must necessarily build its own tools from the ground up.

“Regarding existing tools and systems, my hope is that we’re quickly getting to a point where a company’s open source program office should not need to create any tools or technologies on their own,” said McAffer. “They should be able to find and use existing open source tools which can be used to manage their open source programs.”

Categorized Tools

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from. These include Source Code Scanning and License Compliance tools, Bug Tracking tools, Release Management tools, and more. Are you familiar with FOSSology? It’s a Linux Foundation project that functions as an open source license compliance software toolkit capable of running license, copyright and export control scans from the command line. Have you heard of Docker Hub? It’s a cloud-based registry service that allows users to link to code repositories and build and test their images. These and many, many more useful tools are linked to and explained in the free guide.

Do you know how to answer questions like these?

  • How are your project APIs documented?
  • Have you laid out a Contributor Licensing Agreement that everyone can use?
  • Have you picked the right license for your project?

Various tools can help you determine the right answers to these questions, and the Tools for Managing Open Source Programs guide is a great way to surface them.

Methodologies

It’s important to understand that using open source for business strategy requires its own methodologies and processes which are very different than those needed when using and releasing proprietary software. As the guide notes:

“Nobody said it was going to be simple to move your company into the world of open source. But plenty of other companies, including giants like Microsoft and Google have done this before you and have provided detailed road maps, code, suggestions, and more to make your own journey easier. The creation of an open source program office and the selection of a package of critical tools to get your efforts started are within your grasp. By collaborating on open source projects and inviting others to collaborate with you, your company can gain immeasurable benefits and drive its progress forward with energy and innovation.”

The Tools for Managing Open Source Programs guide is one of a new collection of guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization setting up an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

These guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We encourage you to check out the guides and stay tuned for our continuing coverage of them.

Also, don’t miss the first article in this series, on How to Create an Open Source Program, which explores everything from the role of the open source program office to how successful open source programs at companies like Google function.

At organizations of all types, launching and maintaining successful open source programs has become a business priority. A strong open source program office helps to ensure that open source is supported, nurtured, shared, explained, and leveraged. With such an office, organizations can establish and execute on their open source strategies in clear terms.

With all this in mind, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published a free collection of detailed open source guides to aid companies developing open source programs. The guides are available to you now, and this is the first in a series of articles that can introduce you to the value of the guides.

How to Create an Open Source Program is the first of the guides, and it explores everything from the role of the open source program office to how successful open source programs at companies like Google function. The guide also includes insights and advice from open source experts, including John Mark Walker, Founder of the Open Source Entrepreneur Network, and Will Norris, Open Source Office Manager at Google.

“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,” notes Walker, in the guide. “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.”

The How to Create an Open Source Program guide makes clear that there is not a one-size-fits-all approach to creating a successful program. In fact, Google’s Norris notes that stakeholders from individual business units play a key role in how open source projects advance at Google.

“We allow the various business units around the company to make the decision on whether it makes sense to open source a given project from a business perspective, because there’s a lot of different reasons why you might open source a project or a piece of code,” he notes. “We’re comfortable with allowing projects to take the approach that works for them given their goals. We play more of a role of facilitating and advising.”

The first guide lays out recommendations for how to include stakeholders ranging from Legal to Engineering in the maintenance of a program office. It also delves into the importance of setting clear program policies and observing compliance guidelines.

“Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy,” said Jeff Mcaffer, director of the Open Source Programs Office at Microsoft, who was interviewed for the first guide. “Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a straitjacket full of policy that basically means that nobody can do anything.”

These free guides are extremely valuable for any organization setting up an open source program. Notably, the guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We strongly encourage you to check out the guides, and stay tuned to this space for more articles in this series.

Starting an open source program office is a growing trend among companies that leverage open source software in their business strategies.

Led by an open source program officer, open source offices can range in size from one or two advocates on an engineering team to an entirely separate R&D division. But the goal is the same: to strategically address common challenges companies face when adopting open source software.

“An open source office whether centralized or by division can bring multiple best practices on how a company can manage consumption, compliance and contribution to open source” says Nithya Ruff, the head of SanDisk’s Open Source Strategy office, in the Q&A below. “It can create a proactive plan for driving more strategic involvement in projects important to the company’s roadmap and drive clear and common messages.”

The TODO group, which became a Linux Foundation project in March, is a cross-industry effort that brings together open source program managers to help establish open source best practices, tools and programs and support corporate open source engagement.

Open source program managers from Twitter, Box, Google, Facebook, Microsoft, and SanDisk will be on hand at OSCON May 18-19, 2016, in Austin, Texas, to discuss why they started open source offices at their companies and the lessons they learned along the way.

We caught up with Nithya Ruff for a preview of their panel discussion, “Open source lessons from the TODO Group.”

Be sure to attend the TODO Group talk from 1:50 p.m.–2:30pm on Wednesday, May 18 in Meeting Room 9C.

And visit The Linux Foundation booth #109-2 to collect a wooden Linus Torvalds token for the OSCON open source history game for attendees.

nithya-ruff.jpg

Nithya Ruff, SanDisk

Nithya Ruff is head of SanDisk’s Open Source Strategy office.

Linux.com: What are some of the common challenges companies face when they start adopting open source?

Nithya Ruff: Companies that have not grown up with open source in their DNA face a number of challenges when they first adopt open source or look at adopting an open source strategy.

a.       They don’t completely understand the licenses and legal obligations and often see it as a single license which would force them to open their intellectual property or trade secrets.  Once they start understanding it more deeply they realize that one can consume without creating obligations and that there are a number of different licenses each with their own obligations.   So legal education is the first challenge.

b.      The second is to create awareness of the need to engage with open source and the need to have a strategy around how the company needs to work with open source communities. This is a strategy and a business discussion with executives and business leaders so that they support the need to have a plan and investment in this effort.  These are the top 2 areas of challenge.

Linux.com: How does creating an in-house open source office help companies maximize their open source involvement?

Ruff: One can continue to engage with open source in an ad hoc and distributed manner but this often creates issues and challenges with messaging, unintended consequences, multiple processes and confusion in the market on company intent.  It could also inadvertently expose a company to compliance risks.  An open source office whether centralized or by division can bring multiple best practices on how a company can manage consumption, compliance and contribution to open source. It can create a proactive plan for driving more strategic involvement in projects important to the company’s roadmap and drive clear and common messages.

Linux.com: What is one of the key lessons SanDisk has learned about corporate open source participation since starting its open source office two years ago?

Ruff: The biggest lesson has been learning about how much open source activity there already was in the company and how we would not have any knowledge of this and support it without starting this initiative.  Knowing consumption and dependencies has allowed us to shape our compliance and community engagement plan.

Linux.com: How have you benefited from your involvement in the TODO Group?

Ruff: Just this week, I needed to know a simple and best practice way to manage contribution license agreements or CLAs.    I contacted my fellow open source officers in other companies via the TOoDOo group and within hours I had two very usable solutions.  This is huge, to be able to consult each other on the best way to do things.  I am a big believer in reuse and to not recreate.  And this was a great example of how we can share practices..   TOoDOo members have been generous in sharing their time and coming to SanDisk to share their practices like Guy Martin (Autodesk) and Cedric Williams (PayPal) did recently. It is impactful to hear from other companies and to learn from their initiatives in open source.  This is one area, where we don’t compete and are happy to share.

Linux.com: What will TODO Group members discuss in your panel at OSCON?

Ruff: Open Source officers in companies are still rare. There are less than 30 of us and we know there is a lot of pent-up need for information on how to set it up.  We will discuss what TOoDOo does, what each of us do at our companies and shed light on helping companies manage their open source efforts successfully.

Linux.com: What else are you looking forward to at OSCON this year? What do you hope to accomplish by attending?

Ruff: I always enjoy attending OSCON as it covers culture and community very well side by side with technical topics.  I look forward to connecting with friends in the community. I am also doing a talk on why it is important to market in open source.  We all need people on the project who can write clearly, tell stories and create awareness.   The business side of open source is a passion and I look forward to sharing this at OSCON this year.