Overcoming IT Obstacles to open source participation

This page is dedicated to discussing various obstacles to contributing to Linux (and other upstream projects), and otherwise engaging in the open source community, that are inhibited or blocked by a company's IT infrastructure.

= Problem Statement = Often, the corporate IT environment provided to employees presents significant challenges to developers in participating in open source.

A few of the problems encountered with "Strong IT" at large companies are:
 * Corporate network firewall rules are configured to disallow access to open source sites
 * specifically, the git protocol may not be allowed through the firewall
 * also, other protocols may not be allowed, such as ftp, ssh, or others that may be needed to retrieve files for builds
 * The firewall may not allow access to package feeds for Linux desktops
 * for example, a developer may need a Linux IDE for their work, but be unable to add the Ubuntu repository that provides the packages for that tool.
 * This is a problem related to lack of support for Linux desktop usage within a larger corporate environment
 * Corporate e-mail may use Outlook and/or Exchange
 * Outlook and Exchange by default mangle patches and malform e-mails in ways that are unnacceptable for some open source communities
 * For example, patches must be sent without reflowing the text (which most modern e-mail clients do by default)
 * Also, many modern e-mail clients send mail as HTML instead of plain text, and are configured by default to top-post (or don't handle inline comments well, because of text reflowing)
 * Also, attachments are sometimes sent in base64, which may be confusing for text-based email clients

= Possible Solutions = The solutions that some developers resort to is sometimes referred to as "Shadow IT". That is, open source developers work outside the normal confines of their IT departments, because they fail to get the support needed, and just need to get their job done. At one company I worked for, I had two separate network lines (one inside the company and one outside) run to my office desk. When I had to do open source work, I manually switched my ethernet cable to the outside line. When I had to do internal work, I switched the cable to the internal line. This arrangement worked, but was sub-optimal in a few ways.

Here are a few ideas for overcoming IT obstacles:

method of contributing patches independent of e-mail client
One idea is to have patch submissions be independent of a person's e-mail client. Historically, patches have been submitted via e-mail, and there exists a lot of community infrastructure to support e-mail interactions for patch submission and patch review.

Solutions to his problem have historically been to tell developers to adjust their e-mail systems to accomodate the requirements of the community practices and infrastructure. But this is not practical for some developers.

However, just because the patches have to be received as e-mails, doesn't mean they have to be sent from the submitter's preferred e-mail client.

See Create non-email method of contributing kernel patches

open source contributor sysadmin guide
Mark Brown wrote: One other idea in this area that's been suggested before but I don't know went anywhere is to produce some sysadmin targetted documentation from the perspective of sysadmins - things like "here are the specific Exchange settings" and "this is technically what people need and why". At the minute a lot of this stuff seems to get pushed by users who often don't really understand the system admin point of view and can come over as annoying people just complaining about firewalls. Would also be a nice way for bigger corporates to contribute back (and potentially a nice thing for their sysadmins for career development and so on).

source mirror aggregators
Some projects (such as the Yocto Project), work around the problem of accessing source code sites from inside corporate networks by providing a repository of the software that is referenced by their build system that is accessible via a firewall-friendly protocol such as http. This approach works for the case of retrieving source code for Yocto Project builds, where the source for at least the packages is the reference distributions is known. This falls apart a bit when a YP user adds arbitrary packages (via e.g. OE layers) to their embedded distribution.

In general, it is not possible to determine ahead of time the sites that one will need to access in order to download the source code for open source software packages.