[MrRoboSteve]

I'd be interested in hearing more about the issues that you ran into with your robot code this year. While I have some "would have done it differently" moments with the command-based approach, we have not run into anything that prevented us from achieving our goals.

I mentally model WPILib as having several different subsystems, with important ones being:

. a class hierarchy that represents all of the physical devices that can be attached to the robot
. the NetworkTables abstracting, which is a state sharing mechanism between the DS and the robot
. A layered set of application-building frameworks that allow you to build a robot control system at one of three levels of abstraction:

Simple -- you handle the loop
Iterative -- loop abstracted out
Command-based -- event-driven

If you don't like the application-building frameworks that are provided, there's nothing in WPILib today that prevents you from building your own along side/above what is already there. In fact, if you build something new, it's adopted by teams, and you are careful about code ownership issues, you'd be in a good position to lobby to get your framework adopted into WPILib. The best model for this would be a library that is designed to work alongside WPILib.

If there are bugs in WPILib that you'd like fixed, the best approach is to report them with good repros attached, or a fix if you have one available. I've found the maintainers are very responsive to issues that I've reported. If you need the fix for your robot to work, bring the code for the class into your robot, give it a different class name, fix the bug, and run with that. No need to fork the whole thing in most cases.

Be sure you're ready to take on these issues with your fork:

. competition year updates (1-3) will need merging and resolving
. will need to quickly handle (1-2 days) any week 1 software updates (a la this year)
. harder for CSAs to provide support at competition (e.g., validating all required updates have been applied to the library)