Posts

maintainer

At Embedded Linux Conference, Sony’s Tim Bird discussed some of the challenges faced by maintainers of open source projects.

What are some of the challenges open source project maintainers face? One common issue is “The Maintainer’s Paradox,” which refers to the fact that open source maintainers are presented with more ideas along with more challenges as their communities grow. This occurs even when they take very minor patches from contributors. This topic was recently tackled by Tim Bird, Senior Software Engineer at Sony, in a keynote address at the Embedded Linux Conference.

The Maintainer’s Paradox is referenced in Eric Raymond’s seminal work “The Cathedral and the Bazaar,” and Bird opened his keynote address by citing the reference. “Raymond said that with enough eyeballs, all bugs are shallow,” Bird noted, adding that the reference applies to large open source communities.

Diversity of thought

“When I do training at Sony, I use a light bulb metaphor for this,” he said. “If you have five or 10 light bulbs that are similar to each other and you turn them on, there will be some good ideas represented by those light bulbs. But if you have a thousand light bulbs of different shapes and sizes, it’s more likely that there are going to be thousands of good ideas represented. So there are probabilities involved here. It’s the diversity of thought that is important. Diversity has a lot of upside.”

“Of course diversity has costs,” he added. “It takes time to assimilate different ideas and integrate them into the existing code path.”

Bird is the maintainer of the Fuego test system, which provides a framework for testing embedded Linux. During his keynote, he provided examples of challenges that maintainers face,  within the context of maintaining Fuego.

Tread carefully

“I learned things becoming a maintainer,” he said. “The Maintainer’s Paradox is that the maintainer is really excited about new contributions, but there is also fear and trepidation. Sometimes when I see a patch set on the mailing list I say, ‘Oh no, another patch set.’ I just might not have time to look at it. You want to review patches carefully and give appropriate feedback, but being a maintainer is sometimes overwhelming.”

Bird displayed a large photo of a puppy as he said: “Every time you get a patch that implies a new feature branch, that is something that has to be cared for indefinitely. As a maintainer, your incentive can be to not take too many of these things.”

Bird also noted some important social dynamics involved with how maintainers interact with community members. For example, differing personalities can create challenges. “People can get frustrated, and there can be miscommunications.” Additionally, although many maintainers want to reward contributions on a meritocracy basis, it can be difficult to achieve that goal.

What are Bird’s recommendations for optimizing tasks and communications? He supplied the following tips:

  • Call out negative communication
  • Route around offenders
  • Listen carefully, actively clarify and act on feedback
  • Assist by helping others
  • Become a maintainer

Finally, for more on active management of open source projects, including free tools, check this post.

Watch the entire presentation below:

Join us at Open Source Summit + Embedded Linux Conference Europe in Edinburgh, UK on October 22-24, 2018, for 100+ sessions on Linux, Cloud, Containers, AI, Community, and more.

OS Summit

See schedule highlights for Automotive Linux Summit and Open Source Summit Japan in Tokyo, June 20-22.

Attend Automotive Linux Summit and Open Source Summit Japan in Tokyo, June 20 – 22, for three days of open source education and collaboration.

Automotive Linux Summit connects those driving innovation in automotive Linux from the developer community, with the vendors and users providing and using the code, in order to propel the future of embedded devices in the automotive arena.

Open Source Summit Japan is the leading conference in Japan connecting the open source ecosystem under one roof, providing a forum for technologists and open source industry leaders to collaborate and share information, learn about the latest in open source technologies and find out how to gain a competitive advantage by using innovative, open solutions. The event covers cornerstone open source technology areas such as Linux, cloud infrastructure, and cloud native applications and explores the newest trends including networking, blockchain, serverless, edge computing and AI. It also offers an open source leadership track covering compliance, governance and community.

Session highlights for Automotive Linux Summit:

  • Enabling Hardware Configuration Flexibility Keeping a Unified Software – Dominig ar Foll, Intel
  • Beyond the AGL Virtualization Architecture – AGL Virtualization Expert Group (EG-VIRT) – Michele Paolino, Virtual Open Systems
  • High-level API for Smartphone Connectivity on AGL – Takeshi Kanemoto, RealVNC Ltd.
  • AGL Development Tools – What’s New in FF? – Stephane Desneux, IoT.bzh

