Introduction to LibrePCB A new, powerful and intuitive EDA tool for everyone

U. Bruhin (the primary author of LibrePCB) answered this question on Reddit ( [LINK] ): ---Quote:--- Hi! LibrePCB has some very new concepts, especially for library management. You should take a look at my talk at FOSDEM: [VIDEO] (Slides: [LINK] ) As these are extremely different to KiCad's concepts, it would be very difficult to contribute that to KiCad because they need to provide backward compatibility. And KiCad already has a lot of legacy code, so it would become even worse when changing very fundamental concepts. It's very questionable if KiCad developers even would accept such fundamental changes - actually I'm pretty sure that they wouldn't agree with some of LibrePCB's concepts. So the only way was to create a completely new project. And LibrePCB 0.1.0 is only the beginning - I have many more ideas how an EDA tool should look like. With a standalone project I'm much more flexible to implement new features than if every feature would need to be contributed to KiCad.

There's also an "Intro to LibrePCB" talk recording from FOSDEM this year: [VIDEO] It explains some of the core design concepts and the rationale for them. In case you don't have time to watch the video, here are the slides: [LINK]

Before people start asking: Comparison with KiCAD and Eagle: [LINK] Talk by Urban that explains why he started LibrePCB, and how the library concepts are different from other similar tools like KiCAD: [VIDEO] (Slides: [LINK] ) If you want to try it: [LINK] Previous HN discussion: [LINK]

Here's a video from FOSDEM where Urban (the main author) explains why he started LibrePCB and how the library concepts are different from other similar tools like KiCAD: [VIDEO] (Slides: [LINK] ) Also, previous HN threads: [LINK] [LINK]

I haven't used any of these before, but this LibrePCB talk explains why they wanted an alternative: [VIDEO] Horizon docs have this explanation: [LINK]

It's something we thought about, but I think it's somewhat orthogonal to the question of serialization - you still need code to go back and forth between the representation in the database and the native data structures. See [LINK] for a deeper discussion of issues around a file format for a font editor. One of the biggest current pain points is dealing with merges in version control (usually git). I think there are ways of dealing with that in an sqlite-based file format, but I worry it would require some custom tooling, especially to make sure invariants aren't violated. Another interesting example is LibrePCB (see [VIDEO] ) who devised their own text based format specifically to make version control more friendly.