Posts

Networking industry experts gather at the Orange Gardens facility outside of Paris, France on October 9, 2017, for the Open Source Networking Day event, hosted by Atos and Orange.

Something that we’ve learned at The Linux Foundation over the years is that there is just no substitute for periodic, in-person, face-to-face collaboration around the open source technologies that are rapidly changing our world. It’s no different for the open networking projects I work with as end users and their ecosystem partners grapple with the challenges and opportunities of unifying various open source components and finding solutions to accelerate network transformation. This fall, we decided to take The Linux Foundation networking projects (OpenDaylight, ONAP, OPNFV, and others) on the road to Europe and Japan by working with local site hosts and network operators to host Open Source Networking Days in Paris, Milan, Stockholm, London, Tel Aviv, and Yokohama.

This series of one-day events was a valuable opportunity for local ecosystems to meet and collaborate around the latest in open source networking. Heather Kirksey and Phil Robb of The Linux Foundation attended and spoke at the events to share our vision of the open networking stack, build relationships, and facilitate community collaboration. Our local site hosts were amazing—taking the lead on organizing, programming, and executing events in line with the needs and interests of their various regions. On behalf of The Linux Foundation, “thank you” to all our incredible site hosts, speakers, attendees, and sponsors: Amdocs, ATOS, Cloudify, Enter Cloud Suite, Ericsson, Huawei, Intel, Login, NEC, Nokia, Orange, Red Hat, SUSE, and Vodafone.

The feedback we’ve received on these events has been very positive. Attendees appreciated the opportunity to learn about the various components of the open networking stack, examine the integration and collaboration points between them, and map that to their strategies for rolling out cloud, SDN, NFV, MANO, and more across networks. By taking the OSN Days on the road, we were able to meet in-person with more than 460 people—from developers to service providers to vendors—venues near them with an agenda focused on their needs. Attendees also expressed their desire for more hands-on work (e.g. tutorials, demos, workshops, hackathons, etc.) and we are taking that into consideration for future OSN Days.

I encourage you to check out the great content from the latest tour. From the OSN Days Tour website, you can navigate to each tour page, and access all the slide presentations under the “View Session Slides” tab. You can also watch videos here from the OSN Day London Event, and read detailed recap blogs of both the London and Stockholm events, posted by site hosts directly.

The next tour is being planned for India in late January 2018, and other tours are being considered for North America and Asia—stay tuned. In the meantime, please consider joining an Open Source Networking User Group in your region.

We hope to see you next year at Open Networking Summit, an OSN Day, or an OSN user group meetup near you! Please email osndays@linuxfoundation.org with any questions.

The Linux kernel is the lowest level of software running on a Linux system. It manages the hardware, runs user programs, and maintains the overall security and integrity of the whole system, according to the recent Linux Kernel Development Report. It is also the result of one of the largest cooperative software projects ever attempted, with some 15,600 individual developers from more than 1,400 different companies contributing to the kernel since 2005.

Linux kernel developer Arnd Bergmann

The report, released by The Linux Foundation, outlines the development process and highlights the ongoing work of some of these contributors. In this article, Arnd Bergmann of Linaro answers a few questions about his work on the kernel.

Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Arnd Bergmann: I co-maintain the arm-soc kernel tree together with Olof Johansson. This is where all the platform-specific changes for ARM processors and SoCs (both 32-bit and 64-bit) get merged. This is one of the larger subsystems in the kernel, and it interacts with most driver subsystems.

I also maintain a couple of smaller things in the kernel. In particular, I look after new CPU architectures getting merged into the kernel and the associated include/asm-generic/ directory. One of my long-term projects is to fix the time_t overflow in the kernel, which will cause 32-bit code to fail in the year 2038.

Linux Foundation: What have you been working on this year?

Bergmann: Aside from my maintainer work, I have spent a lot of time during the last year on fixing hundreds of smaller bugs that lead to build failures or warnings. I started doing a lot of build-testing as a way to improve the quality of contributions I merge into the kernel from other people, but this has now turned into a separate effort to get all random configurations to build cleanly.

Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Bergmann: I hope we can get the y2038 cleanup work to the point of actually being able to build a kernel with no 32-bit time_t users. For this, we still need help from additional developers cleaning up various areas of the kernel.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