Session highlights for Open Source Summit Japan:

  • Building the Next Generation of IoT Applications – Dave Chen, GE Digital
  • Use Cases for Permissioned Blockchain Platforms – Swetha Repakula & Jay Guo, IBM
  • Using Linux for Long Term – Community Status and the Way We Go  – Tsugikazu Shibata, NEC
  • Hitchhiker’s Guide to Machine Learning with Kubernetes – Vishnu Kannan, Google
  • OSS Vulnerability Trends and PoC 2017-2018  – Kazuki Omo, SIOS Technology, Inc.
  • Microservices, Service Mesh, and CI/CD Pipelines – Making It All Work Together  – Brian Redmond, Microsoft

View the Full Schedule >>

Register now and save $175 through April 28!

Register Now>>

Note: One registration gets you access to both Automotive Linux Summit and Open Source Summit Japan.

Linux Foundation members and LF project members receive an additional 20% discount off current registration pricing, and academic, student, non-profit, and community discounts are available as well. Email events@linuxfoundation.org to receive your discount code.

Applications for diversity and needs-based scholarships are also being accepted. Get information on eligibility and how to apply.

Fossology

To help celebrate Fossology’s 10th anniversary, we look at how the project makes it easier to understand and comply with open source licenses.

FOSSology turns ten this year. Far from winding down, the open source license compliance project is still going strong. The interest in the project among its thriving community has not dampened in the least, and regular contributions and cross-project contributors are steering it toward productive and meaningful iterations.

An example is the recent 3.2 release, offering significant improvements over previous versions, such as the import of SDPX files and word processor document output summarizing analysis information. Even so, the overall project goal remains the same: to make it easier to understand and comply with the licenses used in open source software.

There are thousands of licenses used in Open Source software these days, with some differing by only a few words and others pertaining to entirely different use universes. Together, they present a bewildering quagmire of requirements that must be adhered to, but only as set out in the appropriate license(s), the misunderstanding or absence of which can revert rights to a reserved status and bring about a complete halt to distribution.  

How FOSSology came to be

In short, there are over a 1000 different ways licensing can go mildly or horribly wrong, creating a desperate need to find one single way to make sure everything goes consistently right. Enter FOSSology, which as the website points out, is all about scanning: It’s a framework, toolbox and Web server application for examining software packages in a multi-user environment.

There are several important highlights since the first version of the FOSSology project was published in December 2007. The Linux Foundation started hosting it in 2015. The 3.2 release was in March 2018, which, as mentioned above, provides the ability to import SPDX files. SPDX (Software Package Data Exchange) is another Linux Foundation project that helps reduce complexity by defining standards for reporting and sharing licensing information. FOSSology is the first open source project to consume SPDX in this way.

“This project has been more successful than anticipated, because license compliance was a very special topic, and running it as an open source project is also difficult, because it has a naturally small community,” said Michael C. Jaeger, Senior Research Scientist Open Source Software at Siemens AG, Maintaining FOSSology and SW360, and Trainer at SW Compliance Academy.

When goal and delivery are tightly entwined, as are the benefactors and beneficiaries, good things come from any project.

“License compliance for open source projects is hard, and FOSSology helps here by doing most of the work, such as scanning the files to find licenses, copyright statements and more, to simplify the necessary clearing. It also generates reports which can be used to document the results, which is rather important in the context of larger companies,” said Maximilian Huber, a software consultant at TNG Technology Consulting.

A paper titled “The FOSSology Project: 10 Years Of License Scanning,” has been prepared to commemorate the 10th anniversary. Project members will be participating  at the FSFE’s Legal and Licensing Workshop in Barcelona this week to present on the project.

The project’s value and who benefits  

“It is important because it offers organizations a free software solution for license compliance – an area where commercial products have a very dominant position for more than a decade. However, with free software, especially open source projects can implement license compliance without upfront cost,” explained Jaeger.

FOSSology fits in well with the other open source compliance related projects like SPDX, OpenChain, and SW360. Indeed, there is even community and developer cross-over with some of these projects and FOSSology.

“There is one person who is a maintainer in both the SW360 and FOSSology projects, and there are some persons contributing to both projects in different roles,” said Jaeger. “Consequently and naturally, there is good coordination between both projects. The FOSSology project also has a long history for supporting SPDX since it represents the de facto standard for exchanging license compliance information.”

“With its review functionality, FOSSology was one of the first supporters of the concept of concluding a license in SPDX,” he added. “It was also the first project which allowed for importing SPDX descriptions, another elementary support because the “X” in SPDX stands for exchange and not “eXport.” As far as I know, OpenChain is not concerned very much with particular tooling; however, FOSSology helps to implement OpenChain conformance.”

