Interview with Wayne Stambaugh about KiCad Electronics Development Application – Pt. 3

In our second post covering this conversation with Wayne, we discovered that there is a little bit of an itch for some folks out there that can only be scratched by open source. I am glad Wayne chose KiCad. Again, with the duplication of efforts, like building components, an engineer’s dream is to work on new and exciting projects, not duplicate what others have done. It’s one of my dreams too, Wayne. We also saw how old Wayne really is . . . (I mean, it was hard to find the Teradyne L210 on Google, but there are some used ones for sale for any interested parties). And he talked about the importance of teamwork with KiCad releases. Especially in the open source community, getting all the right pieces together can be like herding cats sometimes, yet the KiCad team can accomplish so much because of their passion. Good luck with that Wayne; may the Force be with you.

In Part 3 of this three-part series, we’ll take a deeper dive with Wayne on the actual KiCad electronics development application.

JP (Jeremy Purcell): What makes KiCad the great choice for designers?

WS (Wayne Stambaugh): That KiCad will never use file format changes or change the license agreement to get more money from our users. I think what recently happened with the Eagle licensing was a wake-up call to designers. As more and more hardware is being released under various open hardware licenses, using a proprietary IDE makes little sense. KiCad seems like the obvious choice in this case. Personally, I still think the KiCad schematic editor is one of the easiest I’ve ever used.

JP: Share one of the great hurdles you have run into with KiCad.

WS: One of the most frustrating things is spending time and effort to work with a new developer to get them up to point where they have commit privileges to the KiCad development repository, only to have their contributions drop to almost zero due to job or life changes. I understand that this is to be expected, but it takes time to get developers to the point where I am comfortable enough to make them part of the lead developer’s team. The other big hurdle is that I do not scale, and I do not have any more time than what I already commit to KiCad, so many times I am the bottleneck when it comes to KiCad development both in terms of project management and code contributions.

JP: Where does KiCad need the most help?

WS: I don’t think there are too many areas in KiCad that couldn’t use more help. Documentation is always one thing that tends to lag behind development, so if there is a weak spot, that is probably it. The other area is infrastructure. Currently KiCad development is split between using Launchpad for source code development and Github for library, website, documentation, and translation repositories. It would be nice to have this all under one umbrella that the KiCad project has control over rather than split between two competing tools that we have no control over. This would be a huge task and require hardware and developers with experience in setting up and maintaining Git repositories, bug trackers, mailing lists, etc.

JP: Do you hear a lot of talk about KiCad in the professional world?

WS: I have heard from various sources that would suggest that KiCad is making inroads in the professional world. I know board vendors have reported a significant increase in the number of Gerber files created with KiCad where the Gerbers contain the tool used to generate them. To me this one of the most encouraging things about KiCad. I have always worked on KiCad under the assumption that the target is professional users.

JP: Where do you see KiCad going in the future? If you had unlimited resources?

WS: World domination! Sorry, I couldn’t resist. In all honesty, there is no reason, with unlimited resources, that KiCad couldn’t become the dominant EDA software. Even with the limited resources we have, we continue to make inroads because we will slowly add more features, and users will not be able justify the cost of proprietary tools unless they have very specific requirements.

In Part 1, we talked with Wayne about how he got interested in electronics and coding. In Part 2, we explored with Wayne his thoughts on open source coding and teamwork. What an interesting and complex thing the KiCad project has become!

I’d like to personally thank Wayne for his time and sharing his passion with us. We share your passion!

Thanks for tuning in!

Información sobre el autor

Image of Jeremy Purcell

Jeremy Purcell es el Gerente del Programa de Herramientas de Diseño Digital y es responsable de involucrar a los proveedores de herramientas y de desarrollar la estrategia sobre los activos de diseño. Se unió a Digi-Key en 2006 y ha trabajado como Ingeniero de aplicaciones sénior en varias campañas sobre el intercambio de información con la base de clientes y el compromiso de los clientes dentro del negocio. Jeremy tiene una licenciatura en Ingeniería Eléctrica de la Universidad Estatal de North Dakota en Fargo, ND. Le gusta pasar un par de semanas cada verano arreglando y haciendo funcionar las máquinas de tracción a vapor y el resto del año pensando en ellas.

More posts by Jeremy Purcell