This article explains how to walk through, measure, and define strategies collaboratively in an open source community.

“If you don’t know where you are going, you’ll end up someplace else.” Yogi Berra

Open source projects are generally started as a way to scratch one’s itch and frankly that’s one of its greatest attributes. Getting code down provides a tangible method to express an idea, showcase a need, and solve a problem. It avoids over thinking and getting a project stuck in analysis-paralysis, letting the project pragmatically solve the problem at hand.

Next, a project starts to scale up and gets many varied users and contributions, with plenty of opinions along the way. That leads to the next big challenge how does a project start to build a strategic vision? In this article, I’ll describe how to walk through, measure, and define strategies collaboratively, in a community.

Strategy may seem like a buzzword of the corporate world rather something that an open source community would embrace, so I suggest stripping away the negative actions that are sometimes associated with this word (e.g., staff reductions, discontinuations, office closures). Strategy done right isn’t a tool to justify unfortunate actions but to help show focus and where each community member can contribute.

A good application of strategy achieves the following:

  • Why the project exists?
  • What the project looks to achieve?
  • What is the ideal end state for a project is.

The key to success is answering these questions as simply as possible, with consensus from your community. Let’s look at some ways to do this.

Setting a mission and vision

Efforts and courage are not enough without purpose and direction.” John F. Kennedy

All strategic planning starts off with setting a course for where the project wants to go. The two tools used here are Mission and Vision. They are complementary terms, describing both the reason a project exists (mission) and the ideal end state for a project (vision).

A great way to start this exercise with the intent of driving consensus is by asking each key community member the following questions:

  • What drove you to join and/or contribute the project?
  • How do you define success for your participation?

In a company, you’d ask your customers these questions usually. But in open source projects, the customers are the project participants and their time investment is what makes the project a success.

Driving consensus means capturing the answers to these questions and looking for themes across them. At R Consortium, for example, I created a shared doc for the board to review each member’s answers to the above questions, and followed up with a meeting to review for specific themes that came from those insights.

Building a mission flows really well from this exercise. The key thing is to keep the wording of your mission short and concise. Open Mainframe Project has done this really well. Here’s their mission:

Build community and adoption of Open Source on the mainframe by:

  • Eliminating barriers to Open Source adoption on the mainframe
  • Demonstrating value of the mainframe on technical and business levels
  • Strengthening collaboration points and resources for the community to thrive

At 40 words, it passes the key eye tests of a good mission statement; it’s clear, concise, and demonstrates the useful value the project aims for.

The next stage is to reflect on the mission statement and ask yourself this question: What is the ideal outcome if the project accomplishes its mission? That can be a tough one to tackle. Open Mainframe Project put together its vision really well:

Linux on the Mainframe as the standard for enterprise class systems and applications.

You could read that as a BHAG, but it’s really more of a vision, because it describes a future state that is what would be created by the mission being fully accomplished. It also hits the key pieces to an effective vision it’s only 13 words, inspirational, clear, memorable, and concise.

Mission and vision add clarity on the who, what, why, and how for your project. But, how do you set a course for getting there?

Goals, Objectives, Actions, and Results

“I don’t focus on what I’m up against. I focus on my goals and I try to ignore the rest.” Venus Williams

Looking at a mission and vision can get overwhelming, so breaking them down into smaller chunks can help the project determine how to get started. This also helps prioritize actions, either by importance or by opportunity. Most importantly, this step gives you guidance on what things to focus on for a period of time, and which to put off.

There are lots of methods of time bound planning, but the method I think works the best for projects is what I’ve dubbed the GOAR method. It’s an acronym that stands for:

  • Goals define what the project is striving for and likely would align and support the mission. Examples might be “Grow a diverse contributor base” or “Become the leading project for X.” Goals are aspirational and set direction.
  • Objectives show how you measure a goal’s completion, and should be clear and measurable. You might also have multiple objectives to measure the completion of a goal. For example, the goal “Grow a diverse contributor base” might have objectives such as “Have X total contributors monthly” and “Have contributors representing Y different organizations.”
  • Actions are what the project plans to do to complete an objective. This is where you get tactical on exactly what needs done. For example, the objective “Have contributors representing Y different organizations” would like have actions of reaching out to interested organizations using the project, having existing contributors mentor new mentors, and providing incentives for first time contributors.
  • Results come along the way, showing progress both positive and negative from the actions.

