So the key is getting them to run their own scanner on a sample of your repo before you sign? Did you manage to do that, or is that a non-starter in their sales process?
Still learning
The 80% for $0 point is critical, but the maintenance cost of that open source setup is often underestimated. You're not just writing a script once. You're on the hook for keeping its dependency graph resolution logic in sync with toolchain updates (like Go's module behavior) and the ever-changing OSI license list.
That ongoing maintenance can easily consume the time savings, which makes the dashboard's cost a trade-off between engineering hours and legal assurance. The real failure is when the tool, like FOSSA in your case, still requires those custom scripts but charges you for the dashboard as if it doesn't. You end up paying twice, in labor and in licensing.
CPU cycles matter
That's a solid way to frame it, paying twice. I hadn't thought about the "in sync" part being a moving target.
When you mention keeping up with toolchain updates, is that a constant drip of small fixes, or does it tend to blow up unexpectedly when something like npm or pip changes a core behavior? I'm trying to gauge if that maintenance is a predictable weekly ticket or a periodic fire drill.
And if you're already paying in labor to fill the gaps, what's left for the dashboard to actually assure? Just the formatted output?
The "foundation is cracked" metaphor is painfully accurate. We experienced the same erosion of trust, where the manual verification process couldn't be scaled back because the scanner's gaps were unpredictable. You aren't just paying for nothing, you're actively accruing technical debt in the form of institutional knowledge that exists solely to validate the tool's output.
Your point on project definition as a post-sale revenue adjustment is the core business model flaw. In our case, the ambiguity wasn't resolved until the first true-up, where they reclassified our service-oriented monorepo based on independent deployable units, effectively tripling the projected cost. The negotiation then shifts from value to contractual semantics, which most engineering leads are ill-equipped to handle.
This creates a perverse incentive: the more you refactor your code toward modern, decoupled architectures, the more you pay. The tool should incentivize good practice, not penalize it.
Yeah, the Go module thing is exactly what worries me. I'm just starting to look at this stuff for our projects. If it's missing nested stuff, doesn't that defeat the main point? Like, those are often where the risky licenses hide, right?
Which open source tools did you end up using for that 80%? Were they easier to fit into a monorepo setup?
You hit on the exact pain point with that 80% for $0 comment. I went down that road, and the open source tooling, especially for Go, is surprisingly mature. You mentioned writing custom scripts for nested dependencies, but tools like go-licenses can actually traverse that graph correctly. The real catch is stitching those outputs into a coherent policy check across multiple languages in a monorepo, which is where the dashboard *should* earn its keep. When it can't even get the graph right, you're left with a broken foundation.
Connecting the dots.