And the momentum continues. More changes are on the horizon and some new obstacles as well.

“In the future, more and more open source projects will be straightforwardly licensed and the strong scan correction functionality and file review functionality of FOSSology will move to the background,” said Jaeger.

“However, questions still arise because of incompatibilities of licensings, or in considering obligations of licensing. Therefore, FOSSology needs to shift its focus from correcting scan results of not-well-formed licensing to licensing analysis and license problems on the component level.”

Modernization efforts are also under consideration.

“An important goal is to modularize the parts of FOSSology, to allow a smooth transition to a more modern architecture and software stack,” added Huber.

As even more licensing and related tools cross the horizon, simplifying the information exchange between them and FOSSology will be an ongoing task. That in turn will further cement FOSSlogy’s place in the license compliance ecosystem.

But today, all attention is on a decade of successes and the community that’s responsible for so many wins.

Happy anniversary, FOSSology!

software security

Software security requires discipline and diligence, said Mårten Mickos, speaking at the Open Source Leadership Summit.

Achieving effective security takes constant discipline and effort on everyone’s part – not just one team or group within a company. That was Mårten Mickos’s message in his keynote speech appropriately titled, “Security is Everyone’s Responsibility,” at The Linux Foundation’s recent Open Source Leadership Summit (OSLS).  

Mickos, CEO of HackerOne, which he described as a “hacker-powered security company,” told the audience that $100 billion has been spent on cybersecurity, yet, “Half of the money is wasted. We’ve been buying hardware and software and machines and walls and all kinds of stuff thinking that that technology and [those] products will make us secure. But that’s not true.”

Even if you ply your network with hardware to create a perimeter around it, it won’t make your organization any more secure, Mickos said. The answer is much simpler, he maintained, and the magic bullet is sharing.

“You share the defense, you share information, you work together,’’ he said. “You can’t have secure software if just some of your software engineers are in charge of security. You can’t just delegate it or relegate it to a security team. If you do that it won’t happen.”

Mickos likened that approach to the 1990s, when companies had quality managers and people got ISO certifications. “It didn’t help. It reduced quality in the companies, because people felt that quality now was the job of somebody else, not of you.”

Discipline

Software security, Mickos said, “only happens when we’re very disciplined.”

Mickos’ company has 160,000 contributors, including security researchers, ethical hackers and “white hats;” people who have signed up to find flaws in software, he said.  Security vulnerabilities can emanate from situations even when there are no bugs, he noted, adding that HackerOne hacked the U.S. Air Force in eight minutes.

“We found 200 vulnerabilities in the Air Force’s systems, 20 of those were found by Jack Cable, a 17-year-old high school student from Chicago, Ill.,” he said.

HackerOne has fixed over 65,000 security vulnerabilities, Mickos claimed. “So that has removed a lot of holes where criminals could have entered. But there are still tens of millions of vulnerabilities; no one knows the exact number. But if we deploy 100 billion lines of code every year … there’s a lot of security to look after.”

Pooled Defense

In his speech, Mickos promoted the notion of a “pooled defense;” the idea that “the number of defenders is far larger than the number of bad guys.’ He said there are far more white hats in the world than there are cyber criminals or “black hats.”

Cyber threats are often characterized as being asymmetric, he said, in the sense that one single criminal attacker can cause a lot of harm — so much so that a company needs 100 people to defend against it.

“If companies can get together and pool their defense, you … suddenly you have 10 times the power of the attackers,’’ he said. “If you share information, share the defense, share best practices, and share the act of responding to threats, then you overcome the asymmetry and you turn it around.”

It takes discipline and diligence, Mickos said, recalling how Equifax had “so many failures and acts of negligence or … omissions in the way they handle security,” and that “it was one single software vulnerability that led to the data breach in their systems.” Meanwhile, he added, “There’s nobody here who has a software system with just one vulnerability.”

While people often complain about long passwords or having to use multi-factor authentication because it is so time-consuming, they had better get used to it, he cautioned.

“Security doesn’t come for free. The only thing that … acts against these threats is the discipline and diligence [and] remembering long passwords,’’ Mickos said. “Even when somebody invents a method where we don’t need passwords anymore, you will be asked to do something else which is burdensome and every day, and where you’re not allowed to miss it one single time.”

