Bitcoin Magazine: Open Source vs. Source-Available: What the Coldcard Failure Reveals About Bitcoin Software Incentives

Closed source and open source have divided the Bitcoin and broader crypto industry for more than a decade. Bitcoin advocates have long argued that the world’s financial infrastructure should be built in public, saying transparency and auditability are non-negotiable when real money is at stake. The app and legacy layers of finance often disagree.

The recent Coldcard hack, involving a popular self-custody hardware wallet in which users lost more than $100 million worth of bitcoin, or more than 1,500 BTC, raised questions about what “open source” actually means. It also suggested that many people, including some serious bitcoiners, are poorly educated about the open-source software philosophy and the conditions under which it fails.

The principles and terminology

The language around open source can be confusing. Free and Open Source Software (FOSS) and Free/Libre and Open Source Software (FLOSS) describe software that meets formal definitions of user freedom.

The Free Software Foundation (FSF) defines free software through four essential freedoms:

Freedom 0: The freedom to run the program as you wish, for any purpose.

Freedom 1: The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.

Freedom 2: The freedom to redistribute copies so you can help others.

Freedom 3: The freedom to distribute copies of your modified versions to others. Access to the source code is a precondition for this.

The FSF emphasizes that “free” refers to liberty, not price, in the familiar phrase used by FOSS advocates: “‘free’ as in ‘free speech,’ not as in ‘free beer.’”

The Open Source Initiative’s Open Source Definition adds ten practical criteria. These include free redistribution without royalties, source code availability in the preferred form for modification, the right to create and distribute derived works, and no discrimination against persons, groups, or fields of endeavor, including commercial use. A license must meet all ten criteria to qualify as open source under the OSI standard.

“Source available” or “source viewable” is different. Code may be publicly readable while the license still restricts the right to sell it. Coldcard’s firmware, for example, is released under MIT terms plus the Commons Clause. The clause specifically removes the right to “Sell” the software, defined as providing it to third parties for a fee or other consideration in a product or service whose value derives entirely or substantially from the software itself. In other words, Coldcard’s firmware could not be used commercially.

The Commons Clause FAQ states the distinction plainly: “Is this ‘Open Source’? No.” It says that applying the clause means the software meets many elements of the Open Source Definition but not all of them, and therefore should not be called open source.

These distinctions matter. Publishing source code creates the possibility of inspection. Granting the full set of rights defined by the Free Software Definition or the Open Source Definition is what makes software FOSS or FLOSS. But the badge itself is not the point. Critics argue that commercial liberty in FOSS unlocks third-party incentives to test and review code that otherwise might not exist.

The four freedoms form the philosophical core of open source, but in practice they depend on an economic assumption: that enough motivated people will actually examine the code. When that assumption fails, the result resembles a tragedy of the commons, where a shared resource is neglected because individuals act in their own short-term self-interest rather than the long-term interest of the group.

Each person has an incentive to take more, or contribute less, than is sustainable, and the resource degrades as a result. Whether the incentives align depends on the situation.

One Bitcoin developer put the problem bluntly: “Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech.”

Open source does not create safety by itself. It creates the possibility of verification. Whether that verification happens depends on incentives, skill, and attention. Historical FOSS is often said to harden over time as vulnerabilities are discovered, disclosed, and patched, creating solid foundations for others to build on. The Linux kernel is a leading example of hardened FOSS; it powers the vast majority of the world’s servers, cloud infrastructure, Android devices, and embedded systems, making it one of the most widely deployed pieces of software in history.

Open source as demonstrated by Bitcoin Core

Bitcoin Core, the reference implementation of Bitcoin, is another large-scale example of open source working in practice. The software, which runs behind most Bitcoin-related infrastructure, is released under the MIT license. Its development process is public by design.

Anyone can open a pull request. Code review is the primary filter and the recommended entry point for new contributors. Reviewers use a formal vocabulary: Concept ACK, meaning acknowledgment and agreement with the goal; Approach ACK, meaning agreement with the goal and method; ACK with a specific commit hash, meaning tested and approved for merge; or NACK, meaning disagreement accompanied by technical reasoning.

Maintainers weigh contributor consensus and the technical merits of a change before merging it. Consensus-critical changes face a higher bar and usually require a Bitcoin Improvement Proposal, along with extensive multi-year discussion on the bitcoin-dev mailing list and IRC.

