Hi -
I am probably the person you're looking for at WPI.
We are in the process of setting up a procedure for community contributions to WPILib. In fact we had several mentors contributing new additions to the library over the past summer and into the fall beta and I believe that the collaborations were both successful and productive. We also had a number of mentors that contributed code to the initial roboRIO release last year. You can see the list of contributors here:
http://wp.wpi.edu/wpilib/wpilib-supporters/
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. As I said, 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. I 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. For example, this summer we are working on a new NetworkTables implementation and it will be rolled out across all three languages. What this means is that a developer contributing a change for one language possibly obligates 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, C11/14 language features to make the code more reliable and unerstandable. This clearly has no analog in the other languages.
We have a hardware test system at WPI, FIRST, and NI and all the code checked into our version control system is automatically tested. We currently have several hundred Java and C++ tests that are automatically run against every checkin and every release. We ask that people who are adding core features also create tests to add to the test system to help ensure that we don't break everything from release to release.
And it often, if it makes sense, needs to work in simulation. There are significant improvements coming this year in this area and we try to keep everything working in the real and simulated environments.
Maybe some of you remember back in 2009 when the cRIO first rolled out with WPILib, we had a server called FIRSTForge which was a collabnet project server. We ran the betas on that server and kept all of our code on it. Back then, we allowed teams to use the server to host "community" projects - those projects that were open source and of general use to the FRC community. Those projects were run by the team or teams that created them. The idea was, by having them all in one place it would be easy for all teams to find everything that was available rather than hoping to notice that a team posted an announcement on Chief Delphi or somewhere else. That worked somewhat, but teams like to keep their own identity and host their code in the location of their choice.
What I'd like to see happen is the creation of a directory of projects with small description of each project, maybe tags to help find things, and a link to where that group is storing it. Github has been a very generous supporter of FIRST and would probably make a good place to host these projects, although that shouldn't be mandated. The key is that there would be a single directory of all the projects so it would be easy to find that code that, maybe, didn't meet our constraints for contribution to the WPILib main code release, but useful none the less.
So, in summary, I propose that there are two classes of contributions:
- Those changes that fit the constraints described above. Those improvements we will gladly accept, although I suggested contacting us before spending too much time to make sure it doesn't conflict with something that is already going on.
- Those changes that, while are useful, don't for whatever reason qualify to be part of the main library. And they can be developed by one or more teams in collaboration and added to this directory that I'd like to see be implemented, where anyone is free to grab the code and add it to their own robot projects. Maybe in some cases, this code will prove to be so popular, that it is moved into the first category.
We will soon post the guidelines for contributing to the library, although we're pretty busy right now getting ready for beta. So it will probably come after that. But for now, feel free to clone the repository and look around. That represents the most up to date version (not necessarily released) at any instant.
My two cents.
Brad