Contributing to Open Source Projects
The Yahoo Open Source Program Office (OSPO) provides services to help engineers at Yahoo prepare code for external publication, promote projects, and build open source communities. If you are interested in open source collaboration, we are here to help. To get an overview of our program, vist the OSPO Welcome Page intranet page, chat with us on our internal Slack channel (#opensource), or send an email to ospo@.
This page highlights the steps you’ll take when it comes to contributing company code as an existing open source project managed by someone else.
Step Zero: Planning for Success
We encourage Yahoo engineers to contribute to projects we rely upon. We seek to be good open source citizens. If you find a bug, or can make some code better, we want to enable you do it. However, we want you to be aware of some concerns that you should keep in mind. Most of the time, these will not come up. Given the number of projects we work on, the number of engineers we have, and the complexity of some projects, we occasionally run into blocking issues.
Please read the guidelines below. If none of these issues are relevant to your pull request, then go ahead and contribute to an open source project. You do not need to get approval for every pull request. The overhead involved in these approvals is not worth it. That said, if the issues below are relevant, or if you have any concerns about your contribution, ask us. We’re here to help you.
Step 1: The Contributing File
Some open source projects have a Contributing.md file that specifies how the project wants to see contributions. Read it. The better you conform to the project’s requests, the more likely they’ll accept your contribution.
Step 2: The Contributors License Agreement (CLAs)
Some projects require you to sign a Contributors License Agreement (CLA) before the contribution will be accepted. When this happens, you will need to get approval from the OSPO.
Most CLAs contain terms that we are okay signing. So don’t be worried about asking. Once in a while we see something in a CLA that we don’t wish to agree with. In those cases we’ll tell you not to sign the CLA; and thus preventing you from completing the pull request. This is rare, but it does happen. It’s better that we block your contribution than you sign something we didn’t authorize you to sign. We’ll then work with you to help identify other ways of accomplishing your open source goals.
Step 3: Special Projects
We perform some extra record keeping steps with some projects that require us to manage updated Corporate CLA lists. Check out the list of projects that require extra record keeping and follow the additional steps so that we maintain records of who we included in our Corporate CLAs with these entities.
Step 4: Review your Contributions
Although this should be obvious, let’s take this moment to remind you:
- We can only contribute code that we have the right to contribute. If you have any reason to think you are contributing code that we shouldn’t contribute, open a Jira ticket with the OSPO and let’s clarify things first.
- Don’t contribute code that exposes sensitive or proprietary information. This includes code (or documentation) with links to servers that external developers can’t get to.
- Don’t contribute sub-par code. Your contributions are a reflection of your engineering skills. We’d rather take the time and get another set of eyes and do a proper code review. It’s our reputation too.
Once in a while we’re reminded that it’s better if you think things through first. Most of the time, a code contribution to an open source project is a normal and inconsequential task. But sometimes its more than that. If you are working on something that is quite consequential, and you have any reason to wonder if you should make this contribution, open a Jira ticket and ask us for help.
Step 5: Review the Project
If the project you seek to contribute to has many unanswered issue and many untouched pull requests, you probably have a dead project. Contributing to it will do you little good. Moreover, if you are contributing to it, presumably we’re using this code; yet it’s not supported by an active community. Maybe we’re better off finding an alternative, or in some cases we might have to ressurect the project and support it ourselves. Feel free to open a Jira ticket with the OSPO and we can help you work through this.
In Summary
We encourage you to contribute to open source projects. You don’t need our review and approval for every contribution you make, we’re not here to slow you down. Rather, we want to highlight potential issues and address them for you.
- Assuming your code is awesome, the project you are contributing to is active, and you don’t anticipate any concerns with the contribution, then contribute to the project.
- If you have any questions, see anything strange about the project, are asked to sign something, aren’t sure if you need to add a copyright statement to some file header, or anything that gives you pause, then open a ticket and let us help you.
Additional Considerations
- When we have multiple groups at the company who contribute to the same project, we encourage you to reach out to your colleagues and coordinate your efforts internally.
- If you encounter any conduct issues with the project you are working on (e.g. if anyone in the community engages in misbehavior toward you or anyone else), alert the OSPO immediately. Please don’t engage in an online spat as these can escalate in non-productive ways. Call us in and we’ll find ways to work things out.
- The above guidelines cover your contribution of “company code” to open source projects. Sometimes you might be unclear if the code you are working on is “company code” or perhaps your personally owned code. Please contact the OSPO and we’ll help clarify this with you.