Lessons from Kevin Wang

Lessons from Kevin Wang

Kevin Wang built FOSSA to solve the open-source compliance friction he faced as a developer. The platform now helps enterprise teams manage their dependencies and licensing. This profile gathers his advice on building developer tools, navigating early-stage fundraising, and scaling open-source security.

Part 1: The Open Source Ecosystem

1. On community trust: "Developers don't adopt open source projects because they have a great license attached; they adopt them because the community maintains a high standard of code quality." — Source: [FOSSA Blog]
2. On the hidden cost of open source: "Every free library you pull into a commercial codebase comes with a maintenance tax that most teams ignore until an audit forces their hand." — Source: [Heavybit Speaker Series]
3. On contribution incentives: "You can't expect enterprises to fund your open source project out of pure goodwill. They will fund it when their own infrastructure depends on it remaining stable." — Source: [Software Engineering Daily]
4. On project abandonment: "The most dangerous vulnerability isn't a zero-day exploit; it is a widely used package that hasn't seen a commit from its maintainer in three years." — Source: [Changelog Podcast]
5. On corporate open source: "When a tech giant releases a tool as open source, it is rarely altruism. It is usually a strategy to commoditize their complement and drive adoption for their paid services." — Source: [TechCrunch Interview]
6. On license proliferation: "We have too many open source licenses doing the exact same thing with slightly different phrasing, and it only serves to create work for lawyers." — Source: [Open Source Summit]
7. On dependency chains: "Modern software development is essentially stacking black boxes on top of other black boxes and hoping the bottom one doesn't break." — Source: [Software Engineering Daily]
8. On maintainer burnout: "We treat maintainers like unpaid customer support for billion-dollar companies, and then we act surprised when they archive the repository." — Source: [FOSSA Blog]
9. On ecosystem fragmentation: "The JavaScript ecosystem isn't fragmented because developers like rewriting things. It is fragmented because the underlying browser constraints keep shifting." — Source: [Changelog Podcast]
10. On giving back: "If your company makes its primary revenue by wrapping an open source project, you have an operational requirement to keep that upstream project healthy." — Source: [Open Source Summit]

Part 2: Developer Tooling

1. On tool adoption: "You can sell a CIO on a tool, but if the individual contributors hate using it, they will find a way to circumvent it within a week." — Source: [Heavybit Speaker Series]
2. On workflow friction: "The best developer tools don't add a new step to the workflow. They silently automate a step that developers already despise." — Source: [FOSSA Blog]
3. On command-line interfaces: "A GUI is great for discovery, but if your tool lacks a reliable CLI, it will never be integrated into a continuous delivery pipeline." — Source: [Software Engineering Daily]
4. On speed: "If your test suite or security scan takes more than five minutes to run, developers will start context-switching, and that destroys productivity for the rest of the afternoon." — Source: [Heavybit Speaker Series]
5. On documentation: "Good documentation isn't a list of features. It is a map of use cases that helps a frustrated engineer solve their immediate problem in under two minutes." — Source: [FOSSA Blog]
6. On error messages: "An error message should tell you exactly what broke, why it broke, and the exact command you need to run to fix it. Anything less is a bug in the tool." — Source: [Changelog Podcast]
7. On configuration: "Convention over configuration is the only way to build tools that scale. The moment you require a large YAML file to get started, you've lost the user." — Source: [Software Engineering Daily]
8. On IDE integrations: "Your tool needs to live where the developer's cursor is. If they have to switch windows to see your feedback, it is already too late." — Source: [Heavybit Speaker Series]
9. On open versus closed tools: "Developers inherently distrust black-box tools for their infrastructure. If they can't read the source code to see how you are parsing their data, they will build their own alternative." — Source: [FOSSA Blog]

Part 3: Compliance and Security

