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 Summit

Join us in Edinburgh! Submit a proposal to speak by July 1 for Open Source Summit & ELC + OpenIoT Summit Europe.

Submit a proposal to speak at Open Source Summit Europe & ELC + OpenIoT Summit Europe, taking place October 22-24, 2018, in Edinburgh, UK, and share your knowledge and expertise with 2,000+ open source technologists and community leaders. Proposals are being accepted through 11:59pm PDT, Sunday, July 1.

This year’s tracks and content will cover the following areas at Open Source Summit Europe:

  • Cloud Native Apps/Serverless/Microservices
  • Infrastructure & Automation (Cloud/Cloud Native/DevOps)
  • Linux Systems
  • Artificial Intelligence & Data Analytics
  • Emerging Technologies & Wildcard (Networking, Edge, IoT, Hardware, Blockchain)
  • Community, Compliance, Governance, Culture, Open Source Program Management (Open Collaboration Conference track)
  • Diversity & Inclusion (Diversity Empowerment Summit)
  • Innovation at Apache/Apache Projects
  • TODO / Open Source Program Management

View the full list of suggested topics for Open Source Summit Europe.

Suggested Embedded Linux Conference (ELC) Topics:

  • Audio, Video, Streaming Media and Graphics
  • Security
  • System Size, Boot Speed
  • Real-Time Linux – Performance, Tuning and Mainlining
  • SDKs for Embedded Products
  • Flash Memory Devices and Filesystems
  • Build Systems, Embedded Distributions and Development Tools
  • Linux in Devices such as Mobile Phones, DVRs, TVs, Cameras, etc
  • Use of Linux in Automotive
  • Drones and Robots
  • Linux in the Internet of Things
  • Practical Experiences and War Stories
  • Standards
  • Public Infrastructure
  • Industrial Automation

This year’s tracks and content will cover the following areas at ELC:

Suggested OpenIoT Summit Topics:

  • Real-Time OS (Zephyr, RIOT, MyNewt, FreeRTOS, NuttX, mbed and Others)
  • Outside World Meets IoT (Sensor Interaction,  Low Footprint, Connected Sensors, EMF/RFI Impact)
  • Bootloaders, Firmware & Updates
  • Containers
  • Distributed Edge
  • Application Technologies
  • On-device Analytics
  • Blockchain for Constrained Devices
  • Device Management
  • Power Management
  • Configuration Management
  • Developing for Security
  • Safety Considerations
  • Certifications – Lessons Learned Taking Devices to Product

View the full list of suggested topics for ELC + OpenIoT Summit Europe.

SUBMIT FOR OPEN SOURCE SUMMIT EUROPE »

SUBMIT FOR ELC + OPENIOT SUMMIT EUROPE »

Sign up to receive updates on Open Source Summit Europe and ELC + OpenIoT Summit Europe:

Register & Save

Not submitting, but plan to attend? Register before August 18 and save $300 with early bird pricing. One registration gets you access to both Open Source Summit Europe & ELC + OpenIoT Summit Europe.

Interested in Sponsoring?

Showcase your thought leadership among a vibrant open source community and connect with top influencers driving today’s technology purchasing decisions. Learn how to become a sponsor of Open Source Summit Europe or ELC + OpenIoT Summit Europe.

building leadership

The latest Open Source Guide for the Enterprise from The TODO Group provides practical advice for building leadership in open source projects and communities.

Contributing code is just one aspect of creating a successful open source project. 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.  

Being a good leader and earning trust within a community takes time and effort, and this free guide discusses various aspects of leadership within a project, including matters of governance, compliance, and culture. Building Leadership in an Open Source Community, featuring 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.

Leadership Mindset

According to the guide, the open source leadership mindset involves:

  • Influence, not control
  • Transparency as a means of crowd-sourcing solutions, not as exposure
  • Leading, not herding

Building leadership can happen at all levels — from managers to developers to volunteers. Developers, for example, are often highly motivated to contribute to open source projects that matter to them and to build their reputations within the community. According to the guide, “open source is so hotly in demand that developers actively seek opportunities to develop or hone their open source chops.”

Guy Martin, Director, Open at Autodesk, Autodesk, says that when interviewing developers, he is frequently asked how the company will help the developer build his or her own open source brand.

