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?