The article and project come across as so much being about building robots, as building tools which are capable of building physical things (including robots).

The article and project come across as so much being about building robots, as building tools which are capable of building physical things (including robots). The emphasis is on the tools, not the product. One can then ask the question "where does the tool stop and the design begin"? With proprietary CAD/EDA systems it's reasonably clear, in that the tools are typically in the form of binaries, so the tool is "the stuff for which there is no source". With open source tools, it's much greyer. Which side of the boundary does a library with source lie? How does the boundary change with time? Say you design a product with free software tools, then others build on top of that product. Is your product now a part of the tool? This, to my thinking is a competitive advantage of the open source design tools: products can be incorporated back into the tools used to design them, thus extending the tools and allowing the effort expended in the design to be reused. It's also an area that seem to be largely neglected. Library management is generally the weakest part of the open source EDA/CAD tools, at best trying to emulate the commercial library offerings, but ignoring the unique ability of open source to gather extensions in from the associated ecosystem. Software tools at least some of this, in the form of collections like CPAN, github and so on. I'm meandering here, but is anyone aware of an effort to do for the EDA/CAD world what github does for the software world, but even more than that to offer integration with the tools? Sort of like Diaspora (peer-to-peer) meets github (distributed RCS with social) meets CPAN (integrated) meets OpenCores (EDA/CAD).