We just raised a $30M Series A: Read our story

FOSSA OverviewUNIXBusinessApplication

FOSSA is #5 ranked solution in top Software Composition Analysis (SCA) tools. IT Central Station users give FOSSA an average rating of 8 out of 10. FOSSA is most commonly compared to Black Duck:FOSSA vs Black Duck. FOSSA is popular among the small business segment, accounting for 43% of users researching this solution on IT Central Station. The top industry researching this solution are professionals from a computer software company, accounting for 27% of all views.
What is FOSSA?
Up to 90% of any piece of software is from open source, creating countless dependencies and areas of risk to manage. FOSSA is the most reliable automated policy engine for legal teams to maintain license compliance, security to fix vulnerabilities, and engineering to improve code quality across the entire software supply chain. As the only developer-native open source management platform, FOSSA fully integrates with your existing CI/CD pipeline to provide complete visibility and context earlier in the software development lifecycle. For the first time, teams can collaboratively shift left and audit, analyze, control, and remediate license issues and vulnerabilities right in their existing workflows.
FOSSA Buyer's Guide

Download the FOSSA Buyer's Guide including reviews and more. Updated: November 2021

FOSSA Customers

AppDyanmic, Uber, Twitter, Zendesk, Confluent

Pricing Advice

What users are saying about FOSSA pricing:
  • "FOSSA is not cheap, but their offering is top-notch. It is very much a "you get what you pay for" scenario. Regardless of the price, I highly recommend FOSSA."
  • "Its price is reasonable as compared to the market. It is competitively priced in comparison to other similar solutions on the market. It is also quite affordable in terms of the value that it delivers as compared to its alternative of hiring a team."

FOSSA Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Brett Fattori
Manager of Open Source Program Office at a financial services firm with 5,001-10,000 employees
Real User
Top 5
Compatibility with a wide range of dev tools, web and "C-type", enables us to scan across our ecosystem, including legacy software

Pros and Cons

  • "The most valuable feature is its ability to identify all of the components in a build, and then surface the licenses that are associated with it, allowing us to make a decision as to whether or not we allow a team to use the components. That eliminates the risk that comes with running consumer software that contains open source components."
  • "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."

What is our primary use case?

We use it to scan for all licenses, to identify the open source licenses that are found, to identify licenses that are unknown or unrecognized so that we can deal with those, and we use it to make sure that our client-facing apps are compliant with open source licensing requirements.

How has it helped my organization?

I would rate FOSSA's compatibility with a wide range of developer ecosystem tools as quite high. It covers all of the popular languages that are used in software development today, which is mostly centered around web development. But it also has the ability to work with what I like to term as "traditional development," those things that are done using the C-type languages, like Objective-C, C itself, or C# for .NET — languages that compile into an application. I'm glad that they also support that. Their support for all of the ecosystem is pretty high. This compatibility is very beneficial to our open source management operations in that we have been able to handle the various shades across the organization. We've been in trading since 1975, and our software has been evolving since then. We have a lot of legacy stuff that falls into the areas of scanning that might be more complex, and FOSSA handles it quite well.

Also, because of their policy engine and because of the ability to flag licenses, there is improved awareness in our organization of the licenses that our software contains and what the different requirements are of those licenses. It has raised awareness and understanding of when certain licenses are more problematic than others, because of the way we integrated it into our processes.

In addition, FOSSA has decreased the time our team spends on troubleshooting because it identifies the issues, surfaces them, and brings them to my attention in several ways. It has definitely simplified things. It's hard to quantify how much time it has saved because I really had not been doing this in the absence of FOSSA. I haven't got anything to compare it to. 

What is most valuable?

The most valuable feature is its ability to identify all of the components in a build, and then surface the licenses that are associated with it, allowing us to make a decision as to whether or not we allow a team to use the components. That eliminates the risk that comes with running consumer software that contains open source components. It allows us to be ahead on that so that we are in compliance with open source rules, so that our company is seen as a good steward of open source.

We also like their policy engine because it is very simple in that it is a "red, yellow, and green" mechanism, like a stoplight that everybody's familiar with. Red to deny, yellow to flag, and green to approve. We found that to be in direct correlation with how we were viewing licenses. We've added a couple of policies since then that are not covered in FOSSA directly, but their policy engine has been flexible enough to allow us to accomplish adding what we call "white licenses." That means they have no color assigned yet because we've never seen them in our ecosystem. We have a way, through FOSSA, to identify those using the API, which extends the policy engine for us. It does the same for "black licenses," licenses that we just flat out deny.

And because of the way their policy engine works, its accuracy is fairly high. It identifies multiple licenses on some components and makes a decision for us. It would be beneficial to be able to affect some of those, twiddle some knobs and change some dials in the background for how those are handled, but for the most part, it works all-around.

What needs improvement?

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.

For how long have I used the solution?

I've been using FOSSA for three years now.

What do I think about the stability of the solution?

It's quite stable - but when it's running on a single instance, it can become overloaded quickly if there's a lot of projects being scanned. We've been talking, for quite some time, about deploying it to a cluster so that it can handle the load. 

It's good at what it does. But you have to put together a good plan for deploying it at scale along with your applications that are being scanned, to handle that kind of load. That's something that you have to plan for from the beginning. For us, because things were still evolving, we couldn't really plan for them. We had to adjust as we went.

What do I think about the scalability of the solution?

FOSSA enables us to deploy software at scale. We have been using it in an automated scanning process since the very beginning. We've made several tweaks to it throughout, but we're now at a point where, daily, we are scanning upwards of 800 commits, successful builds that are done in our system. It has scaled quite well, and we're now rolling out applications into cloud environments using Pivotal Cloud Foundry and it is functioning quite well with that as well. 

We are also looking to scale its capabilities by deploying it into a cluster so that it can handle the amount of requests and other API functions that get hit on a daily basis.

They have worked extremely closely with us to get it deployed on Kubernetes. From what I understand, we've been helping them to test it. We were at the beginning of it and they're on the cusp of making that a regular part of their solution. They have worked with us and made it very simple to install. We installed Kubernetes, and installed Rancher to manage it. Using Helm Charts, FOSSA created a deployment for us that made it easy to roll it out to the cluster and scale it as needed, using Rancher. It's scalable, but we're just getting to the point where we can deploy it to production. There are still a few steps remaining before we can launch, full-time, on the cluster.

We have a bit of an issue getting individuals to use FOSSA, because we don't provide a consistent experience to all of the projects through FOSSA. There are still little differences between the ecosystems that have to be touched upon. We do a "white-glove" treatment before we roll it out to the teams. It's been growing as we get projects into a steady state where it's approachable by developers. Before it hits that steady state, I wouldn't want to put it in front of the developers because there would be too many questions on their end that would make them walk away from it before they used it. There is some license work that needs to be done before we communicate it to the developers, but that's because we want to provide a consistent experience. It's not an issue with FOSSA - rather, we want to make it so that a developer on one team feels the same as a developer on another team, when using it.

How are customer service and technical support?

Their technical support is good. They have been the most responsive company that I have ever worked with in my 28 years of doing software development. They are an understanding company. They are listening to my needs and they are willing to implement features that are, maybe, more useful to our company than to other companies, while always looking for how they could apply those features more generally. Because they're looking to grow their platform, I find them more willing to work with me. So overall, their technical support is fantastic.

Which solution did I use previously and why did I switch?

We did not have a previous solution.

How was the initial setup?

The initial setup was straightforward. There were some growing pains because when we adopted FOSSA it was still a "zero dot" version. It wasn't even the official 1.0 release yet. But it has grown with us.

It was very straightforward in that it was a simple Docker installation. All I needed was a machine to run it on. Making the connections within the organization, because of the way we're structured, was a little difficult to implement. The installation and integration, overall, were very straightforward.

The initial deployment of it, from the time of installing it to the time where we were productive with it, was about six months, but that was because we had to figure out the internal connections within the organization to get the data we needed to be operating properly. It was not really an issue with FOSSA. FOSSA needs certain information and figuring out those linkages took some time.

Our strategy, initially, was to go after projects that run through our software pipeline, and then we would approach the ones that were not involved in the software pipeline. But as we worked through the process, we found that there was more of a mandate to make things a part of the software pipeline. As a result, we stepped away from looking at things that were not a part of that software pipeline unless they were our client-facing applications, like our mobile applications. They're not built through our pipeline, they're built separately. Although we started out looking at it in terms of ones that are in the pipeline and ones that are not, we then said, "We'll just go with the ones that are in the pipeline," because eventually the ones that are not will be in the pipeline. Then we would only have to focus on the ones that will never be in the pipeline, which greatly simplified our deployment.

What was our ROI?

We have definitely seen return on our investment with FOSSA. We are at a point now where we are starting to see trust in the open source program office. We're seeing developers reach out to the open source program office because they see what's in FOSSA and they want to be more aware. They want to be more cautious, but they also want to know what's available to them. Using FOSSA to surface the information has brought more awareness to our developers of what's going on in the software they're creating. That awareness is bringing more understanding of open source and its impact on our software.

What's my experience with pricing, setup cost, and licensing?

