To further a point made by KenWittlief and others earlier...
Ohio State this year sponsors *3* teams, each at a different high school (one public, one private, one home school). Each team operates semi-autonomously - each design/build their own robot, but at the mentor level there is a lot of cooperation (especially since we're all friends/classmates). We/they (I've graduated or something) run integrated fall training sessions (in conjunction with other Central Ohio teams), which is amazing. This is way better than each team developing and implementing essentially the same material. By sharing it across our teams and with the others in the area, we're able to leverage the combined expertise of the group. We're electrically heavy, so we teach most of the electrical/controls related materials. Mentors from other teams share their mechanical knowledge, or 3DStudioMax, or fundraising, or.... The class/team ratio is such that some teams don't even have to contribute - they can just show up and participate. To me, this really starts hitting at the spirit of FIRST - since it's all about inspiring/teaching, who cares who's at the front of the room or gets the credit?
We even extend this, to some degree, to the build season. One of our fall sessions is a "lessons learned", where we share how we go about the design/build process and some pitfalls we've come across - other teams do the same. This isn't to say we're dictating "here's how we run design week, you must do it this way", but rather we're just sharing our (unique) way of viewing the "FIRST problem". This is fairly recent so I can't comment on how well this is worked (unless some of the other CORA teams want to jump in here and say something), but I view this as a good thing.
The area-wide collaboration dies down once build starts, mostly b/c teams are too busy doing their own things. The idea has been floated to have design review sessions of sorts. The idea here would be for teams to present their high-level designs to some moderated (or un-moderated) panel, which would hopefully catch major design flaws and pass on advice. For example, if a team said they wanted to build a time travel device, the panel might caution against that. A similar idea has been proposed for exchanging strategy ideas. The big problem we've found so far is that the inner culture of each team is different -number of hours expected from the students, days of the week they meet, pace of the design schedule - those are prohibitively different enough that unless the need is really clear, most teams shy away. The comparisons to industry start to break down here – all TRW/Ford/Wherever employees share (well, in theory) the same vision, purpose – and they are paid to do so. That’s not always the case in the FIRST world – if it was, these forums would be pretty boring.
The OSU teams, however, still collaborate a little during build season. This is mostly limited to an exchange of ideas (again at the mentor level), leveraging off the experience of the collective group. We're all college students, so we don't have the years of experience built up to help us out. Instead, we do have years of making really stupid mistakes designing FIRST robots, so we pass those stories along hoping we don't repeat them. Each team has a machinist-type (a college student that has some experience), so we can leverage off the experience of another team's "machinist". For us, this is just a logical step. The number of mentors keeps increasing, so we keep spawning new teams. The relationships are there, so why not capitalize on them? In fact, for us it's one of the few ways we can really be competitive against teams with "real" engineers. (well, that and we have no families and lots of machine shop access, but that's for a different thread)
So, back to Ken's point, we nearly fit what he's saying - we're several teams, working together, but still semi-autonomously. At the mentor level, I think this is a great idea. The individual teams still have ownership of their designs, but we can leverage off of the collective experience of the group. For us, it's pretty natural because of the way the team(s) were founded/structured. For disjoint industry teams, the integration might not happen so seamlessly. Our biggest problem has just been a lack of workspace. The mentors play nicely (well, as much as you could hope for anyway
), and the students seem to enjoy it. We did have an issue a few years ago where the "gracious professionalism" bit didn't take hold, but once they got it, things have been fine ever since.
We don't, however, completely share designs/prints/parts, though I suppose I could envision instances where this could/would happen. What I don't see, however, is that this ruling will "require" such collaboration in the future. To us, the most important thing is exposing the students to the realm of engineering. If we happen to build a robot to do that, so be it. The robot is just a delivery mechanism to make that happen. Would I like to have a competitive machine? Of course I would. Our team has had both the lows of not moving for most of a competition, to the highs of making the semi's at the Chicago regional a few years ago, so I know what it’s like to be on both ends of the spectrum. Performing well is much better than not moving. But does it really matter if we win? Of course not. To me, the basis for a collaboration decision shouldn't be to remain competitive, but rather to have your students get the most out of the experience. If your situation is such that a collaborative effort makes sense, then by all means. If not, so what? That doesn’t mean you won’t be competitive, and so what if you don’t win? (ignoring sponsorship concerns, of course)