Posts

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!

Open Source Summit

Only two weeks left to submit your talk for Open Source Summit North America.

Submit a proposal to speak at Open Source Summit North America taking place August 29-31, in Vancouver, B.C., and share your knowledge and expertise with 2,000+ open source technologists and community members. Proposals are being accepted through 11:59pm PDT, Sunday, April 29.

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 (Open Collaboration Conference track)
  • Diversity & Inclusion (Diversity Empowerment Summit)
  • Innovation at Apache/in Apache Projects (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)

View the full list of suggested topics, learn more about the 2018 Program Chairs, Track Chairs, and Program Committee, and submit now >>

SUBMIT YOUR TALK

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.
open source project

Focusing on teamwork is important to open source projects. “It’s a collaborative effort,” says Matt Butcher.

Are you managing an open source project or considering launching one? If so, it may come as a surprise that one of the challenges you can face is rapid growth. Matt Butcher, Principal Software Development Engineer at Microsoft, addressed this issue in a presentation at Open Source Summit North America. His talk covered everything from teamwork to the importance of knowing your goals and sticking to them.

Butcher is no stranger to managing open source projects. As Microsoft invests more deeply into open source, Butcher has been involved with many projects, including toolkits for Kubernetes and QueryPath, the jQuery-like library for PHP.

Butcher described a case study involving Kubernetes Helm, a package system for Kubernetes. Helm arose from a company team-building hackathon, with an original team of three people giving birth to it. Within 18 months, the project had hundreds of contributors and thousands of active users.

Teamwork

“We were stretched to our limits as we learned to grow,” Butcher said. “When you’re trying to set up your team of core maintainers and they’re all trying to work together, you want to spend some actual time trying to optimize for a process that lets you be cooperative. You have to adjust some expectations regarding how you treat each other. When you’re working as a group of open source collaborators, the relationship is not employer/employee necessarily. It’s a collaborative effort.”

In addition to focusing on the right kinds of teamwork, Butcher and his collaborators learned that managing governance and standards is an ongoing challenge. “You want people to understand who makes decisions, how they make decisions and why they make the decisions that they make,” he said. “When we were a small project, there might have been two paragraphs in one of our documents on standards, but as a project grows and you get growing pains, these documented things gain a life of their own. They get their very own repositories, and they just keep getting bigger along with the project.”

Should all discussion surrounding a open source project go on in public, bathed in the hot lights of community scrutiny? Not necessarily, Butcher noted. “A minor thing can get blown into catastrophic proportions in a short time because of misunderstandings and because something that should have been done in private ended up being public,” he said. “Sometimes we actually make architectural recommendations as a closed group. The reason we do this is that we don’t want to miscue the community. The people who are your core maintainers are core maintainers because they’re experts, right? These are the people that have been selected from the community because they understand the project. They understand what people are trying to do with it. They understand the frustrations and concerns of users.”

Acknowledge Contributions

Butcher added that it is essential to acknowledge people’s contributions to keep the environment surrounding a fast-growing project from becoming toxic. “We actually have an internal rule in our core maintainers guide that says, ‘Make sure that at least one comment that you leave on a code review, if you’re asking for changes, is a positive one,” he said.  “It sounds really juvenile, right? But it serves a specific purpose. It lets somebody know, ‘I acknowledge that you just made a gift of your time and your resources.”

Want more tips on successfully launching and managing open source projects? Stay tuned for more insight from Matt Butcher’s talk, in which he provides specific project management issues faced by Kubernetes Helm.

For more information, be sure to check out The Linux Foundation’s growing list of Open Source Guides for the Enterprise, covering topics such as starting an open source project, improving your open source impact, and participating in open source communities.

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

Modern open source projects rarely consist solely of all new code, written entirely from scratch. More often, they are built from many sources. And, each of these original sources may operate under a particular license – which may also differ from the license that the new project uses.

license scanning and complianceA new publication, called License Scanning and Compliance Programs for FOSS Projects, aims to clarify and simplify this process. This paper, written by Steve Winslow from The Linux Foundation, describes the benefits of license scanning and compliance for open source projects, together with recommendations for how to incorporate scanning and compliance into a new or existing project.

Winslow runs The Linux Foundation’s license scanning and analysis service, and he advises projects about licenses identified in their source code and dependencies.

He says that getting license compliance right early can help attract contributors and users to an open source project. However, he notes that license scanning and compliance are not end goals; rather, they are processes that can serve other objectives, including:

  • Protecting the project’s developers.
  • Assisting downstream compliance efforts.
  • Demonstrating project maturity.  

According to Winslow, “any project that implements license scanning and compliance should aim to make it sustainable” and should set realistic goals to avoid being overwhelmed by the number of options and issues that may arise.

Winslow also explains how using tools, such as FOSSology for license scanning and Software Package Data Exchange (SPDX) to help package scan results into meaningful reports, can help projects succeed in compliance efforts.

Learn more and download this free publication now.

product manager

As a product manager, you should definitely look at how open source can impact on your customer’s experience.

As open source program offices emerge in organizations worldwide, the focus is often on developers and other technical leaders. This makes sense – the drive for an open source program office comes from developers who are already engaged in open source.

But, as explored in the recent open source guide on starting a new open source project in your organization, as you build credibility as an open source contributor, you may want to open source your own code. Although developers are used to engaging in open source, when you look to open source your code, others in the organization will need to engage as well.

A key participant in this process is the product manager – this person drives the direction of the product forward with input from the business, engineering staff, and user feedback. This complex job requires the product manager to manage strategy, roadmap, features, and delivery – many think of it as being the “CEO of the product.” The product manager must also be creative and collaborative to be successful, especially when looking at how to build out the product and the ecosystem surrounding it.