Consider the cost of the product and what it provides in terms of your developers. We looked at the pricing schedule at the time, per developer seat and tried to understand what a developer was. The fixed seats didn't line up with what we thought actual usage could be. It's always a razor's edge when trying to convince upper management of the usefulness, while trying to justify the overall cost.

When we evaluated our intended usage, we determined that our actual developer count was best represented by the number of developers that are making commits to projects being scanned by FOSSA during a 30-day window. Historically, how many developers have committed code to projects that are being tracked by FOSSA? We decided that those developers would need access to FOSSA, and we monitor for increases based on seasonality, as we hire or renew contractors, to determine what our average would be for licenses.

Using this method we were able to determine the number of licenses we would need, and adjust later based on projections. We continually monitor our usage, which rises and falls periodically, but we average right about the number of actively, engaged developers we're licensed for. Being able to agree on something that can be calculated, that was backed by hard numbers, as opposed to just guessing how many developers would actually be engaged and using it, was something that management could get behind.

Which other solutions did I evaluate?

We did evaluate some alternative platforms before we got into this. We looked at Black Duck and we looked at FOSSology, which I believe is an open source solution, and we looked at FossID as well.

With Black Duck, I didn't like the fact that features we were requesting, that we thought were necessary for our implementation strategy, would be thrown into a pool of ideas and their developers would pick and choose among those ideas. Whereas FOSSA immediately worked with us. In fact, before we had even bought anything, they had implemented a solution for what we needed. The fact that they went ahead and did it before we signed a licensing agreement with them, was fantastic. Black Duck did not want to do that kind of thing and I think that was because they're just so big.

FOSSology is open source, and far from complete. We could invest our time in making it do what we needed, but the chances of getting that done in our time frame was slim to none. 

FossID was a brand new solution, even newer than FOSSA at the time, and didn't have what I considered to be a cohesive business plan for their product. While providing scanning and reporting, it lacked a homogenous interface and seemed overly complex to use.

What other advice do I have?

My advice would be to understand your software development environments before you try implementing FOSSA. How does the software move through your system? How does it go from being source code to production software? Through that, you can identify the point where you want to place FOSSA. We did an evaluation and used our software delivery pipeline to identify what should be scanned, and that helped to increase acceptance.

Others will understand better, once they know their software ecosystem's final, production quality software that consumers are going to use or ingest, that that is what FOSSA is best at doing. If they understand those connection points then they will have a better integration. Knowing what FOSSA can do, where to put it, was the biggest decision that we had to make and the hardest decision we had to make. FOSSA simplified it with their CLI app.

The solution helps me work with both legal teams and DevOps, in a way. However, I still haven't been able to roll out FOSSA for general use by everybody. I don't know how useful it would be for the legal teams because they've already worked with me in establishing policies and then left it with my department to make decisions based on those policies. If there's ever a question about things, we have offline discussions. But they typically don't get into FOSSA because there's not much of an interface there for them, per se. I could see creating an interface that's more targeted at the legal side of things, but I don't feel that is necessary in our situation because I tend to handle the issues that might arise as legal questions. If I need to go further, I will talk to them. I might share some information from FOSSA, but I don't direct them to FOSSA because there's really nothing that I can show them that's going to give them what they need.

The biggest lesson I have learned from using FOSSA is having patience to understand what the teams are using and why they're using it. This is all in the context of the fact that we went from being a company with no open source program office, and a very light policy touch on what was allowed and what wasn't allowed. So it has really been about patience in working with those teams, understanding their needs and FOSSA as a tool they're going to have to work to accept. But it was also important to listen to them so that I could make changes to the way that I had the FOSSA implementation done, to simplify their work. Asking them to do something new was a big ask in their already busy days, so making it as simple as possible was something that I had to figure out and patience is what really made that possible.

When I initially tried to roll out FOSSA, I received a lot of pushback from what I would say is the "old guard" at my company. FOSSA was a company that had only been around for about eight to 10 months at the time. They were essentially a startup. Their CEO, Kevin, is a very brilliant guy. He has a finger on the pulse of the future of open source. Some of their actions and what they've done since I started working with them show that they really understand it. With the old guard of my company, I ran into ageism, where they said, This is a very young company with a bunch of young people. How are they going to know what to do in this particular industry?" That is something that other companies might run into: "Why should we go with a startup over something that's established, like a Black Duck?" The reason you should is because FOSSA is a hungry company, wanting to do good by their customers, and it's a company that cares about what their customers' needs are.

Everybody that I had talked to at trade shows about FOSSA was happy with them as well, it seemed. They had their gripes and their complaints, just like I do, about functionality within the software. But overall, it simplifies our jobs, and others recognize this.

Other companies that are trying to make a decision should be aware they may run into these kinds of issues. FOSSA is now just over three years old. It's still establishing itself against bigger companies. When Synopsis announced that they had acquired Black Duck, I went and looked at what they did as a company - they were into printed circuit boards, hardware on circuit boards, and hardware security. To me, that's a company that has no idea what open source software truly is. They might use it, but do they really have an in-depth understanding of it and the security around it? Just because they did security for PCBs doesn't mean that security in software was going to be a natural fit for them, and I still don't think it is.

Some people stick with what they know, and are unwilling to look at something new. Those people should really give FOSSA a chance because, as a hungry company, FOSSA is going to be willing to work more with companies that adopt them, unlike larger companies. FOSSA is young - they're in tune with what's going on with modern software. Evaluating the newer option was the right choice for us, and for me.

Overall, it's a great product. It's really well organized in its interface and it is targeted towards a manager of an open source program office. Other products I looked at seemed to be more targeted at developer operations. And because I wasn't specifically trying to be DevOps, FOSSA really worked. It really fits in with my workflow.

Which deployment model are you using for this solution?

On-premises
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Patrick Lonergan
Associate General Counsel at Circleci
Real User
Top 5
Provides contextualized, easily actionable intelligence that alerts us to compliance issues

Pros and Cons

  • "FOSSA provided us with contextualized, easily actionable intelligence that alerted us to compliance issues. I could tell FOSSA exactly what I cared about and they would tell me when something was out of policy. I don't want to hear from the compliance tool unless I have an issue that I need to deal with. That was what was great about FOSSA is that it was basically "Here's my policy and only send me an alert if there's something without a policy." I thought that it was really good at doing that."
  • "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."

What is our primary use case?

Our primary use case was for the license compliance. We were doing all the open-source scanning in our CI build using FOSSA. So we would use it, have a step where FOSSA would be installed, and it would scan all the open-source libraries that were being used and then report back on what those licenses were. Then that would match up with policies that we had preset in the FOSSA UI and let us know if there are any license violations with our use of open-source.

How has it helped my organization?

Prior to FOSSA, we were really struggling to get priority using FOSSA to get open-source set up on a repository. We were actually using Flexera before we came to process and we would run a scan on one of our repos and get around 10,000 results and I'm one person and this is a tiny fraction of my job. I didn't know how I was ever going to get through all those results and once I saw what FOSSA could do, we were up and running on a lot more repos much more quickly with FOSSA. It wasn't giving us tons of false positives, FOSSA was just giving us what we cared about. We had presets and it was matching against policies. That was a big thing.

FOSSA provides functionality that allowed you to do public reports as the dependencies you use. So if you were doing attribution for a mobile app, for example, you could iframe FOSSA's report of all the dependencies and use that as the attribution that they require for a mobile app or other distributed software. That was really nice. That was a functionality that put them ahead at the time. Prior to using FOSSA, we would run these scans and we had figured out the tendencies and then I had the engineers implement it in the mobile app with all the lists of all the attributions we needed. If something changed, I would have to have the engineers redo it, whereas with FOSSA, since those reports were constantly being generated every time CI build was run, then that list was always up to date. I didn't have to worry about the engineers updating it or keeping it current if something changed. That was a really nice functionality I liked.

FOSSA provided us with contextualized, easily actionable intelligence that alerted us to compliance issues. I could tell FOSSA exactly what I cared about and they would tell me when something was out of policy. I don't want to hear from the compliance tool unless I have an issue that I need to deal with. That was what was great about FOSSA. It was basically "Here's my policy and only send me an alert if there's something without a policy." I thought that it was really good at doing that.

As soon as I got an alert from FOSSA, I could reach out to the engineers who were working or owned that repo and say FOSSA's telling me that we're using this dependency that's out of our policy or if they can't find a license for the dependency or whatever it was, and it would tell me exactly what the issue was. There's no license on this dependency and then I could just tell them exactly what the issue was. They could look into it and say, "Oh, actually there is a license. For some reason FOSSA wasn't picking it up." Or, maybe the projects dual licensed and FOSSA thought it was GTL, but it's actually GPL and it would be a fee.

I felt that FOSSA told me exactly when there was an issue, what the issue was and then I could work with the engineers to easily figure out if there truly was an issue that needed remediation, or if it was some sort of course in-process tool. The other thing that was helpful is that a lot of times people will come and say "Send me a list. What are all the dependencies that we use on this project?" I could easily generate those reports in FOSSA. I could go in and see where all the dependencies are and if it was a transitive or direct dependency. That's all really nicely done in FOSSA's UI. For open-source license compliance, FOSSA had the nicest UI of any of the products that I looked at. We tried a few. For me on the legal team, that was really what I cared about. 