Increase Visibility

“Raising your own company’s visibility in its open source work can thus also help recruit developers. Some companies even offer open source training to add to the appeal. Presenting the company’s open source projects at conferences and contributing code in communities are the best ways to raise your company’s visibility. Asking your developers to network with other developers and invite them aboard also tends to work well,” the guide states.

Read the complete guide to Building Leadership in an Open Source Community online now. And, see the list of all Open Source Guides for the Enterprise to learn more.  The information contained in these guides is based on years of experience and best practices from industry leaders. They are developed by The TODO Group in collaboration with The Linux Foundation and the larger open source community.  

Open networking summit

Submit your proposal to speak at Open Networking Summit Europe, happening September 25-27 in Amsterdam.

Open Networking Summit Europe (ONS EU) is the first combined Technical and Business Networking conference for Carriers, Cloud and Enterprises in Europe. The call for proposals for ONS EU 2018 is now open, and we invite you to share your expertise.

Based on feedback we received at Open Networking Summit North America 2018, our restructured agenda will include project-based technical sessions as well.

Share your knowledge with over 700 architects, developers, and thought leaders paving the future of network integration, acceleration and deployment. Proposals are due Sunday, June 24, 2018.

Suggested Topics:

Networking Futures: Share innovative ideas and submissions that will disrupt and change the landscape of networking, as well as networking enabled markets, in the next 3-5 years. Submissions can be for Enterprise IT, Service Providers or Cloud Markets.

Network General Sessions: Common business, architecture, process or people issues that are important to move the Networking agenda forward in the next 1-2 years.

(Technical) Service Provider & Cloud Networking: We want to hear what you have to say about the containerization of service provider workloads, multi-cloud, 5G, fog, and edge access cloud networking.

(Business & Architecture) Service Provider & Cloud Networking: We’re seeking proposals on software-defined packet-optical, mobile edge computing, 4G video/CDN, 5G networking, and incorporating legacy systems (legacy enterprise workload migration, role of networking in cloud migration, and interworking of carrier OSS/BSS/FCAPS systems).

Submit a Talk >>

Get Inspired!

Watch presentations from Open Networking Summit North America 2018

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 Summit

Submit your proposal to speak at OS Summit before the April 29th deadline.

Share your knowledge and expertise by speaking at Open Source Summit North America, August 29-31 in Vancouver BC. Proposals are being accepted through April 29th.

As the leading technical conference for professional open source, Open Source Summit gathers developers, sysadmins, DevOps professionals, architects and community members from across the globe for education and collaboration across the ecosystem.

As open source continues to evolve, so does the content that Open Source Summit covers, and we’re excited to announce new content areas that will be covered this year in addition to those that continue to be of critical importance to our attendees.

This year’s tracks/content will cover the following areas:

  • Cloud Native Apps/Serverless/Microservices
  • Infrastructure & Automation (Cloud / Cloud Native / DevOps)
  • Linux Systems
  • Artificial Intelligence & Data Analytics
  • Emerging Technologies & Wildcard (Networking, Edge, IoT, Hardware, Blockchain)
  • Community, Compliance, Governance, Culture, Open Source Program Management (in the Open Collaboration Conference tracks)
  • Diversity & Inclusion (in the Diversity Empowerment Summit )
  • Innovation at Apache/In Apache Projects (in the Apache Software Foundation track)
  • Cloud & Container Apprentice Linux Engineer Tutorials Track (geared towards attendees new to using Linux and open source based cloud & container technologies)

SUBMIT YOUR TALK  >>

Our program chairs are ensuring that we increase content for our sysadmin, devops and software architecture audience this year as well, based on feedback received from 2017, so please submit talks geared towards any of these audience types, as well as community managers, program office management, and of course developers.

On that note, we are pleased to announce our 2018 Program Chairs, Track Chairs and Program Committee:

Program Co-Chairs:

  • Robyn Bergeron, Ansible Community Architect, Red Hat
  • Donnie Berkholtz, VP, IT Service Delivery, Carlson Wagonlit Travel
  • Greg Kroah-Hartman, Linux Kernel Developer
  • Bryan Liles, Staff Engineer, Heptio

