What needs improvement with FOSSA?

If you have thousands of applications, organizing them all into teams or tags is challenging. There is a point where you start using FOSSA at a very large scale, and the user interface needs to adjust. That's probably a challenge because the organizations using it are huge. It's not a problem if you use the tool for smaller use cases with hundreds of applications. When you get into the thousands of applications, managing through the user interface becomes a little hard.

I want the product to include binary scanning which is missing at the moment. Binary scanning includes code and component matching through dependency management. It also includes the actual scanning and reverse engineering of the boundaries and finding out what is inside.

One thing that can sometimes be difficult with FOSSA is understanding all that it can do. One of the ways that I've been able to unlock some of those more advanced features is through conversations with the absolutely awesome customer success team at FOSSA, but it has been a little bit difficult to find some of that information separately on my own through FAQs and other information channels that FOSSA has. The improvement is less about the product itself and more about empowering FOSSA customers to know and understand how to unlock its full potential. More training would be helpful. When we first purchased FOSSA, there was no real onboarding that I was a part of. That could just be because FOSSA did an onboarding with someone else on the team, and I inherited that after the fact, but onboarding would be very helpful. Another thing that would be really helpful is building out more documentation for more advanced use cases of FOSSA. One, in particular, would be for the use case where FOSSA can help you really drill down on a specific package and what licenses are flagged or rejected in that package, and how to resolve those within the system. This was something about which I couldn't find documentation on the FOSSA website, and I had to have the CS team walk me through that.

I would like the FOSSA API to be broader. I would like not to have to interact with the GUI at all, to do the work that I want to do. I would like them to do API-first development, rather than a focus on the GUI. There were also some reporting things that I thought could be better. I talked to FOSSA about this. A lot of times when they were reporting, their labels did not match. Classically, there hadn't been a way to get well labeled output. It was just in HTML or PDF or CSV. They put out a JSON version of things that is certainly helpful. So that part's fine.

On the legal and policy sides, there is some room for improvement. I know that our legal team has raised complaints about having to approve the same dependency multiple times, as opposed to having them it across the entire organization. I believe that our legal team is working with FOSSA on improving those things. FOSSA is very open to our suggestions, requests, etc.

I would like more customized categories because our company is so big. This is doable for them. They are still in the stages of trying to figure this out since we are one of their biggest companies that they support. I do feel like we are being heard and they are working on trying to give us what we asked for.

The solution provides contextualized, actionable, intelligence that alerts us to compliance issues, but there is still a little bit of work to be done on it. One of the issues that I have raised with FOSSA is that when it identifies an issue that is an error, why is it in error? What detail can they give to me? They've improved, but that still needs some work. They could provide more information that helps me to identify the dependencies and then figure out where they originated from. That would give me a better idea of where to look, rather than just generically searching the web. They do provide more information than they used to, which is good, but I still think that they have a ways to go with it. Another topic is the components tab of FOSSA. It has a couple of reports that tell me the packages that are being tracked and that allow me to look up packages. That could be expanded in several ways and fixed up in several ways. It could be expanded in that, right now, you can only search for and find packages that are in use in the organization. There is no way to search for all packages, even packages that we're not using. That would be really useful to my developers, for them to be able to come into FOSSA and get more information about components before they use them. The other thing on that tab, regarding the reports, is something that I've been working on with them for a while. The reports don't really work that well for us. They do provide good information but they perform poorly with either the number of projects, or components, in the system. Reports that worked when the load was low, are now timing out before finishing. Unfortunately, that makes it a feature that I can't really roll out to the rest of the organization. For example, the due diligence report and the audit report FOSSA has would be very beneficial to my teams, but until they work for all the teams, I can't roll it out. So there is work that needs to be done on this page for reporting. If they're going to provide reports they should function and they should provide actionable information. They do provide actionable information but because they don't function, they're not really useful to me, and I need them to be. So the components tab needs work, or it needs to be removed, but I prefer that it gets the work. There are other little things that could be improved as well. On the issues tab, there is a problem with resolving issues that have been identified and that occur in a larger number of projects. It doesn't even have to be that many. We've got one component that is tied to 61 projects and we have tried to resolve it for all but it never actually works. It spins for a while, but it doesn't do anything. These aren't things that happen on a regular basis. They're not so much of an issue that the system doesn't work. There are a few other usability issues in the system, UI concerns that I have, and I bring those up on the Slack channel with them as I run into them. Quite often they address them very quickly.

I wish there was a way that you could have a more global rollout of it, instead of having to do it in each repository individually. It's possible that's something that is offered now, or maybe if you were using the CI Jenkins, you'd be able to do that. But with Travis, there wasn't an easy way to do that. At least not that I could find. That was probably the biggest issue. Another thing that is they were super great to work with. I could contact them and the engineers were very responsive to the questions I had or if there was some issue I found they were always helpful working it out. I would say that the documentation would probably be another area that could use some work. If I was doing something that was undocumented but I might know about it because I talked to one of the engineers at FOSSA, then our engineers were always a little worried that it wasn't documented and if they should be using an undocumented feature. I felt like the documentation a lot of times trailed the product functionality a little bit. If you were trying to solve problems on your own, sometimes it wasn't the easiest.

Security scanning is an area for improvement. At this point, our experience is that we're only scanning for license information in components, and we're not scanning for security vulnerability information. We don't have access to that data. We use other tools for that. It would be an improvement for us to use one tool instead of two, so that we just have to go through one process instead of two. Another area for improvement is because our list of projects is large. We have over 700 projects that we're scanning through FOSSA right now on my dashboard, and it's just very hard to arrange 700 things. So any way that it would allow me to categorize products better, so that I could say, "Automatically categorize all the Android projects, all the iOS projects, and which are the ones that are for the US or Taiwan, and which are related to this customer or that customer." Better ways to categorize the projects would be very helpful. Another thing that would be very helpful is during issue triage. I would like to see a better way to get access to the component without leaving the app. When the app tells me, "Your mobile product uses this component and this component has a problem." In that case, I want to look at that component to see, first of all, am I really using it? And second of all, is the problem real — I have to do some triage. It would be better if the tool made that triage step easier in the tool, without me having to go outside the tool and search around: Am I really using that component? Does the component really have the problem FOSSA thinks it has? One other thing that would help is a report of all the components that I'm using. For example, suppose I have two apps and each app uses a hundred components. These two apps are very similar. Are the hundred components they're using the same or different? I would like to be able to run a report that takes a list of apps and tells me, here's all the components of one, here's all the components of the other, and whether they are the same version. If I have two versions of the same app, how different are the components? To be able to do that kind of holistic analysis of the components would be helpful, but not just in terms of a scan. It has scanned it, so it has all this data. I want to be able to now put that data on a chart. Not all 700 of my apps, but three of them; I want to take three apps and compare their bills of materials. Are they using the same STKs and are they the same versions of the STKs? That could be very helpful.

We have seen some inaccuracies or incompleteness with the distribution acknowledgments for an application, so there's certainly some room for improvement there. Another big feature that's missing that should be introduced is snippet matching, meaning, not just matching an entire component, but matching a snippet of code that had been for another project and put in different files that one of our developers may have created. A snippet matching is important as well and something that should be included soon. Those are the two big improvements that should be implemented.