I would describe FOSSA as being holistic in that it helps us work with both legal teams and DevOps. Our engineers found it easy enough to use. I think a lot of engineers are willing to follow a policy but they're not really interested in being in charge of managing it. They like the fact that they could easily get in the tool and see if there was an issue and that they didn't have to do a lot of tinkering with it to keep it running. That was probably their favorite part about it was that it was easy enough for them to use and help me out, but didn't require a lot of work on their part.

It enabled us to deploy software at scale. It's a huge company. We could keep doing what we were doing and feel that we were in compliance with all of our open-source obligations.

FOSSA also decreased the time our staff spent on troubleshooting. It helped us save time with staying on top of open-source license compliance. Once it was set up, it kind of ran itself. It only reached out to me with an issue when it thought there was one.

I would say it probably saved me on average five or six hours a week. It's allowed me to only spend a few hours a week doing things related to open source license compliance, which I thought was great.

What is most valuable?

The box policy was great. It was very closely aligned. We had multiple policies depending on which code base we were scanning so we had some code that was software as a service and we had some code that was distributed. We had different policies for that. The policy-setting at FOSSA is the number one reason I picked it because the policy set up and having the different policies was so easy and so intuitive. It was really exactly what I needed for what we cared about at my company, what we were looking for, and the checking again as the policy and licensing really meshed well with the way FOSSA did it.

I like that their result set with very tailored. Some other open-source license management things, like Flexera, for example, would do a really in-depth, crazy scan where it gives you 10,000 results and then you have to go through and check which result sets you actually care about and clear the stuff that you're not concerned about it, which was too time-consuming. FOSSA is very tailored. It gives us the dependencies that we know we use.

FOSSA's result set was very tailored to what I cared about. I didn't have to send a whole bunch of time clearing a whole bunch of false positives. I was really the only person on the legal team doing open-source compliance. I didn't have a whole team of compliance people to go through and look at a million potentially false positives. I needed something that would just give me the information I cared about and then tell me if there was a change once I had approved the ongoing list.

In terms of its compatibility with the wide range of developer ecosystem tools, when I was at my previous company, we'd use it with three different CI tools. We used it with CircleCI, Travis, and with Jenkins. It was set up to work the best with CircleCI. I thought it was pretty easy to set up with all three. I think it depended on the complexity of your CI setup. Like Jenkins, for example, which is notoriously difficult to set up, the setup there was also pretty complex.

Overall, I thought it was pretty easy to set up. I did most of the coding myself and I'm not a software engineer anymore but I was still able to figure it out. It was pretty easy, pretty compatible, pretty user-friendly and certainly, for an actual true software developer, not a reformed one, it wouldn't be a problem for someone to set up and use.

It made it so that it was something that even a legal team could set up. It's a one-time setup and then you're just off and running unless you change something or add a new repository you want to do scanning on. It's great. Setting it up in the CI and having it run was one of the appeals. 

What needs improvement?

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.

For how long have I used the solution?

I used FOSSA for a year. 

We had the integration of the field, the FOSSA CLI integration into our CI service, which we were using Travis there. We would just use each build, we would install whatever the current version of the field that client was on.

What do I think about the stability of the solution?

We only had like a few times where we ran into any sort of issue with them having downtime.

What do I think about the scalability of the solution?

The scalability was good. We had no issues with the scaling to our whole organization, aside from just the limits on my time to spend doing it.

I'm not sure how many people were actually using it, but all of the engineers had access. Then there were a few of us on the legal and security teams who all had access too.

I supported most of the engineering team because I was more technical and a more IP-focused attorney amongst other things. I had a lot of relationships with different people on our engineering team at my company. I would reach out to them directly. When we started using FOSSA we were one of the earlier customers. I got to know them, they were a couple of blocks away, and they were really accessible. I would end up reaching out to them via a Slack channel.

Which solution did I use previously and why did I switch?

We also used Flexera. I thought the setup was too complicated and the results weren't focused enough. It wasn't set up in our CI system. You'd have to manually run scans periodically instead of it being run every time that a build was run in CI. It wasn't scalable for us and it was not efficient enough for us with the team size that we had.

How was the initial setup?

The initial setup was straightforward. It depends on how many repos you have, it can be a bit time consuming, at least in the Travis world, only because you have to do it for every single project, this might just be because of how the set up is in Travis. There might be a simpler way, but we spent a decent amount of time getting it set up only because we also had around a thousand repos to set up. It wasn't so much that any individual setup was complicated. It was the number of projects that needed to be set up and that you had to do each one individually. The entire setup took a few months.

There is a simpler setup that FOSSA offers, which is like a more traditional scan where it's not set up in CI. That was set up where it scanned all of our repos. When we very first started with FOSSA, it did that in a matter of a few hours. We had results for all of our projects in a few hours. It was just the actual CI setup part that took a few months.

I had a priority list of things that I cared about. I evaluated the repos that I thought were a higher priority to know where we were. I had a list that I created and worked down from. They were either bigger, distributed projects, or for a variety of other reasons, I might've prioritized them and then just worked down through that list.

What about the implementation team?

We did not use a third-party for the implementation. Although I understand that FOSSA offers professional services to help with implementation, we decided to do it ourselves.

It was primarily me with input from engineers. I had realized that once I had a pretty good idea of how to set it up on a Go Project in the way the CI for a Go Project was set up at my previous company, then I could replicate that work. Usually, it would be me working with an engineer who was familiar with that sort of type of project. Then I would just take it from there.

We don't need too many people for maintenance. Depending on what the issue was I would reach out to whatever engineer I thought I needed depending on what the project was, who owned it, what the issue was, and things like that.

All the engineers had access if they wanted to. I don't know how many of them used it.

What was our ROI?

We did see ROI. We had results the very first day that we had set it up. My confidence in what the results were was much higher with FOSSA than it had been with Flexera. I would say that we've had a nice return on investment just from the time spent by our team reviewing the results, plus our confidence in the accuracy of those results.

What's my experience with pricing, setup cost, and licensing?

In terms of pricing, I thought FOSSA was reasonable but slightly more expensive than Flexera if I recall. You weren't having to do IT stuff yourself. I certainly think in terms of time saved, it was more than satisfactory. 

Which other solutions did I evaluate?

We had also looked at Black Duck and that was pretty much it.

My recollection was that Black Duck was a lot like Flexera. It wasn't set up in CI. The results set was too big. Also, the setup was hard. We had to host Flexera. I had to have IT set up an AWS instance that I could then use for the set up of Flexera. It was a lot of work.

What other advice do I have?

It's easy to use, it's easy to maintain, and it saves you time on your open-source license compliance work. I felt like the solution was very tailored for open-source license compliance with their license.

I would rate FOSSA a nine out of ten. There were a few little things that could be improved, but overall for my use case, it was great.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Learn what your peers think about FOSSA. Get advice and tips from experienced pros sharing their opinions. Updated: November 2021.
553,954 professionals have used our research since 2012.
Justin Giannone
Sr. Security Architect at a computer software company with 1,001-5,000 employees
Real User
Top 5
Embedded within the software development lifecycle as close to the introduction of dependencies as possible

Pros and Cons

  • "Their CLI tool is very efficient. It does not send your source code over to their servers. It just does fingerprinting. It is also very easy to integrate into software development practices."
  • "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."

What is our primary use case?

FOSSA provides a command line interface tool, and we always use the latest version of that. It gets pulled down automatically by some scripts that I've written, so we will always pull down its latest version.

We're using it primarily for the free, open source license compliance portion of it. Those scripts that I've built have the ability to be able to fail builds on pull request checks, though we haven't started enforcing that yet. Therefore, we're really primarily using FOSSA as a dependency inventory tool, then our legal team can also review and give feedback to the teams about the licenses that they're using. In the future though, we are planning on leveraging FOSSA for that policy enforcement piece as well.

How has it helped my organization?

It lets legal sleep at night. We have been acquired by a parent company who has a much stricter policy around free, open source dependencies. The fact that we already had FOSSA in place, which had that inventory of the 13,000 dependencies, has drastically eased the discussions that we've needed to have with them. This is sort of tangential, but the reason why they're so much stricter than us is because they are traditionally not a SaaS-based company. Their software tends to be installed on-prem, which means that the free, open source license compliance piece becomes a much touchier subject for them.

Any license type that is not categorized in either a denial, review, or approval state. This also ends up bringing up an alert that says, "Someone's using an uncategorized license. Should we add this to the approved or denial list?" I believe that those get applied across the entire organization. This functionality helps us identify the violations, then legal can come in and review as to whether or not there's action that needs to be taken. Recently, I've seen some back and forth between our legal team and FOSSA about improving this functionality.

FOSSA helps the legal team interact and communicate with the engineering teams who are introducing the dependencies, which is all part of DevOps. In the context of DevOps, it absolutely helps in their communications with legal.

What is most valuable?

It is a combination of both features and the perspective that FOSSA tries to take, which is sort of different than a lot of their competitors. The main feature and perspective that they take is their desire to be embedded within the software development lifecycle as close to the introduction of dependencies as possible. That has allowed us to build these checks and FOSSA execution into the pull request checks that run automatically whenever an engineer opens a pull request to introduce new code changes into a code base.