Track Chairs:

  • Jono Bacon, Community Strategy Consultant, Author & Speaker (Open Collaboration Conference)
  • Rich Bowen, Vice President of Conferences, Apache Software Foundation (Innovation at Apache)
  • Nithya Ruff, Senior Director, Open Source Practice, Comcast (Diversity Empowerment Summit)
  • Behan Webster, Converse in Code (Apprentice Track)

Program Committee:

  • Laura Abbott, Fedora Kernel Engineer, Red Hat
  • Zaheda Bhorat, Head of Open Source Strategy, Amazon Web Services
  • James Bottomley, Distinguished Engineer, IBM
  • Joe Brockmeier, Senior Evangelist, Linux Containers, Red Hat
  • Jessie Frazelle, Software Engineer, Microsoft
  • Michelle Noorali, Software Engineer, Microsoft
  • Daniel Whitenack, Data Scientist, Lead Developer Advocate, Pachyderm

Register & Save

Not submitting, but planning to attend? Register now and save $300 with early bird pricing.

Interested in sponsoring?

Showcase your thought leadership among a vibrant open source community and connect with top influencers driving today’s technology purchasing decisions. Learn more »

The key to open source compliance is knowing what’s in your code, right down to the exact versions of the components, says Ibrahim Haddad.

Companies across all industries use, participate in, and contribute to open source projects, and open source compliance is an integral part of the use and development of any open source software. It’s particularly important to get compliance right when your company is considering a merger or acquisition. The key, according to Ibrahim Haddad, is knowing what’s in your code, right down to the exact versions of the open source components.

Ibrahim Haddad

Haddad often writes about compliance with the aim of simplifying what can be a complex and daunting process. Recently, Haddad, who is Vice President of R&D and Head of the Open Source Group at Samsung Research America, wrote Open Source Audits in Merger and Acquisition Transactions, a free ebook from The Linux Foundation. In the book, Haddad provides a practical guide to open source audits in merger and acquisition (M&A) transactions and offers tips for improving general open source compliance preparedness. We reached out to Haddad to understand more about the importance of compliance and audits in the open source world.

The Linux Foundation: A common perception is that using open source software means you do not have to worry about negotiating licenses, fees, and other complications associated with proprietary software. So, why should enterprises care about compliance?

Ibrahim Haddad: It is true that open source software has to a large extent simplified the process of software procurement. The traditional procurement model for proprietary software has always been heavy on the front end, as it involves trial and evaluation, negotiation related to possible customizations, licensing terms, fees, and several other factors. With open source, it is still true that you should evaluate the software, compare it to other possible alternatives, and evaluate if the license of that software is in line with how you plan to use it.

However, this is generally the extent of the initial effort. Once you ship a product, you then must demonstrate that you have respected the terms of the licenses attached to the open source components. That may mean providing a written office, publishing all copyright, attribution and license notices, and/or making available source code including any modifications you have introduced.  Obligations will vary based upon the terms of the open source license and how the code is used.

Companies must make open source compliance an engineering priority, as it is the best way to display their fulfillment of the license obligations. If a company is unable to demonstrate compliance and is unwilling to become compliant when challenged, the owners of the copyright on the open source software may decide to revoke the license.  The company could easily end up in a very difficult space where they may need to recall products and re-engineer around the code.

The Linux Foundation:  In my opinion, there are two primary aspects of Open Source — consumption and contribution. What role does compliance play in these cases? 

Haddad: I agree that the two primary aspects of open source are using and contributing. An enterprise can choose open source components and deploy them in their software stack. An enterprise can also decide that certain open source components are strategic to their products and contribute to these components, inject new dynamics in the projects, and steer them in a technical direction that is favorable to their products.

In the first case, compliance is a critical aspect of the “usage” model. A product or software stack that incorporates open source and is being made commercially available must demonstrate open source compliance. This is essential, and no enterprise should risk their profitability with incomplete compliance.

In my mind, contributing involves a different type of compliance than what is implied through the “usage” model. My recommendation and actual practice for code contribution is to follow an internal process that includes:

  1.     Scan source code intended for contribution to identify its origin and license.
  2.     Ensure you have the rights to contribute it under the project’s license.
  3.     Get your company’s approval for that contribution – and in the case of CLA, also getting approval to sign the CLA on behalf of your company before making the contribution.