You can put these into a table like this:

Goals Objectives Actions Results
Grow a diverse contributor base     Have X total contributors monthly
  • Existing contributors mentor new mentors
  • Providing incentives for first time contributors
Have contributors representing Y different organizations
  • Reach out to interested organizations using the project

In large organizations, monthly or quarterly goals and objectives often make sense; however, on open source projects, these time frames are unrealistic. Six- even 12-month tracking allows the project leadership to focus on driving efforts at a high level by nurturing the community along.

The end result is a rubric that provides clear vision on where the project is going. It also lets community members more easily find ways to contribute. For example, your project may include someone who knows a few organizations using the project this person could help introduce those developers to the codebase and guide them through their first commit.

What happens if the project doesn’t hit the goals?

“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas A. Edison

Figuring out what is within the capability of an organization — whether Fortune 500 or a small open source project — is hard. And, sometimes the expectations or market conditions change along the way. Does that make the strategy planning process a failure? Absolutely not!

Instead, you can use this experience as a way to better understand your project’s velocity, its impact, and its community, and perhaps as a way to prioritize what is important and what’s not.

Turkey’s Leader in Information and Communication Technologies Provider to Help Accelerate Open Source Innovation and Automation Globally

Orlando, Florida – November 15, 2017 — MEF 17’–The Open Network Automation Platform (ONAP) Project continues its membership growth with the addition of new Platinum member Türk Telekom. Türk Telekom, Turkey’s world-class, integrated telecommunication and technology services provider, joining the project demonstrates both the continued ONAP momentum globally and growing commitment to open standards and open source.

With this collaboration and extension into Turkey, Türk Telekom will help accelerate ONAP globally and continue its mission to deliver a neutral automation platform for networks. Türk Telekom will also help ONAP execute the project’s plan for cloud providers and enterprises challenged to provide on-demand services profitably and competitively, while leveraging existing investments.  By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a globally shared architecture and implementation for network automation–with an open standards focus–faster than any one product could on its own.

Türk Telekom joins 18 other global service providers and technology leaders that are platinum ONAP members including Amdocs, AT&T, Bell, China Mobile, China Telecom, Cisco, Ericsson, GigaSpaces, Huawei, IBM, Intel, Jio, Nokia, Orange, Tech Mahindra, VMWare, Vodafone and ZTE. In addition, 55 percent of the world’s mobile subscribers are supported by its members.

“We are delighted to invest in ONAP at the highest level and help guide the strategic, technical, and marketing direction for the project. As the only Turkish operator participating at ONAP, we believe joining the project is crucial for our  vision and helps us to better support technologies that our engineers are building,” said Cengiz Doğan, Chief Technology Officer of Türk Telekom. “We believe that ONAP has the ability to transform future networks by providing end-to-end, closed-loop automation to design, orchestrate, automate and manage new services.”

Türk Telekom offers its customers a complete range of mobile, broadband, data, TV and fixed voice services as well as innovative convergence technologies. With its rich history and continued growth, Türk Telekom is helping to advance Turkey into one of the largest telecom markets in EMEA. With its global presence, Türk Telekom will help drive the ONAP initiative into new regions and spread the continued adoption of open standards and open source. 

“We are delighted to welcome Türk Telekom to the project and expand the list of telecommunication and technology services providers supporting ONAP,” said Arpit Joshipura, General Manager of Networking and Orchestration, The Linux Foundation. “With Türk Telekom on board, we look forward to their ongoing POC development and together will collaborate to create the future of network automation.” 

About ONAP

The Open Network Automation Platform (ONAP) Project brings together top global carriers and vendors with the goal of allowing end users to automate, design, orchestrate and manage services and virtual functions. ONAP unites two major open networking and orchestration projects, open source ECOMP and the Open Orchestrator Project (OPEN-O), with the mission of creating a unified architecture and implementation and supporting collaboration across the open source community. The ONAP Project is a Linux Foundation project. For more information, visit https://www.onap.org.

 

# # #

 

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

 

Media Contact

Sarah Conway

The Linux Foundation

(978) 578-5300

sconway@linuxfoundation.org

Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.

Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require.

Inner source means applying open source development practices and methodologies to internal projects, even if the projects are proprietary. And the culture change required to be successful can be a hard shift from a traditional corporate hierarchy to an open approach. Even though they’re connected, all three changes are distinct heavy lifts.

They began by hiring Guy Martin as Director of Open Source Strategy in the Engineering Practice at Autodesk, which was designed to transform engineering across the company. Naturally, open source would play a huge role in that effort, including spurring the use of inner source. But neither would flourish if the company culture didn’t change. And so the job title swiftly evolved to Director of Open @ADSK at the company.

“I tend to focus a lot more on the culture change and the inner source part of my role even though I’m working through a huge compliance initiative right now on the open source side,” Martin said.

The history of Autodesk’s open source transformation began shortly after the shift of all its products to cloud began, including its AutoCAD architecture software, building information modeling with its Revit products, as well as  its media and entertainment products. The company’s role in open source in entertainment is now so significant that Martin often speaks at the Academy of Motion Picture Arts and Sciences on open source. They want to hear about what  Autodesk is doing as part of a larger collection of initiatives that the Academy is working on, Martin said.

At Autodesk, the goal is to spring engineers loose from their business silos and create a fully open source, cloud-centric company.

“Your primary identity detaches from being part of the AutoCAD team or part of the Revit team, or the 3ds Max or Inventor team or any of these products,” Martin explained. “It’s now shaping you into part of the Autodesk engineering team, and not your individual silo as a product organization in the company.”

Talent acquisition is among the top business goals for Open@Autodesk, especially given the company’s intense focus on innovation as well as making all of its products work seamlessly together. It takes talent skilled in open source methodologies and thinking to help make that happen. But it also means setting up the team dynamics so collaboration is more natural and less forced.

“With company cultures and some engineering cultures, the freedom to take an unconventional route to solve a problem doesn’t exist,” Martin said. “A lot of my job is to create that freedom so that smart and motivated engineers can figure out a way to put things together in a way that maybe they wouldn’t have thought of without that freedom and that culture.”

To help create an open source culture, the right tools must be in place and, oddly enough, those tools sometimes aren’t open source. For example, Martin created a single instance of Slack rather than use IRC, because Slack was more comfortable for users in other lines of the business who were already using it. The intent was to get teams to start talking across their organizational boundaries.

Another tool Martin is working with is Bitergia Analytics to monitor and manage Autodesk’s use of GitHub Enterprise.

Martin says the three key lessons he’s learned as an open source program manager are:

  1. Stay flexible because change happens
  2. Be humble but bold
  3. Be passionate.

“I’ve been at Autodesk two years but I’m still bootstrapping some of the things around culture. We have strong contributors in some projects, while in some projects we’re consuming. I think you have to do both, especially if you’re bootstrapping a new open source effort in a company. ”

“The challenge is always balancing the needs of the product teams, who have to get a product out the door, and who (and as an engineer I can say this) will take shortcuts whenever possible. They want to know, ‘why should we be doing this for the community? All we care about is our stuff.’ And it’s getting them past that. Yes, we’re doing work that’s going to be used elsewhere, but in the end we’re going to get benefits from pulling work from other people who have done work that they knew was going to be used in the community.”

The Linux Kernel Development Report, which was recently released by The Linux Foundation, sheds light on various aspects of the development process as well as on who is doing the work. According to the report, more than 85 percent of all kernel development is done by developers who are being paid for their work. Additionally, the overall number of companies involved in working toward the improvement of the kernel is increasing, with the top 30 companies contributing to the Linux kernel shown in the table at right.

The report states:

What we see here is that a small number of companies is responsible for a large portion of the total changes to the kernel. But there is a “long tail” of companies (nearly 500 of which do not appear in the above list) which have made significant changes since the 4.7 release. There may be no other examples of such a large, common resource being supported by such a large group of independent actors in such a collaborative way.

