> Why would somebody maintain their own library of symbols?
Adding to TD-Linux's answer...
Process variants can create situation where board reliability might be negatively affected by boilerplate PCB patterns. Yes, while things have gotten better over time, you cannot trust anything in any library without, at a minimum, a full check. And, frankly, if you are going to do that, you might as well create your own symbols and PCB patterns.
If you work in aerospace or anything where high reliability is a must, you simply cannot use stock PCB patterns. Everything has to be process qualified and tested. At the extremes you have thermal cycling and vibration testing. High acceleration can rip components right off PCB.
There are other considerations. For example, most library schematic symbols have pins arranged in some fashion that made sense to whoever did the work. This can easily lead to truly convoluted schematics that are the equivalent of spaghetti code. Arranging and spacing pins according to the design one is working on can result in very clean and easy to understand schematics. This can be especially true of analog electronics.
Another case is FPGA's. If you approach FPGA symbols in a generic per-bank style, you can end-up with, again, schematics that are a rats nest nobody can follow. If, on the other hand, you create symbols in the context of the design, things can be massively easier to work with and understand.
Yes, that means you don't use the same symbol for every design. We have created tools to manage this effortlessly. As we transition to KiCAD we are likely to port these over from Altium's VBA to Python and open source them.
Bottom line: The potential liability of delivering a design that fails because you used a third party library can be costly. People with experience have learned this is a false economy. It simply isn't worth the potential consequences, from having to redo boards to product failing in the field.
That said, for quick "non flight-qualified" prototypes and hobby projects, sure.
Adding to TD-Linux's answer...
Process variants can create situation where board reliability might be negatively affected by boilerplate PCB patterns. Yes, while things have gotten better over time, you cannot trust anything in any library without, at a minimum, a full check. And, frankly, if you are going to do that, you might as well create your own symbols and PCB patterns.
If you work in aerospace or anything where high reliability is a must, you simply cannot use stock PCB patterns. Everything has to be process qualified and tested. At the extremes you have thermal cycling and vibration testing. High acceleration can rip components right off PCB.
There are other considerations. For example, most library schematic symbols have pins arranged in some fashion that made sense to whoever did the work. This can easily lead to truly convoluted schematics that are the equivalent of spaghetti code. Arranging and spacing pins according to the design one is working on can result in very clean and easy to understand schematics. This can be especially true of analog electronics.
Another case is FPGA's. If you approach FPGA symbols in a generic per-bank style, you can end-up with, again, schematics that are a rats nest nobody can follow. If, on the other hand, you create symbols in the context of the design, things can be massively easier to work with and understand.
Yes, that means you don't use the same symbol for every design. We have created tools to manage this effortlessly. As we transition to KiCAD we are likely to port these over from Altium's VBA to Python and open source them.
Bottom line: The potential liability of delivering a design that fails because you used a third party library can be costly. People with experience have learned this is a false economy. It simply isn't worth the potential consequences, from having to redo boards to product failing in the field.
That said, for quick "non flight-qualified" prototypes and hobby projects, sure.