I will explain my logic for these three steps:

On 1: It is necessary to identify all the code planned for contribution, and any licenses upon it. This step will also help you identify any possible incompatibilities between the licenses of the contribution and the target project. If the code you plan to contribute and the target project have incompatible licenses, or if you discover the code was copied from somewhere else, then you will need resolve the issue before your code submission.

On 2: This step ensures that you are not accidentally open sourcing third-party proprietary code.  This can be a problem in big internal projects with legacy code.

On 3: In most companies, ongoing contributions require approval following whatever internal process that has been set in place. That process should also address who can sign and submit a CLA as an individual contributor (employee of company X), or on behalf all contributors from company X.

Following these steps, you will be able to significantly minimize legal or compliance risks resulting from using or contributing to open source projects.

The Linux Foundation: If you do serve external customers, but you are not shipping any code, then you are simply offering a service. Do you have to be compliant in that case also?

Haddad: I would like to highlight two use cases here. The first is using open source software in your company for internal purposes: IT, testing, evaluation, etc. In such cases, there are no compliance requirements because it is never distributed.

The second case involves offering online (or web) services to clients using software that incorporates open source software. In that specific case, some licenses such as the GNU Affero General Public License (AGPL) do require companies to comply with the license obligations, even if the software itself never changes hands.

Therefore, regardless of how you use the open source software, I am a strong believer in the value of going through a compliance process to identify open source code, applicable licenses and usage models. I believe that good compliance practices are also good engineering practices.

The Linux Foundation: What was the motivation behind writing Open Source Audits in M&A Transactions? Who is the main audience of the book?

Haddad: I mainly had three motivations for writing this book:

  • The first motivation was the lack of documentation around the open source audit process that must take place prior to a merger or an acquisition. If you search online for documentation on this topic, you will not find much outside of the advertisements from various compliance services providers.
  • The second motivation is saving time. I get many inquiries about this process and having such a document is great to share when I am asked about it. In addition, I thought that if I am able to produce a document that highlights the process and explains it, maybe this will encourage others to write about it and share their experiences and recommended practices.
  • The third motivation was related to innovation in the compliance space that was not getting the attention it deserves. For example, the “Blind Audit” model from FOSSID AB where your compliance service provider can complete the audit without having access or even looking at the source code. This level of privacy and security is highly desirable.

The target audience of the book is anyone interested or involved in ensuring open source compliance. Although the ebook focuses on the specific process during an M&A transaction, it offers various recommendations on how to be compliant. These recommendations apply to any company that uses open source. Therefore, if you are an engineer, legal counsel, someone who works in software procurement, or anyone who is involved in open source in their organization, then you will get something out of reading the book.

The Linux Foundation: Compliance can be a challenge when you use a lot of open source projects with many license mixes. What practices would you suggest to companies to help them with their compliance efforts?

Haddad: I think we have come a long way in the open source compliance domain. Back in the early 2000s, open source compliance was really misunderstood, in large part because it was a developing domain. Today, open source compliance is well understood and most companies have a good enough understanding of the licenses and what needs to be done to stay in compliance. My view is that the top challenges are related to scale and building compliance into the software supply chain.

Of the two challenges I just mentioned, scale is the hardest, and it covers multiple dimensions. One is scaling at the project level, when you are dealing with hundreds of open source components and potentially thousands of open source snippets. The other dimension is scaling to address the complexities of a product with an arbitrary number of licenses involved. The way to deal with that is twofold: process and automation. In November 2016, The Linux Foundation published an ebook entirely dedicated to this topic: Open Source Compliance in the Enterprise.  It offers a guide for how best to use open source code in products and services and participate in open source communities in a responsible way.

The second challenge is building trust in the software supply chain, and there are several initiatives that are geared for that purposes. The most prominent projects are OpenChain and SPDX, both hosted at The Linux Foundation. The SPDX initiative has created a standard method to communicate software components, licenses and copyright information associated with the software. In addition, the OpenChain project is offering a systematic approach for companies to build their compliance efforts and be in conformance of various levels of compliance. They are also offering a training curriculum that companies can adopt and customize for their internal use.

