[eugenebrooks]

<R71> Unaltered software modules developed during prior competitions may not be directly re-used. Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused. However, the specific lines of code must be customized for each robot each year.

The plain English of R71 is clear. It disallows the reuse of unaltered software modules, allows the reuse of software algorithms and designs, and requires that modules be customized for the robot each year. The rule was clear and easy to satisfy, hence no Q&A activity regarding it.

The business of retyping code developed outside of the allowed work periods in order to make it legal is a red herring from a prior season. It did not apply this past season, probably because more than one person saw teams busily retyping their entire robot program in order to legalize it in a prior season, while the "illegal copy" ran the robot during practice matches, and realized the foolishness of this rule. Retyping modules, verbatim, did not satisfy the plain English of R71.

Sharing is one of the key principles of the FIRST community. Sharing has been encouraged and has been expressed in many ways: design ideas, actual parts, actual software, etc..., have all been shared. From the point of view of the FIRST community, there is everything to gain and nothing to lose by sharing at any level that you are comfortable with. If someone walked up to me at a competition and asked for a copy of the source code for our robot I would hand it to them without a second thought. I would like to think that the recipient would learn something from it. The same goes for any of the mechanical aspects and wiring aspects of our robot, in any level of detail. I would encourage every team to share at any level of detail that they are comfortable with as nothing but good can come of it.

I am not one to think, however, that we should have rules that force sharing. Forcing sharing is as much an anathema to FIRST principles as is the notion of seeing a robot covered by a black shroud to conceal "trade secrets" while it is in the pits. There are so many teams eager to share that we need not make teams uncomfortable by forcing sharing upon them.

If the past experience is our guide, the rules for software development will change again this year. The notion of treating the software like hardware misses some of the fundamental aspects of software development. Suppose we were to place the same "customize modules" requirement on CNC software used to turn out identical parts that are used in a team's robot year to year. Just what purpose would customizing the CNC program have, only to have it turn out exactly the same part. A module that implements interrupt driven wheel counters is exactly the same. The end result is the count, no more or less than that. The role of customization here is exactly the same as a rule of customization for the CNC program that turns out exactly the same axle as last year.

I would hope that the rules for software development get changed so that they reflect the nature of the software development process. There isn't any need to customize a software module that provides wheel counters, and that the program for the robot will be customized given that each game is entirely new, is a given. Lacking that, it is best to follow a reasonable interpretation of whatever the rules may turn out to be.

Eugene