Ansys works with OSS in much the same way that other organizations do, through GitHub and our developer portal/forum. However, there are a couple of key exceptions that you should be aware of before you get started:
-
Ansys does not allow anonymous or unverified contributors to commit to our open-source repositories. Because of this, we require everyone who wants to contribute to agree to our Terms and Conditions and Contribution License Agreement prior to being allowed access to our repositories. You will also have to register for an Ansys SSO account using your business or academic email address.
-
Ansys is not providing our core solver and commercial software as Open Source at this time. We reserve the right to change this, but this means that currently our OSS software is limited to our PyAnsys family of Python client libraries.
If these terms are acceptable, then it is very easy to begin by accepting the CLA and signing up for your SSO account (which will also give you full access to the forums, documentation, and other parts of the Ansys ecosystem).
If you’ve never contributed to an open-source project before, here is the basic process we follow @ Ansys:
Figure out what you’re going to work on.
Most open-source contributions come from people working on their own interests. However, if you don’t know what you want to work on, or are just looking to get familiar with what OSS @ Ansys has to work on, here are some tips:
-
Look in the repositories on GitHub for issues and see if there are any that you would be interested in working on.
-
Join us in the forums and let us know you’re interested in getting to know our PyAnsys libraries. We’re very happy to help researchers and partners get up to speed with the codebase.
What is the scope of the change? We can help if you are thinking of something big!
-
Most pull requests are small with minor changes to the overall code base. In these cases, there is not much extra for you to do, just code it and get your PR submitted.
-
Sometimes changes can be large or involve many features that cut across the whole of the project. In these cases, we recommend you post your idea in the forums, and ask for feedback on the proposed change BEFORE posting a PR.
Open a pull request.
-
If you are not ready for the pull request to be reviewed, create a draft pull request first. You can convert it to a full PR by pressing the “Ready for review” button in GitHub when you are ready.
-
Start your PR as a draft PR, and use the prefix of “[WIP]” to indicate you are still working on the PR. We will skip these when we review PRs allowing you to get everything ready before it goes to review.
-
Absolutely reach out on the forums for review guidance and help! We are always happy to support anyone wanting to contribute and the project maintainers are always willing to look at proposed PRs
Work through any issues on the PR until it is accepted.
-
We will generally only block a PR for major issues so your review should be relatively quick and painless.
-
Once the PR has been accepted and the CI confirms as passed, that’s it for you, we will do the rest.