This project was born (like many other open source projects) out of one person's frustration. After ten years of tinkering with electronics I simply had too many components, gadgets, and tools to keep track of. When designing a project, however, I needed to know what I had in stock to avoid duplicate purchases.
My first attempt at inventory management was a complete failure. It was a PHP+MySQL GUI that had two tables - one for tools and one for parts. There was no parametric search; components simply had a string description like "Resistor - 100 ohm - 0603 - 5%". There were no connections between the same part in different packages - the same microcontroller in breadboardable DIP package or a tiny SSOP package would be considered completely different.
After spending a while tossing ideas around I came up with a new schema and refined it with the help of some of the regulars in ##electronics on Freenode (one of whom has expressed interest in contributing to the project).
The new architecture is a client-server model which will allow any number of front-ends to be developed for the same database. We are currently doing an HTML+AJAX client and a gtkmm-based PC application and plan to explore mobile apps in the future.
Data modelThe core concept in Penguin is that of a device. This is associated with a set of properties such as "maximum working voltage", "clock speed", "memory size", etc. A device represents the internals of a component without relation to the packaging.
A device is then associated with a package type to become a physical device. To give a concrete example, "ATmega328" is a device and "ATmega328 in 28-pin DIP" is a physical device. The user of the system can track how many of each physical device they have in stock, as well as optionally storing a "minimum stock amount" for popular parts. When the actual count is less than the minimum the user will be prompted to purchase more.
A physical device may be purchased from one or more distributors. A (physical device, distributor) tuple, plus some other metadata such as the distributor's internal part number, is referred to as a distributor device and may be associated with one or more price quotes, each for a specific volume. Prices change over time so we intend to implement an interface to update quotes via a web-service interface (if provided by the vendor) or scraping of the HTML (if left with no choice)
Devices are described by datasheets. One device may refer to several datasheets (complex CPUs often have dozens of PDF's in their developer manuals) and several devices may refer to the same datasheet (memory devices in the same family with different capacity, for example).
Once the user has designed their project they may create a bill of materials, which specifies how many of each physical device is required to build their project. We intend to include cost-minimization code which, given shipping prices from each distributor, will determine the least expensive way to purchase a given number of copies of that BOM - in other words, how many of what to buy from which distributor. The optimizer may be instructed to not buy extras of parts that are already in stock (though if not enough are available, or the order would deplete stock below the minimum, the necessary number of units will be added to the generated orders).