Contributing to Open Source Projects

This page highlights the steps you’ll take when it comes to contributing company code to an existing open source project managed by someone else.

Step Zero: Planning for Success

We encourage Power developers 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 developers 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: Contribution rules

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 SDRT.

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 prevent you from completing the pull request. This is rare, but it may 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.

If a corporate CLA is required in place of or in addition to an individual CLA, a member of the SDRT must sign this; employees other than members of the SDRT are not authorized to sign CLAs in Power’s name.

Step 3: 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 ticket with the SDRT 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 development 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 it’s 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 ticket and ask us for help.

Step 4: Review the Project

If the project you seek to contribute to has many unanswered issues 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 ticket with the SDRT 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 SDRT 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 SDRT and we’ll help clarify this with you.