For organizations that rely heavily on open source for their products/software stacks, it is essential for them to participate in these efforts. When you look at the errors that lead to non-compliance, we’ve notice that large companies have significantly improved their internal compliance practices. However, many compliance issues are still being propagated via the software supply chain, from upstream suppliers whose compliance practices are not as rigorous. The final product integrator is responsible for compliance obligations even if they did not create the code they distribute, so this is a relevant issue throughout the entire supply chain. Both SPDX and OpenChain help minimize the compliance gap and ensure proper compliance when software changes hands.

The Linux Foundation: What would be your top recommendations for companies who are major consumers of open source software but are not well versed in ensuring compliance?

Haddad: I have one recommendation: know what is in your code, right down to the exact versions of the open source components. This statement sounds simple but it involves setting up a compliance policy and process, investing in tooling and automation, training employees, and assigning someone (or a small team) to oversee the overall effort.

Also remember that open source compliance is an ongoing process, not a destination. Maintaining good compliance practices enables companies to be prepared for a possible acquisition, sale, or product or service release. For this reason, companies are highly encouraged to invest in building and improving upon their open source compliance programs.

There are also many resources available, so please check them out:

  • Open Source Compliance in the Enterprise is a practical guide for enterprises on how to best use open source in products and services in a legal and responsible way.
  • Practical GPL Compliance is a guide for startups, small businesses, and engineers, particularly focused on complying with the versions of the GNU General Public License (GPL).
  • OpenChain Curriculum is designed to help organizations meet the training and process requirements of the OpenChain Specification. It can also be used for general open source training.
  • The Linux Foundation offers a free open source compliance course for developers.
ONAP

Building an open ecosystem and accelerating operational transformation is key to the open networking industry, says Huawei’s Bill Ren.

The 2018 Open Networking Summit (ONS) is almost here. We spoke to Bill Ren, Vice President Network Industry & Ecosystem Development at Huawei recently to glean some insights on ONAP since Huawei is a founding member and top contributor to this project.

“SDN/NFV solutions have been in the market for many years but we did not see massive deployment due to lack of working standards and automation,” Bill said.

Bill Ren

Bill Ren, VP, Network Industry & Ecosystem Development, Huawei Technologies Co., Ltd.

“We believe open source will help produce de facto standards faster. We need to bring automation and intelligence into networking, we need a full end to end automation platform and that is why ONAP is particularly important for networking.”

Here is what Bill had to say about the ONAP’s growing role in open networking.

Linux.com: How does adopting ONAP as a standard help all operators and vendors to innovate?

Bill: ONAP can help to set up a common framework for all operators as an onboarding resource, or to design and deploy service, manage and control the network, collect data from networks, and manage policy. Adopting ONAP as a standard means that operators can focus on service innovation rather than on the software platform itself. And, vendors can focus on innovation as ONAP removes the difficulty of OSS integration and brings an open unified marketplace for all vendors.

Linux.com: Huawei leads five of 28 ONAP projects, including SO, VNF SDK, Modeling, Integration and ONAP CLI. Why did Huawei choose those projects? What benefits do you see in those projects?

Bill: Huawei treats open source as a strategic tool to build a healthy telecom industry and we set up a dedicated management team for networking open source projects like ONAP. We chose to lead some of these projects because they are key elements in building a healthy ecosystem. Take modeling for example. Modeling aims to build common information model for network resource and service across the whole industry. This will result in simple and quick resource onboarding and OSS/BSS integration. VNF SDK aims to build common VNF packaging and marketplace. Integration aims to support multi-cloud and multi-vendor environments. SO is the core component in ONAP that links other components so that they work together.

Huawei also chose to lead these key projects because we, as an end-to-end telecom solution leader, have the necessary resources, expertise and experience to significantly contribute. For example, we can involve our global expertise in SDOs for modelling project. And we can involve our key customer to discuss use case, requirements and POC/trials. Huawei believes an open healthy ecosystem will enlarge the total market and ultimately benefit Huawei’s business.

Linux.com: What benefits do you see in being involved in the ONAP community?

