Bitcoin is often celebrated for its decentralized, trustless architecture—but behind the scenes, the human layer of development tells a more nuanced story. At the MIT Bitcoin Expo 2025, Bitcoin Core contributor Sjors Provoost sat down with Bitcoin Magazine’s Technical Editor Shinobi to peel back the curtain on how Bitcoin Core development actually works. The conversation revealed a process far less robotic and far more human than most assume—filled with coordination challenges, communication bottlenecks, and the quiet persistence required to maintain one of the most secure open-source projects in the world.
This deep dive into Bitcoin Core’s development culture clarifies common misconceptions, exposes systemic inefficiencies, and issues a powerful call to action: if you believe in Bitcoin, contribute to its evolution.
What It’s Actually Like to Contribute to Bitcoin Core
Contributing to Bitcoin Core isn’t like submitting code to most open-source projects. The stakes are incredibly high—every line of code touches a global financial network worth hundreds of billions. As Provoost explains, new contributors often underestimate the rigor involved.
“It’s not just about writing good code,” he says. “It’s about writing code that survives years of scrutiny, that doesn’t introduce edge cases, and that aligns with Bitcoin’s long-term philosophy.” Most pull requests (PRs) take months—even years—to merge. Reviewers must assess security implications, performance impacts, and backward compatibility.
And yet, despite its importance, Bitcoin Core remains a volunteer-driven effort with no formal hierarchy. There are maintainers, yes—trusted developers who can merge PRs—but even they don’t have unilateral control. Decisions emerge from consensus across mailing lists, GitHub discussions, and in-person meetings like this one at MIT.
👉 Discover how decentralized innovation really works—see what drives the future of digital currency.
How a Pull Request Gets Merged
The journey of a single pull request is a masterclass in decentralized governance. It starts with a developer identifying a bug or proposing an improvement. They write the code, submit it to GitHub, and await feedback.
But here’s where things get messy. A PR isn’t merged because one person approves it. It needs multiple rounds of review from different developers. Each reviewer may have different priorities—one might focus on security, another on code clarity, another on protocol economics.
Then comes testing: automated CI checks, manual builds across platforms, and real-world simulation in testnets. Only after passing all these hurdles—and surviving weeks or months of debate—does a PR approach merge eligibility.
And even then, it might stall.
GitHub Drama and the Problem with Drive-by Reviews
One of the most revealing parts of the talk was Provoost’s critique of “drive-by reviews”—comments from developers who weigh in once, offer strong opinions, and disappear.
“These reviews can be helpful,” he admits, “but they often lack context. They don’t follow the full thread, they don’t understand the trade-offs the author has already considered, and they can derail progress.”
Worse, GitHub’s notification system amplifies noise over substance. A single controversial comment can trigger a flood of replies, drawing attention away from quieter but more constructive discussions happening elsewhere.
This creates a skewed perception of consensus. A vocal minority can make it seem like there’s widespread opposition to a change—even when most core contributors are neutral or supportive.
Rebase Hell and Why PRs Stall
Perhaps the most relatable pain point for developers? Rebase hell.
Because Bitcoin Core evolves continuously, any unmerged PR quickly becomes outdated. Contributors must frequently rebase their work—adjusting their code to fit the latest version of the master branch. Each rebase risks introducing new conflicts or breaking tests.
For volunteers working in their spare time, this is demoralizing. You spend weeks perfecting a patch, only to find it needs another rebase—again—just as you thought it was close to merging.
“This isn’t a technical problem,” Provoost emphasizes. “It’s a human one. We lose good contributions because the process is too exhausting.”
Is More Developers Always Better?
A common refrain in the Bitcoin community is: “We need more developers!” But Provoost challenges this assumption.
“More developers aren’t useful if they’re not aligned with Bitcoin’s values,” he argues. “We don’t need people who want to ‘move fast and break things.’ We need careful, patient engineers who understand that stability is paramount.”
He also notes that scaling coordination is hard. With more contributors comes more communication overhead. Without clear processes or tooling improvements, adding more people can actually slow things down.
The real bottleneck isn’t code output—it’s review capacity. There simply aren’t enough experienced reviewers to keep up with demand.
Why GitHub Notifications Skew Developer Attention
GitHub is the de facto platform for Bitcoin Core development—but it wasn’t built for long-term protocol evolution. Its real-time notification system favors urgency over depth.
Developers get pinged for every comment, every rebase, every test failure. The result? Attention gets pulled toward the loudest or most recent activity—not necessarily the most important work.
Provoost suggests that better tooling could help: filtered notifications, prioritized review queues, or even alternative platforms designed for asynchronous, thoughtful collaboration.
Until then, maintainers risk burnout from constant context-switching.
Why Bitcoin Core Culture Is Hard to Change
Bitcoin Core’s culture values caution, skepticism, and long-term thinking—traits essential for securing a trillion-dollar network. But they also make change slow and innovation difficult to onboard.
New ideas face intense scrutiny. That’s by design. But without active mentorship or clearer contribution pathways, many potential contributors give up early.
“Culture isn’t written in code,” Provoost says. “It’s passed down through interactions. And if those interactions are cold or dismissive, people leave.”
He calls for more empathy in reviews, better documentation for newcomers, and structured onboarding programs to grow the next generation of core contributors.
👉 Learn how you can become part of the next wave of blockchain innovation—start exploring today.
Final Thoughts and Call to Action
Sjors Provoost ends with a powerful message: stop complaining about Bitcoin’s pace of development—and start helping.
Criticism is easy. Contribution is hard. But only contribution moves the needle.
Whether you’re a developer, writer, tester, or translator, there’s a role for you in the Bitcoin ecosystem. Submit a patch. Review a PR. Improve documentation. Attend a dev meeting.
Bitcoin’s resilience doesn’t come from its code alone—it comes from its community.
Frequently Asked Questions
Q: Who maintains Bitcoin Core?
A: Bitcoin Core is maintained by a group of volunteer developers who have earned commit access through consistent, high-quality contributions. No single entity controls the project—it operates through decentralized consensus.
Q: How can I contribute to Bitcoin Core?
A: Start by reviewing open pull requests or fixing beginner-friendly issues labeled “good first issue” on GitHub. You can also help by writing documentation, testing releases, or participating in discussions on the mailing list.
Q: Why does it take so long to merge changes into Bitcoin Core?
A: Every change undergoes rigorous review for security, performance, and philosophical alignment with Bitcoin’s goals. This slow process ensures network stability and prevents costly mistakes.
Q: Are there paid developers working on Bitcoin Core?
A: Some contributors receive funding from organizations like Chaincode Labs, Blockstream, or Brink, but many work voluntarily. Funding remains a challenge for long-term sustainability.
Q: What tools do Bitcoin Core developers use?
A: Primary tools include Git/GitHub for version control, IRC and mailing lists for discussion, and CI systems for automated testing. Some developers are exploring better platforms for asynchronous collaboration.
Q: Can non-programmers contribute to Bitcoin development?
A: Absolutely. Technical writing, UX research, translation, community moderation, and event organizing are all vital roles that support the ecosystem.
👉 Join the movement shaping the future of finance—take your first step now.