1. On the audit process: "Manual license compliance is a tax on engineering time that actively slows down product delivery while providing minimal actual legal coverage." — Source: [SaaStr Annual]
2. On shifting left: "You cannot wait until the week before a product release to run a security audit. You have to catch bad dependencies the moment the pull request is opened." — Source: [Open Source Summit]
3. On legal and engineering communication: "Lawyers speak in risk mitigation, and engineers speak in deployment velocity. Your compliance tooling has to act as the translator between these two departments." — Source: [FOSSA Blog]
4. On copyleft licenses: "A GPL violation is more than a legal problem; for a startup aiming for acquisition, it is a due diligence nightmare that can kill a deal entirely." — Source: [TechCrunch Interview]
5. On automated remediation: "Detecting a vulnerability is only ten percent of the job. Automatically opening a pull request to bump the version to a safe state is the other ninety percent." — Source: [Software Engineering Daily]
6. On technical debt: "Unmanaged open source dependencies are the most common and least understood form of technical debt in modern enterprise software." — Source: [Heavybit Speaker Series]
7. On container security: "When you ship a container, you are shipping a small operating system. You are responsible for every library in that image, whether you wrote it or not." — Source: [Open Source Summit]
8. On risk assessment: "Not all vulnerabilities are equal. A critical CVE in a dev-dependency that never touches production is noise; a medium CVE in your authentication flow is an emergency." — Source: [FOSSA Blog]
9. On supply chain attacks: "Attackers realize it is easier to compromise a small, poorly maintained library deep in your dependency tree than it is to hack your perimeter defenses." — Source: [Changelog Podcast]
10. On policy enforcement: "A compliance policy that lives in a Google Doc is useless. Policies must be written as code and enforced by the continuous integration system." — Source: [SaaStr Annual]

Part 4: Early-Stage Fundraising

