Open source project management can be risky business

Our digital lives are powered by programming philosophers who choose to develop their code out in the open.

All programs begin with lines of instruction. When ready for execution these lines of instruction are converted to a binary format that the computer can execute. Open source programs are programs where the human readable code is accessible to anyone. This philosophy of openness and freedom has allowed these projects to impact the lives of everyone.

The Linux kernel is the core of all Android devices, and nearly a third of all Internet traffic rides on just one openly developed project, Netflix. (Read the excellent article in Time magazine about this.) How does the choice of using open source software as part of a project plan affect the amount and type of risk to a project within an organization?

Risk is both a perception and a reality. Tools help us move from perception toward reality the same way good thermometers helped us move from very generalized use of the terms hot and cold to more specific quantifiable temperatures (see an example in Google). Over time we've adopted different standards and techniques for discussing specific temperatures, which depend on the audience and the standard's limitations. Kelvin, Celsius, Fahrenheit, and even RealFeel are now established standards for measuring temperature.

^{Illustration 1: Quantifying temperatures}

Every project has risk and every PM (project manager) perceives and articulates that risk differently with various levels of accuracy. The understanding of risk may be as simple as a good or bad description similar to the terms hot and cold. The PMBOK (Project Management Body of Knowledge) states that the process for discussing risk management should move from a qualitative evaluation to a quantitative one (as stated in the Project Management Institute's publication, "A guide to the project management body of knowledge/PMBOK Guide" (5th ed.)). Like temperature, the discipline of project management has different quantifiable standards for measuring project risk. At least one of these standards for risk evaluation communicates why open source software is often rejected as a possible consideration for projects during the project planning process.

The Risk Complexity Index discussed in Tom Kendrick's book Identifying and Managing Project Risk (Kendrick, 2015) serves as our foundation. Complexity indexes aren't uncommon in project risk management. David Bearden used a complexity index to show how NASA's adoption of its FBC (Faster, Better, Cheaper) philosophy has impacted project risk. While his index is based upon near recent data points, the risk complexity index in Kendrick's book attempts to be more predictive. Kendrick articulates the formula for the index as:

Index = (Technology + Architecture + System) X Scale

Technology, Architect, and System are scored from 0 to 5, based on the PM's experience and capabilities. "Architecture refers to high-level functional components and any external interfaces, and System is the internal software and hardware that will be used in the product. The Technology dimension is defined as the basis for development used on the project," Kendrick said in his book. He explains that the Index could be scored using the following key:

0. Only existing technology required
1. Minor extensions to existing technology needed in a few areas
2. Significant extensions to existing technology needed in a few areas
3. Almost certainly possible, but innovation needed in some areas
4. Probably feasible, but innovation required in many areas
5. Completely new, technological feasibility in doubt

Scale is assigned a value based on the number of people expected on the project:

• 0.8 Up to 12 people
• 2.4 Up to 40 people
• 4.3 Up to 100 people
• 6.6 More than 100 people

In this index a result of 0 to 20 is considered low risk, 20 to 40 is medium risk, while the range from 40 to 100 is high risk. Just as a price tag is a summary of the cost of production elements for a given item on the grocery store shelves, this index is a summary of items that contribute to project risk. At this point of risk management, the risks have been identified and quantified. Initially, the entire risk index refers to the risk of the project internal to the organization conducting it. After mitigation measures are developed the project can be re-scored with the matrix.

^{Scoring risk}

In Adrienne Watt's chapter in the book Risk Management on risk management planning, she discusses four strategies for mitigating risk. These are risk avoidance, risk sharing, risk reduction, and risk transfer. After applying some combination of these strategies, the PM team can rework the risk complexity index to determine if they reduced the project's overall risk to an acceptable level.

The key issue with open source is that when it is used, the risk is assumed by the organization. Open source code licenses such as BSD's very brief license includes language expressly transferring the responsibility from the code's originators to the code's users. It does this through its statement that "this software is provided 'as is' and without any express or implied warranties." For Linux, the GPL 3.0 preamble states, "for the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software" (Free Software Foundation, 2007).

This undermines several key aspects of the mitigations listed previously. If the organization assumes technical responsibility for the code, they have a reduced capacity to avoid, share, reduce or transfer the risk. Open source code can still be a part of the solution for a risk management strategy and in some cases, open source code is a huge factor in mitigating risk.

Software from major vendors includes the added risk of the strategy tax for that vendor. The strategy tax associated with Microsoft Windows reached a critical point with Valve, the creator of Steam, a popular game distribution platform. Valve chose to mitigate the increased risk and developed SteamOS, which ported their distribution software to run on open sourced code (Dingman, 2013). The code they chose for their foundation has a much lower strategy tax, significantly reducing their risk.

While Valve's talent pool of programmers meant they had the technical knowledge to audit and understand the relevant source code, not every business is as well resourced. Businesses that do have a sizable number of programmers tend to incorporate open source applications into their project planning. In 2010, Google switched a large number of their machines from Windows to Linux. Netflix runs FreeBSD to take advantage of the technology built into ZFS.

Brand value plays a large role in a business asset portfolio and projects that could damage that brand can be viewed as putting the company at higher risk. One of the more sensitive brand sectors is that of IT Security firms who work projects for each one of their clients. From my private conversations with employees from this sector, I've learned that one way they transfer their risk is through policies on company communications channels. Precisely none of their communications channels are internal. Instead, each employee is required to use multiple external communications technologies. The organization's reality is that if their brand becomes victim to a successful attack and any part of the news cycle includes the organization's name, this causes severe damage to the brand, so for email they use Gmail and for chat they use Slack (Pen Testing, 2016). They rely on a myriad of other applications and services to reduce their attack surface and transfer risk to as many organizations as possible.

The true cost of risk to a project doesn't end at project completion but rather with customer satisfaction throughout the product's lifecycle. To precisely illustrate brand risk from open source projects the recent past contains a poignant example. When Trend Micro's team conducted a project to build their organization's website they chose the popular open source WordPress suite. Recently, WordPress had a vulnerability that was exploited by hackers and received mostly positive attention for its measured response to patch this vulnerability. In contrast, Trend Micro's site received similarly bad press (McCaskill, 2017 and JupiterBroadcasting, 2017) from the decisions of earlier project managers.

With this type of negative press surrounding open source, it's no wonder why many PMs overlook the advantages open source may have in actually reducing the complexity index for a project. KDE's website recently published an interview with a Thomas Weissel, a developer working for the Austrian school system who concluded a project to incorporate KDE into the Austrian school where he worked. In the interview, he describes one critical advantage for open source, the accessibility of the team to resolve issues. In his words:

"That's yet another reason why I picked Plasmashell: The KIOSK system. I reported a lot of issues with the KIOSK system and Plasma developers did an amazing job finding and fixing all the bugs I've found for 5.8. We now have a desktop that is completely locked to make sure nobody accidentally removes or reconfigures important parts of the user interface," said Weissel (Riddell, 2017).

Chris Fisher, a long-time open source commenter, rhetorically asked PMs how long they believed it would take a closed source vendor to respond to identified bugs during a project's execution. This is a terrific example of architecture cost being shifted from the organization to the developers. For enterprise-scale projects, large, closed sourced vendors may be willing to work with their clients. For smaller-scale projects, the responsiveness of a project team may be their only way to tool the software to their specific needs.

Open source solutions have been adopted by various sectors of the market to fit key roles in our technology infrastructure. The risk complexity index developed by Tom Kendrick helps us to understand the difficulties with the adoption of open source solutions across all dimensions of the market.

In general, open source solutions shift the risk from a software vendor to the organization. In today's environment where branding is both costly and crucial, open source solutions represent a direct risk to the brands who use them. Despite this risk, many large- and small-scale projects are still choosing open source solutions for projects where the complexity index is reduced by their implementation. The example of the KDE development team working with a small project manager in Austria to develop the best code possible is a clear example of a significant advantage within the field of open source. While the authors of the code may not be legally liable, their pride in their product generally serves as a terrific motivator for them to deliver their best.

References

Kendrick, T. (2015). Identifying and managing project risk: essential tools for failure-proofing your project. New York: American Management Association.

Pen Testing [Personal interview]. (2016, December).

Project Management Institute (PMI, 2013). A guide to the project management body of knowledge/PMBOK Guide (5th ed.). Newton Square, Pennsylvania: Project Management Institute, Inc.