Contributing to OpenLayers

Contributors

OpenLayers was originally created by MetaCarta, Inc., and is a project of the OSGeo Foundation. As described in the BusinessCase, OpenLayers aims to become "the Apache of web mapping APIs" by providing a powerful, unified, open source framework for building web-based mapping applications using data from any source. OpenLayers intends to enable commerce and encourages people to use OpenLayers for profit and non-profit activities alike. Contributors to OpenLayers help achieve these goals.

For a full list of Contributors to the OpenLayers project, see http://openlayers.org/dev/doc/authors.txt

Contributors License Agreements

OpenLayers is open source and welcomes contributions from the community of people finding value in it. To accept contributions, the OpenLayers project needs contributors to submit a Contributor License Agreement, which is similar in substance to the Apache Foundation's contributor agreement.
This document guarantees that we will be able to transfer copyright in the code to the OSGeo Foundation, when the time comes.
You can indicate your agreement by simply emailing a completed copy of the agreement to openlayers-cla_at_lists_dot_osgeo_dot_org.

• Individuals should submit the  Independent Contributor License Agreement (ICLA)
• Corporations should submit the  Corporate Contributor License Agreement (CCLA)

The OpenLayers copyright is held collectively by all contributors, referred to OpenLayers Contributors. The purpose of the Contributor License Agreements is to clearly define the terms under which intellectual property has been contributed to OpenLayers and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. This allows us to cleanly transfer OpenLayers to OSGEO.

For a list of individuals and companys participating in OpenLayers with signed CLAs, see: CLA

Submitting Code, Documentation, etc.

• Start a ticket: If you have found a bug or a feature that you would like added to OpenLayers, please file a ticket in the  OpenLayers Trac.
  See FilingTickets for more info on how to provide a useful description of your bug or feature.
• Upload your patch: If you have a patch that fixes the bug or implements the feature, you should take the following steps:
  1. Fill out a Contributor License Agreement -- See above.
  2. Attach your patch to the ticket -- See CreatingPatches for info on the prefered way to make a patch.
  3. Mark the ticket for review -- Set the state of the ticket to Review
  4. Email the list -- Send an email to dev_at_openlayers.org with a brief summary of (and a link to) the ticket and any relevant notes about your patch. Please be sure to state clearly that you would like to have the patch reviewed.
  5. Wait for review -- A project committer will review your ticket ASAP!
• All code, examples, etc. from the  SVN repository is made available under by a BSD-like license, with a special provision relating to intellectual property rights. Formal releases published on  http://www.openlayers.org/ are distributed under a normal updated BSD license, with no special constraints.

Acquiring and Using Repository Commit Privileges

• Anyone can request that the SteeringCommittee give them the ability to commit changes directly to  http://svn.openlayers.org/.
  Generally, we prefer to give committer access to developers who have demonstrated expertise and committment to the project.
• Developers with committer access may make changes to their sandbox directory without seeking SteeringCommittee approval, refer to the FAQ How do I create my own sandbox
• Any changes to trunk, aside from improvements to tests and documentation, shall first be submitted for review as a patch attached to a Trac ticket. (see Submitting Code above and TrunkCommits for more detail).
• A patch must only be applied to trunk if the committer feels reasonably confident that the patch:
  1. Follows the project's CodingStandards.
  2. Helps fulfill the ProjectDefinition.
  3. Will not cause a dispute in the community -- if there is reason to believe that the change might be controversial, the ticket and patch should be submitted to the SteeringCommittee for a vote.
• We consider the act of committing code to the repository to be implicit acceptance of the project's published procedures.
• Commit messages should be informative, and should mention any author of the patch if the author is not the committer.
• When committing code changes, include the ticket number that the commit is designed to resolve in the commit message, for future tracking.

Code changes should not be made without a corresponding ticket. Trac will automatically pick up on messages with text in a specific format, to help you manage tickets from commit messages. Including text of the form:

• (Closes #925) -- Closes the ticket (with the revision number and commit message added as a comment).
• (References #925) -- Adds a comment to the ticket with the commit message.

• If the patch is from a new contributor, ensure that the user has sent in a CLA before committing and add the contributor's name to doc/authors.txt when committing.