There is no privileged caste of “Bitcoin Core developers.” Trust is earned through demonstrated competence over time. Maintainers exist for practical reasons: auditing and merging code, managing releases, and basic moderation. But the work produced is pure open-source code that anyone can inspect, build, fork, or run. Developers who get code commits merged into Bitcoin Core are broadly called Bitcoin Core Contributors.

Calle, a long-time open-source Bitcoin developer, summarized the situation recently: “People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code.”

Funding for this work comes largely through nonprofit and grant structures such as Brink, OpenSats, Spiral, and others rather than a traditional company product roadmap. Technical discussion and debate take place publicly on the bitcoin-dev mailing list and in the #bitcoin-core-dev IRC channel on Libera Chat, where proposals are scrutinized before and during the pull-request process. GitHub issues and pull requests often include comment histories that stretch back a decade. The result is a development culture optimized for correctness and auditability rather than speed or commercial feature velocity.

The economics of open source

Most users of open-source or source-available software never read the code themselves. They rely on the assumption that others are examining it. In the Coldcard case, a critical entropy flaw remained in publicly available firmware for roughly five years before it was exploited and discovered.

The bug entered the codebase during a major 2021 rewrite that also removed remaining GPL-derived code from Trezor, the first hardware wallet and now the second-largest in the self-custody industry. The library at the center of the entropy failure, which replaced trezor-crypto, is called libngu and had minimal external scrutiny, with only 7 stars and fewer than 20 forks in more than five years of use in production. By comparison, the trezor-crypto library has 512 stars and 212 forks, while the more modern trezor-firmware has 793 forks and 1.8k stars. Source availability alone did not produce the review that mattered, because other for-profit, well-funded companies were restricted from using it, or so critics would argue.

In practice, that makes licensing choices more than a legal footnote: they influence who can participate in review, who has a reason to do it, and how quickly flaws may be noticed in software that secures real funds. The stakes are higher in Bitcoin than in most software domains. A critical flaw can be converted directly into liquid funds on the open market. While the first half of the Coldcard funds stolen are still held in a handful of addresses and the hacker may one day be caught, copycat hackers that followed were more careful, and some have stolen more bitcoin and laundered it successfully, according to Galaxy Research. Bitcoin’s censorship resistance and immutable transactability create both a strong incentive for attackers and a Darwinian filter: only projects that continuously attract competent review, and users and companies that take serious precautions, tend to survive long term.

Licensing choices shape those incentives, according to FOSS advocates who criticized Coinkite’s licensing decisions for years. Pure open-source licenses maximize the pool of potential reviewers and forks. Restricted “source available” licenses can reduce commercial free-riding, but they can also shrink the circle of people with both the legal right and the economic motive to invest deep attention. In that sense, the burden of code review falls back on the company under a restrictive license, placing it closer to closed source than open source.

How AI changes open and closed source development

Artificial intelligence is now also changing the balance between FOSS and closed source.

After the Coldcard incident, a volunteer effort known as the Bitcoin Red Team — led by developers including Calle and Rob Hamilton of AnchorWatch, and supported by OpenSats — used frontier AI models to scan hundreds of open-source Bitcoin repositories. In one intensive period, the team filed thousands of findings, including dozens classified as critical or high severity, across hundreds of projects. Responsible disclosures were made to maintainers before broader publication. The exercise showed that systematic AI-assisted review can surface issues at a scale and speed previously impractical for purely human teams.

On this front, the Red Team found Chinese open-weight models far more reliable than closed-source American models, which, even with cyber permissions and top-line access, refused to answer Red Team queries, a trend the American developers lamented.

At the same time, the flood of AI-generated code has created a new denial-of-service pressure on FOSS maintainers. Reviewing AI output often takes longer than generating it. Some open-source projects outside Bitcoin have restricted issue trackers or imposed strict anti-AI contribution rules simply to remain functional.

On the closed-source side, the traditional advantage of security through obscurity is eroding. Modern AI models can read, de-obfuscate, probe endpoints, and reason about code at high speed. The practical difference between open and closed source is now mostly confined to backend code that never gets shared online. Closed-source code, as a result, stands on the quality of professional audits, the speed of patch deployment, and the incentive structure that keeps competent people with access looking.

Bitcoin and the broader crypto industry are placing unusual pressure on free and open-source software. The combination of real monetary value at risk, adversarial economics, and AI-scale analysis is forcing software models to evolve. Returning to analog pre-digital systems is hardly an option for infrastructure that underpins modern society. Only the most audited projects are likely to survive the pressures of AI-aided hackers and the weight of digital-first finance.

This post, "Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives," first appeared on Bitcoin Magazine and is written by Juan Galt.