Bill: We learned a lot. ONAP brings really good architecture for network automation and this will benefit our related products. ONAP brings operator and vendor together and this will help us to understand requirements much better. ONAP will even bring a chance to try some new business model in certain area like service or cloudification. I believe we will see more and more benefits over time. I believe we will see more and more benefits over time.

Linux.com: Your keynote at Open Networking Summit is “Make Infrastructure Relevant to a Better Future.” Explain that please. What has Huawei done along these lines and how well is it working?

Bill: Yes. Building an open ecosystem and accelerating operational transformation is our industry strategy. Infrastructure operators need operational transformation to be more deeply relevant to a better digital intelligent society. And open source is the strategy tool for that. My keynote at ONS will address this point.

Basically, we believe all partners in our industry, including SDOs and open source projects, operators and vendors can work together to build an open and intent-driven cloud-friendly network to empower the digital life and vertical digitalization. I am happy to see that most network related open source projects are now merged into Linux Foundation Networking (LFN) umbrella and SDOs like MEF/TMF are cooperating with LFN. I would say it moves on the right direction.

Linux.com: What are your thoughts on the Linux Foundation Networking umbrella overall?

Bill: I look forward to LFN speeding the building of the open source networking ecosystem, and Telco operation transformation. I would like to see LFN work out a clear technical vision, flexible full stack architecture, cross-domain common models, harmonized SDO cooperation and faster production and field trials. I recommend LFN set up strong Technical Advisory Committee (TAC) team, unified use case committee, and unified verification programs. I believe our industry has found a better way to work together and I look forward to another quick change and successful year for our industry.

This article was sponsored by Huawei and written by Linux.com.

Sign up to get the latest updates on ONS NA 2018!

open networking

The industry is taking open networking to next level; learn more from Dell EMC’s Jeff Baher in this interview.

Ahead of the much anticipated 2018 Open Networking Summit, we spoke to Jeff Baher, director, Dell EMC Networking and Service Provider Solutions, about what lies ahead for open networking in the data center and beyond.

“For all that time that the client server world was gaining steam in decoupling hardware and software, networking was always in its own almost mainframe-like world, where the hardware and software were inextricably tied,” Baher explained. “Fast forward to today and there exists a critical need to usher networking into the modern world, like its server brethren, where independent decisions are made around hardware and software functions and services modules are assembled and invoked.”

Jeff Baher, director, Dell EMC Networking and Service Provider Solutions

Indeed, the decoupling is well on its way as is the expected rise of independent open network software vendors, such as Cumulus, Big Switch, IP Infusion and Pluribus, as well as Dell EMC’s OS10 Open Edition that are shaping a rapidly evolving ecosystem. Baher describes the progress in the industry thus far as Open Networking ‘1.0’, proving out the model successfully of decoupling networking hardware and software. And with this, the industry is forging ahead taking open networking to the next level.

Here are the insights Baher shared with us about where open networking is headed.

Linux.com: You refer to an industry shift around open networking, tell us about the shift that Dell EMC is talking about at ONS this year.

Jeff Baher: Well, to date we and our partners have been working hard to prove out the viability of the basic premise of open networking, disaggregating or decoupling networking hardware and software to drive an increase in customer choice and capability. This first phase, or as we say Open Networking 1.0, is four years in the making, and I would say it has been a resounding success as evidenced by some of the pioneering Tier 1 service provider deployments we’ve enabled. There is a clear-cut market fit here as we’ve witnessed both significant innovation and investment. And the industry is not standing still as it moves quickly to its 2.0 version. In this next version, the focus is shifting from decoupling the basic elements of hardware and software, to a focus on disaggregating the software stack itself.

Disaggregating the software stack involves exposing both the silicon and system software for adaption and abstraction This level of disaggregation also assumes a decoupling of the network application (i.e., routing or switching) from the platform operating system (the software that makes lights blink and fans spin). In this manner, with all the software functional elements exposed and disaggregated, independent software decisions can be made and development communities can form around flexible software composition, assembly and delivery models.

Linux.com: Why do people want this level of disaggregation?

