ExpertsFMBuilding the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue)
ACQ2 by Acquired · October 14, 2024
5 Selected Lessons:
heuristic · 3 case · 1 framework · 1
Community-feedback-driven product expansion
Source
ACQ2 by Acquired — Building the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue) (October 14, 2024) · at 12:24 ▸ · at 14:32 ▸ · at 17:20 ▸
When this applies
when deciding what to build next for any user base that actively tells you what it needs
The takeaway
Let committed users dictate the roadmap by watching what they ask for repeatedly, rather than planning features in isolation.
Why it works
Direct, repeated requests from active contributors reveal real adjacent needs (e.g., hosting bigger models, searching datasets) that founders would not have predicted from first principles.
One level up
Products that serve a community well grow the community's trust, which compounds into a defensible network effect.
Where it stops holding
This stops working when the user base is too small or non-representative to generalize from, or when short-term requests conflict with long-term platform coherence.
Detail
procedure:
- Ship a small, useful open artifact (e.g., a ported model) and make it easy to adopt.
- Listen when users ask to add their own models/datasets or request new capabilities (hosting large files, searchable datasets).
- Build the requested capability as a platform feature rather than a one-off.
- Repeat, letting the sum of these features define the platform.
benchmarks: {"models_datasets_apps_total":"3,000,000+","rate":"one built every 10 seconds"}
rationale: Development has always been very community driven, really following the feedback from the community, and that's a big part of the reason for success.
In their words
So we started to build that and a few months later, we realized that basically we built kind of like a new GitHub for AI. So our development has always been very community driven, really following the feedback from the community.
Openness as adjustable tool, not mandate
Source
ACQ2 by Acquired — Building the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue) (October 14, 2024) · at 17:20 ▸
When this applies
when deciding how much transparency or openness any organization should offer around its proprietary work
The takeaway
Make the desired behavior easy and optional rather than mandatory, so adoption scales with comfort level instead of being blocked by resistance.
Why it works
Giving users optional tools for openness (rather than forcing disclosure) lets each organization open exactly what it's comfortable with, which in aggregate raises total openness in the ecosystem without alienating cautious players.
One level up
Platforms that minimize friction for a desired behavior capture more of that behavior in aggregate than platforms that mandate it.
Where it stops holding
This stops working when the underlying behavior (e.g., openness) requires critical mass or coordination to be valuable, so a patchwork of partial adopters produces little benefit.
Detail
rule: Provide infrastructure for openness without forcing it; let each company or scientist choose their own openness level.
threshold: Roughly half of models/datasets/apps on the platform are private; this is treated as fine, not a failure.
rationale: openness and open source AI, open science is really kind of like the tides that lift all boats.
In their words
What we like to do is to give tools for companies to be more open than they would be without us, but without forcing them in any way.
AI startups need science co-founders and longer, lumpier timelines
Source
ACQ2 by Acquired — Building the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue) (October 14, 2024) · at 32:19 ▸ · at 54:45 ▸ · at 58:51 ▸
When this applies
when building in a domain where fundamental research determines the product's quality, not just engineering speed
The takeaway
Match your team's skill set and shipping cadence expectations to whether the underlying work is incremental-engineering or breakthrough-science in nature.
Why it works
Science-driven work produces step-function improvements only after long investment (months, not days), unlike software where small incremental ships compound; teams optimized for fast iterative shipping misjudge this and either give up too early or mismeasure progress.
One level up
The right operating model depends on the shape of the value curve (linear/incremental vs stepped/breakthrough), not on industry convention.
Where it stops holding
This stops working when the AI product is a thin wrapper on existing APIs rather than requiring genuine model training/research, in which case traditional fast-shipping software practices still apply.
Detail
rule: Have at least one scientist co-founder; expect model training/optimization to take months, not days; expect long stretches with no visible product improvement followed by a 10x jump.
threshold: Training/optimizing a model is 'at best, a matter of months than a matter of days.'
rationale: For science, it's almost like you don't create any Speaker 1: value, you work on something for six months, and then Speaker 1: after six months, you have something 10 times better than the existing.
In their words
I think having more science backgrounds are actually kind of like a must. Having one co founder who is a scientist, I think is a big, big plus.
Stay an order of magnitude leaner than peers to balance speed and stability
Source
ACQ2 by Acquired — Building the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue) (October 14, 2024) · at 46:25 ▸
When this applies
when managing the tension between shipping fast in a still-evolving technology and building stable, mature infrastructure at scale
The takeaway
Deliberately cap headcount well below what peers/competitors have, using leanness itself as a tool for speed and adaptability rather than pursuing scale for its own sake.
Why it works
Smaller teams move faster and avoid the coordination overhead and process ossification that comes with scale, which matters most when the underlying technology (and thus the 'right' architecture) is still rapidly changing.
One level up
In a fast-evolving domain, constraints on organizational size can be a feature, not a limitation.
Where it stops holding
This stops working when the underlying technology/market has matured and stabilized, at which point scale advantages (more hands, broader coverage) outweigh the agility benefits of staying small.
Detail
rule: Always want to stay an order of magnitude less team members than our peers.
threshold: 250 employees vs. a peer scale of ~2,000.
rationale: there's this constant battle Speaker 1: between building mature, stable Speaker 1: platforms and solutions, but at the same time innovating, Speaker 1: iterating fast enough so that you don't miss the next wave.
In their words
With two fifty team members in the company, we say that we always want to stay an order of magnitude less team members than our peers.
Pivoting three years in despite $6M raised and community traction
Source
ACQ2 by Acquired — Building the Open Source AI Revolution (with Hugging Face CEO, Clem Delangue) (October 14, 2024) · at 5:13 ▸ · at 8:58 ▸ · at 12:24 ▸ · at 14:32 ▸
When this applies
when building the infrastructure for your product turns out to be more valuable than the product itself
The takeaway
Stay alert to signals that the by-product of your work is more valuable than your stated mission, and be willing to abandon sunk-cost direction when that signal is strong.
Why it works
Early technical choices made to serve a narrow product need (an abstraction layer for multiple models/datasets) can accidentally create a reusable platform with independent demand.
One level up
Opportunism and flexibility matter more than conviction in an original plan, especially early in a company's life.
Where it stops holding
This stops working when the team conflates noise (small vanity signals) with real demand, or when switching costs/raised capital commitments make the pivot too costly to execute cleanly.
Detail
situation: Hugging Face spent 3 years and ~$6M building a conversational AI chatbot for teens; meanwhile cofounder Thomas ported Google's BERT to PyTorch as a side project.
decision: After the PyTorch port got outsized community interest (a tweet with ~1000 likes felt huge), the team doubled down over six months and then told investors they wanted to pivot entirely away from the chatbot.
outcome: Hugging Face became the 'GitHub for AI,' now valued at $4.5B with 5M+ builders, while the original chatbot vision was abandoned.
lesson: Even with meaningful capital raised and years invested, seize an emergent opportunity signaled by real community enthusiasm rather than persisting in the original plan.
In their words
Obviously, it reinforces for people who are listening the importance of being flexible, being opportunistic, and being able to seize kind of like new opportunities, three years in, right?