Ethics 101: To re-use or not to re-use?

[Alexa Stott]

Originally Posted by Dave Scheck

I disagree with the proposed idea.

My reasoning is that I think that this will punish teams that actually take the time to create well written, reusable code. They have put in the time to create this product....why should they be forced to share this with a team that doesn't put in the effort? What is the motivation of a new team to actually learn how to write code when they can go out and download the prewritten code of their choice? What is the motivation for a team to post their code in a legible format?

I have to agree with David on this one. As a programmer, I have witnessed how much time, effort, and frustration it takes to maybe even get a small part of the robot working. You write some code, test it, change it, test it again, etc. This could go on for hours. How is it fair to that team that sits there writing and testing the code to post it online for anyone to see?

I can see how this would help enforce the rule, but the outcome isn't fair to the programmers that spend 14-hour days writing code for their robot only to have a team that is too lazy or too inexperienced come and just copy it all. Moreover, how is that helping to teach students how to program if they know that pre-written, working code is out there for them to just download? I know you can all sit there and say "Well, they would do the right thing...they would be GP and not steal it...blah, blah, blah." But honestly, if you know you could skip those hours upon hours of coding and spend 2 minutes downloading someone else's code, you know you'd be typing in the URL to that site.

Don't get me wrong-I'm entirely open to helping other teams with programming help if they PM/email/IM/approach me at a competition asking for it. I'm more than willing to let people look at our code to get an idea of how it works. But this brings to a new level. At least when they talk to me directly, I know what their problem, unlike the people that would be downloading code from this "central location."

[Dave Scheck]

Originally Posted by Kris Verdeyen

They aren't forced to do anything - in the propoal, those teams are free to do the busy work of re-typing everything.

How is saying "if you're going to reuse all that stuff you already did, you have to waste your time to re-type it" not forcing? Because it has the condition that you don't have to reuse it? I don't buy it. We're here to teach engineering skills, not busy work. If you go back to Dave Flowerday's post about what our team went through at Purdue, I consider that a punishment. We had kids that weren't able to enjoy almost a full day at a competition because they had to perform busy work.

Originally Posted by Kris Verdeyen

Because for anyone to be able to use another team's code, they will have to understand it first. Even the best-intended public code (kev or usfirst) still requires hours to fit into a complex scheme like what's used on a robot.

Granted, but it's not understanding how it works but understanding how to work with it. My previous post explains my stance on this.

Originally Posted by Kris Verdeyen

So that other teams could use it? I don't know. Maybe so they don't have to retype all those comments they left out? Because it makes them feel good? Altruism? First fame? They're trying to get into heaven? It seems more stupid to purposefully obfuscate posted code than to simply re-type it.

I agree that obfuscating the code is more of a hassle than its worth, but I guarantee you there is someone out there that will do it. Then how do you handle that? Require that code be posted in a certain format? Do you then require teams to support any code that they make public?

Why should completely spilling the beans on last year's robot be any different?

There's a difference between sharing a design and handing something out.

The teams that want to make themselves better will seek out the assistance of the teams that they want to learn from. The teams that want to make others better will seek out teams to teach what they've accomplished.

I can't tell you how many requests we received in 2003 about how our autonomous worked. We gave explanations both at competitions and remotely to anybody that requested it. I have seen many teams behave in the same way in all aspects of the competition. Want to know how 71 dragged everybody around the field in 2002? Want to know how 33 automated their arm in 2005? Want to know how team X did Y? Just ask. That's one of the foundations of this program that makes it so great. I can't think of another program in which participants share their secrets.

I really don't intend my involvement in this thread to be an argument. I just think that if we are going to have rules intended to level the playing field, they shouldn't hurt teams that put the effort in to go the extra mile.

[MikeDubreuil]

Let me start off by making a bad analogy to hardware. In the past 5 years the hardware guys have made a significant improvement in the FIRST program by encouraging the spread of designs. From multiple speed transmissions to omni-wheels to some craziness called swerve drive- they are sharing everything! Yet, on the software side we want to keep our code hidden. Teams put their electronics in black boxes. It's getting bad. Maybe we should take a play out of the hardware guys book?