The solution’s compatibility with a wide range of developer ecosystem tools is incredibly easy to use. I've written a handful of scripts to even ease that process even more. It is at the point where, in order for one of our teams to integrate FOSSA into their development process, it requires them to add essentially two commands to their pull requests check pipeline. That builds in a bit more functionality than the FOSSA command line tool provides out-of-the-box. However, just executing FOSSA can be achieved by adding a single line to a continuous integration pipeline. With all of the various platforms that you can use to build your project, FOSSA is incredibly easy to integrate.

Their CLI tool is very efficient. It does not send your source code over to their servers. It just does fingerprinting. It is also very easy to integrate into software development practices.

What needs improvement?

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.

For how long have I used the solution?

We have had FOSSA for probably two to three years at this point. When we picked up FOSSA, they had only been on the market for roughly a year.

What do I think about the stability of the solution?

There are times, and this is true of any SaaS offering, where they experienced transient issues every now and then. Occasionally, I'll get a team, saying, "My pull request check failed and it's coming up with FOSSA saying that it timed out," or that they're getting a 500 response. I tell them to wait an hour and try again, then I usually don't hear back from them. I would say that it's as stable as any SaaS offering that I can imagine out there. If I was to go and check their API status page, I think I would end up seeing at least 99 percent across the board on their services.

We have had minor downtimes here and there that have been less than a day.

They are just now releasing version 2 of their command line tool. That is the first major update that they have released for the CLI tool.

For maintenance, there's just me from the technical side, and at most, two people on the legal side. I have to add an API key to a CI pipeline when someone new wants to integrate with FOSSA. I don't even know if that would equate to one percent of my responsibilities. We are constantly looking to improve. Therefore, we are actually looking at ways that I wouldn't need to do that. That literally the entire process would just be running that CLI command to generate the configuration file, add that configuration file to GitHub, and add these two commands to your pipeline, then everything should just work. That's in the future, but my responsibilities may even diminish even more.

What do I think about the scalability of the solution?

We have almost 200 projects currently using FOSSA. Those are all built into the pull request checks, and we are planning on extending their use, potentially even up into our parent company as well. I rarely get complaints from teams that their pull request checks are being held up or anything like that. They seem to scale at whatever size we need them to.

The solution enables us to deploy software at scale as a global company. We have probably a few thousand nodes hosting our software in AWS and our private data center. We would not be able to confidently be able to deploy all of this stuff without knowing that we were compliant with these licenses.

The largest set of users is engineering. The teams want to be able to get in there so they can see the results of the submissions, and whether or not they have any alerts that they need to talk to legal about. The next largest, which is a funny word to use for this because there are only two of them, would be the legal team, then there is myself from security. It's going to be interesting to see what users in our parent company want to be involved as well, because I know that they actually have a dedicated intellectual property group.

How are customer service and technical support?

The technical support is fantastic. I have waited, at most, five days for them to fix bugs that we've identified in the CLI tool. They are knowledgeable, can escalate properly, and their turnaround time is excellent.

Their CLI tool is also open source. I have actually had some of our engineers submit pull requests to them to fix bugs that they've not only identified, but figured out a fix for. They are open to merging outside pull requests as well.

Which solution did I use previously and why did I switch?

A lot of competitors that we had tried prior to FOSSA seemed to want to be more of an audit tool, which gets run at the end of a release. Unfortunately, at that point, there is no flexibility or time to correct a policy violation. You're already at code freeze. The team has already validated and tested the build. Now, all of a sudden, you're going to tell them that they have to go in and tear out a dependency. There's no way that you would be able to do that within the timeframe of a release. Whereas, FOSSA wants to come in as soon as that dependency gets introduced. This reduces the amount of work and everything that would need to be done in order to replace that dependency with something else.

Prior to me getting involved with this whole effort, we had been using Black Duck. I believe it was very expensive and we were never able to get it to function the way that we wanted it to. 

When I came onboard and started looking at stuff, we were using a provider called WhiteSource who was not able to fill that pull request check feature that I really wanted because it was slightly tangential. However, I came from an engineering background before coming over to security with about 15 years of software engineering, so I had a very opinionated view of where these checks should be happening. WhiteSource just flat out could not support the use case that I had.

We purchased and tried to use Black Duck before bringing on WhiteSource. I'm not sure how long we had Black Duck floating around for, since that actually predated me. However, I tried to work with WhiteSource for a year in order to try get their offering into the process and add the stuff that I wanted to do. We were completely unable to do it.

How was the initial setup?

The initial setup was straightforward. They made it so easy to run and submit a build to their platform. In order to set up a configuration file, it's running one command out of the CLI tool, then submitting it; you run a build and do all the fingerprinting, then submitting all that data up to the FOSSA platform is just one more command with the CLI tool. They streamlined everything behind the scenes for us.

We are still rolling it out to teams who have not adopted FOSSA, e.g., if we have a new project, then we ask them to set up FOSSA for their project. I literally tell them that it's less than an hour's worth of work. If your guy is working, and he's telling you that setting up FOSSA is taking longer than an hour, you should probably have him come talk to me, because he's doing something wrong. When people start pushing back, and they're like, "Oh, we don't have time to put FOSSA in." I'm like, "It takes less than an hour. You have time to put FOSSA in."

We are going to need to reevaluate our implementation strategy as we work more with our parent company. Now that we have exposed them to FOSSA and the way that we've been using it, they're interested in adopting FOSSA themselves, and they are a far larger organization than us. 

What about the implementation team?

I was part of the PoC, initial setup, and everything since then.

What was our ROI?

It is not a moneymaker. It's more of a compliance tool. It helps legal sleep at night, so to the extent that our legal team is better rested, we've seen return on investment.

There is no way that we would be able to manage the volume of open source licenses that our organization uses without using a tool at least similar to FOSSA. Off the top of my head, we have somewhere around 13,000 unique dependencies identified in FOSSA today. That is with some projects not quite being properly configured as well. We expect that number will likely go up to 15,000. Just trying to maintain anything with that volume using a manual process is impossible.

What's my experience with pricing, setup cost, and licensing?

FOSSA is not cheap, but their offering is top-notch. It is very much a "you get what you pay for" scenario. Regardless of the price, I highly recommend FOSSA.

Which other solutions did I evaluate?

I poked around at other options. Granted, this was two or three years ago. So, I only remember the guys who sort of stuck out in my mind, like SonarQube. 

Because we're also a SaaS company, it's good to eat at least some of your own dog food. We ended up going with the SaaS offering. This also means that there is less maintenance on our side, since the SaaS offering gets updated automatically. We don't have to worry about making sure that those nodes are up and running within our infrastructure, and our infrastructure guys don't have to worry about maintaining them.

I know that FOSSA would love if we did use the solution’s security/vulnerability management features, but the organization is going in a different direction. We're going to end up going with the GitHub Dependabot offering. This is mainly because all of our source code is already in GitHub, who has automated a lot of those checks, even the remediation. They have kind of automated the non-vulnerable already, and just keeping all of that information in one place is also beneficial rather than spreading it around multiple tools.

If FOSSA did the automated piece that GitHub has Dependabot doing where Dependabot identifies one of your dependencies as being vulnerable, then they will automatically open a pull request upgrade that package to a non-vulnerable version. If FOSSA can introduce something along those lines, then I would be more interested in their vulnerability and security management piece. The other thing I would say is that GitHub offers the Dependabot feature at no additional cost, which is also a very significant selling point that I think FOSSA would have a very hard time competing with.

What other advice do I have?

With my engineering background, I was supporting legal from the technical side of things in order to get the processes and checks embedded into the development process. The accuracy of the policies and checks was handled by the legal team.

I recommend taking a look at, or at least considering, the approach that I took, where I wrote some scripts to automate the steps within a continuous integration pipeline. We've actually open sourced the scripts that we used. They're on GitHub. While the FOSSA CLI tool is fantastic, there tends to be a bit more functionality that you need to build around it that's a little more specific for your organization, and scripting works well for that.

Biggest lesson learnt: There's a tool out there that does free, open source license compliance that wants to come in and be part of the software development life cycle early, i.e., as soon as the developer introduces a dependency. 

Before I found FOSSA, and after my experience with WhiteSource, I thought that I was going to have to write my own solution, which would have been a nightmare because I'm not a lawyer and don't know necessarily how to parse nor understand all these licensed languages. It was a huge undertaking, and I'm one person. Now, since I'm technically not on the engineering team, it's very difficult for me to get engineering resources beyond myself.

One of the features that FOSSA has on their roadmap is that they want to provide functionality before a developer ever introduces a dependency, so they can sign into FOSSA, run a search, and find out whether or not that dependency is going to violate policy. Just being able to move those checks earlier into the development process saves a ton of development work and time.

I would put FOSSA as a solid eight out of 10. Nothing is perfect. There is always room for improvement. However, they are a fantastic tool and an incredibly responsive organization.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
GY
Sr. Director of Open Source at a comms service provider with 10,001+ employees
Real User
Top 10
Integrated into our build pipeline and automatically scans for compliance, giving us confidence problems will be caught

