Modifying 'cf1ec12'

Comment

Alert wiki admin that help items are not loaded

# Contributing back code at your workplace #

# introduction #

The Software Freedom Day 2011 workshop on contributing to free software in your workplace came up with a number of ideas. The goal is to produce an agreement between employers and their employees or contractors to facilitate upstream contribution to free software projects.

Free software licences such as the GPL require that licence freedoms be passed on to the users of redistributed and modified versions. However, there is no obligation to provide modifications back to the authors of the software.

Sometimes modifications are general enough that they would benefit the wider community of users. Companies may be willing to consider providing upstream contributions, but need to be aware of the benefits in order to justify the extra resource cost.

# benefits #

The many ways of contributing to free software projects has been widely covered, ranging from code changes, to documentation, bug reports and so on. But there are also a number of desirable benefits in a commercial environment.

The use of a free software project base implies that the company recognizes the value of that project. The many contributions to the project are fundamental to its quality and even existence. By adding to those contributions, a company can help ensure the long-term success of the software project they are using.

Interaction with the upstream contributors allows a company to collaborate and network with other experts. This assists in developing in-house expertise in the software beyond just the modifications being made. It is a source of feedback on the competence of the software engineers involved. And it can help to identify future potential employees and contractors.

Involvement in the wider project is promotion for the company. It displays their expertise, and gains brand recognition.

Collaborating with the leads of the upstream project gives visibility and credibility to the company. It gives the company a voice to influence the future direction of the code base.

Distribution of modifications to existing experts provides an independent code review. For systems with safety implications, it allows major flaws to be recognized before the auditing stage, and increases accountability.

A wider distribution of changes broadens the range of test contexts and can provide a resource for user acceptance testing.

When modifications are incorporated into a base project, software maintenance costs are reduced. Revisions of the base project will be automatically tested against the modifications, dramatically reducing the work required to release new versions of the system. It also simplifies customer updates, since more changes will already be included in the base system installation.

Having a closer connection to the upstream project can provide a reassurance to customers of the company, since it mitigates the risk of loss of supply of the software, for example, when a system is no longer being produced by the company.

Upstream contributions can be seen as in-kind corporate donations, as part of a companies social responsibility to the wider community. This can also increase employee satisfaction, as they recognize the broader significance of their work beyond a single project.

# other considerations #

When making the case for upstream contributions, there are a number of considerations.

Positive vocabulary frames the argument. It can be helpful to test the water first, for example, a non-core project or just making single contributions upstream, so that people can become comfortable with the idea before integrating it in to the development. Upstream contributions by companies are not rare either; for example, corporations such as Oracle, Intel, IBM, Google and Microsoft make significant contributions to the GNU/Linux kernel and drivers; it would be helpful to provide additional local and project-related case studies.

When contributing upstream, relevant factors include: the particular licence that covers the software; the conditions upon contributions (for example, is there usually assignment of copyright, and if so, whether a grant-back licence is needed); the interested parties (managers, employees, contractors, company owners, upstream community, customers, other users); and whether the software is used in-house, is distributed on to customers, or provided as a service to customers.

[todo - are there examples or templates of legal clauses on contracts or employee agreements that clarify the freedom to contribute modifications upstream?]

## other commentary that touches on this subject ##

Julie Bort interview with Jim Zemlin of the Linux Foundation in [NetworkWorld](NetworkWorld)
[http://www.networkworld.com/news/2011/083011-zemlin-250234.html](http://www.networkworld.com/news/2011/083011-zemlin-250234.html)

Dries Buytaert blog entry on contributing back to Drupal
[http://buytaert.net/contributing-back-to-drupal](http://buytaert.net/contributing-back-to-drupal)

James Dixon's paper on commercial software models
[http://jamesdixon.wordpress.com/the-bees-and-the-trees/](http://jamesdixon.wordpress.com/the-bees-and-the-trees/)

[...]{: page-href="wiki:///contributingAtWork"}

Upload file:

General meta

Summary
Tags

Tags may have embedded blanks, use commas to separate.