Bitcoin Magazine

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

Closed versus Open Source code has divided the Bitcoin and broader crypto industry for well over a decade. Bitcoin advocates have long argued that the financial infrastructure of the world should be built in public. Transparency and auditability, they say, are non-negotiable when real money is at stake. Yet the app and legacy layers of finance often disagree.

Yet the recent Coldcard hack, a popular self-custody hardware wallet where users lost over $100 million worth of bitcoin (more than 1,500 BTC), cast doubt over what “Open Source” actually means. It revealed that perhaps most people, even many hardcore bitcoiners, are poorly educated on the Open Source software development philosophy and when it fails.

The  Principles and Terminology

The language around Open Source can be complicated. Free and Open Source Software (FOSS) and Free/Libre and Open Source Software (FLOSS) refer to 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 a common quote heard from 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, availability of source code 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 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’s own FAQ states the difference explicitly: “Is this ‘Open Source’? No.” It notes 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 having the badge of approval, being able to wave a FOSS or FLOSS flag, is not the point. Commercial liberty in FOSS unlocks third-party incentives to test and review code that might otherwise not be there, critics argue.

The four freedoms form the philosophical core of Open Source. In practice they rest on an economic assumption: that enough motivated people will actually examine the code. When that assumption fails, the system produces a classic tragedy of the commons, a situation where a shared resource is overused or neglected because individual users act in their own short-term self-interest rather than in 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. This happens when there is misalignment between the short-term self-interest of the individual and the long-term interest of the group. Sometimes alignment exists; sometimes it does not.

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.”

As a result, Open Source does not create safety by itself. It creates the possibility of verification. Whether that verification occurs depends on incentives, skill, and attention. Historical FOSS is believed to harden over time as vulnerabilities are discovered, disclosed and patched, creating solid foundations others build on top of. The Linux kernel is a great example of such 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 prescient large-scale example of pure open-source functioning in the wild. The software, which runs behind most Bitcoin-related infrastructure, is released under the MIT license. Its development process is broadly 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 (acknowledgment and agreement with the goal), Approach ACK (agreement with the goal and method), ACK with a specific commit hash (tested and approved for merge), or NACK (disagreement, which should be accompanied by technical reasoning).

Maintainers weigh consensus among contributors and the technical merits of a change before merging. Consensus-critical changes face a still higher bar and usually require a Bitcoin Improvement Proposal and extensive multi-year discussions 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 reality 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 carry comment histories stretching 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 thus 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 over 5 years of being used in production. Compare that to the 512 stars worn by the trezor-crypto library alongside 212 forks, or the 793 forks and 1.8k stars of the more modern trezor-firmware. 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.

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, per Galaxy Research. Bitcoin’s censorship resistance and immutable transactability create both a powerful 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 also shrink the circle of people with both the legal right and the economic motive to invest deep attention. Alas, the burden of code review falls back on the company under a restrictive license, placing it in some sense closer to closed source than open.

How AI Changes Open and Closed Source Development

Artificial intelligence is now also altering 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 demonstrated that systematic AI-assisted review can surface issues at a scale and speed previously impractical for purely human teams.

On this front, it is worth noting that 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 that the American developers lament.

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 stay functional.

Source: BitcoinMagazine