Pros and Cons

  • "I found FOSSA's out-of-the-box policy engine to be accurate and that it was tuned appropriately to the settings that we were looking for. The policy engine is pretty straightforward... I find it to be very straightforward to make small modifications to, but it's very rare that we have to make modifications to it. It's easy to use. It's a four-category system that handles most cases pretty well."
  • "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."

What is our primary use case?

The primary use case for FOSSA is that when we build mobile applications — we have a few dozen mobile applications that we build — the build script calls FOSSA automatically and determines through the FOSSA scan what licenses are being used in the dependencies, and it determines if they comply with our policies. If they don't, it notifies that there's a problem. If they do, it generates information that we turn into a report that we then use to disclose what licenses we're using in our product. 

There's a secondary use case, which isn't about mobile apps but about looking at code in general and running it through FOSSA to see what it can find, but that's a very rare occurrence. Most of the time we're just automatically scanning mobile apps

How has it helped my organization?

FOSSA is at the heart of the license compliance part of our open-source management program.

We have an obligation to comply with open-source licenses on our products. Anyone in the business of distributing products has a certain obligation, and our job is to meet that obligation as best we can without spending too much time or money to do so. We're trying to efficiently ensure that we're doing the right thing, and FOSSA enables us to do that. 

And since we've been able to integrate FOSSA into our build, it's not something that we have to run as a separate step after the fact — and even allow people to circumvent if they're really busy and they're rushed and they want to jump past and not do it. They can't. They can't avoid it. It's part of our build process. As long as people are building software using our build pipeline, which they have to, we automatically scan for compliance, and that gives us a tremendous amount of confidence that if there's a problem we'll catch it.

There are two risks when it comes to compliance. There's the risk that you do the wrong thing, but the bigger risk is that you didn't know that you're doing the wrong thing. If you don't know that there's a problem, then you think there isn't a problem until you find out.  FOSSA makes sure that we're looking at everything. We also have to do the right thing, but that's on us, and FOSSA makes it easy to do that too. The fact that we've integrated it into our process so it automatically runs means that we're confident that we're not missing the compliance step.

The solution is comprehensive. It does what we need.

It allows us to deploy software at scale. We have a CI/CD pipeline and build many mobile apps, many times a day. That means dozens of mobile apps, and we deploy them frequently. We deploy more mobile apps than most companies in the world do. We're one of the larger providers of mobile apps in terms of the number of apps and the number of apps that we deliver them to. Ours is a fairly high-scale operation, and FOSSA is part of the build of all of it.

In addition, it has significantly decreased the time our staff spends on troubleshooting. I can't approximate by how much, because prior to FOSSA, we didn't really have an effective troubleshooting process. It was hard to manage because there was a lack of process. We did it when we felt we had to do it. FOSSA gave us a regular process, and what that did is allow us to predict how much time things take.

What is most valuable?

I view FOSSA as a singular tool, not really one that has components, so it's hard for me to say that there's a valuable feature. FOSSA, to me, is something that scans, and it determines what you have and if there's a problem. But if I were to call it a feature, the most valuable would be the deep dependency scanning.

If I were to use another tool that scans source code but not during build-time, one that just scans the source code as a static thing, then it would tell me what it thinks goes into my mobile app. But when I use FOSSA, and it scans during the build, it tells me what actually goes into my mobile app. I believe it's a more accurate way to determine what's in my code, because it not only tells me what my code says should go, but it tells me what actually goes during the build. When the build pulls artifacts from an artifact store, FOSSA detects that happening.

I found FOSSA's out-of-the-box policy engine to be accurate and that it was tuned appropriately to the settings that we were looking for. The policy engine is pretty straightforward. When it comes to licenses, there are always very strange cases that no policy engine can predict, so those happen once in a while. But for the most part, in terms of an automated policy engine, I find it to be very straightforward to make small modifications to, but it's very rare that we have to make modifications to it. It's easy to use. It's a four-category system that handles most cases pretty well.

The way we've set it up, it's compatible with our build and packaging system, and that's all we need it to be. So it's perfectly compatible.

The solution provides us with contextualized, actionable data, but I wouldn't call it "intelligence." It gives us a signal which says, "We have found a violation." As an analogy, data tells you what the temperature is outside. Intelligence tells you that the temperature is so cold that you have to wear a sweater, and wisdom is to know that you can't wear a sweater over a coat. Those are different. So FOSSA gives us data. It tells us there's a problem. It doesn't tell us much about how to fix the problem. It tells us where the problem is, but it doesn't give us intelligence. It gives us data. It provides us the signal of the problem and the component that is causing the problem, and allows us to inspect that component to see if it really is a problem.

What needs improvement?

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.

For how long have I used the solution?

I've been using FOSSA for about two years.

What do I think about the stability of the solution?

We have a problem no more than about three or four times a year. Relatively speaking, it's very stable with very few incidents. We do have a few. Every so often there's a problem and we have to reboot or do something else, but it's rare.

What do I think about the scalability of the solution?

We've been able to scale the solution to meet our needs.

How are customer service and technical support?

Their technical support got better. Initially, it seemed that our demands exceeded their capacity. When we started, they were a smaller company, and we just had more demands. They eventually staffed up and provided a better route for receiving requests and tracking the time to resolve those requests. So initially it was a little slow. We understood that, and then it got better.

Which solution did I use previously and why did I switch?

We used Black Duck Protex. We switched to FOSSA because we found that FOSSA addressed our use cases better than Black Duck was able to. When we got Black Duck, it was before we were doing mobile apps, and the nature of scan was different. We weren't scanning during build, we were scanning large repositories. As our business shifted to a mobile business, we found that we really needed to scan during build. We weren't able to do that with Black Duck and we were able to do that with FOSSA. Black Duck provides the capability, but we weren't able to get it to work the way we needed it. FOSSA looked like it was going to be better for us — and FOSSA actually costs us more money.

How was the initial setup?

The initial setup  was relatively straightforward. They gave us the hardware specification and we were able to set up the server. They were able to set up pretty quickly. The initial setup was pretty good. I've seen much harder setups, relatively speaking. It wasn't plug-and-play, because it was an internal install, but it was actually quite good.

From the time that we wanted it up and running to the time that it was up and running was probably a week or two, but that was largely because of delays on our end. Reality is complicated. Their process was pretty straightforward; it took two days. But our process took about two weeks.

They helped us with an implementation strategy. Our experience with their staff during deployment was favorable and positive. They were very good. They were motivated to help and they did a great job. We didn't have any incidents.

What was our ROI?

We have seen ROI because, at the end of the day, we're getting the value we needed. With Black Duck, we weren't really getting the value. We weren't able to get what we needed out of that tool.

What's my experience with pricing, setup cost, and licensing?

I don't love the license model where FOSSA charges per engineer, given that we don't really have engineers who use FOSSA. The method that we pay by, the metering that they use, is based on a mode that doesn't make sense to us. We pay for some number of engineers. Well, only one engineer uses it, and we're not paying for one engineer, because that's not fair; we use it for dozens of projects. So the method by which it's determined what to pay doesn't make sense. 

The amount that we pay, we pay. We're okay with it. We've negotiated a price that works for both parties, so that's not an issue.

Which other solutions did I evaluate?

We had a good relationship, and I was very familiar with Alameda. We looked at WhiteSource, and we looked at FossID and at two other small ones that never really made it into the market. They were startups that were trying to get in.

There were two reasons that we chose FOSSA over these other vendors. One was because it met our use cases. And the second was because I believed in the direction of the company. I was impressed with Kevin, and I believed that this was a company that would either meet our needs today or would be meeting our needs as our needs changed. FOSSA, as a company, was going in the direction that we, as a company, were going. Whereas, some of the other vendors that compete were going in a different direction and were solving problems that I was having less of and were ignoring problems I was having more of. I believed in their long-term prospects less, and believed in FOSSA's long-term viability more.

What other advice do I have?

Focus on those applications that pose licensing risks. I don't believe that one needs to use FOSSA to scan everything. You need to use FOSSA to scan products that you distribute to third-parties.

The biggest lesson I have learned using the solution is that command-line integration is the most important part of a scan tool.

We don't really have "users" using it. There's really only one person who does most of the work around FOSSA and everything is automated. Very rarely does somebody go into the tool and do anything, but we have many apps that are scanned with FOSSA. The one person who goes into it is one of the mobile build engineers and he is responsible for the mobile build process, which includes FOSSA scanning.

We do not use FOSSA's security or vulnerability management features yet. We want to. We know that that was recently released, but we haven't enabled them on our internal build yet.

There's opportunity for the solution to grow. There are things that it needs to do that it doesn't yet do. There are things it does that I'm satisfied with. I can't give it a 10 because there's opportunity to grow, so this is really less a measure of the product and more a measure of my expectations for the product. I'll give it a favorable eight, because it does what I need it to do, but I need it to do more as well.

Which deployment model are you using for this solution?

On-premises
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
CL
Data Privacy Officer at a healthcare company with 51-200 employees
Real User
Top 20
Reduces our costs and timeline and allows us to go very granular and automate the scanning of licenses

