[FRC Blog] Event Results and API Data

FIRST General Forum
#41

This. It’s surprising how some people on this thread don’t seem to understand how typical open source development works. It’s not like we’re suggesting FIRST make the repo public, accept all pull requests, and then just build and use whatever’s there come competition season.

FIRST is likely very limited in the number of software engineers they can hire. Based on some of the technology stack being used, it’s likely that FMS continues to utilize legacy code that’s been around for a while. As Cheesy Arena demonstrates, a fresh approach using modern technologies can have great results.

Open sourcing FMS and creating a community advisory board could allow recognized developers to contribute to FMS and improve quality more than FIRST’s in house developers could do on their own.

The biggest potential obstacle in making FMS an open source project might be the risk of potential game leaks. One possible approach could be to keep source closed closed during initial development and release the source once kickoff occurs. Then, feedback and community improvements could be put towards the next release. Android works in a similar way; each new version is developed internally by Google, then released to AOSP when it is announced publicly. OEM partners and community members can submit fixes which are then rolled into point updates or put towards the next version of Android.

#42

I echo the calls for open sourcing FMS.

This and this.

Open Source does not mean there is not a core group of developers committed to working on it for a deadline. It just opens it up to the possibility that extra pairs of hands/eyes can be volunteered.

Open-sourced software does not make it more vulnerable to security flaws; in fact, if the community is strong enough, it can lead to even better security. Again, another set of eyes/hands to spot and fix those security, performance and scalability issues.

One could argue that FIRST should make FMS Free, not just Open Source, Software, but one step at a time I guess.

#43

I also agree with the idea of a greater open-source initiative on the part of FIRST.

Open source has become huge in the CS world recently; and one reason is because of all the advantages it provides. FIRST’s development team can remain “benevolent dictators” of their code, just like Linus is with the Linux kernel - contributions may be submitted by anyone, but only the worthy get merged in. I think that the community is dedicated enough to make meaningful contributions back upstream - and this benefits everybody.

Many people also regard the field software as a “mystery box” and have no idea how any of it works. An open code base will let people understand how the field functions, because they can peruse the code themselves. I think this might reduce some of the anger we’ve seen in recent years - this weekend’s API issues and last year’s delayed pedestals and hot goals come to mind. Who knows, maybe somebody in the community would have spotted an optimization that could have fixed the problems quickly. Often, a new set of eyes is all you need to spot errors (my favorite tactic is to Rubber Duck Debug with a stuffed tux toy on my desk).

I can, however think of a few drawbacks. Mainly developer time. I can only imagine how stressful being a developer at FIRST (it’s a pretty small team, too) is this time of year, and adding in a responsibility to watch a public repository can be a lot. However, most of the main contributions can come back in the offseason, when they have more time. An open source repo also shouldn’t contain any advance information about the next game. I liked the suggestion above about following the Android model - code doesn’t have to be pushed to the repo until kickoff.

To me, the benefits of a greater open source involvement far outweigh the cons. I know that if the FMS API was open source, I would have spent a significant chunk of time this weekend helping debug it, and I would have been happy to help contribute fixes. Plus, FIRST could set a great example for teams by promoting open code; something all computer science students should have experience with when the enter the real world. FRC already gives so many positive experiences, this is another one that could make a great difference.

Plus, GitHub has a much better UI than TeamForge…

#44

This alone should be enough of a reason to switch to a different release model. TeamForge is one of the worst pieces of software I’ve had the misfortune to work with

#45

The model used by WPI during control system beta tests would be another possibility. In this model, access to source is granted to a select group of vetted individuals during development in order to move fast and avoid buggy or incomplete code from making its way into teams’ hands. Once a stable version is available (such as at the beginning of the season), source is released to all comers, and bugs may be filed or patches proposed using online tools.

#46

Greater than the FRC event API? That’s pretty darned open. Anyone can take the data from the events and massage it and display it anyway they want. I myself have plans to work with it but no time yet.

Open source for the FMS is pretty silly. You cannot test and validate it without all of the specialized hardware required for a field and you cannot do any coding on the part that changes yearly (the scoring) without knowing the details of a game that’s kept secret.

#47

The scoring part isn’t really the issue here; it seems to be data storage and transport that needs a lot of work. A properly designed system would let you work on all of that independent of the scoring components. And, as it’s already been stated, the scoring components can still be released on kickoff for other individuals to review.

And no, the FRC event API is not open. It couldn’t get any more closed. Public data != open-source software.

#48

I think you’re misunderstanding what we mean by open source, and are confusing it with a publicly available API. From Wikipedia:

In production and development, open source as a development model promotes a universal access via a free license to a product’s design or blueprint, and universal redistribution of that design or blueprint, including subsequent improvements to it by anyone.

For some more information about open source development models, read through this page

The FRC API is not open source, because I can not access the code running on FIRST’s servers. They have published an interface for the API, but not the implementation details.

For example, it would have been beneficial to have the API open source this past weekend, when it went belly up. If members of the community had access to the source code, they could have been able to find the root cause of the issue and helped collaborate with FIRST on a fix. This would result in faster iteration and higher quality code.

A popular project that embodies many benefits of open source is the Linux kernel. It’s the basis for a totally free (as in libre, not gratis) operating system, and is very heavily used in development circles. It is community written (over 4,500 different people have contributed), and is (in my opinion, but debate on this can be for another thread) the best OS out there.

As for your comments about FMS - it may not be feasible to run the software without access to the field hardware, but there is still value in making it open source. Namely, increased transparency. If people have the ability to go through the source and understand how it works, a lot of the mystery is taken out of plugging into the field (when you know exactly what is happening behind the scoring table). It would also let the community understand how and why some of the bugs in FMS (and believe me, they exist) are there, and possibly contribute to a fix, which means the bug could be patched faster than it would be otherwise.

#49

It’s also pretty darned broken.

And on the topic of testing without knowing the game, that is just wrong. It’s absolutely possible to test data transport without knowing the game. And a properly architected system should just have game specific actions as part of a workflow anyway.

#50

The API is somewhat “open” in a sense that they are taking suggestions from the community (in the team forge discussions) for the implementation of the API. However, the source code is completely closed to the public.

You are definitely right, just because public data is available doesn’t make it an open source project. I think some people are confusing the difference between data and code.

#51