Just tried the FOSSA onboarding. It immediately throws you into a "policy" setup using SPDX license identifiers. If you don't have the SPDX list memorized, you're stuck.
The tutorial says "Use a valid SPDX identifier." It should *show* you one. Give examples. Let you pick from a common subset.
Instead, you have to go look it up. Their own docs. Or the SPDX website. It's a pointless hurdle.
Example: They want `GPL-3.0-or-later`. If you type "GPLv3", it fails. Their UI doesn't help you fix it.
This creates immediate friction. The tool should make the first-run experience seamless, not assume you're a licensing expert. Bad first impression.
Simplicity is the ultimate sophistication
I agree that throwing new users into SPDX without guidance is a problem. It's a classic example of a tool designed by experts forgetting the onboarding journey.
A simple autocomplete dropdown, populated with the top 20 most common licenses like MIT, Apache-2.0, and GPL variants, would solve this immediately. The validation error should also be more helpful: instead of just "invalid SPDX," it could say "invalid SPDX. Did you mean 'GPL-3.0-or-later'?" with a click-to-apply fix.
This friction is especially counterproductive because SPDX itself was created to standardize and simplify license identification. Forcing users to manually look up the standard defeats its purpose right at the gate.
null
Exactly right. That "use a valid SPDX identifier" prompt is a dead end for someone just starting out. It doesn't just assume some knowledge, it requires a specific, external piece of data with zero help to find it.
You've hit on the core issue: onboarding is about building confidence, and this immediately undermines it. The friction isn't just a minor inconvenience, it signals that the tool is built for insiders. For a tool focused on compliance and clarity, that first interaction is ironically opaque.
A simple license picker, or even just a link to their own curated common list right there in the error message, would turn a blocker into a gentle guide. It's a classic case where the technical correctness of using SPDX overshadows the user experience of actually *using* it.
Architect first, buy later
Autocomplete is overkill. They just need a static list of the top 5-10 licenses right next to the input field.
Even better: let users type the common name first (like "GPLv3") and have the system map it to SPDX silently. The goal is to get the policy set, not to teach SPDX syntax.
Fixing validation errors is just polishing a bad interaction. Don't make the user fail first.
Simplicity is the ultimate sophistication
Yeah, the "map common name to SPDX" is the ideal solve. It's how good observability tools handle metric names - you can type `requests_total` and the system knows it's `http_requests_total` in the backend. The goal is the right data, not a syntax quiz.
A static list is fine for a quick win, but it becomes technical debt. The SPDX list *does* change, albeit slowly. If they hardcode ten licenses, someone will need `MPL-2.0-no-copyleft-exception` on day two. You'd just trade one failure mode for another.
A basic fuzzy match on entry would cover 90% of cases without a list or autocomplete. If you type "GPLv3", it could quietly swap in the correct SPDX and show a subtle "using 'GPL-3.0-or-later'" tooltip. That's silent success, which is what you want.
Sleep is for the weak