Baher: Ultimately, it’s about more control, choice and velocity. With traditional networking systems, there’s typically a lot of code that isn’t necessarily always used. By moving to this new model predicated on disaggregated software elements, users can scale back that unused code and run a highly optimized network operating system (NOS) and applications allowing them to get peak performance, with increased security. And this can all be done independent of the underlying silicon, allowing user to be able to make independent decisions around silicon technology and software adaptation.

All of this, of course, is geared for a fairly savvy network department with most likely a large-scale operation to contend with. For the vast majority of IT shops, they won’t want to “crack the hood” of the network stack and disaggregate pieces. Instead, they will look for pre-packaged offerings derived from these larger “early adopter” experiences. For the larger early adopters, however, there can be virtually an immediate payback by customizing the networking stack, making any operational or technical hurdles well worth it.  These early adopters typically already live in a disaggregated world and hence will feel comfortable mixing and matching hardware, OS layers, and protocols to optimize their network infrastructure. A Tier 1 service provider deployment analysis by ACG Research estimates the realized gains with a disaggregated approach to be 47% lower for TCO, three time the service agility for new services at less than a third of the cost to enable them.

And it is worth noting the prominent role that open source technologies play in disaggregating the networking software stack. In fact, many would contend that open source technologies are foundational and critical to how this happens. This adds in a community aspect to innovation, arguably accelerating its pace along the way. Which brings us back full circle to why people want this level of disaggregation – to have more control over how networking software is architected and written, and how networks operate.

Linux.com: How does the disaggregation of the networking stack help fuel innovation in other areas, for example edge computing and IoT?

Baher: Edge computing is interesting as it really is the confluence of compute and networking. For some, it may look like a distributed data center, a few large hyperscale data centers with spokes out to the edge for IoT, 5G and other services. Each edge element is different in capability, form factor, software footprint and operating models. And when viewed through a compute lens, it will be assumed to be inherently a disaggregated, distributed element (with compute, networking and storage capabilities). In other words, hardware elements that are open, standards-based and without any software dependencies. And software for the IoT, 5G and enterprise edge that is also open and disaggregated such that it can be right-sized and optimized for that specific edge task. So if anything, I would say a disaggregated “composite” networking stack is a critical first step for enabling the next-generation edge.

We’re seeing this with mobile operators as they look to NFV solutions for 5G and IoT edge. We’re also seeing this at the enterprise edge, in particular with universal CPE (uCPE) solutions. Unlike previous generations where the enterprise edge meant a proprietary piece of hardware and monolithic software, it is now rapidly transforming into a compute-oriented open model where select networking functions are selected as needed. All of this is made possible by disaggregating the networking functions and applications from the underlying operating system. A ‘not so big a deal’ thing if from a server-minded vantage point, monumental if you come from “networking land”. Exciting times once again in the world of open networking!

This article was sponsored by Dell EMC and written by Linux.com.

Sign up to get the latest updates on ONS NA 2018!

Open source is a thriving part of Microsoft’s global works. And, the company’s open source journey has been neither as abrupt nor unexpected as it may have appeared.

Microsoft is now an accepted big player in the open source space, but just a few years ago such a role for the software giant, seemed inconceivable. Many people were thus surprised when Microsoft emerged from its market lead as a proprietary software maker to make a move towards open source in a big way. Although the company’s story is remarkable, its open source journey has been neither as abrupt nor unexpected as it may have appeared.

“Despite perception, Microsoft has been doing open source for quite a while. At first, it was experimental pieces here and there but about six years ago, in 2011, we brought much of that into focus in an entity called Microsoft Open Technologies,” explained Jeff McAffer, Director of Open Source Programs Office at Microsoft.

Open source in earnest

That’s when the exploration of what Microsoft could do with open source began in earnest, McAffer said. In the early days, if anyone in the company was interested in doing anything with open source, they came to the centralized group for assistance from the open source developers, contributors, and maintainers involved.

About three years ago, things began to change. Microsoft decided to make open source pervasive throughout the company and rolled open source into the main engineering groups.

“If that’s all we had done, we would have left an untenable vacuum around how we do open source,” said McAffer. “Someone has to think about policy and how all the open source efforts would be coordinated, the processes and tools they would use, how would we keep track of projects, etc. So, we created what is now known as the Open Source Programs Office to handle all those issues.”

