A proposal on sharing designs and projects in the maker community.
Makers like to share their creations, but choosing where to share their work, so that it is discovered by the right people, can be prove difficult.
Anyone wishing to build a creation-sharing service has a Catch-22 situation: people won't use the service until it's deemed popular enough, yet it won't become popular without people using it.
Groups and individuals may wish to host their own designs, yet make them discoverable to a wider audience.
Instead of being another content sharing service, this site describes a proposal whereby existing, and future, services could share their data in order to create a web of things.
By sharing key metadata, services could work together to form a truly decentralised network, where participants focus on their individual needs and yet be sure their content can be easily discovered, and tracked, by the wider community.
The proposal is as simple as it is powerful.
Anyone may participate in the network by simply making a list available online of the things they wish to track. This is referred to as a tracker.
The things in the list should contain a set of required metadata which identify the thing and say where it can be found. This metadata is defined in the specification. Optional metadata may also be defined.
The tracker list may also contain the addresses of other trackers. In this way a network can be formed.
This proposal does not dictate how the list should be created or managed. So long as the tracker complies with the core specification, users and services may implement them as they wish. This gives a lot of flexibility in the type of services that may be developed to support the network (see ecosystem below).
Why would anyone participate in such a network?
Freedom, Choice, and Progress.
Say that you wanted to use a new, or specialised, service to host and present your newly designed widget, then you run the risk of it not being discovered by others simply because the service does not yet attract many, or the right, visitors. For this reason many feel obligated to use one of the large, established services, even if they would prefer not to. However, if that new service is a participant in the Thing Tracker Network then information about your widget will be made available to all participants in the network so it can be picked up and indexed by search services, shown in other trackers and made easier to discover.
Another use case: Say that your project team, hackerspace or group of friends wish to host and publish your designs on your own website. In order to make them discoverable they would also have to also be submitted to an established service, such as Thingiverse. But this would result in duplicated Things plus the headache of maintaining the information in both places. By publishing a tracker on your team's website it can participate in the Thing Tracker Network and be tracked and discovered by others.
The current maker ecosystem is ripe for competition and diversification in the field of creation repositories and services, yet innovation is being stifled by the simple fact that, without a large enough user base, many services do not attract content and traffic. The Thing Tracker Network would spur progress by fostering the development of an ecosystem consisting of boutique repositories and services which can be discovered without first having a large user base; You don't have to be large to be discovered.
A common understanding.
In order for participants to be able to share data within the network a common understanding must be established. For this reason a specification is proposed which simply states the data that is required for one member to be able to successfully discover the things of another member. It also allows a member to provide further, optional, data to aid the development of the ecosystem.
The core of the specification is a data interchange format. A document is made available, in the common JSON format, which contains two lists. One is a list of things that have been directly registered on this tracker. Each thing must have a title and a URL which points to the address of where the thing is hosted. Optionally, it may contain further metadata which further describes the thing.
The second list contains trackers that the current tracker also follows. Each tracker is identified by a URL which points directly to the tracker. Again, supplementary metadata may be available.
Note that the the list of things does not include all the things from the children trackers. This would pollute the tracker as a data source and result in much duplication. More about this is given in the technical specification.
The specification also makes suggestions on how the data might be managed and supplemented in order to provide a rich set of information for downstream services.
An open, participatory culture.
Should the proposal gain traction there are many exciting possibilities that the network could lead to. When smaller repositories no longer have to worry about attracting a critical mass of users they become able to focus on tailoring the solution they wish to offer. For example, a tracker may choose to only follow things within a specific area of interest, say everything to do with RepRap development, or only things for toys and games.
People may also start to offer applications and services that support and develop the community, and in this way an ecosystem could develop. Such services might include:
A Call To Action.
This project is now no longer actively maintained.
This site will act as a collection point for the discussions and ideas, and form the basis of a specification that can be used throughout the maker community.
The actual specification is found in a github project, to allow for forking, pulling, issue tracking and the use of a wiki.
Some of the URLs for Google+ and such are a bit long, so here are a few shortened versions: