Ughh, the current libraries are a mess

First off, this is NOT a post of hate on KiCad or the librarians.

It IS, however, a sad statement of the truth.

One of the most common questions on this forum are about the libraries. Over the last couple of days I have found out why. Two things happened. First, I attempted to use the KiCad libraries for a demonstration of KiCad at the maker space. Second, I decided to clamp down on the data bandwidth that KiCad keeps using to talk to GitHub.

The maker space has a member that goes to the DEFCON convention every year. He brought back a wide variety of Electronic Badges. Well, on that theme I thought I could do a presentation with KiCad “on-the-fly”. Turns out, that was very challenging using the GitHub footprint libraries. In fact, I could not find a battery holder a common CR2032 coin cell. Several members had suggestions for where to look, but not a single one of us was able to intuitively find this footprint.

My projects are to a point where I need more organization of both the KiCad libraries and my own developing personal libraries. Ugghh, if anyone has done this, they know my aggravation. One of the worst offenders is having to decide to download all the GiHub libraries again, or add them all manually. I decided it would take me less time if I went ahead and downloaded them all yet again.

I’ve done some searching, and I was not able to find a coin cell holder footprint (CR2032) that matches anything I can currently purchase at Digikey.

While doing my internal library creation, I noted that there are coin cell holders in other libraries other then the “battery holder” library.

I also browsed a few other libraries, and found things that made me wonder, "Why are these in this named library.

I’ll even agree to help to fix this mess, but if I do, all battery holders are going to get moved to the “battery holder” library.

1 Like

I’ll even agree to help to fix this mess, but if I do, all battery holders are going to get moved to the “battery holder” library.

As it should be. We would welcome such assistance in reorganization.

There has not been an organizational / categorization policy the libraries to date, which has worked as expected.

Now (and in the future) the governing principle is “libraries are organized by function”, both for symbols and footprints. The libraries do not look like this currently, it is a work in progress. But, at least now we have a rule in place for what we want the libraries to look like in the future.

Some of the more recent footprint library additions show this strategy. e.g.

  • Connector_USB
  • Connector_HDMI
  • Capacitor_SMD
  • Capacitor_THT
  • Diode_THT


A major goal for the v5 release is to ensure that all library elements are properly categorized. If you want to help with that, fantastic :slight_smile:


Also, where did you find the battery holder footprint if not in the BatteryHolders library?

At the moment I can’t remember; or I would have stated the conflict. There are 3 or 4 footprints of coin cell holders, all with just the size of the battery. Example: “2032”. Just a 4 digit number.

And, I think there were some connectors in that library also.

Sorry, that I did not think to make special note of it.


Line 28 of the general “Connectors” library.

However, there were many more that I came across and was like, “WTF mate?”

I had just made the time and data to download this “most awesome library”… and no current footprint for the CR2032 coin cell holder that I could currently purchase from Digikey.


Does this mean that library symbols for SiLabs microcontrollers should have gone into microcontrollers.lib instead of silabs.lib?

1 Like

@maui Show me one that I can order on-line?

Probably more like MCU_Silabs_BusyBee or similar. I have written a Python script to extract symbols from a library and put them into new libraries based on regex filters, and I will begin the reordering process soon :slight_smile:

1 Like

1 Like

Here a few links that show what everything will look like in future:
For symbol libs reorganization (This is a massive rearrangement. Can not be done during a minor release.)

For connector footprints (Can not be done if the current one repo per lib policy governed by the github plugin is used.)

Our effort in getting the developers to kill the github plugin

As you can see a lot of this will get better in v5. (Some of it depends on the developers playing along.)
If the developers insist on keeping the current github plugin we really can’t do a massive reorganization of the footprint libs. Not now and not in the future it is way too much work for us librarians to deal with that many repos. (It is also confusing for users and for contributors.)


I guess finding data is a binary thing, yet you can be very close to something without realising it. If you had looked in Battery_Holders, you would have found what you want, and you would be posting here THANKING the library contributors for their voluntary work - oh wait, no one BOTHERS to do that.

