12 September 2012

Learning By Doing

At its core, buddycloud is a set of protocols and specifications that can be used to create a wide range of familiar web features, such as Twitter feeds, Facebook conversations, and Flickr albums; as well as an unknown and boundless set of additional applications that nobody has thought of yet.

The protocols underpinning buddycloud are completely open, and participate in a healthy, ongoing standards process. Anyone is free to write buddycloud applications, and everyone will remain free to do so, without fear of licensing fees or arbitrary API restrictions. 

buddycloud threads an interesting needle: how can we enable all these powerful features, while still giving each user complete control of their personal data and their own privacy?

The solution lies in the buddycloud server, which turns anyone’s computer into an implementation of all the buddycloud protocols. We’ve written our own version of the server, but anyone is free to implement their own server as well. So long as a user’s server speaks the buddycloud language, it will be able to interact happily with all the other buddycloud servers in the world. This freedom of each user to control their own server guarantees that nobody can suddenly change the way your data is treated. You don’t need to agree to any ‘privacy policy’, because you set the privacy policy for your own data yourself.

That’s why we talk about buddycloud being ‘federated’.  Each server is responsible entirely for itself, but at the same time each server is able to communicate very tightly and seamlessly with all other buddycloud servers. The result is a broad tapestry in which the full nature and behaviors of buddycloud are made available to all.

One of the problems with existing social networks has been the desire of the parent corporation to control the user experience for its own benefit. When you use facebook, it’s impossible to forget that you’re embedded in that user experience. And the goals of that parent corporation may involve things that are unrelated to what’s best for the user; such as taking maximum advantage of each user’s retinal ‘real-estate’. By giving the user total control of their own data and their experience, buddycloud doesn’t risk this temptation.

Developing the buddycloud protocols and software architecture has had its own set of challenges to overcome. Any federated system needs developers and users in order to achieve the federation; so we’ve had to engage in a lot of advocacy, while simultaneously making decisions that affect the protocols and development framework. We recently made the hard decision to do a major architectural change to our web client, which involved abandoning work that had taken a lot of time and energy to produce; we did it because it was the right technical decision, though it required a big adjustment from our whole team. And we want to recognize and make those kinds of decisions early rather than late, so the fewest number of users are affected.

In light of that, and as another part of our advocacy, we want to make our own development processes and decisions more transparent to anyone who’s interested in learning more about us. There are a lot of debates - most of them friendly, but sometimes there are strong differences between developers. And we’re going to be publishing the logs of all our developer discussions as they happen - even our video hangouts! But more than that, we’re starting a blog that will summarize a lot of the key discussions and decisions that we engage in from week to week. And from time to time you’ll hear from the buddycloud CEO, Simon Tennant, who’ll talk about various events, hacking sessions, and the strategies behind the company.

# Back

2 notes
  1. buddycloud posted this