Why you should use Free and Open Source Software to design your hardware
When you design hardware, it is very likely that you want to share your design files with others. At the very least, you may want to share them with your future self, i.e. you probably want to be able to open your files and edit them in the future. This article explains the advantages of using Free and Open Source Software (FOSS) if you want to make sure you always have access to your files. In order to make things concrete, I will discuss the case of Printed Circuit Board (PCB) design, but all arguments translate easily to other domains.
Commercial not the opposite of FOSS
Let me start by dispelling a common myth. ‘Commercial software’ is not the opposite of ‘FOSS’. The opposite of ‘FOSS’ is ‘proprietary software’. A proprietary program is one for which you do not have access to the source code, or at least not in ways that would qualify it as FOSS. The Open Source Initiative (OSI) and the Free Software Foundation (FSF) maintain definitions for open source and free software respectively. FOSS is a convenient umbrella term I will use because my focus here is not the difference between free-as-in-freedom and open, but the difference between either of them and proprietary. I will use ‘open source’ equivalently as well. ‘Commercial’ just means there is money involved. You can buy support for FOSS, and then it’s commercial FOSS. In fact, many people, myself included, argue that it’s a winning combination: you avoid lock-in situations because it’s open-source, but you contribute to the sustainability of the project and you don’t expect people to work for free, which unfortunately is often the case with open-source projects. KiCad is the most popular FOSS tool to design PCBs, and you can either use it for free or buy commercial support for it.
Basics of PCB design tools and flow
So what is the problem with proprietary tools? Before I go into that, let me explain a typical workflow for PCB design in a simplified way. This will help me illustrate the issues with using proprietary tools later on. In order to design a PCB, you start by drawing your circuit using a so-called schematics capture tool. This looks like a drawing program in which you place your symbols (representing electronic components such as resistors, capacitors and integrated circuits) and interconnect them together using lines called wires. In order to place a symbol in your schematics, you typically search for the symbol in a symbol library. Libraries are stored in files, and when you place a symbol in your schematics, the information for that symbol is typically copied from the library to your schematic file.
Once you are happy with your schematics, you can start the layout phase. In layout, you draw the shape of your PCB, place your components inside and route all the copper connections between them. The schematics of your circuit usually follow some conventions: operational amplifiers are little triangles, resistors look like rectangles or zig-zags depending on whether you use the International or American style, and so on. In layout on the other hand, your components are represented by the copper footprints they will have on your PCB. This defines the final product to be manufactured, a physical representation of your circuit. Footprint libraries play a similar role for layout to that of symbol libraries in schematics. Layout tools allow you to move footprints around and interconnect them using copper tracks of different widths. They also allow you to use intermediate copper PCB layers for your tracks, which in many cases is necessary for the routability of the circuit or other reasons, such as signal integrity.
When you are done with layout, you can generate manufacturing files (e.g. Gerber) which will allow a PCB manufacturing company to build the circuit and send it to you. Other important files include the Bill Of Materials (BOM) and assembly files such as those used by pick-and-place machines to populate your PCB with components.
The problem with proprietary tools
There is nothing particular about PCB design but it provides a good illustration of the most important issue with proprietary tools: the dependency on an external entity, typically a software company, to be able to open and edit the content you created to begin with. We are so used to accepting this that we don’t see anymore how unnatural it is. Imagine you kept a hand-written diary. Some of these diaries come with a lock for privacy reasons. Now imagine that every time you wanted to open your diary you had to ask a company for the key to the lock. The company could ask you for regular payments to continue giving you the key every time you asked for it, and if you stopped paying you would not have access any more to the years of content you might have already written in those pages. Even if you were willing to pay, the company could go belly-up, or their priorities could change, and you might lose access to your diary. Sounds ludicrous, right? Yet, this is what we accept every time we generate content using a proprietary tool. The current trend for design software to be ‘in the cloud’ and for licensing to be subscription-based gives tool providers even more control over who can access files and when.
The importance of open formats
The issues with proprietary tools are lesser if you use file formats based on open standards. One good example for text files is ASCII, the American Standard Code for Information Interchange. If I write a text file using a proprietary text editor, it’s not a very big deal in terms of my ability to access my content in the future. This is because there are many open-source tools which have ASCII support, and I will be able to use any of them in the future to open my file, read it and modify it if need be. Software developers, who typically develop their software using a text editor, are blessed in that regard. They don’t even have to think about whether they will be able to edit their files in the future.
Hardware developers on the other hand evolve in an ecosystem dominated by proprietary tools which use non-open file formats to store their content. By non-open I mean that the file structure is not publicly documented. Sometimes these files even use obfuscation techniques meant to make them very hard to reverse-engineer, not to mention legal restrictions which may be enforced by the End User License Agreement (EULA) of the proprietary tool.
You may be used to exchanging MS Office files at work or elsewhere, and may be thinking that using proprietary file formats is not such a big deal after all. The difference between the Electronics Design Automation (EDA) and Office Suite markets is that while the latter is clearly dominated by one vendor, the former is split among a number of options with comparable market shares. So there are many more chances of sharing problems triggered by file incompatibility. Also, the docx, xlsx and pptx file formats are at least partially documented in a way that has allowed some open-source tools to implement imperfect but sometimes good-enough read/write support. So while the Office situation is far from perfect, it is much better than the one in EDA.
Why sometimes open formats are not the (full) solution
There is one prominent proprietary EDA vendor which uses a fully-documented format for their files. This is clearly a step in the right direction. It allows you to implement software tools which could, if necessary, make it possible for you to still access your files in the future. Even if not many people are capable of doing this kind of software development, the mere fact that it’s possible is already reassuring to some extent.
So does that mean that vendor lock-in is absent when file formats are fully documented? Not completely. The information a designer wants to store for schematics is more than just the ‘netlist’, i.e. the list of symbols and their interconnections. Some of the information we may want to keep is linked to features in the software itself which may be proprietary and not documented (at least not to the extent that you can create an alternative) such as options for Electrical Rule Checks (ERC). The same is true for Design Rule Checks (DRC) in the layout tool. Other examples include shapes that may be generated at runtime, such as teardrops, meanders and solder masks, whose geometry may not only depend on what’s in the file but also on the algorithms implemented in the software. Any feature an EDA tool supports may find its way to a given syntax used in the file format to store its configuration. In a FOSS tool, the software implementation of those features is open for everybody to see, and therefore the absence of vendor lock-in is guaranteed.
But didn’t we say that the ASCII standard guarantees full interoperability of tools? Yes, text editing is one domain where the format tells the whole story. The Portable Document Format (PDF), standardized as ISO 32000, is a similarly successful case, with open-source and proprietary PDF readers co-existing in full harmony. In other domains, you really need the software implementation as well. You may have the full information about the docx format, but without access to the exact MS Word typesetting algorithm, you will not be able to guarantee that your tool displays the document in exactly the same way as Word. PCB design tools belong in this family. An open format is not enough. One could discuss if it would be possible to design a file format which captures all possible features in a PCB design leaving no room for interpretation, but the examples above illustrate it would be a complex endeavor and the fact that it has not happened yet also shows a lack of strategic priority for this in industry.
But my EDA vendor gives me this super-good deal!
Some people invoke low prices of a given proprietary EDA tool as a reason not to worry too much. Versions of the tools with limited capabilities are sometimes even available for free! EDA vendors can give extreme discounts to users as part of their commercial strategy. For example, academic institutions often get very good deals because vendors know that these tools have a steep learning curve and once a user has developed the muscle memory to be super-efficient, they are very likely to ask for the same tool in their next job, which may be in a company paying the full standard license fee.
Does that mean that you are safe provided you work in an academic institution? Ask people working there, and you will find out that changes in the strategy of EDA providers (for example as a result of new management) can easily result in abrupt license fee increases. The feeling of helplessness in those cases is hard to describe, especially if you already have a huge number of designs done with that tool.
Zero or very-low license fees create the illusion that you will not lose much if you have to change tools as a result of a price increase, because you never paid them much to begin with. This may be true unless you and your colleagues have invested a big effort learning the tool and creating content you may not be able to access again. For example, a single PCB design might have taken hundreds of hours and multiple iterations to be completed; you might still have the Gerber files for production, but if you need to make a small modification, there is a significant cost to starting the whole layout project again.
If, on the other hand, you think that you may be willing to accept a steep increase in fees to be able to keep access to your files, I have bad news for you: your EDA vendor may be doing that very calculation for you as you read this. One cannot blame a commercial company for wanting to make more money. That’s what companies do. Whether your interests and theirs are aligned enough for you to purchase a proprietary license to their software is for you to judge. At this point it is worth noting that many users absolutely want to pay in exchange for the assurance that they will get technical support if they need it. This is a reasonable expectation when one uses a tool for important design work. As I mentioned earlier, it is very possible to buy that kind of support for an open-source tool. It is also an excellent way to help the project, funding software development work while maintaining the benefits of FOSS. Proprietary licenses typically conflate two aspects which are largely independent: the ability to open and edit your files on one hand, and the support if anything goes wrong on the other. You can certainly get the latter without compromising on the former.
Call to action
Every designer wants to be able to share designs with their future self. If, in addition, you are designing Open Source Hardware (OSHW), your motivation to use FOSS should be even stronger. Open-source tools are sometimes lacking in features and quality. This may be partially explained by the fact that developers are often volunteers who join a project to ‘scratch their own itch’. As a result, conceptual integrity and user experience may get less priority than they should. You can help develop a good open-source tool in your domain (mechanics, electronics or other) in many ways. Contributing code, helping fund development or steering these projects to make them more organized and scalable are just some of the ways people are already doing this. In software development, many of the best tools are open-source. Awareness of the importance of FOSS in guaranteeing easy sharing and absence of lock-in is a first step. This article, necessarily limited in scope and depth, is meant to raise this awareness. So, what next? If you would like to discuss further and see how we can get organized and reach critical mass in this important endeavor, feel free to post your questions, ideas, suggestions, etc. in the OSHWA Forums. Let’s make FOSS the standard way of sharing OSHW designs!
