I highly recommend that you make sure that your leadership understands and agrees with these concepts, because they drive the strategies and tactics that help OSPOs create business value. Let's take a minute and break them out.

First: Your company's IP may be more valuable outside your company

This is the key assumption, and it might be controversial.

Many companies take the approach that they are better off capturing all the possible intellectual property (IP) output from every employee and keeping it within the company. This "capture it all!" philosophy comes from an effort to eliminate downside risk. If you don't know what might be valuable in the future, then you try to hold on to everything to avoid letting out the goose that lays the golden eggs.

In contrast, the value in open source communities lies outside your company. Your open source program will usually be focused on maximizing the value of each employee's contributions, even if the IP is technically in outside hands.

More broadly, we assume that only some parts of a company's IP matter to the company. There are more ways to get value from IP than just licensing it for money. In some circumstances, it can be more profitable to use IP to develop the company culture, to enhance the capabilities of employees, or to build the company's reputation and mindshare.

Be aware that making the distinction between what IP is "core" to a company and what can be better used in the context of a community requires that your leaders have good knowledge and confidence about what the company does to provide value.

Contributing to existing projects

Let's be more concrete: Let's look at the case of a patch to an existing OSS project. The chance that your company will have unique, valuable IP in a patch provided to an existing open source project is very low. The project is already in the sphere of public knowledge. If the patch is not shared, it probably stays within the mind of the one employee who developed it. Sometimes keeping patches internal can even become a financial burden as your company tries to maintain its own parallel copy of the community-developed software.

In contrast, letting out the IP associated with the patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.

Identifying "differentiating" versus "supporting" IP

The trickier issue has to do with the release of company-developed IP to the outside world. Not everything should be released, but that many things can be.

Realistically, only a fraction of a company's efforts actually provide differentiating value to customers. Regardless of what you do, or what business you are in, or what your product is, you spend a lot of time, effort, and money on stuff that either serves your internal needs or is simply "table stakes" for customers.

At a high level, this should not be a surprise. From an accounting perspective, companies already break out "G & A," or "General and Administrative Expense." This is finance-speak for overhead - things that companies do that don't directly build products or create revenue.

But let's look within a revenue-producing, you-sell-it-for-money product. A "product" is usually not a singular entity. Instead, it is a bundle of lots of little services, or code, or components. While each of these little pieces may be necessary to the final product, most of them are not differentiating to the customer. They don't provide a reason to buy.

A few simple examples: Screws and nails are essential parts of a house, but only rarely do buyers care about which screws and nails are actually used. A smartphone dialer (the number pad used to input the phone number) is a necessary part of the smartphone product, but buyers only really care that it is there and that it works.

You can break apart every product into smaller and smaller bits, and you will find that most parts of most products are necessary, but they don't actually drive customers to buy. Any parts of your product that don't drive customers to buy are candidates for sharing.

An ROI-focused open source policy

Having a clear idea of what is "supporting" IP versus "differentiating" IP can even make your company more effective in developing its proprietary products. It is now common wisdom that you can increase your company's value by commoditizing your complements. In economic terms, a " complement " is something that is used with your product. If the price of a complement goes down, then the customer cost of using your product goes down and the value of your product has gone up - but the reduction in cost doesn't reduce your revenues.

Creating and supporting open source projects is powerful way to use this dynamic to your advantage. For example, if your company is focused on data analytics, then commoditizing the projects that "feed" data to your analytics platform makes your platform a better value and can drive increased sales.

An ROI-focused open source policy should reflect these business judgments. Being able to articulate how your open source program fits into the company's overall business strategy will make it easier to get support for your open source activities - and it can help you draw the line between supporting your open source communities and increasing business profits.

Second: Employee acceptance and engagement will determine the success of your policy

Policies are overhead. The most effective policies are the ones that receive the highest voluntary compliance. Sometimes policies can be effectively enforced, sometimes they can't. A strict, "optimal" unenforced and unenforceable policy is far worse than a less-constraining policy that has high voluntary buy-in.

Build assumptions about trust and judgment into your agreements with your employees.

You should also consider how your open source policy reflects the trust you have in your employees. Your employees are already trusted to exercise their discretion on behalf of the company all the time. They already have made a substantial commitment to your company.

So, where possible, build on those assumptions in your policy. It is better to have a flexible policy that implements an expectation of good judgment and honesty than to have a rigid policy that ends up creating compliance headaches because you can't anticipate every situation.

It is true - you do need to build checks into the process. But starting from the assumption that your employees can exercise judgment makes many things easier. And if you can't trust your employees, well, you need much more than a better open source policy.

Work from a place of mutual respect

Finally, your policy may be a legal document, but it doesn't have to be full of legalese. It should be designed to be read and understood by your employees. If they understand your policy and the reasons behind it, then they will be able to follow the intent of your open source policy, leading to more engagement and better outcomes.

You have the responsibility to safeguard your corporate interests, but your open source program is a great place so show how you value and respect the personal initiative of our employees. If you provide clear communication and guidelines about how to engage with open source, you will be able to set expectations so that you are never in an adversarial position with your employees nor with the open source communities with whom you engage.