So, how can the product manager look at leveraging open source as part of their product strategy?

Filling in the gaps in product development

Product features tend to fall into one of two gaps – features that are key differentiators and that actively sell the product, and those that just need to be there but don’t actively sell the product (often referred to features that “check the boxes”). The latter is likely an area where open source can help.

For example, suppose you are building a task management application. The key pieces that differentiate the product would likely be ease of use, integration with key productivity applications, as well as the approach taken to managing/assigning tasks – those features are ones you’d ensure your team is best skilled at building. But what about the authentication? Or maybe iCal integration for publishing tasks on a calendar? Those are all great features, but you could leverage open source libraries or tools to add them easily without knowing the ins and outs of dealing with identity providers or the iCal spec.

Leveraging open source this way gives you both the ability to deliver product faster and to increase functionality and stability as those tools are further developed over time.

Enabling an ecosystem

Thinking about that task management application, the possibilities for how people would use it are probably endless. And on top of that, your users might have specific applications they would like to integrate into it. In a proprietary model, the product owner is the full gatekeeper of such things, but an open source model lets the product thrive and build an ecosystem of applications and integrations to increase customer value.

Ecosystem building is the holy grail for a product manager – it helps bring your application out of a silo and be relevant to more users. This gives the product manager two important assets:

  • Insight into how the product is used by the integrations being leveraged.
  • Freedom for your customer to evolve how they use the application without being blocked by product development.

Finding talented developers

As the product grows, so does the team to support it. How do you best identify the right person with the skills and interest in developing out that product? Start by looking at those in the community who are most active in working with the code.

Bringing in developers to work on the team in the ecosystem ensures they have the skills to be effective right away. But since they have chosen to spend time on the code already, you know they find value in the work and are much more likely to stay with the product for the long term.

Collaborating on hard problems

Some technical problems are just hard, and finding the right talent to work on them may not be feasible. Open source collaboration evens the playing field and helps bring in the best talent to solving those problems, sometimes with competitors in the market.

Managing these projects can be hard, but the projects in turn can produce amazing results. For examples of this in practice, check out projects such as the Apache Hadoop project, and Automotive Grade Linux – both of which have competitors collaborating together in a vendor-neutral forum.

Open source is a transformational technology that enables people and organizations to innovate faster, collaborate globally, and make a different in each of our lives. As a product manager, you should definitely look at how open source can be used to make a noticeable impact on your customer’s experience.

OSLS

Keynote speakers announced for The Linux Foundation Open Source Leadership Summit.

The Linux Foundation Open Source Leadership Summit is the premier forum for open source leaders to convene to drive digital transformation with open source technologies and learn how to collaboratively manage the largest shared technology investment of our time.

Confirmed keynote speakers and panelists for this year’s event include:

  • Deepak Agarwal, VP of Artificial Intelligence at LinkedIn
  • Subbu Allamaraju, VP of Technology, Expedia
  • Dustin Bennett, Software Engineer Sr. Manager, The Home Depot
  • Austen Collins, Founder & CEO, Serverless Inc.
  • Justin Dean, SVP Platform & TechOps, Ticketmaster
  • Ashley Eckard, Sr. Software Engineer, The Home Depot
  • Dr. Mazin Gilbert, Vice President of Advanced Technology, AT&T Labs
  • Chen Goldberg, Director of Engineering, Google Cloud
  • Nidhi Gupta, SVP of Engineering, Hired
  • Patrick Heim, Operating Partner & CISO, ClearSky Security
  • John M. Jack, Board Partner, Andreessen Horowitz and Advisor to The Linux Foundation
  • Edward Kearns, Chief Data Officer, National Oceanic and Atmospheric Administration
  • Marten Mickos, CEO, HackerOne
  • Mark Russinovich, CTO, Microsoft Azure, Microsoft
  • Tarry Singh, Author, AI, ML & Deep Learning Executive, and Deep Learning Mentor, Coursera
  • Aaron Symanski, Chief Technology Officer, Change Healthcare
  • Rachel Thomas, Co-Founder, Fast.ai
  • Jim Zemlin, Executive Director, The Linux Foundation

Open Source Leadership Summit fosters innovation, growth, and partnerships among the leading projects and corporations working in open technology development. Business and technical leaders will gather at the summit to advance open source strategy, implementation and investment.

Here’s How To Join Us at Open Source Leadership Summit:

Speak

Are you a business or technical leader looking to advance open source strategy, implementation and investment? Join us and share your expertise at Open Source Leadership Summit. View the full list of suggested topics and submit a proposal by 11:59pm PST on Sunday, January 21, 2018.  

Attend

Attendance to Open Source Leadership Summit is limited to members of The Linux Foundation and LF Hosted Projects, as well as media, speakers and sponsors. If you are a member, and would like to attend, email us at events@linuxfoundation.org.  For media attendance inquiries, email Dan Brown at dbrown@linuxfoundation.org.

Sponsor

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.

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

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

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

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

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

A good application of strategy achieves the following:

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

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

Setting a mission and vision

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Goals, Objectives, Actions, and Results

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

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

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

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

You can put these into a table like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

Creating a Policy

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

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

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

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

The Using Open Source Code guide can help you with everything from licensing issues to best development practices, and it explores how to seamlessly and safely weave open components into your open source projects. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

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

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

How to Create an Open Source Program

Tools for Managing Open Source Programs

Measuring Your Open Source Program’s Success

Effective Strategies for Recruiting Open Source Developers

A Free Guide to Participating in Open Source Communities

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

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

Linux kernel developer

Laura Abbott, a Fedora Kernel Engineer at Red Hat

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

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

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

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

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

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

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

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

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

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