Three years ago, when our team at Kassi began sketching our idea of an online service for sharing goods and skills, we were not aware that others were doing the same thing. Since then, we have found that the idea is definitely not new. This catalogue alone lists more than a hundred services that allow people to lend, borrow, swap and recycle goods, and it probably includes only a fraction of them all.

How could collaborative consumption services collaborate?

While it is great that there are so many people working to promote sharing, this also causes problems from the users' point of view. When there is more than ten sharing services working in the same city, it becomes tedious to find the stuff you're looking for or list what you have. As a result, it's difficult for a single service to achieve the network effect. A traditional capitalist approach would be to rely on the survival of the fittest. But could there be a more collaborative way? After all, our common goal is to boost sharing by mapping all the resources that people have to share and linking them together. Would it be possible to form a huge pool of resources that all sharing economy services could then use to their benefit?

I'm going to look things from a practical (read: technological) point of view here and suggest two collaboration approaches that could solve these issues: a common API and a distributed data storage.

Approach 1: Common API

A common API would be a rather simple solution since it does not force current services into major changes in their infrastructure. Basically it would mean that each sharing service would build an API according to the same specification. The method would be somewhat similar to Google's Open Social initiative for social websites. We would have to define an ontology that maps all the resources that can be shared (stuff, skills, space) and their subtypes and properties related to them. For example, in the case of goods, the specification could require the API to provide some basic information of each item, such as  name, picture, location, category (books, tools, etc) and how they will be shared (lending, swapping, giving away, etc). This would mean that when I wanted to show all tools that people can lend near San Francisco area I could use the same query to retrieve results from all the different services.

The benefit of this approach is that it would be easy to display results from different services when a user does a search in one service, because there would be no need to build a separate integration mechanism for each service. For example, if you were searching for a certain tool from NeighborGoods and did not find it, the search would then return results from Share Some Sugar and Freecycle. And since most modern online services plan on building an API at some point, using an existing specification could save time and resources.

Using this kind of API connection would benefit all parties. Those who displayed results from other services in their search would be able to offer a better service to their users. It's a good customer service and marketing practice to point to your competitors if they can serve your customer better. Those offering their APIs for others to use would get exposure and traffic when other services pointed to them, and the people would get a wider selection of available resources and would be introduced to new sharing services.

This approach is not perfect. When actually borrowing the item, the users would still need to sign up for those services. They would not be able to take their data from the original service with them. This data would include feedback received from other users and other information that is vital to facilitate sharing. A person with an excellent reputation as a frequent lender and a trustworthy borrower in NeighborGoods would become a suspicious newbie in Share Some Sugar.

How could this issue be addressed? It's not easy, but it could be done, at least in theory, using a technique called distributed data storage.

Approach 2: Distributed data storage

Diaspora is a project familiar to many due to its huge Kickstarter success. Diaspora's main idea is to create a social networking site like Facebook but with a significant difference: people own all their data and can move it as they please, and only display it to people they choose. It uses peer to peer technology to distribute data between servers (or "pods") set up by the users of the service. This means that it has no central place where all the data is stored.

Applied to collaborative consumption, this would mean that some core data–like users' profile information, things they are sharing and their reputation in different services–would be an identity that could be shared between different services. Each time a user came across a new service he could conduct a "collcons connect" (similar to Facebook Connect) which would transfer the data he selects to transfer to the new service. A publish/subscribe method could be used to ensure when some data is changed in one service, the change gets transferred to all the other services using that same data.

This approach would make it easy for people to discover new services and start using them, and therefore start sharing with even more people. It would also create a huge catalogue of shared resources which new entrepreneurs could then use in innovative ways.

Challenges

The main challenges in this kind of collaboration between services are not technological. All the things mentioned above could be done. The actual reasons that are preventing collaboration between services are very similar to those that are preventing sharing between people in collaborative consumption services: convenience and trust.

Startups have limited resources and want to be agile. The collaboration cannot take too much time away from their core business of developing a good service for their users or slow them down. Moreover, most startups have their own strong vision and want to test it first before considering collaborating with others. We all think that we should eventually collaborate, but no one is ready to take the step beyond talking.

Then there are the trust considerations. If I'm going to pull data from somebody else's service, I need to be able to rely on the quality of the data. And if I let them take my data, I need to trust them to handle it responsibly. For the biggest players, it might seem that smaller services areusing their content and not giving enough back. The small services might think their users have no reason to return to them if their data is available on the bigger hubs. And naturally, owning data can be also viewed as a competitive advantage, which is why walled gardens are so prevalent on the web.

There is no single one-size-fits-all solution for all collaborative consumption services. But there is certainly room for more cooperation than what currently exists. With this post I hope to get the discussion going. Should collaborative consumption services collaborate more? Are the suggestions provided in this post viable? What else could be done? How do we get this thing started? Share your thoughts!