Here's my 10 cents...
Teams have a 1 season monopoly on their software. If a veteran team wants to re-use code from a previous year they should be required to post it in a "Software Portfolio" hosted by FIRST. The portfolio is publicly available to everyone. A new regional award can be created for veteran teams who share code, "The Software Award." An award that celebrates a teams generosity and their ability to write good software with even better documentation.

[Bharat Nain]

Originally Posted by MikeDubreuil

Let me start off by making a bad analogy to hardware. In the past 5 years the hardware guys have made a significant improvement in the FIRST program by encouraging the spread of designs. From multiple speed transmissions to omni-wheels to some craziness called swerve drive- they are sharing everything! Yet, on the software side we want to keep our code hidden. Teams put their electronics in black boxes. It's getting bad. Maybe we should take a play out of the hardware guys book?

Here's my 10 cents...
Teams have a 1 season monopoly on their software. If a veteran team wants to re-use code from a previous year they should be required to post it in a "Software Portfolio" hosted by FIRST. The portfolio is publicly available to everyone. A new regional award can be created for veteran teams who share code, "The Software Award." An award that celebrates a teams generosity and their ability to write good software with even better documentation.

There is still a difference between hardware and software. Many teams did not share their exact design on hardware but what they did was visible and people caught up on their idea. Most teams took the time to teach people what they did too. Software is just like that and people do not need to see a team's code to understand the concept. It is easy enough to write something based on a concept but not for high schoolers. It is easy for professionals or the more experienced. Therefore, Sharing code is the team's business and it should be upto them if they want to share it or not.

[Alexa Stott]

Originally Posted by MikeDubreuil

Here's my 10 cents...
Teams have a 1 season monopoly on their software. If a veteran team wants to re-use code from a previous year they should be required to post it in a "Software Portfolio" hosted by FIRST. The portfolio is publicly available to everyone. A new regional award can be created for veteran teams who share code, "The Software Award." An award that celebrates a teams generosity and their ability to write good software with even better documentation.

There is a huge difference between hardware and software. Teams post their designs or pictures, other teams take them, and make them themselves. The thing with that is, they actually have to do some work actually making the parts. Or maybe they go and find a way to make it lighter or whatever.

With software, someone has to simply quickly download the files or do a quick copypasta. Maybe they have to go as far as to declare a few variables.

As Bharat as repeatedly said, you cannot compare hardware and software.

[MikeDubreuil]

Originally Posted by Bharat Nain

Most teams took the time to teach people what they did too. Software is just like that and people do not need to see a team's code to understand the concept. It is easy enough to write something based on a concept but not for high schoolers. It is easy for professionals or the more experienced. Therefore, Sharing code is the team's business and it should be upto them if they want to share it or not.

Can you explain... Are you saying that it is okay for teams without software engineers to flounder with software?

[aaeamdar]

Originally Posted by Marc P.

Naturally, this wouldn't make much sense given the change in game play form year to year, but how far off from reality could it be if a team has not much more than a pusher/drive train bot from year to year? In that situation, how would a mentor tell their programming team "sorry guys, the code we had from last year is good enough, so we won't be needing you." More importantly, what do the students learn from that?

[...] such as the camera tracker. Mentor to programming team: "Sorry guys, our code from the camera last year worked so well, we don't need to rewrite it. Just copy and paste it and call it a day." Again, what do the students learn from that?

Marc, as a previous poster said, there are some holes in your logic. I'm not sure how much knowledge you have of the programming process, but in your first example, a robot that simply pushes other robots around, there is (programmatically speaking) nothing for the programming team to do. The default code that you are required to use takes care of this already. R71 would have no effect here, since you would be using the default code each year (which I'm sure doesn't violate the rule).

In your second example, you seem to be out of touch with the way that the camera code was implemented last year. I'm sure some teams last year wrote their own camera code, but the vast majority of teams (including mine) took advantage of the code graciously provided by Mr. Kevin Watson. So in effect you have the mentor saying this: "Sorry guys, we have code already for the camera. Just copy and paste it and call it a day." Maybe you would argue that such code should not be provided?

