I believe the ecosystem idea requires only what's described in this document . Once we have that, or if we have enough resources, in parallel to that, we could also develop some extras. This document describes one of those extras: a public footprint/symbol/resource library.

Service: library repository

• a repository is a collection of data files in an interchange and/or in random native formats
• there are existing examples out there, including gedasymbols.org and random cvs, svn, git repositories of users
• we shouldn't expect to have a single central service for this; we may run our own service any time, but it's even better if we design our formats and tools to let people easily set up their own services
• such separately ran and maintained repositories would have different goals and policies; we shall accept that and be happy about that; we should distribute file formats and tools, not policies and ideologies.

How my favorite service would look like

(Meanwhile I've designed, implemented and started a service called edakrill, using these ideas. In the below list I mark points that are already done by edakrill.)

• project-neutral - not a gEDA or KiCad or eagle or qucs or ltspice library, but a generic user library. If done with converters and/or interchange formats, neither the originator nor the consumer project would matter. (done)
• optimized for multiple UIs:
  • CLI access (e.g. through a VCS client) (done: svn)
  • web access (done), maybe even web2.0
  • remote repo integration in editors (e.g. pcb-rnd has strong support for this) (done)
• backed up by a version control system in the background (done: svn)
• instead of complex, pre-designed meta-data systems, offer free form tagging, like openstreetmap does:
  • tags are free form key=value pairs, both key and value are simple strings (done)
  • let tagging conventions emerge (done)
  • let these conventions be specified and maintained by the user community (done)
  • do not split the repository on a per uploader basis - that's the least useful information for an end user (done)
  • maybe implement a separate namespace for "signed" tags; e.g. some registered user would validate a few footprints and would tag them "went on copper and looked good"; if it's a signed tag, end users have the chance to validate the source of the tag and other contributors can not change or overwrite this tag
• content licensing:
  • the ToS would say users must not upload footprints not drawn by themselves (done)
  • chose 2..3 reasonable licenses and require the user to specify which one the footprint uses upon upload (partly done: licenses not restricted but strictly tracked, only open source contribution accepted)
  • optionally have a separate distribution and use license (done)
• first support footprints and symbols because we have converters for those (done); gradually extend to 3d models, FEM, spice, schematics, PCBs as common formats and/or converters emerge.