The future of eCad

Reposted from the Contextual Electronics forum where members were discussing Altium and Kicad.

I’ve been doing a little thinking about this subject. Most PCB designers lock themselves into one tool and use it exclusively. There are reasons for this as you might build up reusable libraries, develop tooling to integrate with inventory systems, etc. Thinking about the software development industry, what would happen if a programmer insisted in writing everything in one programming language? Or what would have happened if all programming languages were still commercial, proprietary products? Today, we know that is absurd – we reach for the tool that best fits the job. Most developers are fluent in at least a couple programming languages. We use C/C++ on microcontrollers/U-boot/Linux, Go for cloud and embedded Linux applications, Javascript and Elm in the frontend, etc. We build up libraries in multiple languages. Many projects require multiple languages to build the entire stack. The availability of free, low friction tooling is one of the great contributing factors in the explosion of open source software. There are plenty of companies innovating on top of these programming languages and providing additional tooling. However, almost no one (with the exception of several MCU tool vendors) is selling a C++ compiler (does anyone remember Borland?). Most C/C++ development today is done using GCC or Clang. Would Linux have ever happened if the GCC compiler would not have been available? I doubt it. Access to open tools are a critical ingredient in open ecosystems.

KiCad is at an inflection point as of version 5.1 – it now has the basic features needed for many PCB designs and development seems to be accelerating. Just as GCC was one of the key ingredients for kick-starting the open source software movement, KiCad may fulfill a similar role in the open hardware movement. Although a few vendors in the highly fragmented eCad market will surely disappear in the next few years, this loss (though difficult for those involved) will be negligible compared to the opportunities in an expanding market enabled by open tooling. As the open hardware movement expands, re-using open hardware designs will start to become the norm. With its open database formats, KiCad will likely be a critical ingredient in this. Today, no one thinks of using Borland C++ for a project, not because it was not a good product, but because the pieces you depend on (Linux, libraries, etc) all use GCC.

Most low level tooling is destined to become open source. It has already happened in the software industry, and it is now happening in the hardware and chip design industries. I have witnessed Microsoft fighting this for most of my 30 year career and only recently have they finally embraced OSS. Hardware tooling vendors will eventually do the same. In the end, it will not be a loss because the overall market will expand and there will be more opportunity. Smart tool companies will move up the stack and embrace open projects to solve the lower level pieces.

Altium will certainly have its place for a number of years for implementing large high speed designs. But instead of looking at KiCad as stepping tool to Altium, it might be better to view KiCad as just another tool in your toolbox that will increasingly become more and more relevant in the open hardware ecosystem. For simpler PCB designs that you plan to maintain for 5-10 years, is a proprietary tool really a good choice? In 10 years, KiCad will likely still be around and going strong. I’m not so sure about Altium.