Pros and Cons

  • "One of the things that I really like about FOSSA is that it allows you to go very granular. For example, if there's a package that's been flagged because it's subject to a license that may be conflicts with or raises a concern with one of the policies that I've set, then FOSSA enables you to go really granular into that package to see which aspects of the package are subject to which licenses. We can ultimately determine with our engineering teams if we really need this part of the package or not. If it's raising this flag, we can make really actionable decisions at a very micro level to enable the build to keep pushing forward."
  • "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."

What is our primary use case?

I lead the legal team at my organization, and we use FOSSA largely in partnership with our engineering teams. We use FOSSA for open-source software licensing scans and diligence.

We are using its latest enterprise version.

How has it helped my organization?

It has reduced the time that we used to take to go through the internal review and the diligence of a build and then push that build to be live on production. It has not only reduced the time; it has also reduced some of the pain points to make us more operationally efficient. It has allowed us to scale up our engineering efforts in a way that enabled us to push multiple builds for different product features and create more agency for those teams. From a timeline perspective, we've had it for two years, and our baseline prior to that was very narrow, but it has significantly reduced the time taken for a more complex build with diligence reviews from maybe two or three weeks to almost instantaneously. Of course, the second component to the timeline reduction is that we also don't need to staff someone to conduct those reviews. They are automated through FOSSA.

Its actionable intelligence helps with triage. It doesn't do recommendations, but it highlights those issues so that I and my team can move them on very quickly and ultimately unblock those issues for our engineering teams. It doesn't make recommendations per se, as far as I know.

It contextualizes the specific license that maybe has an issue or that is approved or rejected in a package. It contextualizes that within the package and the other licenses that are in play. So, it allows us to isolate that portion of the package and make a decision if the license was rejected or flagged. It allows us to make the decision on the package to say, "This piece of it, do we need it or do we not?" We can then move forward.

I do find the license solution of FOSSA very holistic in terms of collaboration between the legal teams and DevOps. We don't use the security solution of FOSSA, so I can't speak to that, but I would agree wholeheartedly that it's a very holistic tool for both teams. It has enabled us to build out a process that removes some of the typical pain points between an R&D team and the legal team when it comes to third-party license scanning. One of the pain points is often timing and how long it takes to typically do these reviews manually. FOSSA does them near instantaneously. The second pain point is around isolating issues. I can't even imagine how long a manual review of a package would take, and fortunately, we haven't had to do that manually because FOSSA does that for us. From a relationship standpoint, it has removed some of such pain points between the legal and engineering teams to allow us to work faster and smarter and ultimately push new features and projects to production in a more efficient way.

It 1000% enables us to deploy software at scale. Our engineering teams are constantly working on new builds. They're scaling those builds out and upwards, but the legal team is fixed. So, we leverage technology like FOSSA to be able to scale up our legal operations, meet the engineering teams' needs, and keep track with them without having to bring in an additional FTE to manually do some of the work, which would be required if we didn't have FOSSA. It helps us reduce our costs, and it also reduces the timeline to better support the engineering teams.

It has absolutely decreased the time that our staff spends on troubleshooting. It is difficult to know how much time it has decreased because it has been so long since we've had FOSSA, and it is hard to remember those baselines. If I were to estimate based on the number of projects that we have in play from the engineering teams, it has reduced our demands on the team by probably 80 hours on a quarter by quarter basis, if not more.

Because of being on the legal side, I'm less familiar with its compatibility with the wide range of developer ecosystem tools, but our engineering teams use FOSSA for their builds and for pushing them out to production. So, from my understanding after many conversations with them, FOSSA makes it much easier and more efficient for them to make their builds and then ultimately get to the production phase.

What is most valuable?

FOSSA has a feature that allows you to automate the scanning of licenses. You can do that by setting up different policies that are custom-tailored for your organization, which in my case are legal policies or intellectual property policies. These policies are used to scan the open-source licenses and flag them, approve them, or reject them based on your company's preferences. One of the things that I really love about FOSSA is the way we can take what would manually require probably hundreds of hours of individual review and automate that through this platform.

In terms of ease of use and accuracy of its out-of-the-box policy engine, it is certainly very easy to use. It is also very accurate. There were some things that we custom-tailored based on our risk appetite and our internal policies related to intellectual property. The out-of-the-box policies were great, but we just slightly tailored them for what we needed for our use case. The majority did not need tailoring, and across the board, all of the policies that were out of the box were consistent with the decisions that I would have made in the absence of internal policies that I had to be mindful of.

One of the things that I really like about FOSSA is that it allows you to go very granular. For example, if there's a package that's been flagged because it's subject to a license that may be conflicts with or raises a concern with one of the policies that I've set, then FOSSA enables you to go really granular into that package to see which aspects of the package are subject to which licenses. We can ultimately determine with our engineering teams if we really need this part of the package or not. If it's raising this flag, we can make really actionable decisions at a very micro level to enable the build to keep pushing forward.

What needs improvement?

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.

For how long have I used the solution?

I have been using this solution for about two years.

What do I think about the stability of the solution?

It is very stable. We have not experienced any downtime.

What do I think about the scalability of the solution?

It scales very well. One of the things that I love is that the engineering teams have been able to load more and more projects into FOSSA and build out their pipelines. FOSSA also has integrations with Slack, and these integrations enable FOSSA to notify and push notifications on Slack after a scan has been completed and the issues have been identified. That's very helpful from my perspective and from a team's perspective because it creates visibility. It also enables me to not spend all day every day in the FOSSA platform. Instead, I only need to go in when I receive a notification.

In terms of its usage, it is adopted a hundred percent in our company. In terms of users, there are two people from the legal team who use FOSSA. Largely, the entire engineering org uses FOSSA in one way or another, and its users range from the Chief Technology Officer, who oversees the engineering team, to director-level people in the engineering team. One in particular who uses FOSSA a lot and with whom I partner is the director of platform and security at my organization. There are others as well, such as individual engineers, engineering managers, and our security manager.

How are customer service and technical support?

When I couldn't find the answer to a question that I had, I was able to turn to our customer success manager who then was able to connect me. We jumped on a Zoom call with probably one of their platform engineers. Three of us were then able to recreate the issue and work through it together. On top of that, they were able to help me anticipate future issues on that point and how to navigate them. It was a near-term troubleshooting solution and a long-term way to work more efficiently. They're responsive and knowledgeable.

Which solution did I use previously and why did I switch?

We didn't use any solution previously.

How was the initial setup?

I don't know if its initial setup was complex or straightforward. I was a part of the initial setup, but I wasn't the primary owner of the initial setup. I was a stakeholder who was consulted and ultimately would become the primary owner, but I wasn't a part of the actual setup piece. Eventually, the setup was transitioned over to me where I took full ownership. 

I don't have a whole lot of visibility on the number of hours per se, but I remember from the time of purchase to the time we stood it up, it was relatively quick and brief.

What was our ROI?

FOSSA is well worth the investment. It is an opportunity to scale your operations, especially for a legal team to maintain pace with your technical teams, especially your engineering teams, in a cost-efficient way. Instead of using a platform like FOSSA, the alternative might be to hire one or two FTEs where their full-time role is to manually scan the open-source licenses. If you were to do that, you have an additional cost, additional overhead, and additional risk. With something like FOSSA, you have something that's easily auditable, easy to roll out of the box, and easy to scale. It's a no-brainer.

The auditability is critical. There have been a handful of conversations that I've had with Enterprise customers at my company where they've requested reports related to open-source compliance and dependencies. If you were to pull this data manually, it would probably take months to track down the data, verify it, and generate the report for a single build, whereas FOSSA does that almost instantaneously through the platform. It produces an auditable record that you can then share with customers and investors as you're going through a diligence exercise.

What's my experience with pricing, setup cost, and licensing?

Its price is reasonable as compared to the market. It is competitively priced in comparison to other similar solutions on the market. 

It is also quite affordable in terms of the value that it delivers as compared to its alternative of hiring a team.

Which other solutions did I evaluate?

We did explore and had demos of other solutions. One of the solutions was WhiteSource. I wasn't involved in the ultimate decision-making process. I was, sort of, consulted, but I was not ultimately involved. I think it came down to the platform itself in terms of usability and the support for our use cases. That was the tipping point.

What other advice do I have?

I would rate FOSSA a nine out of 10 in terms of efficiency, scaling, and speed. I would rate it a 10 if the documentation to really get into advanced features was more widely available. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
BG
Attorney at a legal firm with 11-50 employees
Real User
Top 10
The data provided makes it really easy and effective to determine the source of the license or security concern

Pros and Cons

  • "The most valuable feature is definitely the ease and speed of integrating into build pipelines, like a Jenkins pipeline or something along those lines. The ease of a new development team coming on board and integrating FOSSA with a new project, or even an existing project, can be done so quickly that it's invaluable and it's easy to ask the developers to use a tool like this. Those developers greatly value the very quick feedback they get on any licensing or security vulnerability issues."
  • "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."

What is our primary use case?

Our use cases are for handling incoming open-source software for high speed or agile development that our teams are doing. We also use it for looking at security vulnerabilities in real-time as they're doing their daily builds. It helps to compile distribution acknowledgments or the open-source acknowledgments that need to go out with any distributions.

How has it helped my organization?