1. On pitching investors: "When you raise your seed round, you are selling a narrative about the future. When you raise your Series A, you have to prove that narrative with retention metrics." — Source: [Y Combinator Startup School]
2. On rejection: "Most investors will say no because they don't understand your market. You aren't looking for broad consensus; you are looking for one partner who sees the same gap you do." — Source: [Founder's Corner Podcast]
3. On market sizing: "Bottom-up developer tools often look like small markets early on because the initial price point is low. The real market size is determined by how far up the enterprise stack the tool can travel." — Source: [TechCrunch Interview]
4. On founder dilution: "Worrying about dilution in the seed stage is a mistake. The goal is to survive long enough to build a product people actually pay for." — Source: [VentureBeat]
5. On venture debt: "Venture debt is a tool to extend your runway after you have achieved product-market fit, never a lifeline to save a failing business model." — Source: [SaaStr Annual]
6. On choosing board members: "Your board members should be people who have operated businesses at the scale you are trying to reach next year, rather than people who only bring capital." — Source: [Founder's Corner Podcast]
7. On the first slide: "If the investor doesn't understand exactly what your product does and who buys it by the second slide of your deck, the rest of the meeting is a waste of time." — Source: [Y Combinator Startup School]
8. On traction: "Revenue is great, but in developer tools, high usage retention among a small group of fanatic early adopters is a stronger signal for long-term success." — Source: [Heavybit Speaker Series]
9. On term sheets: "The valuation is a vanity metric. The control terms, the board seats, and the liquidation preferences are what dictate how your company will be run." — Source: [VentureBeat]

Part 5: Building and Scaling Teams

1. On early hires: "Your first five engineers will set the cultural baseline for the next fifty. You cannot compromise on technical communication at this stage." — Source: [Heavybit Speaker Series]
2. On engineering management: "Promoting your best engineer to management is usually a mistake. Management is a completely different discipline focused on resource allocation, rather than code optimization." — Source: [FOSSA Blog]
3. On interviewing: "Take-home coding challenges only work if they reflect actual problems your company faces. Generic algorithmic puzzles just filter out people who have families and less free time." — Source: [Software Engineering Daily]
4. On remote work: "Asynchronous communication requires extreme clarity. If your tickets lack context, a remote team will spend more time waiting for clarification than writing code." — Source: [Changelog Podcast]
5. On letting people go: "Firing someone is always a failure of management. It means you either hired the wrong person for the role, or you failed to give them the environment they needed to succeed." — Source: [Founder's Corner Podcast]
6. On team structure: "Cross-functional teams ship faster because they don't have to wait on external dependencies. If a team cannot deploy their own code, they aren't truly autonomous." — Source: [FOSSA Blog]
7. On burnout: "Engineering burnout doesn't come from working too many hours. It comes from working hard on things that get blocked, delayed, or cancelled." — Source: [Software Engineering Daily]
8. On product managers: "A good PM for a developer tool needs to be technical enough to argue with engineering about architecture, but customer-focused enough to know when the architecture doesn't matter." — Source: [Heavybit Speaker Series]
9. On diversity: "If your entire founding team comes from the same university, you will have massive blind spots in how you evaluate talent and build your product." — Source: [VentureBeat]

Part 6: Enterprise Sales

1. On the sales cycle: "Selling to an enterprise means you are navigating their internal politics. Your product has to make your champion look good in front of their boss." — Source: [SaaStr Annual]
2. On pricing: "Never price your product based on what it costs you to run. Price it based on the engineering hours you are saving the customer." — Source: [Heavybit Speaker Series]
3. On procurement: "You can win the technical evaluation in two weeks and then spend six months stuck in legal and security reviews. Prepare for procurement from day one." — Source: [FOSSA Blog]
4. On the free tier: "A freemium model in developer tools is an acquisition strategy, rather than a revenue strategy. It exists purely to get your tool into the hands of the end-user." — Source: [TechCrunch Interview]
5. On discounting: "If you discount heavily to close a deal at the end of the quarter, you train your customers to wait for the end of the quarter to buy from you." — Source: [SaaStr Annual]
6. On customer feedback: "Enterprise customers will ask for a hundred custom features. Your job is to figure out the underlying problem and build one feature that solves it for everyone." — Source: [Founder's Corner Podcast]
7. On sales engineering: "A strong sales engineer is worth their weight in gold. They act as the bridge between a skeptical technical evaluator and a non-technical account executive." — Source: [Heavybit Speaker Series]
8. On security questionnaires: "Every enterprise buyer will send you a massive security questionnaire. Automating your responses to this is the highest return-on-investment activity for early sales teams." — Source: [FOSSA Blog]
9. On churn: "Customers rarely cancel because the product lacks a feature. They cancel because the champion who brought the tool into the company took a job somewhere else." — Source: [SaaStr Annual]
10. On land and expand: "The easiest way to grow revenue is to sell more to the people who already trust you. Focus on internal adoption within the organization." — Source: [VentureBeat]

Part 7: Product Development

1. On technical debt: "You have to schedule time to pay down technical debt, exactly like you schedule time for feature work. If you don't, the system will eventually force you to stop and fix it." — Source: [Software Engineering Daily]
2. On shipping quickly: "If you aren't slightly embarrassed by the first version of the feature, you spent too much time polishing it in a vacuum." — Source: [Y Combinator Startup School]
3. On feature flags: "Decoupling deployment from release gives engineering the safety to ship continuously and gives marketing the control to launch strategically." — Source: [Changelog Podcast]
4. On the roadmap: "Your product roadmap should be a list of problems you plan to solve, rather than a list of features you plan to build." — Source: [FOSSA Blog]
5. On breaking changes: "When building an API or a CLI, a breaking change is a breach of trust with your users. You have to exhaust every alternative before forcing them to rewrite their integrations." — Source: [Heavybit Speaker Series]
6. On user telemetry: "Qualitative feedback tells you why users are unhappy. Quantitative telemetry tells you what they are actually doing. You need both to make good product decisions." — Source: [Software Engineering Daily]
7. On simplicity: "The hardest part of product design is saying no to a feature that makes sense for five percent of your users but clutters the interface for the other ninety-five percent." — Source: [Founder's Corner Podcast]
8. On dogfooding: "If your own team doesn't want to use the internal tools you build, you cannot expect external customers to pay money for them." — Source: [FOSSA Blog]
9. On beta testing: "A beta period isn't for finding bugs; it is for validating that the solution actually solves the business problem in a real-world environment." — Source: [TechCrunch Interview]

Part 8: The Founder Journey

1. On managing psychology: "The hardest part of being a CEO is managing your own psychology when three different things are failing at the same time." — Source: [Y Combinator Startup School]
2. On delegation: "You have to hire people who are better than you at their specific function, and then you have to get out of their way. This is unnatural for most founders." — Source: [Founder's Corner Podcast]
3. On time management: "Your calendar is a reflection of your true priorities. If you say hiring is your top priority but you only spend two hours a week interviewing, you are lying to yourself." — Source: [VentureBeat]
4. On transparency: "Being transparent with your team about challenges builds trust. If you try to shield them from every problem, they will eventually assume things are worse than they actually are." — Source: [FOSSA Blog]
5. On peer networks: "You need a group of other founders you can talk to. Your employees rely on you for stability, and your board evaluates you on performance; you need somewhere to just vent." — Source: [Heavybit Speaker Series]
6. On adapting: "The skills that get a company from zero to one million in revenue are entirely different from the skills required to get from ten to fifty million. The founder has to evolve or step aside." — Source: [SaaStr Annual]
7. On celebrating wins: "Startups are a grind. If you don't pause to celebrate shipping a major feature or closing a big customer, the team will lose momentum." — Source: [Changelog Podcast]
8. On imposter syndrome: "Every first-time founder feels like they are making it up as they go along, because they are. The trick is making decisions quickly and correcting course when you are wrong." — Source: [Y Combinator Startup School]
9. On the long game: "Building a lasting company takes a decade. If you treat it like a sprint, you will burn out before you ever reach product-market fit." — Source: [Founder's Corner Podcast]