Some of the technical people from the earlier open source group moved to the newly formed program office, while the others joined engineering groups pertinent to their work. It turned out that Microsoft needed additional talent to make sure all projects and processes were fully manned, and so recruitment efforts, both internally and externally, were soon under way. Today, open source is a thriving part of Microsoft’s global works.

Business and programmatic goals

Microsoft does not have a central open source strategy or a central approval body. Instead, the Open Source Programs Office facilitates those discussions and decisions throughout the company. Teams still need to have their open source engagement reviewed, but it is done more locally.  

“They know their business, they understand how they want their technical interactions to work, where they want to drive in terms of ecosystems, and all the various nuances of what needs to happen,” McAffer said.

“We defer most of those decisions and directions to the local management, but we give them a structure in which to think about those decisions and directions. We do have central policies about how we manage IP and what do we do about security issues.  We give them tools and processes that embody those policies to make it super simple for them to execute in a coherent yet specific way.”

The tools to manage

Microsoft’s policies boil down into processes that then are tooled accordingly to handle the workload. One example is open source releases. As a matter of policy, releases are made on GitHub.

“We’ve got a bunch of tooling around our presence on GitHub, where we manage something like 10,000+ repos across about 100 organizations with about 12,000 Microsoft people interacting in that space,” said McAffer.

“That gets up to a scale where you really need a system to manage a multitude of aspects. For example, when people want to contribute to one of the projects that we’re running, we need tools to help manage the contributor license agreements or CLA’s. For all of those things, we’ve either built up solutions ourselves or turned to open source solutions.” For example, for CLA management, Microsoft uses CLA Assistant, an open source program that SAP originated.

“On the GitHub management side, we went the other direction, as there wasn’t an existing set of tooling to help manage an enterprise presence on GitHub,” said McAffer. “So we ended up creating what’s now called the open source portal, which is available on GitHub as open source.”

Elements of that are easily seen on opensource.microsoft.com, but then there’s an internal side, too, where Microsoft employees manage repos and teams. “We’ve open sourced that and other companies are picking it up and using that internally for themselves, so it’s a bi-directional thing,” McAffer explained.

GitHub is a very rich environment, where lots of interactions are possible. Microsoft, like a lot of companies, was finding it difficult to keep track of everything going on and understanding what was happening with its repos.

“We ended up engaging with the GHTorrent project. We did quite a bit of work with them, and we actually are now sponsoring the GHTorrent project so we pay for all their Azure resources, everything you can see that at GHTorrent.org,” he said.

GHTorrent helps Microsoft understand what’s going on at GitHub but also internally in terms of its own projects. Even so, there are some things that GHTorrent was not set up to do, including work with private repositories and some of the more detailed data concerning teams where admin permissions are required.

The company ended up creating another system called GHCrawler, which it also open source. This tool tracks everything on GitHub down to the commit level, team, and permissions changes. That data is then used in metrics and tracking analysis to discover insights such as how many pull requests are coming in, how fast they are getting action, and how long they take to close or merge. “It gives us a way of tracking our presence,” said McAffer.

Simplifying open source use

Consumption of open source is an entirely different matter, and a different process, at Microsoft. The company uses open source in myriad ways, and the need to track them all and to manage the legal security aspects is enormous.

“We’ve done a massive amount of work to simplify the processes and the policies around open source use, to really understand the key attributes of being a responsible consumer of open source, how to do it right, and to make sure we adhere to the licenses,” McAffer said.

“To that end, we’ve written a lot of tools internally to discover, track, and monitor what’s going on there and report on the use of open source,” he continued. Those tools also tend to be somewhat proprietary as they are deeply integrated with Microsoft’s engineering systems.

“We’ve been trying to see ways we can tease that out and make more of that available to the open source community more broadly, but it’s been a bit hard because it is very specific in many ways to our business policy or our engineering system, which isn’t going to be the same as anybody else’s,” McAffer said.

Acknowledgements

We would like to thank Carol Smith, Senior Open Source Program Manager at Microsoft and Jeff McAffer, Director of Open Source Programs Office at Microsoft for being interviewed. We would also like to thank Pam Baker for performing the interview.