[FRC4ME]

While I'm not sure I would have said it like that, exactly, I understand where you're coming from here. I've had the same thoughts recently, reading through topics here and interacting with the community. It seems there are far too many projects going on with the goal of eliminating the need for rookie teams to do programming.

It's not that I don't understand the intent of these projects. Many rookie teams don't have a good programming department, or have only one student who is responsible for doing all of the programming. It's nice for these teams to be able to make their robot do basic teleop stuff like driving and kicking/shooting/etc. But autonomous? In my opinion, that's a challenge best left as just that: a challenge. Let the challenge of autonomous be motivation for rookie team members to learn programming and join the ranks of the veterans. As the OP said, unlike the build team, we aren't limited by financial constraints.

I'm not saying that releasing SDKs is a bad thing. It's awesome to see how different teams approach problems from different angles, and how unique program designs can make things easier in the long run. And don't get me wrong; 619 has its own framework that we intend to release later in the year. But perhaps we should be writing these frameworks not with the goal of making them "so easy to use a rookie can do it," but with the goal of helping motivated rookie team members learn effective program design as quickly and efficiently as possible. Rather than doing everything for them in some sort of black box, give them a nice inheritance tree to play with - one that effectively shows the benefits of oop while requiring the team to implement these concepts by extending the code given to them. Or provide a nice event handling system that shows teams how event-driven programming works while still requiring them to write, instantiate, and order the events. Right now, it's almost to the point that a team can call, "driveForward()," and the robot drives forward, and IMO that does not teach programming skills.

One example of what I would say is going too far is "converting" other teams' code to a veteran framework without them explicitly asking you to do so. Sure; after spending a season designing an awesome autonomous framework you may think it's the end-all-be-all of FRC programming, and that you're doing every rookie team a favor by "porting" their code. But what seems like the best solution to you may not be the best solution for everyone - remember that, because you designed the system, your opinion of it is inherently biased. What if a rookie team would rather learn how to design an effective autonomous solution, rather than just letting another team do it for them? What if ease-of-use isn't the only concern here? And that's assuming your system even is the easiest to use; some of the SDKs I've seen around here look like they would make it harder than the default code to do anything more complex than simple driving, especially when they lack comprehensive documentation.

Note: the above is not directed to any one team or framework. I've seen at least four or five teams releasing SDKs with the specific goal of reducing the number of lines a rookie has to write as close to zero as possible. Overall, I think the releasing of frameworks is fine, and it's certainly a great exercise for veteran teams doing the development. But teams need to keep in mind that their goal should be to help rookies learn how to program - not to do it for them - and that a system's users view that system very differently than the system's designers. That is all.