FOSDEM
1 HN recommender · recommended in 5 months, 2018–2021
24:31 · 15K views · Feb 5, 2018
Urban Bruhin, LibrePCB's main author, introduces the open-source EDA tool at FOSDEM 2018. He explains why he started it and how its library concepts differ from KiCAD.
Linked by the author and others in LibrePCB threads as the best explanation of its design rationale.
6 comments from Hacker News
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: this 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.
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: this 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: this video (Slides: [LINK] ) Also, previous HN threads: [LINK] [LINK]
There's also an "Intro to LibrePCB" talk recording from FOSDEM this year: this 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]
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 this video ) who devised their own text based format specifically to make version control more friendly.