Jens Axboe, Software Engineer at Facebook

In this article, Jens Axboe, Software Engineer at Facebook, answers a few questions about how and why he contributes to the Linux kernel.

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Jens Axboe: I’m the Linux block layer maintainer, so I primarily develop features in that area, as well as help review and guide others doing the same.

The Linux Foundation: What have you been working on this year?

Axboe: This year, I contributed an IO scheduler framework for the block multiqueue subsystem, support for allowing applications to inform the kernel of life time of writes, and much faster IO accounting for blk-mq.   

Since 4.8, I have contributed about 200 patches. In terms of features, the most interesting, which are not mentioned above, are probably writeback throttling (blk-wbt), IO polling for fast devices (both classic and hybrid/efficient modes), and more efficient O_DIRECT.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Axboe: Attracting more young talent. Most young folks these days gravitate towards product instead of infrastructure. It’s important that we bring new talent into the fold.

The Linux Foundation: Why do you contribute to the Linux kernel?

Axboe: First of all, because I enjoy the work. It’s challenging and fun, plus there’s a personal gratification knowing that your code is running on billions of devices. Finally, it’s my job.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

An important step in using open source code effectively is setting explicit guidelines to be followed.

Open source programs at organizations of all sizes are fueling innovation, and many program leaders are quickly learning that weaving open source code into projects — and creating new projects — require informed guidelines and best practices. Organizations are often leveraging existing open source code to build their own commercial products and services, and contributing back to projects.

However, diving in and using open source code without an understanding of everything from legal risks to best development practices is perilous. Approaching open source code usage without best practices in place can also tarnish an organization’s reputation. That’s where the free, new Using Open Source Code guide comes in. It can help you craft and codify a comprehensive strategy.

One of the most important steps in using open source code effectively within your program is to set explicit guidelines to be followed, which are often summarized in a strategy document. What if code comes into one of your projects from a project with a different licensing setup? What acceptance, rejection, and exception policies should developers follow? What is your organization’s overall stance toward open source development?

These are all among the questions that need concrete answers as you codify your strategy, and there are more questions involving the ecosystem that applies to using open source code. How are APIs documented? Have you laid out a Contributor Licensing Agreement that everyone can use? Have you picked the right license for your project? Your strategy document should be specific about best practices, APIs and more.

“A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences,” notes Ibrahim Haddad, Vice President of R&D and Head of the Open Source Group at Samsung Research America.

Creating a Policy

As the guide notes, creating a strategy document featuring best practices does not need to be complicated. A good open source usage policy includes six simple rules:

  • Engineers must receive approval from the OSRB before integrating any open source code in a product.
  • Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
  • All software must be audited and reviewed, including all proprietary software components.
  • Products must fulfill open source licensing obligations prior to customer receipt.
  • Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
  • All changed components must go through the approval process.

Importantly, the guide also notes the importance of effective code review practices. “If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely,” Haddad emphasizes.

Additionally, Haddad, advises that circumspect code usage and compliance practices must be ongoing. “It’s important to remember that open source compliance doesn’t stop with version 1.0,” he said.

The Using Open Source Code guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave open components into your open source projects. 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.

These guides were produced based on expertise from open source leaders. Check out the guides and stay tuned for our continuing coverage.

Also, don’t miss the previous articles in the series:

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

A Free Guide to Participating in Open Source Communities

Read about featured Linux kernel developers in the 2017 Linux Kernel Development Report.

The recent Linux Kernel Development Report released by The Linux Foundation, included information about several featured Linux kernel developers. According to the report, roughly 15,600 developers from more than 1,400 companies have contributed to the Linux kernel since 2005, when the adoption of Git made detailed tracking possible. Over the next several weeks, we will be highlighting some specific Linux kernel developers who agreed to answer a few questions about what they do and why they contribute to the kernel.

Linux kernel developer

Laura Abbott, a Fedora Kernel Engineer at Red Hat

In this article, we feature Laura Abbott, a Fedora Kernel Engineer at Red Hat.

