| Episodes | 155 |
| Mentions | 226 |
| Cited here | 57 |
| First — last | #3 — #723 |
| Top guests | Michael Gielda, Piotr Esden-Tempski, Jeff Keyzer |
| Related | kicad · open source hardware · github · altium · arduino |
Open source software is software distributed with its source code, under a licence that permits the recipient to use, modify and redistribute that code within the licence’s terms.[547] The substantive difference from proprietary software is the availability of the code itself; the other characteristics commonly attached to either label — cost, quality, support, community — are conventions rather than consequences of the licence.[547] In electronics and embedded engineering the model extends beyond applications into compilers, design tools, real-time operating systems and process design kits, and its presence reshapes vendor business models, support relationships and the longevity of engineering work.[20][501][622]
Terminology and licensing
The defining property of open source software is that the recipient receives the code and may do with it whatever the licence allows.[547] Licences described as open but conditioned on non-commercial use, or on payment once money is made, constitute a different arrangement from open source, and the distinction is material when describing a project.[239] Licence choice attracts little scrutiny while nothing is for sale, but organisations with legal teams care which licence applies, which is when the choice begins to matter.[484]
The boundary is frequently blurred in practice. The open-core pattern places a widely wanted capability outside the open licence: a virtualisation package may be open source while its USB support arrives as a proprietary extension.[114] A vendor compiler built on GCC must ship its source under the compiler’s licence, which makes the mechanism that disables optimisation in the free edition visible and removable by recompilation; the paid edition’s difference is optimisation for speed and code size rather than function.[28] The peripheral libraries shipped alongside such a compiler are usually not open: they remain the vendor’s copyright, cannot be redistributed, and carry licence terms restricting their use to that vendor’s parts.[28] An author can also be prevented from opening part of their own product by an upstream agreement — one popular development board’s libraries are open while its bootloader remains closed because the author signed a non-disclosure agreement with the silicon vendor.[713]
Economics and business models
Several recurring commercial structures attach to open source software. Charging only for the highest optimisation levels of an otherwise free toolchain works because the customer is already locked to the silicon vendor and will pay rather than change parts.[633] The distribution-with-support pattern taken from Linux — a packaged, regularly built version sold with support and installation services, with changes contributed back upstream — is the recurring model proposed for open design tools.[188] A project that outgrows spare-time maintenance can fund dedicated staff from user subscriptions rather than investors, keeping the roadmap answerable to users rather than to a platform vendor’s priorities.[657]
A services company can be paid to build something and still push the result upstream; the argument that persuades the paying customer is that they are already standing on a large amount of work contributed by others without paying for it.[547] Building in the open also functions as evidence rather than marketing: prospective customers download the artefact, try it, satisfy themselves that it is real, and arrive already convinced.[547] Fear of being copied is largely misplaced, because competitors are pursuing their own aims and publishing part of a system does not let anyone reconstruct how the whole connects; companies typically begin by opening a narrow area where doing so costs nothing.[547]
Large electronic design and embedded vendors, whose businesses were built on selling expensive proprietary software, began acquiring open source companies and stating publicly that the future of embedded development depends on the wide availability of open source tools, with revenue moving to services.[20] The scale of money involved is no longer in question following a multibillion-dollar acquisition of a company built on supporting an open kernel; the larger value sits in what an open ecosystem lets other companies build rather than in what is charged for the software itself.[501] Acquisition of a project by a large platform company does not close it: a widely used real-time kernel bought by a cloud provider remains open, and the platform-specific additions can be stripped out by users who do not want them.[510]
Not every monetisation mechanism is regarded as beneficial. Putting a price on design blocks inside a tool is argued to be actively harmful, because work that people would have given away — on the grounds that it is not what makes them special — gets withheld and listed for sale instead, draining the shared pool that everyone builds on.[163] Being free is itself an obstacle in some segments: many companies will not use a tool that comes without a paid support contract, regardless of its capability.[555] The accountability argument runs both ways: developers distrust supplied code because a reported defect can take months to fix, and the alternative of maintaining someone else’s code oneself is unattractive, so paying for software is partly paying for an agreement that can be enforced.[489] In capital equipment, vendors compete on throughput figures rather than software quality because the person choosing the machine is not the person operating it; where buyer and operator are the same person, that priority inverts.[686]
Maintenance, governance and sustainability
Publishing working code converts a gift into an obligation: users arrive wanting technical support, bug fixes and better documentation, and what began as a personal project becomes unpaid maintenance work.[105] Selling hardware whose software is written by volunteers creates a support mismatch the buyer does not perceive — the purchaser holds the hardware vendor responsible for defects in software that was given away and that the vendor did not write.[105] A common misreading is that free-to-use implies nobody spent time building or maintaining the software, which sets the expectations maintainers must then manage.[356] Publishing under one’s own name also attracts approaches from prospective clients with unreasonable expectations of free work, a cost of visibility rather than a benefit.[409]
Many widely used libraries begin as something the author wrote for their own use, published under a permissive licence on the assumption that nobody else would want it; on the Black Magic Probe and associated embedded projects, Esden-Tempski has described his libraries as originating in exactly this way.[356] A single-maintainer project stalls on the maintainer’s available time rather than on money or interest; because the source is published, anyone who wants the result badly enough can take it forward. On the I2Cdevlib project, Rowberg’s position is that seeing the thing exist matters more than being the one who built it, since anyone can take the published source and build their own version.[155] The bus-factor worry usually attaches to a lone open source maintainer, but the closed-world equivalent is a supplier going out of business, after which the software and its source are simply gone; with open source the code survives and can be picked up, maintained or forked privately.[547] Losing control of the code base is a real hazard of publishing: contributions that worked well at the outset can age badly and become the original author’s problem to rewrite later.[125]
Projects accumulate administrative obligations that nobody signed up for — trademarks, domain ownership, non-profit registration — which is why umbrella foundations are used; a domain held personally by an early contributor is a genuine hazard, as one project discovered when it was sold out from under them.[563] Open projects have very poor information about who uses them and for what; poor documentation perversely improves that visibility by generating questions whose depth reveals how far a user has got, while repository watchers and stars give only a floor on the audience.[374] The health of a project is readable from its contribution rate — hundreds of merge requests a week and a steady flow of first-time contributors indicate momentum — and momentum is a legitimate criterion when choosing between two projects that both technically fit, as observed in the Zephyr real-time operating system.[653] Submitting a driver upstream rather than keeping it in a private package improves the code through review and puts it where the next person will look for it, at the cost of exposing the work to public review; this is the practice advocated within the BeagleBoard ecosystem.[723]
Support has to be bounded explicitly. On the ESPHome and Home Assistant projects, configurations expressible through the project’s configuration files are supported, while users who modify the underlying source enter territory the maintainers cannot support, and their local changes break when a component is refactored.[657]
Forking and fragmentation
The standing objection to the model is fragmentation: disagreement produces a fork rather than a resolution, leaving many versions of the same thing, each carrying its own defects, and dividing scarce programming talent between them.[169] Multirotor flight controller firmware is the worked example: an early simple controller was forked into a cleaner version, then again and again into separate projects, some rewritten entirely and each aimed at a particular use such as racing or autonomous navigation, with four or five forks of the original code in circulation.[538]
Distribution structure matters as much as licence. Without an official binary a project cannot be supported, because when a user reports a fault nobody knows what they are actually running if they compiled it themselves; a canonical build is a prerequisite for a support community rather than a compromise of principle.[152] The absence of a central place to download a build — executables hosted on a contributor’s personal site — reads as unserious to someone deciding whether to adopt a tool at work.[441] A narrow field can support only one dominant open project, because the people who can write the code, want to work on tools, and understand the domain form a small intersection; an early competitor to a now-dominant open design tool faded rather than coexisting with it.[685] Comparing project velocities across domains is misleading: a graphics tool with a very large user base, commercial users and substantial monthly donations funds a full-time staff, and expecting a niche design tool with a fraction of that base to move at the same pace mistakes scale for competence.[697]
Open source in engineering toolchains
Controlling the whole toolchain shortens the interval between finding a defect and fixing it, and that interval governs developer productivity; contributing directly to an open compiler avoids the overhead of coordinating a change with an outside company, however willing that company is.[501] The compounding benefit is that a defect fixed once stays fixed for everyone; the corresponding waste is rewriting the same peripheral controller repeatedly without reason, as with yet another I²C controller implementation.[375] When a project hits a limit in an open component the options are to dig into unfamiliar code or to wait for someone else, and either way the schedule absorbs the delay — the same position as a silicon defect awaiting a vendor workaround.[432]
In electronic design automation specifically, the canonical representation of a design is its source rather than the artefacts produced from it, and treating it that way is what makes review and change control possible.[243] Every exported format is a downsampling of the design: Gerbers, mesh files and compiled binaries each discard the reasoning present in the source, which is why access to the original files matters more than access to their outputs.[442] A schematic can serve as the controlling document only if more than one person can open it: where each seat of the tool costs thousands, only the seat holder can make a change, whereas a low-cost or open tool lets a production engineer make and revision-control an edit at the source.[243] The capability of accessible tools is routinely underestimated: dense boards carrying several ball-grid-array packages, and high-speed serial designs, have been produced in KiCad.[162]
On the HackRF and GreatFET open hardware programmes, Ossmann’s practice is to choose open tools deliberately to support open hardware, even when they are not the easiest option for a given job, and to impose that consistency on people working with him.[198] The rationale is that coming from a software background changes what a designer expects of a tool: the assumption that a showstopper defect can be fixed personally, or at least driven to a fix through the project’s channels, is what makes a tool usable in professional work.[198] Attributing a problem to a defect is unreliable while switching tools, because unfamiliarity produces the same symptom as a bug — and the mirror image is that long-time users stop noticing their own tool’s defects after years of working around them; this applies equally to closed and open software.[198]
Opening a hardware vendor’s toolchain brings software engineers to devices they would otherwise never touch, producing improvements the vendor could not have made itself, and reduces the vendor’s own support burden of gluing separate proprietary tools together; at QuickLogic this reasoning drove the move to open FPGA toolchains.[525] A business built on a free tool should accept everyone’s files rather than only its own tool’s output, because tying a paid service to one editor undermines the reason people came to the tool.[122] Being able to compile the tools from source, or to take the vendor’s binaries, lets customers choose according to their own skills, a different proposition from a single vertical development environment.[525] Industry consortia coordinate open cores and tools — spanning synthesis tools, processor cores and the layers that tie them together — so that companies designing chips can see what they are building on.[525] At the silicon level, data under a non-disclosure agreement makes public teaching impossible: a design tool cannot have a usable tutorial if the process data needed to follow it requires signing an agreement first, which is the practical barrier open process design kits remove.[501]
Institutions can buy development directly: a research laboratory assigning paid staff to an open design tool accelerates its feature development in a way volunteer effort alone does not.[172] Once vendors converge on one framework, component selection follows the software: a sensor is chosen because it is already supported in that project’s tree, inverting the usual order of hardware and software decisions, as observed in practice with the Zephyr tree.[622] A project with clear commercial backing still mixes paid vendor engineering with volunteers, and the notable shift is that chip companies accustomed to controlling their whole software stack now control very little of it.[622] The licence cost of professional design software excludes anyone without an employer to buy it, which makes capable free tools a question of access to the profession rather than a preference between tools.[549]
A tool that simply works displaces one that requires the user to submit patches and wait weeks for acceptance: an integrated open debug probe replaced a workflow built on patching a general-purpose debug server for precisely this reason.[356] An unopinionated control program that can be persuaded to drive almost any machine suits people building their own equipment; on the LumenPnP benchtop pick-and-place, Hawes’s position is that the value a company can add on top of such a project is shepherding its user experience rather than replacing it.[686] In embedded runtimes, adding a peripheral to MicroPython means writing the driver in C, adding the macros that expose the function to the interpreter, and rebuilding the entire firmware image, which is loaded as a whole rather than as an add-on module.[323] GNU Radio, usable from either C++ or Python, covers common tasks such as spectrum analysis and demodulation without writing code at all, which is what makes software-defined radio approachable before any programming begins.[161] An interactive bill of materials generated by an open KiCad plugin is a single self-contained web page that can be hosted behind a password and handed to a client, with later versions adding trace search that turns it into a troubleshooting aid.[561]
Risk, safety and longevity
Opening a product’s design means accepting that a competitor can take it, sell it and do it better, so the position has to be defended by staying ahead rather than by complaint.[554] The concrete counterargument that stopped one test instrument from being opened was support load: publishing the firmware invites requests about every modified variant a user creates, which the manufacturer would then be expected to answer.[347] There is a line where opening code is argued against on safety grounds, such as engine management firmware, with a counter-argument that publishing it is what would let outsiders find its flaws.[347] Openness and copy protection pull against each other inside a single product decision: a custom display raises the barrier to a cheap clone and lowers unit cost after tooling, while an off-the-shelf display with published firmware lets users change the fonts and behaviour but leaves nothing to stop someone reselling the design.[682]
On security, published source makes an attack cheaper rather than possible: finding the exact instruction that copied a secret into memory took reading the source, and a closed product would have yielded to the same attack after more reverse engineering.[575] At Oxide Computer, Abbott’s approach is to publish both the code and its vulnerabilities, on the position that the value lies in the delivered hardware and software rather than in secrecy, and that outside analysis of published firmware finds problems the vendor would not.[590]
The risk calculus differs by activity: using a free tool to design is a different decision from trusting a six-thousand-dollar reel of precision components to software assembled by volunteers, which is where a professional service is bought instead.[224] Choosing an open tool trades support for control: the user can pin a version and owns the code, but all the surrounding tooling becomes their responsibility and there is nobody to escalate to unless they pay someone.[671] A practical longevity argument favours open tools even for someone who would rather pay for support: a commercial product can be discontinued, after which the user has nothing, whereas the open tool remains available.[424] The archival case is stronger still: with open tools there is no licence to expire and no vendor to lock the user out, so an old virtual machine running the version that created a design can still open it decades later.[442] Published source is likewise what makes a discontinued product revivable: the Pebble smartwatch’s development was done in the open on a public repository, and the resulting operating system is available to anyone building a device with a display, a wireless link and a phone companion application.[715]
Productivity and historical trajectory
The productivity change attributable to building on open source is measurable in at least one documented case: a networked messaging system that took six months of C programming in the 1980s was estimated by its original author, Felsenstein, at about two and a half weeks to reconstruct today, entirely because of the open source available to build on.[684] The pattern in hardware lags software by decades rather than differing in kind: the same arguments were fought and settled in software in the 1980s and 1990s, and are being repeated in silicon and hardware design.[650]
Code written with the intention that it will be read teaches, and code written only to work does not; the distinction matters when pointing a beginner at a repository, though reading code alone is not how the skill is acquired in the first place.[373]