Paul

[aaeamdar]

Originally Posted by AtalanteStar25

I have to agree with David on this one. As a programmer, I have witnessed how much time, effort, and frustration it takes to maybe even get a small part of the robot working. You write some code, test it, change it, test it again, etc. This could go on for hours. How is it fair to that team that sits there writing and testing the code to post it online for anyone to see?

I certainly understand where you're coming from here. It can be very frustrating, but I think you're reacting from that frustration. Let me make a couple points.

My favorite language of all time (so far) is Java. For those who don't know, Java is a language that has huge libraries of pre-written code. People from all over the world submit their code to Sun so that it will be included in the next Java version. What's the point? I would say that it's rather like building a pyramid. You can't start with the top layer. You must start at the bottom and build up. Before you can write a game with orcs that attack humans (à la Warcraft) you must first know how to display an orc on the screen, how to get information from the user, and about 1000 other pieces of information. If every time someone wrote a computer game they had to come up with new code to read data from the keyboard, complex games would never evolve because everyone would be too busy building the bottom layer of the pyramid over and over again.

The other point is that no-one is forcing teams to post their code. I myself would have no problem posting my code online for others to use. In fact, if I knew I were doing this, it might go a long way towards encouraging me to better document my code.

Paul

[aaeamdar]

Originally Posted by Dave Scheck

I agree that obfuscating the code is more of a hassle than its worth, but I guarantee you there is someone out there that will do it. Then how do you handle that? Require that code be posted in a certain format? Do you then require teams to support any code that they make public?

First, I beg everyone's forgiveness for posting three-in-a-row. My short response to this: no one is going to catch you if you re-use code and don't post it online. I'm not recommending it, but I'm simply saying, there's no reason to maliciously obfuscate code. However, I'll acknowledge the possibility that it might happen somewhere. But: You can't make teams be graciously professional. The best you can do is ask. Intentionally obfuscating code is certainly an example of this. No solution will be perfect.

Paul

[Bharat Nain]

Originally Posted by MikeDubreuil

Can you explain... Are you saying that it is okay for teams without software engineers to flounder with software?

Yes. Lets face it. FIRST has never really been an even playing field. Some teams have better engineering support over others. Same goes for programming. Some teams, like Wildstang(I only say this because they have posted on this thread) have accomplished a lot as far as programming goes. Their StangPS has been known to all and they have shared their designs. In my opinion, we should be grateful to them for sharing the concept in detail(I think I saw it on their website). They did not have to because they put in the hard work and were privileged enough to have the expertise. On the other hand, I am sure there are many teams out there who have complex code which do wonderful tasks but never release their code or concept to others. Bottom line: its their choice. So understand - I am by no means saying that teams should not share and the not so privileged teams should have crappy programs - because I know FIRST has taken steps to help teams with their basic needs(default code). But FIRST also provides a kit chassis to all teams and it is totally upto the teams if they want to use them or not. Some will, some won't, so what? The bottom line is always inspiration and having a running bot is a good start.

p.s. 25 doesn't have any flourishing software engineers so I am not standing up for my team by any means.

[Cory]

Originally Posted by Dave Scheck

