An open source policy that works in practice

True story. A project team was in need of an open source tool. Following their company's policy, the team requested their Information Systems (IS) department download the tool. They were soon bombarded with a host of questions and a form that needed to be filled out, which they complied with. Not satisfied with the information provided and unable to take a decision, the IS department then forwarded the request to the Legal department.

After due diligence, the Legal department allowed the use of the tool, provided that the team obtain an approval from their customer (read: the customer takes all responsibility and liability). The tool in question? The humble, unix2dos!

unix2dos is a tool to convert line breaks in a text file from Unix format (Line feed) to DOS format (carriage return + Line feed) and vice versa—from Wikipedia

The team decided it was not worth the effort and the customer's time. They quietly went under the radar, downloaded, and used the tool on a personal computer instead.

What's the moral of this story?

Engineers need and use open source in their day-to-day work. They are willing to follow the company's policy, but where they do not find the policy sensible beyond a point and hinders their productivity, they will find a workaround. Yes, the organization may not like it and may even deem it as a risk, but the solution is not a stricter policy, it's a policy that works in practice.

How to write an open source policy that works in practice:

• More often than not, the open source policy is written by the Information Systems department and enforced blindly in letter, but not in spirit. A good open source policy is best written and defined by those who are affected in the field—engineers and delivery teams—as primary stakeholders and the Information Systems and Legal departments as secondary stakeholders.
• Accept the reality of open source software and its use, and look at it as an enabler. Many organizations view open source with an overly pessimistic view rather than as a business enabler. Open source is now a reality. Open source components form critical pieces of solution architecture today.
• Recognize different uses for open source programs and tools. Not all uses of open source software are equal.

Three common categories of open source software use:

1. As a tool: Open source software is used as-is in binary form without modification during the development process and as an external component not part of project deliverables. Integrated development environments (IDEs) and editors such as Eclipse, VI; compilers such as gcc; documentation tools such as doxygen; web servers such as tomcat or glassfish; and many, many more fall under this category. An open source compliant license places no restriction on how the tool is used, for business or personal purposes.
2. As part of project deliverables, without modifications: Examples are Javascript libraries, frameworks such as Hibernate, and others. This category of use need to take license restrictions into account. For instance, while GPL licensed software cannot be combined with proprietary software, LGPL is more permissive and allows it to be linked with proprietary code.
3. As part of project deliverables, with modifications: Such use requires deeper understanding of involved licenses and terms for subsequent distribution of modified source code.

A company's open source policy ought to be geared towards the most common uses. In practice, the first and second uses are more common than the third category. The least common uses maybe put through a more rigorous vetting process while creating an automated or fast track clearance for the first two.

While many customers are aware of open source software and encourage its use, they are also wary of intellectual property contamination—which is alright and understandable. There are customers who do not want to be bothered regarding each and every tool used, while others are extremely concerned and put every open source tool or program through an approval process. The policy can be tuned as per each customer’s preference. For example, a set of commonly used tools may be listed and pre-approved in the Statement of Work or other agreement prior to the start of project.

Execution of policy is important too. A well-defined policy is one thing. Having to explain again and again why we need a particular open source software program or tool to multiple teams (who clearly do not understand the difference between eclipse-java bundle and eclipse-jee bundle or why jars are downloaded during a maven build) is a pain. The folks who enforce the policy (typically IS teams) need to be made aware of open source basics. Routine policy workflow can be automated with a growing and self-learning infrastructure such as internal open source repository that automatically downloads, tracks, and distributes software internally.

Empower and educate the people! No amount of policy wording can cover all bases. Hence, it is essential that the technical folks understand what they are doing. Line managers and tech leads need to be empowered to guide, make decisions, and act.