Allow me clarify my statement:
Given the talent of our community, I know putting the FMS and STIMS/VIMS on Github would result in useful, bug fixing, and feature adding pull requests. It wouldn’t take away control from FIRST but would allow motivated mentors and students to help.
As a remote spectator, I was disappointed that I could not find a qualification schedule for my former team, and as a result I watched less than I have in years past.
The FRC website is actually doing this more “correctly,” though neither are providing an accurate picture of what is happening. In qualifications, quarterfinals, and semifinals, neither alliance “wins.” It is all based on average score for these rounds.
It would be nice if the FRC website highlighted who won the finals though, and both should more clearly highlight the teams that move on to the next round throughout playoffs.
As for Cheesy Arena:
Keep in mind that Cheesy Arena is designed for offseason events that don’t have the team number signs, the team lights, emergency stop buttons, alliance station lights, SCC (alliance scoring cabinets), any game-specific field hardware (e.g. goal lights in 2014, weight sensors in 2013), ref panels, or any other miscellaneous field hardware that typical comes with a FIRST event.
It may be open source, but it also has far fewer moving parts to deal with.
Except the FRC website doesn’t show the average scores, but The Blue Alliance does.
The bolded “winning” team on The Blue Alliance will be removed for non-finals matches.
Ah, I was just looking at the match results and somehow missed the playoffs breakdown on TBA. That is definitely more useful.
Cheesy Arena handles most of this stuff and was designed around using readily available hardware to display things such as team numbers. It even improves upon the game specific elements like the hot goal lights, which were actually timed correctly in Cheesy Arena.
Yes, it does provide most of things in forms other than what we are used to at FIRST competitions.
However, FIRST is unlikely to completely replace the existing hardware in the very near future. Additionally, while Cheesy Arena is an excellent substitute for the FMS for offseason events and the cost of the overall system is lower, FIRST has a different set of requirements for the official field.
For example, the GitHub page for Cheesy Arena explains that Chezy Champs used cheaper consumer-grade LEDs instead of the professional grade LEDs used on the official field.
I am not privy to the decision making process that goes into selecting the components for the field, and I’m not making any arguments for which software or hardware is better. What I’m saying is that Cheesy Arena isn’t designed to be a replacement for the FMS during competition season, and isn’t likely to become a replacement there.
I’m not sure whether or not open source FMS is a good idea yet. Certainly I think the community would be very on board with helping out. One additional point: wouldn’t open-sourcing FMS open FIRST up to 2012-style sabotage?
The best security is achieved when everyone can see the problems and then fix them, not through obfuscation. Security achieved because “no one knows how our internals work” is bad practice.
Although it’s not a perfect analogy, this sounds like various Wikipedia debates I’ve heard. On one hand, letting anyone edit pages leads to incorrect/biased information, sabotaged pages, and edit wars. On the other hand, Wikipedia is one of the largest, easily accessible sources of information–and most of the time other editors fix incorrect information.
Without any relevant experience, my guess on this would be that if FIRST decides to open source it, they open up the possibility that experienced mentors and students are able to help. However, they also open it to the risk that anyone can sabotage it if they like. Of course, there are far worse consequences to this than just a sabotaged Wikipedia page, which FIRST has to consider carefully.
It’s important that to note that “open source” does not mean anyone can make edits without review, potentially allowing the system to be “sabotaged.” Changes must still be reviewed and then accepted by the owner.
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.
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.
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…
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
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.
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.
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.
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.
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.