Why you should use Free and Open Source Software to design your hardware

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.

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

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.

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.

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.

Related posts:

The overall risk of adverse side effects associated with other treatments for prostate cancer, such as erectile dysfunction and incontinence, is greatly reduced by HIFU’s(العلاج بالهايفو في الشارقة…

This Article is all about Low code Machine Learning using Pycaret framework. it’s really popular yet handy framework by which without explicitly focused on Coding it helps us to focus more on data…

Awareness is a state which runs on a continuum with enlightenment is on the top, and enchantment on the bottom. There are a lot more people on the bottom than the top. So they say being enlightened…