Although it's a little too early for any metrics or data, it has improved my organization through its ability to apply legal and security policies in an automated fashion to a very large volume of open-source components. All of its associate transitive dependencies are invaluable and alleviate so many legal resources to work on higher risk or higher-profile issues that need guidance.

FOSSA absolutely provides contextualized actionable intelligence that alerts us to compliance issues.

The user interface is incredibly straightforward and the communication that's provided to the developers or the project managers and legal team is clear and concise and allows either an attorney, a developer or a manager to take a look at their project and see where the security vulnerability and licensing issues come from. You can quickly identify the source of those issues, verify whether or not that is an accurate determination by the tool, and then either as a manager or attorney, provide feedback to that team on how to remediate the concern.

It helps with triage and remediation. The data provided makes it really easy and effective to determine the source of the license or security concern. And because it's easy to identify where that's coming from, it makes it very straightforward to provide remediation guidance to the development team.

What is most valuable?

The most valuable feature is definitely the ease and speed of integrating into build pipelines, like a Jenkins pipeline or something along those lines. The ease of a new development team coming on board and integrating FOSSA with a new project, or even an existing project, can be done so quickly that it's invaluable and it's easy to ask the developers to use a tool like this. Those developers greatly value the very quick feedback they get on any licensing or security vulnerability issues.

The out-of-the-box legal policies are very good but I think that they lack thoroughness of some of the unclassified licenses. The accuracy was good, I don't think I had to make any major changes. I would only have to make changes if I were a risk-averse or an incredibly risk-tolerant company. But if you're middle of the road, the out-of-the-box legal policies are pretty acceptable. It probably just needs to classify more of the unclassified licenses in one of the three categories for disposition to get a better starting point for new companies adopting the out-of-the-box policies.

We use the security vulnerability management features. I give the developers a heads up that there might be some published vulnerabilities that they might be unaware of. It's good because it gives them really quick feedback, so if they're doing a nightly build they'd get feedback the next day, or if they're building it right away they might get near-immediate feedback. But we don't have any enforced policies regarding security vulnerabilities, especially for internal or hosted applications. 

The background and information these features provide on security workflows is just integration to the national vulnerability database, so it's limited to the data that's contained in the NVD, which of course is standard industry-accepted vulnerability data. There's definitely room for growth there and actually doing analysis of the proprietary code, but looking at the NVD information as a baseline is certainly useful.

In terms of the compatibility with a wide range of developer ecosystem tools, the interoperability with different developer ecosystems is excellent, and that's actually one of the reasons we chose FOSSA as our enterprise solution. Even if they didn't have out-of-the-box compatibility with a certain build environment or a build pipeline, they were able to get it working with one of them or any of the new environments very quickly. It definitely has industry-leading interoperability for different build environments, which is really valuable to us.

This affects our open-source management operations by allowing for a much greater deal of efficiency. As part of the legal team, having to look at an incredibly large volume of open-source components coming into the company, it was immensely time-consuming and it took away attorney's resources from more mission-critical or more complex responsibilities, such as embedded software or any software being distributed outside of the company. Having it as a resource to very quickly triage incredibly high volumes of open-source coming into the company through agile development programs was invaluable.

It is holistic and helps us work with both legal teams and DevOps. It's a great way to help legal and development teams work together by automating a lot of the guidance that gets provided in the more straightforward scenarios like internal development or projects that aren't externally distributed. It's a great resource for having a centralized place for all of the outstanding issues to provide automated, legal, and security guidance to those development teams.

My team is purely legal, but I would say that there's definitely a lot less person power required to address any license concerns as the majority of license questions are resolved in an automated fashion by us populating the license policies in the tool as completely as possible. So the more completely we populate those license policies, the more of that work is offloaded to the tool from my legal team, which is excellent for making more available time where it's more valuably used. 

It has decreased the time our staff spends on troubleshooting by 10 to 20 hours per week where an attorney could have that time then reallocated to something more important.

What needs improvement?

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. 

For how long have I used the solution?

I have been using FOSSA for just under a year. 

What do I think about the stability of the solution?

So far there have not been stability issues, so the stability is very good.

What do I think about the scalability of the solution?

It's definitely scalable although there's definitely some room for improvement when it comes to supporting an enterprise with thousands or tens of thousands of projects. There's a lot of room for improvement developing a bit more detail in groups and teams and being able to filter the projects that have been scanned on the home landing page. But it definitely supports a very large number of teams and projects.

There is a wide range of users who use this solution, including developers, attorneys, security experts, project managers, and just general managers who all have access and look at some of the outputs of the tool.

We're still somewhat early in the rollout being just under a year for being a very large enterprise so the number of projects we've used it for is in the range of a few hundred. For our company, the expected number of projects will be well in excess of probably 10,000 maybe even 20,000. 

We definitely intend to increase usage. The adoption rate across the company is 5%.

How are customer service and technical support?

The support has always been excellent. They communicate in many different ways, be it Slack, email, or on the phone, and they're always able to help us.

How was the initial setup?

The setup process was very straightforward. It was mostly the complexities of our own internal enterprise software policies and data privacy policies that made the implementation a little bit more challenging, but in no way was that FOSSA's responsibility or fault. That were our own internal policies that were relatively strict. But otherwise, I found the deployment in a containerized environment be very fast. It took around one to two months.

We had a three-phase approach for rolling out FOSSA inside of the company. The first one was to bring on the team that was helping us early on throughout the proof of concept stage with FOSSA and some other competitors. Because they were already familiar with it, it was easy to bring them onboard into our newly provisioned FOSSA environment. They already knew what they were familiar with and could provide us immediate feedback if something didn't seem to be working properly. They were development teams at the company that had been doing some POC work with us with FOSSA.

Then phase two was bringing on leaders around the company in different development languages. They may not have been familiar with FOSSA, but they were very competent developers in their respective languages and environments. Bringing them on was phase two. And then phase three was the larger enterprise rollout where anyone who wanted to leverage the tool was welcome.

What was our ROI?

It's still too early to tell for ROI.

What's my experience with pricing, setup cost, and licensing?

Pricing is competitive with some of the other bigger companies, but probably overall middle of the road.

We haven't encountered additional costs.

Which other solutions did I evaluate?

We also evaluated Black Duck as well as Flexera. The biggest pros for FOSSA was the interoperability with different development environments. Being able to support a very wide range of development environments, including older ones, was very important to us as a very large enterprise. We have an incredibly diverse range of build environments, build pipelines, development environments, IEs, all of those things, so having something that supports nearly everything that we had internally was incredibly important. It was also a cheaper alternative. Not cheap necessarily, but it is a more affordable alternative to some of the other solutions out there.

What other advice do I have?

With the rapid growth of the consumption of open-source in development, it was no longer feasible for attorneys to manually review every incoming component on an individual case by case basis. Having a tool to automate the review, both from a legal, but also a security perspective, and provide near-immediate feedback to the developer was critical to have.

My advice would be that if you have a very large volume of open-source that you can apply clear and consistent policies to or you currently do that in a manual process, that something like this is absolutely worth every dollar to be able to keep your teams moving quickly and efficiently. Implementing something like this is definitely worthwhile if someone is on the fence with respect to spending the money to look at the open-source components, both from a license and security perspective in a fast and efficient manner.

The biggest lesson I learned from this solution is that there's a much larger volume of open-source components that might be in your environment that you may not be aware of given the comprehensiveness of FOSSA's scanning of both top-level components and transitive dependencies. You'll learn that there's an incredibly large number of components in your applications.

I would rate it an eight out of ten. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Eric Griswold
Principal Release Engineer at Puppet
Real User
Top 10
Does a good job showing us if we're using open source licenses that conflict with our closed source components

Pros and Cons

  • "What I really need from FOSSA, and it does a really good job of this, is to flag me when there are particular open source licenses that cause me or our legal department concern. It points out where a particular issue is, where it comes from, and the chain that brought it in, which is the most important part to me."
  • "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."

What is our primary use case?

Our major use case is to do open source license compliance. Puppet Enterprise consists of about 90 open source packages under constant development. And it also has some components which are not open source. When we release Puppet Enterprise, we have to make sure that anything that we're relying on is something that we are allowed to use, in an open source sense.

It does do security scanning, which is something that we're interested in and want to do, but we've only been using FOSSA casually for that.

I am the only person really running the FOSSA jobs. I have a FOSSA job that runs daily, that scans all of our important repositories and reports back to me and the release engineering team about what it found. When we go to do a release, we run a report from FOSSA which contains all of the open source licenses in our product and we do a rescan of that to make sure that there aren't any flagged licenses inside of our product. That's our use case.

None of the actual engineers are worried about it. Only when something gets flagged do I contact them and say, "Hey, this license isn't working for us, so we need to find something else."

FOSSA is a cloud project and it contains a CLI component that's open source.

How has it helped my organization?

What we don't want to do is publish our closed source stuff under GPLv3, so we need to make sure we're not using any GPLv3 inside of our product. FOSSA does a good job of showing us if we're using licenses from the open source world that conflict with our needs for our closed source components.