The Linux Foundation: What role do you play in the community and what subsystem(s) do you work on?

Laura Abbott: My full-time job is working as one of two maintainers for the Fedora kernels. This means I push out kernel releases and fix/shepherd bugs. Outside of that role, I maintain the Ion memory management framework and do occasional work on arm/arm64 and KSPP (kernel hardening).

The Linux Foundation: What have you been working on this year?

Abbott: I did some major reworking on Ion this year and ripped out a lot of code (everyone’s favorite type of patch!). Hopefully, I’ll be able to report that Ion is out of staging in the next kernel report. Apart from that, I’ve spent a lot of time testing and reviewing patches for kernel hardening.

The Linux Foundation: What do you think the kernel community needs to work on in the upcoming year?

Abbott: As a general theme, there needs to be a focus on scaling the community. There’s always an ongoing discussion about how to attract new developers and there’s been a recent focus on how to grow contributors into maintainers. There’s still a lot of ‘tribal knowledge’ in pretty much every area which makes things difficult for everyone. I’d like to see the kernel community continue to make processes easier for new and existing developers. I’d also like to see the discussions about building an inclusive community continue.

The Linux Foundation: Why do you contribute to the Linux kernel?

Abbott: I’ve always found low-level systems fascinating and enjoy seeing how all the pieces work together. There’s always something new to learn about in the kernel, and I find the work challenging.

You can learn more about the Linux kernel development process and read more developer profiles in the full report. Download the 2017 Linux Kernel Development Report now.

open source program

“We believe that our projects help move the industry forward while giving other companies and individuals the opportunity to use our platform to scale more quickly and build better products.” – Christine Abernathy, Open Source Developer Advocate at Facebook.

Facebook’s open source team was “formally” created in 2009, but the company has built with open source from its inception. Facebook.com was originally built on top of the LAMP (Linux/ Apache/ MySQL/ PHP) stack. And over time Facebook has used and contributed back to these projects, as well as evolved and released new projects such as Hack which has its roots in PHP.

“Open source is core to our engineering DNA. We believe that sharing our code and even hardware designs accelerates the pace of innovation in the world. We believe that our projects help move the industry forward while giving other companies and individuals the opportunity to use our platform to scale more quickly and build better products.” – Christine Abernathy, Open Source Developer Advocate at Facebook.

Custom tools to manage open source

Facebook has a dedicated Tools team within the open source program office that is responsible for building internal tools to help manage its open source portfolio. This includes the projects that Facebook shares, which are mostly hosted on GitHub, as well as the other external projects they contribute to such as the Linux Kernel.

The program office provides a dashboard for each project that includes GitHub metrics such as the number of open issues or the ratio of internal to external contributions for a given time period. Project maintainers are given tools so they can bring GitHub pull requests and issues into their internal review and bug tracking systems. This makes it easier for engineers to manage external issues where they’re most comfortable. Maintainers also have access to workflow tools to reliably push internal commits out to GitHub, making it easy to quickly sync internal and external code bases and reducing the churn on landing external contributions.

The open source team can look at these project dashboards to help analyze the health of a particular project. They’ve even open-sourced some of these workflow tools: mention-bot and FBShipIt.

The team collects top-level statistics on how the overall portfolio is doing through aggregate dashboards across the GitHub orgs they manage. These are used to provide high-level reports to stakeholders and a community of internal open source enthusiasts. The tools team also provides insight into top contributors. Project maintainers are encouraged to refer to this list and reward their top contributors. The company periodically thanks its top internal contributors and makes some of this information available to its internal review systems.

The open source office also provides tooling to guide potential projects through the review process. This helps streamline the process and helps the team easily spot and correct bottlenecks.

The open source team also provides services such as documentation. This includes helping out with the technical content as well as building out some of the documentation infrastructure and templates that projects can use.

Open Source Success Through Steady Progress

At the end of each half the program office identifies goals around metrics they want to achieve. The metrics they track include:

  • The average age of open issues or open pull requests
  • The ratio of external to internal commits
  • The number of commits
  • The growth in followers and forks
  • The number of social media followers.

They’re periodically tweaking what they measure as they refine what it means to maintain a healthy portfolio.

