opensource.google.com

Menu

Docs

Transferring Project Management to Open Source Foundations

Introduction

There may come a time in the life of an open source project that the team considers moving it into an open source foundation, such as the Linux Foundation or the Apache Software Foundation. Depending on why the project was originally open sourced, such a move could be an important step in achieving the team’s goals. For example, transferring management might make sense for a project if:

  • You believe the project will gain wider community adoption if it’s no longer solely affiliated with Google or the corporate partner.

  • Several companies are working on very similar projects, and transferring management to an open source foundation would unite people under a common project.

  • There are legal or administrative tasks essential to the health of the project, and it’s not clear which current participant should own these tasks. These types of needs typically only arise after a project has already become reasonably established, with an active contributor community and often one or more dedicated corporate partners.

It may make sense to begin talking about a foundation in the early days of a project, but that is not typical. In many cases, this may actually be detrimental to the velocity of the project.

Frequently Asked Questions

There are common things that worry people about when transferring management of a project to an open source foundation.

  • Our company will lose valuable intellectual property rights to our open source project.

    • Management transfers typically only license our code to foundations, not transfer ownership. So our company will continue to own copyright and patents in all its contributions, and can continue to use the code as it wishes, both externally and internally. Even under different licenses! There is no net legal effect to transferring management of a project, because the project’s copyrights and patents were already licensed under the project license, typically Apache 2. Trademark ownership is the only thing that might change hands, from our company to the open source foundation.
  • Our company will lose control over governance.

    • Our team will work with you and the open source foundation to create a governance model that ensures that both strategic project and corporate goals are met. Developing healthy communities requires yielding control over time as the culture of the project gels around strong leadership. It will be up to you to determine the right balance between control and community growth.
  • External bad actors will flood our project with bad code.

    • Though management of the project will transfer to the open source foundation, the core project team will continue to determine how contributions are accepted, where, and by whom. If your project is administered by your engineers, on GitHub, before the transfer of management, it can be kept the same after the transfer. The key is to nail down management expectations with the open source foundation before transfer.

Management Transfer Process

Our management transfer process is designed to create business and engineering consensus around a detailed project proposal before escalation to senior company leadership.

  1. Project Proposal. You must create a detailed project proposal. The proposal must have sections which address:

    a. Open Source Project’s Strategic Goals. This section should focus on ultimate mission statement (e.g., not how the project would benefit the company, but what the project’s objectives are);

    b. IP Assignment. Please note only Trademark ownership assignment will be considered, as copyright and patent must be addressed explicitly by the open source license, and not assigned; and

    c. Community Management Section. This section must detail current community management efforts, including whether there is a designated community manager, current efforts to foster engagement, and a clear policy on how to handle contributor disputes. There should be a code of conduct with an outlined enforcement section.

    You must get review and written approval of your proposal from emailremoved@, emailremoved@ and your engineering director.

  2. Final Review. The Project proposal will receive final sign-off from your VP and your Product counsel.

  3. Management Transfer. OSPO will notify the foundation that the approval process is complete. OSPO will drive execution of all final agreements with foundation.

Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.