WSO2 products are 100% open source and released under the Apache License Version 2.0. WSO2 welcomes anyone who is interested in WSO2 products to become a contributor by getting involved in the WSO2 community and helping with the development of WSO2 projects.
How can I get involved in the community?
You can get involved in the WSO2 community in various ways:
- Use WSO2 products
The latest binary packs that correspond to the WSO2 product releases can be downloaded freely via the respective product pages on the WSO2 website. We recommend that you download and use WSO2 products so that you can discover the advantages of our lean middleware stack. Your feedback on our products is much appreciated, as it will help us to drive our product roadmaps and the underlying technology. For information on product releases, go to the Release Matrix. For tutorials, articles, white papers, webinars, WSO2 documentation, and other learning resources, look in the Resources menu on the WSO2 website.
- Join WSO2 mailing lists
Many WSO2 mailing lists are open to the public, so anyone interested in WSO2 products can monitor the mail threads. You can subscribe to the firstname.lastname@example.org and email@example.com mailing lists to get involved in the discussions on WSO2 development. For more information on subscribing to these mailing lists, see WSO2 Mailing Lists.
- Participate in user forums
The WSO2 team monitors and participates in the discussions on Stack Overflow. If you have any technical or programming questions related to WSO2 products, post them on Stack Overflow. Be sure to tag your question with appropriate keywords such as WSO2 and the product name so that our team can easily find your questions and provide answers. If you cannot find an answer on the user forum, you can email the WSO2 development team directly using the relevant mailing lists described at WSO2 Mailing Lists. We also encourage you to contribute by answering your fellow users' questions on Stack Overflow.
- Report bugs
WSO2 has a public bug-tracking system that you can use to report issues, submit enhancement requests, and track and comment on issues. You can also use this system to report issues related to WSO2 product documentation. If you find a bug, first search the dev mailing list to see if someone has faced the same issue, and also check the bug-tracking system. If you can't find any information on the issue, create an issue in the bug-tracking system with as much information as possible, including the product version you were using, how to reproduce the issue, etc.
- Contribute to the WSO2 code base
WSO2 invites you to contribute by providing patches for bug fixes or features. For this purpose you can check out the source of the relevant GitHub repository, build the product, and make changes. You can then contribute your changes by sending a pull a request for review. For more information, see the next section.
Contributing as a non-committer – anyone can do it!
Anyone (not just committers) can share contributions to WSO2's open-source software products. Your work will be recognized: if your contribution – feature enhancement, bug fix, or other improvements – is accepted, your name will be included as an author in the official commit logs. Read on for details on how you can contribute.
Overview of the WSO2 repository
Contributing to the WSO2 code base
Follow these instructions to contribute to the WSO2 code base. Be sure to follow the WSO2 GitHub Guidelines.
- Fork the respective code base to your Git account.
- Clone the code base to your local machine.
git clone <GitHub-REPOSITORY-URL>
If you are not sure which repository needs to be cloned, send an email to firstname.lastname@example.org.
Build the product using Maven.
- Install Maven and JDK. See the Installation Prerequisites page for compatible versions.
- Set the environment variable
MAVEN_OPTS="-Xms768m -Xmx3072m -XX:MaxPermSize=1200m"to avoid the maven
- Make sure the build server has an active Internet connection to download dependencies while building.
Use the following commands to create complete release artifacts of a WSO2 product, including the binary and source distributions.
mvn clean install
The binary and source distributions.
mvn clean install -Dmaven.test.skip=true
The binary and source distributions, without running any of the unit tests.
mvn clean install -Dmaven.test.skip=true -o
The binary and source distributions, without running any of the unit tests, in offline mode. This can be done only if you've already built the source at least once.
If you need to add a new file to the repository:
- Add the new file.
git add <FILE-NAME>
git add mycode.java
- Commit the newly added file to your local repository.
git commit -m "<COMMIT-MESSAGE>"For example:
git commit -m "Adding a new file"
If you need to update an existing file in the repository:
- Open the file that you want to update and make the necessary changes.
- Commit the changes to your local repository.
git commit -m "<COMMIT-MESSAGE>" -aFor example:
git commit -m "Updated the clauses in the terms and conditions file" -a
Sync your changes with the upstream repository.
- Push the changes to your own Git repository.
- Send a Git pull request to the WSO2 Git repository and add the URL of the Git pull request in the JIRA that corresponds to the patch. Your pull request will be authorized only after it is reviewed by the team lead or release manager or responsible person for the corresponding Git repository.
WSO2 GitHub Guidelines
- The respective WSO2 Git repository should be forked
When contributing to WSO2 code base by way of a patch, make sure you identify the correct Git repository that needs to be forked. If you are not sure which repository needs to be cloned, send an email to email@example.com so that a WSO2 team member can advise you.
- Do not build any dependencies
You do not need to build any dependencies, as everything you need will be automatically fetched from the Maven repository (Nexus) when you are building the product on your machine. Make sure the build server has an active Internet connection to download dependencies while building.
- Always sync with the forked repository before issuing a pull request
There is a high possibility that the forked repository may differ from the upstream repository (remote repository that was forked) that you initially forked. Therefore, always sync the repository to prevent pull requests from being rejected.