Prior to a Puppet Enterprise release, it would take approximately two to three weeks of dedicated engineering time by a single release engineer to go through license compliance. We just did a release in late July or early August, and with FOSSA our license compliance review took five to ten minutes. That is an enormous difference. It has helped to decrease the time that we spend on troubleshooting by huge amounts.

What I really need from FOSSA—and it does a really good job of this—is to flag me when there are particular open source licenses that cause me or our legal department concern. It points out where a particular issue is, where it comes from, and the chain that brought it in, which is the most important part to me. Because there's a chain of dependencies, it's hard to find fourth- and fifth-level dependencies inside that chain, and FOSSA does a really good job finding that stuff and reporting how it got there.

That intelligence provides help with triage and remediation, in a sense. That is, the triage and the remediation on this stuff is to just not use that stuff. With the licensing it just says, "Hey, there's a license here that you might be concerned with." And from there, the remediation is to not use that particular package.

What is most valuable?

The most valuable part is the open source license compliance.

The solution’s out-of-the-box policy engine's ease of use is very high. It works extremely well. That's easy to quantify. Its accuracy seems really good, but I have not diligently measured it. When we have checked what it is doing, it has all come out great. We're extremely happy with the results, but I can't say that it is an accurate product.

The solution’s compatibility with developer ecosystem tools is pretty good. There is some stuff within the C++ world that we haven't been able to get it to work very well with, but that's a really small amount of what we do. Most of our stuff is in Clojure and in Ruby and all the things that we want FOSSA to do there are great. It's not like we have a wide scope of developers who are using it. I'm effectively the only person actually using FOSSA. I just gather up all the information and all the repos from all the other parts of the company and run scans on them daily. I'm the major customer here.

What needs improvement?

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.

For how long have I used the solution?

I have been using FOSSA for about eight months.

What do I think about the stability of the solution?

Any stability issues I have found were from things I did. I've had some chats with FOSSA about it, and we've talked about what could be some gray areas between me and them, but I haven't had time to investigate. So I'm not going to blame FOSSA for any stability issues at the moment. I think most of them have been on me, and there haven't been that many.

What I've got at the moment are some scans that slap on a fairly regular basis and I don't know why yet. It looks like it's something to do with the way that I'm doing scans rather than anything that is on the FOSSA side.

What do I think about the scalability of the solution?

I haven't measured the scalability. It just does its thing. I don't think I'm taxing it in the least bit. But I haven't seen any limitations at all on the Fossa side. None.

It's doing the one task that we bought it for, and it's doing it quite well. I would like to expand the use into the vulnerability scanning part, but that's not my department. But it is doing precisely the job that I want it to do and I'm quite happy with it. I don't plan on changing much with it right now.

How are customer service and technical support?

My experience with their technical support has really been quite good. There have been times where things have languished in the support queue for a little while before they got to them, but that's been the outlying stuff, most of the time. I've had direct access both to my account rep and to the engineering folks there, and we've had some really good conversations over time. So I'm really pleased.

Which solution did I use previously and why did I switch?

Prior to using FOSSA, we didn't have any other tool in place for license scanning. We came to the realization that we needed a tool like this for open source management because none of the engineers who had to do the two weeks of manual license review work wanted to be doing it. We all hated it. So if there was a tool to take care of it, we were all saying, "Yes, let's get that."

How was the initial setup?

The initial setup was extremely straightforward: sign in to the GUI and download the CLI. I did have to write some shell scripts to do the daily scan, but that was on me. I just wanted to do it my way.

From licensing it until bringing it into production on a day-to-day basis, it took about a day and a half. I got reviews of it by other engineers, but I was the one who was doing it.

What was our ROI?

I haven't done any calculations. I'm just glad that I have a tool to replace a bunch of manual drudgery.

Which other solutions did I evaluate?

For vulnerability scanning we're using JFrog Xray. We're using both FOSSA and JFrog Xray at the moment, and most of our production folks are relying on Xray.

Xray and FOSSA, in vulnerability scanning, approach the problem in two very different ways. We have some inertia over JFrog at the moment. People who have looked at the solutions, within our company, like both for different reasons.

What other advice do I have?

There is a temptation to try to insert FOSSA into continuous integration. That was certainly my temptation. To me, that is more work than it ought to be. Sequestering FOSSA into its own job worked out better than trying to insert it into continuous integration. It does not need to be run into a continuous integration. It's not something you need on every commit. That would be an overuse of the tool. Being able to do it as a side project keeps unnecessary failures from happening and it keeps a lot of other things, like unnecessary noise, from happening.

However, that's my use case for my particular setup. I can imagine other use cases where having it inside continuous integration would be useful. But for my use case, while that was my first temptation, that was an incorrect approach. Having it as a side job that stands on a schedule, rather than part of the continuous integration, was much more successful.

In terms of FOSSA's security and vulnerability management features, I am familiar with them. Our security team uses other tools for those needs at the moment. They've been stuck on them and it has mostly been inertia that has stopped us from changing to or adopting FOSSA more widely. In my opinion, there are some use cases inside of FOSSA, for the security aspect, which are better than our tools. But it is up to the security team to decide if they want to do it. There's been some poking at it over the months, but no serious migration, as of yet. Those parts of FOSSA could be used by us in future, but not at the moment.

As for the background and information the solution’s security/vulnerability management features provide on security workflows, it's basically CVE scanning, often before the CVEs get published. So whenever there is a security alert of some sort, it will publish whatever is known based upon all the ongoing, conflicting databases of security scans. It's a helpful "Hey, this bit of software that you're using is known to contain these particular vulnerabilities."

The reporting on security and vulnerabilities is pretty good. As I said, I've only used it casually, so I can't really say anything of great value. I haven't looked at it for a while. But I found the reporting, like all their reporting, to be quite clear, understandable, and straightforward. But my exposure to it isn't enough that I can't be more than vague.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
CL
Program Manager at a consumer goods company with 10,001+ employees
Real User
Top 20
Improves productivity by saving a lot of time for our software developers

Pros and Cons

  • "The support team has just been amazing, and it helps us to have a great support team from FOSSA. They are there to triage and answer all our questions which come up by using their product."
  • "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."

What is our primary use case?

We use it to scan all of our open source projects, including all of our internal projects that people use.

We are about to roll it out to the whole company. Currently, we're only using it for open source projects, making sure people are scanning before they get the project approved.

How has it helped my organization?

FOSSA's compatibility with the wide range of developer ecosystem tools is great. It definitely saves us a lot of time and helps us figure out what security vulnerabilities are going on. Since we can't do it ourselves, we need FOSSA.

The solution provides contextualized, actionable intelligence that alerts us to compliance issues. The intelligence provides help with triage and remediation. The solution reacts really quickly to triage every question or anything going on that needs help.

What is most valuable?

It cuts the software engineers work a lot. Because if it is already approved and scanned, then they don't have to do it again. 

The solution is holistic. Our legal teams and DevOps work hand in hand with it. For example, we have a legal team who is part of the setup for FOSSA. 

What needs improvement?

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.

For how long have I used the solution?

I have been using it for two years.

What do I think about the stability of the solution?

FOSSA has been pretty stable. There haven't been websites down, etc. We are still building on top of it, which is great. We are adding more features which we didn't know that we needed. We are still getting feedback from developers at the company on what they need and what the solution can do for them.

My team of two does the maintenance for FOSSA.

What do I think about the scalability of the solution?

The scalability has been pretty perfect.

The majority of the user roles are software engineers. We have about 3,000 to 4,000 software engineers who will be using it. Currently, I think we have about 1,000 employees who probably have used it, or maybe a little less. We are about to roll it out to the whole company, so that will be hitting the majority of all our engineers.

Right now, it's already in the system. We just haven't yet announced that it is in the system for use. 

FOSSA enables us to deploy software at scale.

How are customer service and technical support?

The technical support is really good. They are very persistent and support what we need by answering all of our questions. They answer right away. 

Which solution did I use previously and why did I switch?

We did not use another solution previously.

How was the initial setup?

The initial setup was straightforward. It was very easy in order to have their platform installed into our company-wide platform for internal users. They gave us what they needed, and we gave them what they needed.

Our deployment took about a week.

For our implementation strategy, we had to figure out what was needed in order for FOSSA to be on our platform along with the needs to onboard an external platform into our system.

What about the implementation team?

The deployment required three or four people: the IT team, the FOSSA team. and myself. My experience with the FOSSA team with great. The deployment went smoothly. They were there for 100 percent life support. Anything that was needed was found and triaged.

What was our ROI?

It takes probably a week to get everything scanned and approved before you can use it. Therefore, we are probably seeing about a couple of days or weeks of times saving per code or project for this solution. This is because it would take some time to scan, have it looked at, reviewed, and get approval.

It improves productivity, saving a lot of time for our software developers. 

What other advice do I have?

If this is the type of product that you're looking for, they are one of the best products that you can use. The support team has just been amazing, and it helps us to have a great support team from FOSSA. They are there to triage and answer all our questions which come up by using their product.

I am not a daily user. I do more of the program management side of setting it up for everyone. I don't actually use it on a day-to-day type of basis.

I would rate the solution a 10 out of 10.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Buyer's Guide
Download our free FOSSA Report and get advice and tips from experienced pros sharing their opinions.