Mickos also had a message for educational institutions: “Don’t call it computer science and software engineering unless there’s security in it. Today, you can graduate in CS without taking a single course in security.” He said he didn’t pay attention to the importance of security when he was in college, but different times call for a different approach. Today, security “has to become part of everything we do.”

We Can Turn the Ship

When everyone recognizes that security is a shared responsibility, he stressed, “the ship will turn. It’s a big ship, so it turns slowly, but it will turn, and we will get to a state that is similar to what we have with airline safety or hospital hygiene or … automotive safety, where today it all works. But it works because we do it together and we jointly take responsibility for it.”

Watch the complete presentation below:

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 »

Xen hypervisor

When it comes to automotive software, there are three key things to think about: safety, safety and safety.

Open source moves into most industries in the same way. First, it is seen as unimportant, then too risky, and suddenly, it becomes essential.

Just think about some of the fundamental building blocks of the connected economy – Linux, HTTP, SSL, Apache Web Servers and so much more. Each of these major open source platforms were combined and refined by many companies to provide a business platform, leading to billions upon billions of dollars in growth. Banking, Commerce, Media, Agriculture, Energy and other massive industry sectors are wholly dependent on the widespread use of open source software to function.

Of course, each industry is different and faces its own set of unique challenges and requirements. In particular, the automotive industry is rightfully cautious about all software, not just open source. However, the industry has come to trust proven platforms that have shown results over time, rather than novel capabilities.

Xen Hypervisor

So, it is no surprise that the open source Xen Hypervisor is quickly moving to the forefront of open source technology for automotive. With a history that stretches back to the late 1990s, Xen is one of the oldest “new” technologies around. Starting as a research project at Cambridge University, Xen was first made open source in 2002 and then became deeply integrated into major Linux distributions in 2011.

When it comes to automotive software, there are three key things to think about: safety, safety and safety. Stability and maturity matter in automotive software. This is where the combination of Xen maturity, 14 years and counting, running in major data centers around the globe, and open source software development have come together to ensure a stable base for new innovations in connected vehicles.

Then there is the basic architecture of the open source Xen Hypervisor. No one wants anything interfering with mission-critical functions. If businesses don’t want to allow software to communicate with hardware, then take out the hardware drivers as driver disaggregation is a basic concept of Xen.

Additionally, there’s the matter of ensuring that the code itself is manageable and does not consume too many system resources. Computers in vehicles are not particularly powerful and their local storage capacity is limited, which can be challenging. However, refining the open source code to the “essentials” is not only possible, it is a best practice. Consider that Xen is about 90K lines of code. It’s small enough to manage and consumes very little computing power, which is a huge benefit for any embedded engineering project with constrained resources.

Open Source in Automotive

Another reason automotive companies often overlook open source is because organizations believe that there’s no economic value to participating in its development and distribution. The hundreds of billions of dollars made each year by hundreds of companies (including Apple, Facebook, Google, Amazon, RedHat and thousands of others) prove otherwise. There are a myriad of benefits – cost reduction, speed of deployment and simplification of change management – that come with utilizing open source software, and the industry could accelerate business value by leveraging these tools.

2018 is shaping up to be an important year for open source in automotive, but there are still a few major concerns that need to be resolved. Out of all the challenges that the industry faces, the primary concern involves third-party safety certification. Attaining third-party certification for any software project (open source or not) is difficult.

However, the argument that open source software, by its nature, can’t be certified or used in life safety applications is invalid. For example, open source software has been behind image-guided surgery equipment since 2006, spurring innovation and advancement in robotic-assisted platforms and improving patient outcome. In 2018, you can expect to see the transition from “useful” to “essential” for more and more open source projects, especially as the whole industry steps up and learns how to use software as a competitive differentiator in the marketplace.

Martin Focazio is Managing Principal, Business Consulting, EPAM

The influence of open source software on every aspect of business has been on the rise for years, and it should come as no surprise that its influence during merger and acquisition (M&A) transactions has grown as well. In particular, open source audits are part of required due diligence in M&A or initial public offering (IPO) processes. Not only do such audits highlight potential instances of copyright infringement, but they give buyers and investors a landscape view of important open source components in their target’s technology stack.

These issues and more are covered in-depth in a new ebook, Open Source Audits in Merger and Acquisition Transactions, from Ibrahim Haddad and The Linux Foundation, which provides an overview of the open source audit process and highlights important considerations for code compliance, preparation, and documentation.

