Getting the Source

This article talks about getting the WPILib sources, the general tools necessary for getting and building WPILib, and how to contribute.

Obtain the Code

WPILib is hosted in a series of git repos, available as part of the WPILibSuite organization on Github. You can see all available project repositories at To view a repository in your web browser or to check out the repository, simply click the link for that repository to load the repository page. To check out the repository, click the Clone or download button on the repository page to get the source code.

Build Tools

Generally, WPILib uses Gradle for building and publishing. There is some variation by project, and the major projects have README files and documentation in their root directories explaining how to build them. Build details will be gone over in more detail in the General Build Concepts section.

Since WPILib is hosted in git repositories, so some git tool is needed to clone them to your local machine although you can just obtain the source code directory by downloading the zip file of the repository.

WPILib builds are done, for most projects, by use of a build tool called Gradle. More information can be found about Gradle at their website, Gradle requires Java to be installed, and the JAVA_HOME environment variable to be correctly set. How to run Gradle is covered in General Build Concepts.

How to Contribute

We (the WPILib developers) welcome changes from the community: a number of mentors and students from FRC teams have submitted a large number of changes to WPILib over the past few years. Generally, we want to be able to steer the direction of WPILib and review ideas for changes before we review code for the ideas. If you have an idea for a change, or a bug you'd like to fix, please create an issue in the appropriate WPILib project on GitHub. To submit an issue, you simply need an account on GitHub; you do not need to be a member of the WPILib project to submit an issue. At this point, we'll talk with you directly about further instruction on how to go about implementing and submitting this change. Before submitting a change, please read the following paragraphs about what types of changes we accept, and please ensure that your proposed changes fit within that description.

While we are very happy to accept contributions to the library, there are some constraints that we operate under that are a little different than doing code for a particular team or a few teams. If the code can fit those constraints, and it is something that we believe would be used by a large number of teams then we are likely to consider incorporating it. We do our best to make our code fit these guidelines, sometimes more successfully than others, but these are guiding principles that we operate with.

First it that the library must work for all the teams that use it. This is the first and most important requirement. It's easy to write code that works in a particular situation, with a particular robot configuration, for a particular team. But the software that we release has to work for everyone. That means thinking about the corner cases that 3000 teams will find and for the most part is reliable. We try hard to do this, usually pretty successfully.

We (the development team) have to guarantee that as the library changes, all the code continues to work. That means that any code added has to be pretty easily maintainable and understandable. We think we've done pretty well there, with some exceptions, and in those cases we try to go back and fix them. You can imagine that if someone from the community graciously contributes some complex piece of code, then a year or two later, for whatever reason stops participating, then the maintenance of that code falls upon the remainder of the development team to ensure that it continues to work.

We operate under a mandate from FIRST to have parity across all the languages. That means that if a significant feature is added to one language, we try to get it into all the languages. To do this we work very closely with NI, CTRE, and FIRST on all significant changes. What this means is that a developer contributing a change for one language is possibly obligated to implement it for all the languages. This doesn't necessarily apply to every new feature because everyone understands that each language is different and some library features just don't make sense to be implemented everywhere. For example, we have been upgrading the C++ library to take advantage of the, now available, C++11/14 language features to make the code more reliable and understandable. This clearly has no analog in the other languages. And it often, if it makes sense, needs to work in simulation.

Hopefully this explanation helps you understand what types of changes we are willing to accept to the library. Note that we will not be merging any new features changes during the build season; we will happily accept bugs, but new features will need to wait until after the 2016 competition season.

Additional detail is available in the Contributing.MD file of the AllWPILib project: