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?
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.