Maybe You Don’t Need an Open Source Policy

“Maybe you don’t need an open source policy.” That’s not what you expect to hear from someone who has created multiple OSPOs at large companies. When first creating an open source program office, guidance from experts (including some I’ve helped write) suggests the need for a policy early in the process. To be honest, making policy documents a priority has always challenged me. It's seen as an effective way to gather concerns and get on “the same page” and it sends a message that you are an authority. But it’s often done before the organization has a consensus on its policy goals or a careful understanding of its real needs. I’m going to challenge conventional thought.

Ten years ago Gunnar Hellekson published this excellent post on the opensource.com blog: “Open source software policy is better without open source” https://opensource.com/government/12/11/open-source-software-policy-without-open-source . Hellekson suggested removing the term “open source” from each sentence of your Open Source Policy document to see if it makes more sense. In most cases, it will. Your policy probably states that you need to ensure that you comply with licenses. That’s true with proprietary software too. Your policy states that you need to address security concerns. That’s true with proprietary software too.?You probably need a software policy. Open source is a subtype of software. Your software policy covers all sorts of concerns already. Just add anything that is uniquely open source to that existing policy.

Let’s talk about why this makes sense. In many policy conversations, I’ve often been struck with how odd it seems when a policy person tells me we need a policy about open source software. I usually ask “can you give me an example of what you mean when you say open source software? In banking-related conversations, the answer often conflates many issues and misses others.I suspect this is a byproduct of the regulatory guidance that covers open source software written in 2004 by the FDIC and FFIEC. Their most recent guidelines still carry an odd understanding of open source. To be fair, what they say is not completely wrong, it's just oddly selective. For example, the regulatory guidance for open source risk mitigation includes blocking access to unapproved shareware sites. (That implies that you might have approved shareware sites and that you get open source code from shareware sites.) So their answers tend to focus on products based on open source, or installed desktop applications, but not source code. 2004 was a long time ago and a lot has evolved since. Also, shareware is not open source. Sigh.

So what does it mean to say open source software? It means too many things. There are open source software projects that run the world’s most popular operating systems, cars, and medical devices. And there are open source libraries that remove spaces from text strings or generate a random sequence of numbers. They share a common licensing modality, but you manage those things very differently.?

To illustrate this point:

1. If you develop applications, you’ll be using open source libraries, frameworks, and components in those applications. Which should you use? You’ll probably want a policy indicating how one selects and validates the right libraries since those pieces of open source will go into your applications.
2. Since you employ developers to develop applications, they’ll need developer tools. Many of those are open source. Which should they install? You’ll probably want a policy indicating what you do or do not allow to be installed on a work-owned laptop.
3. Your applications might need various services such as databases and data transmission technologies that support your applications. These might not be compiled into your app, but your app depends on them. You’ll probably want to clarify when you can use a self-supported open source project and when you prefer a vendor-supported option.?
4. Your applications might be deployed in an operational environment that leverages open source container technology. Again, you’ll want to address questions about selecting and operating the environment. In some cases, you’ll have to address your stance about supporting multiple cloud vendors, perhaps by leveraging open source options instead of vendor-supplied products that may cause lock-in.

Notice that the above list contains open source libraries that go into applications, open source tools used to create applications, open source products used in support of running applications, and applications that go into open source operational environments. The breadth of concerns is rather wide. Moreover, you are addressing different groups very differently. How do you organize your policy documents?

Consider the process you might have in place to address code libraries. Your policy writer will need to know about the software development process. You’ll be dealing with binary artifacts, build files, and potentially the process to contribute fixes to an active community working on a project. In contrast, the concerns are more typically addressed by the good people who manage your workplace IT environment. Installing applications onto your workstation might require admin rights. But it does not require being a developer. The libraries you select will go into applications that are used in production (perhaps by your end customers), but the tools and applications you install onto a workstation don't. These are handled by different people in different departments addressing different concerns.?

Your applications may need to persist data using one of the many data persistence technologies out there. You might need to move data around too. Be it Apache Cassandra or Apache Hive, Apache Kafka or Apache Pulsar, etc. you’ll find mature open source projects that are also offered in productized form by vendors. You might stick with the open source project, or perhaps elect the vendor’s product (which now removes you from the scope of an open source policy since you are basically purchasing a commercial off-the-shelf (COTS) product that happens to be based on an open source project). It’s less likely that your developers will be making engineering changes to the base open source project. So the majority of your potential policy concerns will be more focused on operational issues. Similarly, with your container specification, orchestration, and management processes, you’ll have many engineers involved, but perhaps not the same as the application developers. Are Dev and Ops organized into one group or two? That depends on your organization. But I think it’s fair to say that the kinds of people who deal with these technologies, and the policy concerns that you would address about them, are going to be very different from the ones you’d address with the other categories.

A single open source policy is going to be stretched rather widely if it attempts to address open source that goes into applications, open source used to build applications, and applications that go into, or leverage open source operational infrastructure. We haven’t even addressed questions about open source in code your vendors provide you, or open source due diligence when acquiring technology companies. Would combining those into one policy be effective??

• A single “open source policy” on its own is probably going to be incoherent unless it’s an addendum to a larger software policy.
• A single “software policy" on its own is going to be too complicated since there are many different types of software and related policy concerns.

I’m inclined toward a method where one policy describes installing desktop tools, another policy describes the process of building software applications for internal use, and another describes the process of developing products (that get made available to customers (e.g. via web, SaaS, SDK, mobile app, binary download, etc.). You’d have a separate policy related to vendor software acquisition, which will include details related to open source based products or open source project alternatives, etc. Instead of an open source policy, make sure that each of your technology policies properly addresses the reality that much of your software is open source.

This leaves some aspects of work unaddressed. Open source provides certain unique issues that you simply do not face with proprietary software. For example, you may need a policy describing how you publish new open source projects (if you do), and certainly one about how engineers make fixes to existing projects they are using for work. That is to say: there may be a place for an open source policy. But it would be rather small and probably written after making sure that your other policies already address open source concerns.

When a policy person tells you that you need an open source policy, Ask “what do you have in mind when you say open source? – can you give me an example?”

That’s a very direct way to understand what might be going on. If you need an open source policy in order to check the box that says “do you have an open source policy?” then you have bigger issues related to your policy initiative, that are unrelated to open source itself.?