Would you think the same way if this pertained to mechanical design? Would you force teams to make their gearbox design public if they intended to use it from year to year? (I know that the software/mechanical comparison isn't easily made, but humor me).

Originally Posted by Kris Verdeyen

Yes.

I agree that the comparison is not easily made, and I've tried, but why not? Year after year, and with nearly every chance they get, FIRST rules in a way that makes the game more competitive, the robots better, the compeitition more fun to watch. Why should completely spilling the beans on last year's robot be any different? It's good for good teams, because it encourages them to continue to innovate, and it's good for struggling teams because it demystifies the champion teams in a way that is bound to inspire them to strive further. It makes the pie higher.

Why is it good to hand someone something on a silver platter instead of making them work to attain it? If you put together all the time that team 254 and it's partners in collaboration have spent developing a six wheeled drive base, I'm sure the figure would exceed the thousand hour mark by far. Why should such teams be forced to give everyone in FIRST a transmission design they can hand to a machinist and get back a week later when it took the original teams a thousand hours to perfect the design?

Now by no means am I against sharing designs. Anyone who wants to know anything about our drivetrain, for example, can feel free to ask me or any other student/mentor about it. I'm sure 968 feels the same way. We'll gladly share pictures, theory on how it works, why we did what we did, what we might change and do differently. However, we are not going to handout blueprints. What's the point of that? What is any student going to learn by handing a sheaf of CAD drawings to a machinist and then receiving a nice shiny transmission back? The answer is nothing. You would be cheating yourself.

FIRST is about learning, and nobody learns anything if teams are forced to share code, mechanical systems, or anything else just to use them again. All that would happen is the original teams efforts are completely ignored and everyone reaps the benefits without any of the work. So much more could be learned by simply approaching a team with a innovative and successful idea and learning about how it works from them, and then implement it yourself.

[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

[MikeDubreuil]

Their is a significant difference in the ability to reverse engineer hardware over software. Many people can look at an assembly and then create a design from it. Thereby duplicating that assembly without mechanical drawings. The same can not be said about the software. Sure, you can guess as to how the code is implemented. However, you still don't know the design or the implementation.

I think it would be a step forward for teams to share their code. It's against my perception of FIRST to allow veteran teams to dominate autonomous by leveraging years of software development. It might be a good solution in the private sector but not in FIRST.

[Jack Jones]

I don’t know what the big deal is. Many of you have typed more characters here than it would take to program the robot – autonomous mode included. So, your displeasure with the rule can’t be about wasted typing effort. Many have pointed out that the requirements change enough from year to year so that not much, if anything, from the code can escape customization. Since the rule, as all <R> rules, must only apply to what goes in the crate on ship day, then go ahead and start with the old code. By ship day it’ll be tweaked up beyond all recognition – TUBAR. Any code that hasn’t been touched, you can rewrite. You’ll probably find you’ve improved it, if not in function, then in the appearance.

There’s been a lot of discussion about the difference between hardware and software, especially as to why we can’t equate the two. Well, the main difference I see is that with software the raw material is infinite. We can create and destroy it with the press of a button. If we can live with leaving perfectly good hardware behind each year, then having to recreate software shouldn’t faze us a bit.

There are times when I wish the DoD had an <R71>. I often write CAE software to facilitate signature research and analysis. There are a number of dinosaurs from the eighties, usually written in Fortran, that try to predict atmospherics, bi-directional reflection, thermodynamics, and etc. I don’t know how many times management wants us to incorporate this chunk of code from the Air Force, or that from the Navy, into something we can use to predict the performance of future combat systems. They all have this joint meeting of planners, each wanting to leverage their programs, so they conclude we can just write a wrapper around stuff that may, or may not, have worked all that well to begin with. My group prefers to start from scratch with the code, to take the essence of what has been done and bring it into line with the 21st. century. So, there may be some method to the madness of <R71>. It forces us to revisit and perhaps improve upon what was done, instead of dragging along dinosaurs year after year.

[ewankoff]

As i said in my last post and like alot of other people have said, FIRST is about learning. This rule is simply a big sign saying "learn from your code and know how it works" and so no one blindly copies things that they dont really know about (I know Kevin's code is hard to understand but an attempt can be made). Sharing your code is a great idea but in no means should it be the loophole for this rule. Yes teams that put in the hard work should reap the rewards but, these teams should be able to teach new programmers, robot designers, or someone with a question year to year about their code or part. I see copying and pasting code to be the same as sending a coppied CAD drawing of a mechanical component to a machinest. no one learns from anything. If some one learns from part of the robot in any way it is a whole of a lot better. FIRST is about teaching the students and simply copying and pasting or stealing designs is neither a goal of FIRST nor in the spirit of FIRST.