Yet again, it seems lack of knowledge and effort on the user’s part leads to complaint about other’s “lack of effort”. It really is a theme here. Of course, KiCad libraries are deficient, that is OBVIOUS. There are several MILLION parts on Digikey, and a HANDFUL of people taking the time to contribute to the libraries.

It seems that a century or so of industrial production has turned us all into passive consumers, always expecting someone else to do the work for them, and alien to the idea of contributing to the community without reward.


ON EDIT: Wrong @ … whoops…

There were about 10 others in the room with me, and I scrolled from the very beginning, going slower over libraries that started with the letter b. Found it when I got home, same computer. Have no idea how it could not be found earlier.

I like KiCad, I think it is on it’s way to being a fantastic tool. It was a major decision for me to decide on a primary EDA package a while back when Eagle was actually a more refined product. However, that does not mean that it a perfectly polished machine.

It also appears to me that KiCad is at another important stage of it’s development cycle. With that possibly being the case, sharing a review of a user experience can point out to other long time users where there is difficulty for new users.

Digikey paid the bounty for the KiCad domain. Figured this was reason enough to justify to have a footprint for a part that could be ordered from them.

If one walks into the local book library, every book is intended to be placed on the shelf in a specific order. It is a factual statement that the current KiCad libraries are all a bit of a mess with parts flung all over.

I’m willing to take a small amount of time to help if I can.

1 Like

Sometimes I just grep the directory for keys when I’m looking for something. What was weird was I once got a hit only to find out the part wasn’t there, just a link to the PDF for some reason.

1 Like

So when you upgrade, where do the files that you created go?

These sorts of issue should not be all that difficult to fix.

There are an influx of new members, and those members should see a more refined new experience.

Why do you think it is difficult to fix?

One can simply open the symbol that does not fit the component one wants to use, copy it into a personal lib and change it such that it fits and be done with it. (At least under linux one can not save components into the system libs. Which is a good thing.)

If the component in the official lib has a bug then it might be a nice gesture to create a pull request and give others a better library.


In my opinion it is a matter of attention to the issue of detail.

In my opinion, all developers should have to install KiCad on a new OS install , every now and again, and see what the current experience is like to create a manufacture-able Pcb with KiCad “out of the box”.

My post is not a complaint. KiCad works fine for me for the way I normally use it.

Putting some polish on the things that seem to trip up newcomers might not be a waste of time.

The library problems that you are discussing have a name. It is “Big Data”. The small data solutions that you have been using are breaking down under a growing load and you need to apply some big data solutions. Reworking your small data solutions will only give you a temporary fix.

Let me give you some hints.

The way that you present your libraries looks and acts a lot like the original home page for Yahoo. You need to make it look and act like google. You need a search engine.

You need to assign a unique name to each and every component in your library. IEEE-1685 (IP-Xact) shows you how to do this.

IC designers ran into this same situation 20 years ago and we tried all the same things that you are doing before we figured it out. Learn from our mistakes.

John Eaton


Footprint naming convention for KiCad v5 closely alinged to IPC standards (Massive reorganizations can not be done in a minor release!)

Symbol naming convention for Kicad v5. (Some of our wishes need the new lib format. This means we need to wait for v6 until we can have a clean solution.)

And of course the links i already posted above:
For symbol libs reorganization (This is a massive rearrangement. Can not be done during a minor release.)

For connector footprints (Can not be done as long as the current one repo per lib policy governed by the github plugin is used.)


IP-Xact uses four fields to hold a VLNV. This includes a unique vendor name, a library assigned by that vendor, a component name assigned by that librarian and a version assigned by that component.

If you find a mistake and re-release something then you bump up the version number. Simply fixing the bug will break any design that used that part by compensating for the bug. Designers can then choose to replace the component with the new version.

The vendor maintains the master copy and you can have any number of mirrors for that component. Mirrors are kept in sync with changes made to the master.

John Eaton

1 Like