Facebook also surveys new hires every six months to gauge their awareness of its open source program. They set baseline metrics a few surveys back and the goal is to maintain or grow those numbers.

Their open source success isn’t the result of one action but the cumulative effect of a steady stream of quality releases over the years and a focus on growing thriving communities to support those projects.

“Projects like React, React Native, Create-React-App, Immutable, HHVM, Fresco, and GraphQL are the constant beat that have contributed to the success of our program,” Abernathy said.

One of Facebook’s most successful projects is React Native. It makes use of many of Facebook’s tools to help manage the community. For example, mention-bot came out of this project and was a way to quickly identify reviewers for a pull request. FBShipIt helped it cut down the time to bring in external contributions, review them internally, and land these contributions back out to GitHub. In the early days, this process sometimes took a day as much of it is manual. Now this can be done in as little as minutes if it’s an automatic reviews.

The open source program office also provided documentation services to help refresh and keep the React Native site up to date.

Tips for New Open Source Program Managers

Organizations that are just establishing an open source strategy and program office can learn from the success of Facebook’s open source program. Here are the three key practices that Abernathy shared that have contributed to their success as a program office:

  1. When evaluating what to share, it should be something that’s useful to your company. Many of the projects that Facebook shares are used in production and include all the benefits that come along with that. This means those projects are likely to have continued support which in turn means the community is well supported.
  2. Find a way to highlight, promote, and reward your open source contributors, both internal and external. Facebook has periodic reports that highlight its open source heroes. This helps raise the profile of engineers and their work with managers who may sometimes not be managers of that open source project.
  3. As a central program office, find pain points that cut across the various projects and tackle them.

For example, many projects had previously built their own commit copying scripts and it was the number one pain point from a survey they ran at that time. FBShipIt, which copies commits between repositories, was built to address this and it’s owned by the open source team. It moved the burden off the engineering teams and is universally praised for helping smooth the workflow for pulling in external contributions.

Acknowledgments

For this feature we interviewed Christine Abernathy (@abernathyca), Open Source Developer Advocate at Facebook, to learn more about the Facebook’s open source program. Libby Clark performed the interview.

[vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/1″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_column_text]

OS Summit keynotes

Watch keynotes and technical sessions from OS Summit and ELC Europe here.

If you weren’t able to attend Open Source Summit and Embedded Linux Conference (ELC) Europe last week, don’t worry! We’ve recorded keynote presentations from both events and all the technical sessions from ELC Europe to share with you here.

Check out the on-stage conversation with Linus Torvalds and VMware’s Dirk Hohndel, opening remarks from The Linux Foundation’s Executive Director Jim Zemlin, and a special presentation from 11-year-old CyberShaolin founder Reuben Paul. You can watch these and other ELC and OS Summit keynotes below for insight into open source collaboration, community and technical expertise on containers, cloud computing, embedded Linux, Linux kernel, networking, and much more.

And, you can watch all 55+ technical sessions from Embedded Linux Conference here.[/vc_column_text][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”http://www.youtube.com/watch?v=NLQZzEvavGs&list=PLbzoR-pLrL6pISWAq-1cXP4_UZAyRtesk&index=1″][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/vO0_lhpeqas”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/YZXngLn5UJk”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/OFx9qNee4hw”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/j6WNlX0TDsc”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/ZS-mSwv5CoU”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/Ht3pkuKhZHc”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/mCDXnls6pQk”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/Apw_fuTEhyA”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/wLF53sc1TWM”][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/jdB1FLIDALs”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/W3jIuGLFrO4″][/vc_column][/vc_row][vc_row type=”in_container” full_screen_row_position=”middle” scene_position=”center” text_color=”dark” text_align=”left” overlay_strength=”0.3″][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][vc_video link=”https://youtu.be/IFi41eHP2uk”][/vc_column][vc_column column_padding=”no-extra-padding” column_padding_position=”all” background_color_opacity=”1″ background_hover_color_opacity=”1″ column_shadow=”none” width=”1/2″ tablet_text_alignment=”default” phone_text_alignment=”default” column_border_width=”none” column_border_style=”solid”][/vc_column][/vc_row]