How to help large organizations to contribute open source project ?

Context

During the 2010 thinktank in Napa, one of the participant asked the audience the following question "How could we help organizations to contribute to Open Source software".

The problem is the following : most of the large organizations rely on open source software one way or another. There is not necessarily an official policy about FLOSS usage but system engineers and IT administrators & developers tends to use and deploy Open Source software.

In this context, and because, more-often than not, this software is critical to one or several business unit, in theory, it should be easy to contribute.

Hypothesis : IP protection and no open source policy

The problem is more acute for large organization because there is, more often than not, a legal department and some policies are in place to guide workers. Those policies are in place to protect industrial secret and more generally IP of those organizations.

In those organization, more often than not, there is no open source policy : open source leaders do not necessarily have corporate support and, as a consequence, those projects tends to be hidden/not widely publicized.

How to improve the situation : patchs & minor contributions ?

A public Open Source policy (like the one from the government of California) should be published : the goal is not really to have non-open source users contribute but simply to help open source projects to become more publicized inside the organization. It is a clear sign that Open Source is welcome in town !

Lawyers should become involved at this point in order to define a "contribution policy" for the organization. The main question to answer is : Is the corporation OK to contribute with his own name and (c) on the code or not (for marketing, business or fear of liabilities reasons).

If the organization is OK to be involved and become a more or less official contributor of the projects then, proceed to next step.

If the organization is not OK to be involved, the idea is to use a partner : more often than not an Open Source integrator that will be able to somehow "white label" the contributions and, as a consequence, cut any potential liability between the organization and the contributions (as a matter of fact, we already did this for several customers : they did not want their name to appear in the patch for various reasons).

Once this legal issue is defined, then the CIO should then publish a "contribution guideline" that officially allows and encourage bugfix, patches, documentation update and contribution to be made by internal IT either directly or indirectly (via a partner). The goal of this guideline is not, once again, to _force_ contribution : it simply show the path and will make contributing easy and possible for everyone in the organization.

As contribution become more common, good practice should be encouraged : an internal blog or intranet can be set-up to list every contribution in order to reinforce the positive attitude and to create rock stars among their peers : top contributors could be awarded some really cool things like ... attending the developer meeting of their proffered technology, attend training session or technical training, etc.

Contributing to a community is a good thing and you could then suggest the marketing & communication department to publicize your contributions to the open source community. HT department will be interested as well by this as you will be able to attract highly skilled and motivated IT professionals.


How to improve the situation : major improvements, plugins, new projects ?

In this case, the situation is a bit more complex. We did several consulting sessions for customers that really wanted to open source either a complete project or certain area of the code. Most of those projects were initiated by the IT department and let's say that the relation with the legal department was very very conflictual.

One of the root cause of this conflict is the fact that the legal department was not part of the initial project team, they were seen as a necessary evil and ... they behave as such ;-)

Lesson learned : please, involve your legal department as soon as possible. Propose them to work with a lawyer firm specialized in open source IP and licensing. Have them have lawyers luncheons and let them decide of the funny things like license and IP management for the project. 


Initially, I would recommend to start with small scale project. Ideally, select an existing add-on, plugins, piece of code. Once you can have a small success and contribute one component, you can expect the process to become more and more routine like.

After some successful projects, we could even envision an official "open-source policy" for any project that is not part of the core business/specificity of your organization but I don't think that this should be a goal : this is a consequence of the normalization or major contribution. The same concepts apply : you should celebrate success, list contribution and eventually publicize them !

Before any open-source release, you should have a process in place. The process could be very simple (in our company, this is a very simple form that ask for the Open Sourcing of a project) in order to make sure that : you own the code that you want to open source (it seems evident but ... is it ? Do you have cut&paste some code snippet, have some of your code been developed by sub-contractors, etc.) and then you can make sure that the code is not something you want to offer to your competitors. Finally, you can select the appropriate license based on your own legal department advice but also based on the type of license in use by this specific open source community.


Conclusion


I think that those small steps could really help large organizations to contribute more to the open source software they are using. Those ideas are grounded, easy to implement and easy to put in application. 

• The "contribution barrier" will be lowered inside the organization
• It will reveal a clear path for open source contributors
• It will reveal a clear path for starting open source projects
• Legal department will feel respected and part of the solution
• Internal publicity (blog/intranet) will reinforce the process inside the organization