How to internally socialize the risk of using OSS

on Jan 24, 14 • by admin • with No Comments

“How did you comply with the licenses?” Answers range all across the board, but the most common response is “I assumed it was just free to use.”...

Home » Open Source » How to internally socialize the risk of using OSS

During the interview process at OpenLogic, one question all prospects are asked is “Did you use open source software (OSS) at your previous job?” If yes, “How did you comply with the licenses?” Answers range all across the board, but the most common response is “I assumed it was just free to use.” Individuals in charge of managing open source in their company should ask current and prospective employees the same question. More often than not, the answer will be the same: “I assumed it was just free to use.”

If the typical response to an employee’s governance of OSS is “I assumed it was just free to use,” that raises an interesting challenge: how to socialize the risk of using OSS within an organization. It can be achieved by either informal or formal methods.

Informal practices

Personally, I prefer informal means of socializing risk. I find that other developers respond better to an informal conversation rather than laying out strict guidelines. If developers do not respond to informal conversations, however, and they still put the company at risk, you may be forced to lay out strict guidelines.

Try a brown-bag seminar as a platform for informal conversations about risk and OSS. A brown-bag seminar is a meeting or training that takes place during a lunch break. If convincing your coworkers to spend their lunch break in training is not going to work, try having the lunch catered; you might be surprised how many people respond to something as simple as free pizza.

Once you gather employees, address the issues around risk and using open source. If you are tasked with managing open source risk and are not entirely sure how to do so, OpenLogic staff continually offer blogs to help our clients with various open source issues. Here are two blogs to help you with open source risk:

1. Open source software compliance: How well are you rating risk?

2. Open source software compliance: Developing a risk matrix

Formal practices

In instances where companies may not be able to take an informal approach, here are two methods that may work:

1.Conduct Educational Meetings: This may seem very broad, and it is meant to be. You can provide formal education to employees in a variety of ways, depending on what works best for your environment. I have used a variety of means for training from WebEx, or Weekly Stand-Up Meetings, to in-person conferences.

In these educational meetings, I always discuss the following:

I.The approved open source & open source licenses.

II.The prohibited open source & open source licenses.

III.How to support open source.

IV.How to track open source.

V.How to comply with approved open source licenses.

VI.How to train employees on the open source policy: use, support, tracking, and license compliance.

2.Introduce a Compliance Program: Setting up a compliance program is the most formal means of socializing risk within an enterprise. A compliance program comprises a formal policy that governs what developers can and cannot use. If a formal open source policy and compliance program is what you need, refer to an earlier blog of mine on writing an open source policy.

While it may be a challenging task, I have shared a few of the many ways to socialize the risk of using OSS in the enterprise. You may have other means. What methods have you used of socializing risk?

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top