FOSSA Room for Improvement

Brett Fattori
Manager of Open Source Program Office at a financial services firm with 5,001-10,000 employees
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. View full review »
Patrick Lonergan
Associate General Counsel at Circleci
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. View full review »
Justin Giannone
Sr. Security Architect at a computer software company with 1,001-5,000 employees
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. View full review »
Learn what your peers think about FOSSA. Get advice and tips from experienced pros sharing their opinions. Updated: August 2020.
442,283 professionals have used our research since 2012.
Sr. Director of Open Source at a comms service provider with 10,001+ employees
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. View full review »
Attorney at a legal firm with 11-50 employees
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. View full review »
Eric Griswold
Principal Release Engineer at Puppet
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. View full review »
Christina Luu
Program Manager at a consumer goods company with 10,001+ employees
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. View full review »
Learn what your peers think about FOSSA. Get advice and tips from experienced pros sharing their opinions. Updated: August 2020.
442,283 professionals have used our research since 2012.