Today’s software products and technology stacks incorporate many open source components, and the implementation of these components can mean complex licensing and inter-dependency issues.  Part of the goal with a proper source code audit is to avoid unpleasant surprises post-acquisition. Source code scanning tools have the ability to discover and match snippets of open source code that have been incorporated within software tools and platforms. In addition, these tools can identify modifications to open source code that developers may have deployed.

“Every M&A transaction is different, but the need to verify the impact of acquiring open source obligations is a constant,” writes Haddad. “Open source audits are carried out to understand the depth of use and the reliance on open source software. Additionally, they offer great insights about any compliance issues and even about the target’s engineering practices.”

Haddad also notes that open source audits can expose obligations. “Open source licenses usually impose certain obligations that must be fulfilled when code is distributed,” he notes. “One example is the GNU General Public License (GNU GPL), which requires derivatives or combinations to be made available under the same license as well. Other licenses require certain notices in documentation or have restrictions for how the product is promoted.”

According to Haddad, there are three common types of open source audits that are performed in M&A situations:

  1. Traditional audit, in which the auditor gets complete access to all the code and executes the audit either remotely or on site.
  2. Blind audit, in which the auditor does the work remotely and without ever seeing the source code.
  3. “Do It Yourself” audit, where the target company or the acquirer performs most of the actual audit work themselves using the tools with the option for a random verification of results from the auditing company.

Is a merger and acquisition scenario the only time an organization should consider an open source audit? No, regular audits can provide much value, and companies such as Black Duck Software have specialized in doing them in many types of business scenarios. “While it’s undeniable that an open source audit is essential before any successful M&A or IPO, it’s no less important as part of a software team’s regular operations,” notes a blog post from White Source Software. “Put it this way, if you have license compliance or security issues affecting your open source components, isn’t it better to identify and deal with those issues sooner rather than later?”

Many important issues arise during audits, including potential security threats and lapses in version control. Everything you need to know, including recommended practices and mistakes to avoid, can be found in this ebook.

Download the ebook now.

open source and standards

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

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

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

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

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

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

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

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

In Red Hat’s open source toolbox

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

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

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

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

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

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

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

Measuring Success

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

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

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

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

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

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

Acknowledgements

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

Shuah Khan

Shuah Khan, of Samsung Research America, is a Linux kernel contributor and maintainer.

The Linux kernel development community remains extremely busy, as shown in the recent Linux Kernel Development Report, written by Jonathan Corbet and Greg Kroah-Hartman. Since the 4.7 release, just under 83,000 changesets have been merged from 4,319 individual developers representing 519 known corporations. Part of this busy development process involves the kernel testing infrastructure. According to the report, the “zero-day build and boot robot” system alone found 223 bugs (all of which were fixed) during the most recent reporting period. The in-kernel self-test framework continues to improve and will someday be a comprehensive test suite for the kernel.

Shuah Khan

Shuah Khan

Shuah Khan, Senior Linux Kernel Developer at Samsung Research America, is the maintainer of the kernel self-test framework. In this article, Khan answers a few questions about her work on the Linux kernel.

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

Shuah Khan: I maintain the Linux kernel self-test framework and USB-over-IP driver. I also contribute to the Linux Media, Power Management, IOMMU, and DMA areas. I publish articles related to the Linux kernel on the Samsung Open Source Group (OSG) blog and have previously written for the Linux Journal, where I authored a paper on Linux Kernel Testing and Debugging.

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

Khan: My main focus this year has been Exynos platform upstream stability, Kselftest framework and individual tests. I contributed to improving the quality of media subsystem core, and media and drm drivers on Exynos platform. I enhanced and improved the Kselftest framework by adding support for the Test Anything Protocol and object relocation. In addition, I boot tested stable kernel release candidates and maintained the Kselftest and USB-over-IP drivers.

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

Khan: The Linux Kernel community should continue its focus on adding support for new hardware, harden the security, and improve quality. Focusing on effective ways to proactively detect security vulnerabilities, race conditions, and hard-to-find problems will help towards achieving the above goals. As a process issue, community would have to take a close look at the maintainer to developer ratio to avoid maintainer fatigue and bottlenecks.

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

Khan: Contributing to the Linux kernel requires a unique set of skills in addition to the technical know-how. Contributors should be open to their ideas and work challenged and questioned, be ready to accept criticism, be open and flexible to evolve their ideas and work based on feedback from other contributors. It is an iterative process of review and refinement to evolve a fix or a feature that adds value to the kernel. I enjoy the technical challenges and being part of the community that works towards a common goal of making the Linux kernel better in each release.

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.

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.