Trevor Livingston, principal architect at HomeAway, offers insight on how to introduce Node into companies at Node.js Interactive.
How to Maintain Open Source Compliance After Code Changes
The previous article in this series covered how to establish a baseline for open source software compliance by finding exactly which open source software is already in use and under which licenses it is available. But how do you make sure that future revisions of the same product (or other products built using the initial baseline) stay compliant once the baseline is established?
This is the concept of incremental compliance: you need to ensure compliance of whatever source code changes took place between the initial compliant baseline and the current version.
Maintaining open source license compliance throughout code changes is a continuous effort that depends on discipline and commitment to build compliance activities into existing engineering and business processes. And it’s a process that involves maintaining both the open source code, as well as the open source culture of an organization.
Below are some recommendations, based on The Linux Foundation’s e-book Open Source Compliance in the Enterprise, for some of the best ways to maintain compliance as your organization’s code and company evolves.
Maintaining Code Compliance
First, companies can maintain open source code compliance through processes and improvements aimed at the development process:
-
Adherence to the company’s compliance policy and process, in addition to any provided guidelines
-
Continuous audits of all source code integrated in the code base, regardless of its origins
-
Continuous improvements to the tools used in ensuring compliance and automating as much of the process as possible to ensure high efficiency in executing the compliance program
Maintaining a Culture of Compliance
In addition to the code, companies need to take steps to maintain compliance activities as the organization itself grows and ships more products and services using open source software. They must institutionalize compliance within their development culture to ensure its sustainability. Below are a few ways that companies can maintain the culture of compliance, as well as code compliance.
Sponsorship
Executive-level commitment is essential to ensure sustainability of compliance activities. There must be a company executive who acts as ongoing compliance champion and who ensures corporate support for open source management functions.
Consistency
Achieving consistency across the company is key in large companies with multiple business units and subsidiaries. A consistent interdepartmental approach helps with recordkeeping, and also facilitates sharing code across groups.
Measurement and analysis
Measure and analyze the impact and effectiveness of compliance activities, processes, and procedures with the goal of studying performance and improving the compliance program. Metrics will help you communicate the productivity advantages that accrue from each program element when promoting the compliance program.
Refining compliance processes
The scope and nature of an organization’s use of open source is dynamic — dependent on products, technologies, mergers, acquisitions, offshore development activities, and many other factors. Therefore, it is necessary to continuously review compliance policies and processes and introduce improvements.
Furthermore, open source license interpretations and legal risks continue to evolve. In such a dynamic environment, a compliance program must evolve as well.
A compliance program is of no value unless it is enforced. An effective compliance program should include mechanisms for ongoing monitoring of adherence to the program and for enforcing policies, procedures, and guidelines throughout the organization. One way to enforce the compliance program is to integrate it within the software development process and ensure that some measurable portion of employee performance evaluation depends on their commitment to and execution of compliance program activities.
Staffing
Ensure that staff is allocated to the compliance function, and that adequate compliance training is provided to every employee in the organization. In larger organizations, the compliance officer and related roles may grow to be FTEs (full time equivalents); in smaller organizations, the responsibility of open source management is more likely to be a shared and/or a part-time activity.
Read the first article in this series:
6 Operational Challenges to Using Open Source Software
In today’s rapidly evolving markets, companies that consistently innovate, most quickly and at the least cost, will win. And, as you’ve seen in our ongoing series, using Open Source Software (OSS) enables rapid, low-cost innovation. But it can also introduce operational challenges and legal risks.
We’re at a point now that OSS has become such a mainstream phenomenon that not using open source almost certainly places your organization at a disadvantage. So you must learn how to navigate the challenges and risks in order to remain competitive.
“Open source is ubiquitous, it’s unavoidable… having a policy against open source is impractical and places you at a competitive disadvantage.” — Gartner.
In this post, we’ll explore how open source became the de facto way to build software. Then we’ll cover the challenges this new method of software development has introduced for organizations. You can download the entire series now in our Fundamentals of Professional Open Source Management sample chapter.
The open source development revolution
From innovative beginnings in academic research and the GNU tools project started roughly four decades ago, OSS has grown into a major phenomenon that has reshaped multiple industries. Today, there are more than 1.5 million unique open source projects offering terabytes of working code to software developers. The availability of these resources and the trends toward modular software and software reuse have radically changed the way most companies develop software.
Not so long ago, we developed most of our software products in-house. We might have used a few third-party components for connectivity to other systems or some specialized processing, but these were acquired through a carefully controlled procurement process.
Today, we develop more complicated software faster by using open source components freely available on the Internet. Most of our activity has shifted from specifying and implementing our own custom software to integrating already available working pieces. We only code the parts that are truly unique to our application.
But now, instead of a few carefully controlled code acquisitions, we are repeatedly downloading code from the Internet to evaluate, prototype, and integrate. Although this approach speeds up development, it has created some significant new challenges.
6 OSS operational challenges
While using OSS brings many advantages, it can introduce risks and additional operational complexity to software development lifecycles.
● Organizations must deal with many new software sources, including commercial and noncommercial suppliers – some use OSS acquired from hundreds of different sources.
● The cornucopia of available open source components drives a higher volume of third-party software acquisition decisions. Where are these decisions being made? Many developers are not qualified to consider all of the necessary aspects including software license analysis, but a heavy-weight process like the old procurement approach is too expensive and time consuming to apply to the new volume of acquisitions.
● Integration of a large number of third party components can create complexity. One area of complexity is software version consistency across multiple interdependent stacks of code.
● Open source projects run the gamut from amateur exercises to professionally developed and tested releases. Your organization must ensure that appropriate levels of quality are chosen for each application.
● How will your organization obtain technical support and updates for all of these different open source components? Healthy open source communities provide excellent support and maintenance, but the self-service model of open source requires consistent participation on the part of your developers.
● Commercial relationships can reinforce your requirements with suppliers by adding a financial incentive, but influencing open source project direction is dependent upon multiple aspects of participation.
In our final article, we’ll discuss the legal issues and risks that come when companies incorporate OSS into their own software projects. And we’ll introduce the spectrum of open source license types with which organizations should become familiar.
Read more:
Using Open Source Software to Speed Development and Gain Business Advantage
6 Reasons Why Open Source Software Lowers Development Costs
Why Using Open Source Software Helps Companies Stay Flexible and Innovate
Call for Proposals Now Open for Xen Project Developer and Design Summit 2017
We’re excited to announce that registration and the call for proposals is open for Xen Project Developer and Design Summit 2017, which will be held in Budapest, Hungary from July 11-13, 2017. The Xen Project Developer and Design Summit combines the formats of Xen Project Developer Summits with Xen Project Hackathons, and brings together the Xen Project’s community of developers and power users.
Submit a Talk
Do you have an interesting use case around Xen Project technology or best practices around the community? There’s a wide variety of topics we are looking for, including security, embedded environments, network function virtualization (NFV), and more. You can find all the suggested topics for presentations and panels here (make sure you select the Topics tab).
Several formats are being accepted for speaking proposals, including:
- Presentations and Panels
- Interactive design and problem solving sessions. These sessions can be submitted as part of the CFP, but we will reserve a number of design sessions to be allocated during the event. Proposers of design sessions are expected to host and moderate design sessions following the format we have used at Xen Project Hackathons. If you have not participated in these in the past, check out past event reports from 2016, 2015 and 2013.
Never talked at a conference before? Don’t worry! We encourage new speakers to submit for our events and have plenty of resources to help you prepare for your presentation.
Here are some dates to remember for submissions and in general:
- CFP Close: April 14, 2017
- CFP Notifications: May 5, 2017
- Schedule Announced: May 16, 2017
- Event: July 11-13, 2017
Registration
Come join us for this event, and if you register by May 19, you’ll get an early bird discount 
Travel stipends are available for students or individuals that are not associated with a company. If you have any questions, please send a note to community.manager@xenproject.org.
This article originally appeared on Xen Project Blog