The plugin library category went bad pretty fast because people wanted to include their stuff and then didn’t stick around. This would happen to the libraries times 10. People would start complaining almost immediately about different contributions pretty damned quickly and wouldn’t want to hear that WE don’t maintain them because they are on this site.
In all honesty I don’t think you realize what a nightmare this could become to maintain. Disclaimers wouldn’t mean much.
I’m sure you’re right, I have no experience here.
Anyway, I’ve killed the poll, and this thread can die with it.
It was just an idea.
The “personal library exchange area” exists, it’s called Github 
I like the idea of sharing libraries - with all the caveats included of course. I remember seeing user (gonna have to dig through my memory here) Joansparky’s footprints (and 3d models), which inspired me to create my own libraries.
For me, I would welcome the OP’s idea, if only to share ideas and practices when it comes to library design, management, drawing styles, etc. etc.
It’s a natural idea and not a bad one, but understanding the issue requires knowing the 1000 former discussions about this. I wish this would work, but even without having been tried such a collaborative repository myself I understand too well that almost any attempt without a centralized management and dedicated personnel will fall apart quickly.
To add something constructive I throw out an idea about footprints. If I find a ready made footprint somewhere I usually need or want to modify it somehow. Not necessarily to make it correct for a working board, but because it’s better to make it follow my “standards” and needs. If we had a repository, it should still need to have some kind of quality control and standards, and that makes things difficult. As with the official library, people who basically want to share their footprints pretty quickly notice that to comply with the requirements (KLC) they need to virtually remake the footprint.
This would be much easier if the footprints would be minimal. The critical part is the pads. They are described as “suggestions” in the datasheets. Apart from that, the only objective information which can be found out without interpretation and variance between human beings is the component outline which in KiCad is drawn in the Fab layer. I suggest that if there would be a repository with any rules, the rules should be simple: the footprint has only the pads (and holes) as suggested by the datasheet, and the simple component outline without extra markings in the Fab layer, and nothing else. That way anyone who uses the repository know that the footprint must be modified but gives objective information about the component and nothing “customized”.
A similar idea about symbols would be to have only pins with numbers and names, and nothing else. The users wouldn’t need to type that information themselves but would need to customize everything else, including units, graphic shape and pin orientations. This is of course reasonable only for complex components like ICs.
FreeCAD has also tried such a thing. It’s a library of several Gigabytes, and it’s such a mess that I deleted it again quite quickly after installing. Libraries only have value if they are above a certain level of organization and quality. There was a recent thread about this on this forum (About a month ago) and people mostly agreed with that statement
There are already some libraries in the PCM, and “AKL” is the biggest, and I have not even installed it yet. Have you tried it?
I can see some merit in dumping the whole backlog of symbols and footprints of the “official” KiCad library maintainers into a sort of melee library. Not intended to be used as such, but to give it some more exposure and to make it easier for people to fix problems with the parts in those libraries until they conform to the KLC and can be moved to the official libraries. Preferably, each of those parts would then also have some document that describes it’s state. This info is already on gitlab. having a http link in each part to the issue / merge request may be a good idea.
Another way is to have some sort of voting or checklist thing built into each library part. For example if you’ve checked the pinout of a schematic symbol, you store that info in the symbol, and when 3 to 5 people have done that, It can be assumed the pinout is correct, and if other parts have also collected enough verification data, it can be moved from the melee library to the official library. The goal is to lower the threshold for people to help with improving KiCad’s default libraries.
Its the same with company stock lists. If a fellow designer needs a 100nF cap, there are already 24 diffrent models with 100nF in the stock list. If you dont know the history and reason of each model, you wont find the correct default one for your design. If the fellow is finished with his new design, you will find 25 caps with 100nF in the list.
For symbols, my personal preference is the Elektuur style lib. I dont use it always and for footprints I am searching first the build in libs and then several manufacturers what offer ultralibrarian or others
I once wanted to buy some generic 2k2 THT resistors from Mouser. I could not get the selection down below some 200 variants in a sensible way. When the resistors arrived they turned out to be slightly bigger then “normal” and have very thin leads. They are usable, but I did not like it much.
Not a bad idea at all. Just personal experience with the plugin category makes me think it won’t work.
This may also decrease the workload on the librarians.
That is indeed also a part of the intention behind the idea.
I am not capable of setting up such a system. It’s also just a random Idea (I have 10 of those each day) and I have not thought deep about details of an implementation for it.
I’m guessing that there are quite a lot of people who want to make small contributions to KiCad’s libraries, but for who working with GIT and making actual merge requests is too much to ask. Creating a Gitlab account is quite easy, and if parts in a melee library can be combined with posts for those parts on Gitlab, the need for much Git knowledge is removed.
Personally, I also regret that the library seems one of the most areas of Kicad what requires improvements. The reason seems neither the lack of contributors nor the amount of data what is in the library. We may see the library from data view or from program/functionality view.
E.g. there are other Ecad what store a schematic symbol 4 times in each quadrant rotation view. As Kicad rotates the symbol in schematic editor runtime it is only a quarter to maintain the library. Therefore we may discuss how perfect the automatic rotations are as they never reach the manual rotated quality with all perfect text alignments.
For the moment I did not track the efforts @craftyjon for the database approach and what it is already doing other than moving the existing sym and pretty files in a database instead the file system. With or without database I think the program view functionlities are the biggest chance of improvements for Kicads library. This is not obvious for everybody as the library already works like it is. In reality, it is possible to combine many of the above given examples what shrinks library contents to a fraction and make use more flexible.
There is already more than enough library content and people who contribute to the content but only a few contribute functional improvements for flexible use of existing lib content
Peronally I don’t want any library installed on my computer apart from my personal. That includes the KiCad library. This way I have one clean library that’s easy to search.
However, sometimes it’s nice not having to make my own part when I need a new part in my personal library. In this case I sometimes look for the part in the KiCad library and on various sources online.
The libraries I know of are:
ComponentSearchEngine
snapeda
ultralibrarian
digikey
Having a bloated user-sharing-library installed on my pc is nothing I would like. But none of the sources above let’s users share their parts (I think).
If anyone would create and maintain such a webpage, with the ability for users to vote and comment on the individual parts, then I would happily use it sporadically.
I wouldn’t share my own library since it’s atomic. It uses our internal part numbers and is not of much use for anyone not having our parts-database-system.
At least SnapEDA has user committed library items.
As far as I have understood, it’s not about storing the files at all, but only about storing the metadata.
@ janvi
The Database driven library system that is now being implemented is a completely separate system from the schematic and footprint libraries. It is not the intention of the KiCad designers to combine these, nor to populate the database. The database library system is purely a framework for people and companies who maintain their own parts database. Apparently it’s quite common for companies to have full-time employees working on maintaining such databases. But maybe this database system will also be usable to track the status of parts in the “melee library” I mentioned earlier.
@ albin
I do not understand your post. If you do not even use KiCad’s own libraries, then why respond in this thread at all? It is of course perfectly fine if you only want to work with self made and verified parts, but it’s just another way of working than this thread is for. “The KiCad developers” are aware that different users have different workflows and it’s one of the main goals of them for KiCad to enable these different workflows without getting into each other’s way. For example the database library system may be interesting for you, but the majority (mostly smaller users) may not even know it exists.
The V6 introduction of inheritance by @stambaughw was a first big step in the correct direction to shrink the Kicad Library. We need about a dozen more of features like this in symbol and footprint lib to improve maintenance possiblities for the library. My last EDA system also came without any lib and we had to do everything from scratch ourself. That was one of the reasons why we used eagle in parallel for a long time.
@craftyjon database MR claims to control the amount of inheritance. Such features would make the creation of a personal lib for everybody much more easy. You only click to items from other libraries what you want to have or at least what are similar in any way. Then the inheritance allows to overwrite properties from database to generate the private version moving to your personal lib.
@paulvdhoeven (you) closed #6981 and @craftyjon closed #6313 with hint „this is solved by the database“. I doubt about this and I am curious until I tried myself with the soon upcoming V7. If database ist complete seperate it may do the derive of symbols temporary on the fly. To use all the power it finally requires changes in schematic editor and goes deep inside the library formats what shouldnt be changed too often for reasons of compability. Read the comments of @craftyjon in issue #7436 what is exactly the topics of this thread: „ … it would be possible for people to use this feature to provide public / community-run libraries as well…“ Its a code functionality what reduces the content part of a library data and makes it easy to maintain libs.
I’m sorry if my post came out as arrogant! My points and reasons for my post are:
IMHO web-based “libraries” can be really helpful when you’re looking for a specific part. There’s probably a “market” for yet another such site with only user contributed parts. If users can give thumbs up+down on parts, a team of reviewers wouldn’t be absolutely nessecary.
A single library with every part ever being contributed by a user would be heavily bloated and hard to use if installed on the PC and used directly in KiCad.
If users would actually share their libraries, and not the parts in their libraries, that would mean a hell of a lot of libraries. Having hundreds of libraries on the PC and trying to use these in KiCad would also be troublesome.
Sure, we could all share our libraries on some platform and users could select which libraries to download and use (that would be the same functionality as currently present in PCM). But that to me would defeat the purpose.
I would probably still not find the particular part that I’m looking for. Not without installing all of them, or at least searching all of them and installing the one I need. I would then need to install an entire library when just needing a single part.
@janvi What are those numbers? Are those referring to this forum, or to gitlab?
This one is still open: Component Parts & Stock Management, partkeepr alternative, integration? (#6981) · Issues · KiCad / KiCad Source Code / kicad · GitLab I am only mentioned in that issue because I referred to it from another issue, and that other issue is closed. My contributions on gitlab are also quite modest, I am not a developer.
@albin Not interpreted as arrogant at all, just a bit confused.
Numbers are gitlab issues. I didnt see the reference and there are even different epics to similar library problem. But lets wait and see what the V7 database may improve in future.
