Not true. Today 100% of users do not have a place to record the actual part number you can order and the manufacturer, both of which are required in order to actually make a board.
More than 90% of users have absolutely no need for a database-driven component repository. It might even be more than 95%. This is rare because it is a lot more work than working with simple component libraries. Discussing database-driven solutions in the context of what I am proposing needs fixing simply isn’t relevant, except in the case of noting that the approach I am proposing would actually enable that 1% to 10% of users to link to a database if they need to.
KiCad, today, out of the box, requires the user to jump through hoops in order to create a BOM that contains actual part numbers you can order. If you don’t touch anything, don’t add fields, don’t install plugins, write your own, edit existing plugins or, worse, manually edit and maintain a BOM, you cannot go from a stock KiCad install to ordering parts. The information is not there. Anywhere.
At a minimum you have to add fields in Schematic. Which is a broken solution because you’ll have to do this over and over again in every single project. Yet, again, the point --which is an important one-- is that if you have to do this to every part, in every project, for every board you do, it is yelling and screaming at you that something fundamental is missing.
Several posts back I presented a simple analog low pass filter schematic and asked people to go through the exercise of implementing this super-simple design using stock KiCad (no plug ins, no added fields, no hand-created or managed BOMs) to then arrive at a design you can actually build. Anyone who attempts this task will fail. There is no way to record and manage the two most important bits of information you need in order to complete it: part number and manufacturer.
That’s a problem. A serious one at that. By establishing no baseline standard it drops everyone --including plugin writers-- on their heads to fend for themselves. This means that every KiCad project is an albatross with different and confusing decisions and no standards.
Let’s say you wanted to have a website where KiCad designs could be shared. Manufacturable designs. Designs with real BOMs and part numbers people could order. Well, the first thing you’d have to do is add part number and manufacturer fields and make that standard across all projects posted on this site. Without that it would be a royal mess.
Adding these fields --and the internal functionality to semantically support them-- will provide for a rich ecosystem where designs can be shared with ease and standardized plugins can do great things.
This isn’t about imposing or forcing anyone to use them. The “Datasheet” field is a good example of this. You don’t have to use it. Not at all. You can leave it blank. And yet, if you do, it is embedded with one special property, if you click on a part and type “D” it will open that link on a browser. That is fantastically useful. And that precisely the kind of thing I am talking about when it comes to these much-needed fields. Adding the fields to the libraries isn’t sufficient. Adding them to the schematic manually or through “Edit Field Symbols” isn’t adequate or sustainable. The right path is to have these fields carry some weight in the form of KiCad functionality that makes them more than just a text field in the library. Just like the “Datasheet” field becoming a link you can access with “D”.
What I find interesting about this discussion is that I know, without any shadow of a doubt, that everyone participating on this thread who isn’t doing hobby projects or just hacking has to deal with this issue. Nobody in that group can build a board without real part numbers you can order. In that context, it should really bother you that KiCad makes no statement about this and provides no minimum viable product to establish a baseline standard for it. Your life would be far, far simpler if they did. The tools you would have access to would be far more powerful. The baseline ecosystem, which likely includes more than 90% of the user base would be far better served.
