Planting a Seed: Diaspora’s Story (Part 1)
Things I learned from being Diaspora’s Community Manager.
Diaspora* means something very important to me. It’s the first job that gave me real experience in working at a startup. It’s also the first job that allowed me to participate in an Open Source project that I remain passionate about to this day.
In a lot of ways, this job was a dream come true; it was a byproduct of a thousand wishes about wanting to somehow be part of a big project that I believed in. This is a story about the things I learned while working there, and how it ended up changing me as a person.
Pre-History
The Problems of Centralization
Why go through all the trouble to make the web work in a fundamentally different way? As it turns out, there are some severely limiting factors in offering huge, sprawling social networks to people for free.
Consider that there are many users in many countries using Facebook at the moment. In the interest of keeping those users on its network, Facebook needs to maintain an infrastructure so that its service remains online for its billion users connecting in from all over the world.
Scaling up operations to a global size isn’t cheap. Although Facebook has done a great job at optimizing every part of its software and hardware, a tremendous amount of work and resources had to go into minimizing its energy footprint, and keep their app from slowing to a crawl. Consider also the vast amount of features that Facebook offers — enough to encompass a digital life all day long.
That’s all well and good, but without monetizing such a platform, all development ultimately feeds into a money pit — all of this development costs billions of dollars to services of this scale. A common trend is to see such services delve into selling advertising space, and offering a comprehensive suite of tools to mine user data for businesses. This applies to all sorts of information about content, correlations between who likes a piece of content, and public interactions.
Interactions with content can be put on a graph, and content can be automatically tailored to a user based on this. In many ways, a social stream gradually offers up more advertisements and suggestions than actual friends and liked pages, which now have to pay extra money to promote their own content. In a sense, it could be argued that promoted posts themselves are often done for advertising purposes.
Like many other social platforms, Facebook maintains a global presence, with users in many different countries all over the world. From a political standpoint, these kinds of companies must work to maintain a global presence, lest they risk having access cut off for purposes of censorship. These tactics are mostly in light of the success of the Arab Spring revolutions, as social media proved to be a viable platform to coordinate mass protests, some of which resulted in governments being completely overthrown.
In a sense, centralized networks provide the highest concentrations of people on a platform, effectively creating a massive silo where everyone’s data is stored. Surveillance initiatives such as PRISM tap directly into these networks and get the most bang for their buck because everyone is using these things.
The Answer
What if people didn’t have to be on the same servers and services to communicate, though?
Suppose that people using Myspace could seamlessly connect to their friends using Facebook? Myspace users would use their site, Facebook users would stay on theirs — but everything from status, photos, likes, messages, and a shared stream could pass through both social networks. Suppose that any third party could start their own site in a similar fashion and join in?
This is one of the underlying principles of decentralized networking: anyone can start a social network, and connect to other people using compatible technologies. You could say that this expands on a lot of the core concepts behind how email works — anyone can run their own email server from any domain name they like, and be able to message people on other servers. In this case, the interactions are social.
Decentralized networks are interesting in the sense that when they’re implemented well, they are much harder to censor or shut down than a centralized one, as content and data are being sent to potentially many places. Some servers now are even capable of restoring content after a node in the network temporarily goes offline, allowing for a “self-healing” network of sorts.
Users are able to set up their own servers anywhere in such a network, and can participate both as a user as well as their own service host. This opens up a lot of possibilities in how an individual person can participate on the web.
The Beginning
The year was 2010, and up to that point, not many open source social networks had been developed. For the most part, the closest thing I can remember using at the time was StatusNet, which essentially resembled Twitter but had the added benefits of being decentralized and respecting privacy.
Some people were skeptical of its lofty goals, but many rallied around its cause. The initiative itself had been influenced by a talk given by Eben Moglen of the Software Freedom Law Center about personal data and privacy.
It was part of a bigger idea about how the web could be, and the idea really resonated with people. Why box yourself into one social network when you could use any part of the web to do what you already do on other social networks? Your data stays on your server, your friend’s data stays on their server, but somehow the two of you can communicate as if you were on the same website.
A First Time for Everything
When I first used Diaspora, it looked like this.
This was the preview release of what the software looked like, and it was a significant improvement over the demo pitch in the project’s Kickstarter campaign. Word of this project was spreading through the FOSS community like wildfire, and many people’s imaginations were captured.
Sure, we had an open source decentralized Twitter clone, but what if this idea could stand on its own two feet, and provide an alternative to the likes of Facebook?
The project would go on to raise $200,000 in an era where most campaigns fell stopped in the lower 5 digits. The project got coverage from places like The New York Times and TechCrunch, and expectations hit a peak of excitement. Pivotal Labs offered them a space to work at.
What was originally intended to be a summer project would go on to evolve into something so much more than what anybody had anticipated.
Off Like a Rocket
For a while, the community of supporters waited in anticipation of a formal Alpha launch. The preview release itself was sparse, lacked a lot of general features, didn’t initially support federation, and contained several security holes that more experienced developers were quick to comment on.
After a long summer, the first Diaspora pod had launched at JoinDiaspora.com. Many different media sites gave their initial reviews of what it was like — there was some speculation over whether Diaspora had staying power in its early form. To some certain degree, they were underwhelmed, but some people remained hopeful over its potential.
For an alpha, Diaspora went through several different designs and iterations. At first, it sported an overly simplistic interface with very few features, but over time it evolved into something fairly comparable to other social platforms.
At one point, the team was putting together support for third-party applications that Diaspora could leverage. The idea of an open federated social network that could hook into apps had captured a lot of people’s imaginations.
The first of these third-party app experiments was Cubbi.es, which was a sterling example of how to take a really simple idea and turn it into something people wanted to use.
Cubbi.es was kind of ingeniuous because it solved two unique problems: federating images from pod to pod back in those days wasn’t very good, and the Chrome extension demonstrated how Diaspora’s fledgling API could be used to easily put content on the stream in a new way.
All you had to do was click a button, and any image you saw on a webpage could get shared automatically. You weren’t uploading anything to your pod, you were just sharing a linked image from somewhere else.
Even with some of the negative press going around about the project, Diaspora seemed to be fairly unstoppable in its development. At that moment, it felt like the project was really starting to blossom.
Tragedy Strikes
I never got to know Ilya Zhitomirsky personally. Aside from general interactions on the stream, our paths never crossed.
He was one of the founders and therefore core developers of Diaspora, and he had been really involved at bringing people together from within the project space. He had a lot of really interesting ideas about where Diaspora could go and what it could do. The community he and his friends had built together loved him.
On November 12th, 2011, Ilya took his own life. It was a heavy blow to the project, and the event was in the back of the community’s collective minds for a very long time. News of his death was shared around in an eerily similar fashion to news of Diaspora’s birth.
It’s hard to say what drove him to the point of suicide. Some have speculated that the pressure of Diaspora’s initial success and high expectations might have been a contributing factor. Some of the criticism was particularly visceral. Some of it was directed at the paradox that Diaspora was not exactly a feature-for-feature clone of Facebook. Others pointed fingers at the amount of funds raised, and what the creators did with it.
The startup space brings many challenges, and constant criticism over unmet expectations can definitely wear a person down over time. Things can feel especially rocky for a new venture if a business model hasn’t been set in stone yet — it’s one of the big paradoxes of creating a startup company.
If he was depressed, he never expressed it publicly. This is the last thing he ever posted, and serves as a sort of digital memorial.
A New Chapter
The Diaspora core team kept to themselves for a while. This wasn’t to say that they didn’t interact with the community; it’s just that the brunt of the project’s internal work and planning was handled by a small handful of people. Including the four founders, there were only a few other people involved in the project’s day-to-day activities.
The loss of Ilya was devastating. Progress on development slowed to a crawl for a while. Bugs piled up, issues ran rampant, and development spiraled into a disorganized mess. With that, Dan and Max turned to the Diaspora community for help.
Max and Dan had made a public post about the fact that they were willing to hire an intern to get the job done. Thinking on what had happened to the project, I felt a strange compulsion to answer. Max had asked for me to include an essay with my insights on FOSS development and how it works in different ways, and I expected that to be the end of things.
After a series of short emails, Max and Dan reached out to me with the offer of an interview.
The Internship
At times, it’s difficult to wrap my head around how I ended up working at Diaspora. I was in-between jobs, trying to get freelance work done after the last company I had worked for had gone under. In the few years prior to the posting, I had been going to school, and worked several part-time jobs.
I also was one of the first users on JoinDiaspora.com. I had found a way to exploit Diaspora’s limited invite system so that anyone who wanted to join didn’t have to wait on a long list. I made a lot of new friends on Diaspora this way.
Most of the people that used it couldn’t get their friends to use it, so they engaged over mutual interests instead. Over time, the people that stayed ended up establishing a dedicated community.
I’m very passionate about free and open technologies. I started using Linux when I was a teenager, and readily appreciated the idea of everyone collaborating on code that was being developed out in the open and shared freely.
There was just something really appealing about the idea, and so I tried to find ways to get involved in various user communities. I obsessed over pieces of software, how they were used, and how the underlying libraries and OS made use of them. Somewhere, deep down, I wanted to help these projects succeed.
I’m the sort of dude who has shower thoughts about how free software could change the world if enough people were supportive of it.
When the interview finally came, I was incredibly nervous. I couldn’t wrap my head around the idea that these people actually wanted to talk to me, and that I might have a chance to actually work on a project that I loved so much. My voice cracked over and over again. I could barely modulate the tone of my voice.
Somehow, they managed to see past my anxiety, and gave me a chance to prove myself. I was officially the Community Manager, and so began one of the greatest adventures of my young life.
Order out of Chaos
One of the biggest challenges in maintaining an active community involves organization. Things had piled up quite a bit in the wake of Ilya’s death — our documentation was out of date and messy, GitHub Issues were piling up left and right, and our community engagement had been historically spotty.
The first thing I started doing involved restructuring all of our documentation. Originally, it had served as a dumping ground for useful information, and lack of maintenance had caused it to slowly evolve into a philosophical labyrinth of true-false statements. Each week, I’d comb through Github updates, break things up into sections by topic, and pored over every scrap of information I could find. Eventually, this was restructured into the Diaspora wiki.
The GitHub Issues were a different beast. They served as a hub for figuring out recurring bugs, feature development ideas, and pull requests. I soon came to dedicate a good portion of my daily routine hovering around Github, interacting with threads when they came up.
We established “Bug Mash Mondays”, which existed as a weekly list of low-hanging fruit issues with a description from the core team as to specific problem areas. This actually was met with some great response in the development end of Diaspora’s community, as older community devs were able to mentor newer developers during the code review process.
In time, many developers would end up making feature improvements and contributions to the platform. Some people would make small but incredibly useful tweaks to the interface — other people would develop entirely new features, such as geolocation in posts.
Sometimes it took a lot of input from the core development team to explain why certain features worked in certain ways. Fostering an inclusive community was extremely important to me, so I did my best to communicate with community devs about what they wanted to do with their code.
Birds of a feather
This shouldn’t come to anyone as a surprise, but Diaspora is not alone in its goals or general concept. Nowadays, there are numerous projects out there taking a crack at getting decentralized social communication working. I’d like to think that everyone involved has a different piece of the puzzle.
Everybody has different ideas on how things should be done, and several distinctive implementations emerged over time. For the most part, these communities and platforms didn’t interoperate with one another. This is currently an innate problem of decentralized communication that is only now coming to a head.
The one exception is Friendica. While there is a significant amount of overlap between both projects in terms of aspirations and goals, the underlying differences between them caused friction in the earlier days of development. Diaspora is Rails, Friendica is PHP. Diaspora’s network has some gigantic pods with lots of people on it; Friendica’s approach has been to have people spread more evenly across nodes of the network.
Instead of being supported by any sort of crowdfunding, Friendica initially had been developed mostly by Mike MacGirvin over many years of experimentation and iteration. Its base of contributors grew organically, without much news exposure. The craziest bit is that Mike managed to reverse engineer Diaspora’s federation protocol, so Diaspora users and Friendica users could communicate somewhat seamlessly with one another. Ilya had helped Mike in making certain parts of it work.
For a while, it seemed like the Friendica community didn’t like the Diaspora project very much. There was resentment over just how popular Diaspora was for a while, and that the development team was little more than “some trendy hipster millennials with macbooks”.
With every misstep our project took, there were members of another community federating with our user-base, ready to point it out and invite people to try their platform instead. The flame wars were long, and just as annoying as any other product vs product argument out there.
The thing is, this happens in open source communities all the time. Sometimes, multiple projects will be compared to one another based on their features. There’s VI vs emacs, there’s Gnome vs KDE, and there seemed to be Diaspora vs. Friendica.
Division Lines
Here’s one of the bigger challenges in growing out an Open Source project: as a community, you can have a general vision on what you want to make. However, individual contributors in a project can have contrasting opinions on how to implement a solution.
This happens on a micro and macro level — developers in one community can argue over implementation of a specific feature, and developers from different projects can refuse to use each other’s protocols and technologies under the mindset that their own work is better.
Different developers might write new features that, for whatever reason, don’t get pulled into the main codebase. For this reason, a developer may just end up forking the original project to add their own custom features and styling.
Forking can be beneficial for enabling developers to do these things, but it can also cause massive problems. Let’s assume a developer forks a project, and adds numerous customizations of their own along the way. Meanwhile, the original project goes through some major refactoring of its own.
Authors of forks inevitably end up having difficulty pushing changes back upstream, and have even more difficulty pulling in improvements from the original project, causing an unintended breakage. Ultimately, too many things can change too quickly.
There’s really no sense in sugar-coating things. Diaspora as a project suffered from at least two of these forks happening while it was in Alpha. Halfway through Alpha development, Diaspora’s frontend was rewritten to make use of Backbone.JS, which meant that many of the hooks and even coding conventions needed to change. Many features were simply turned away because there wasn’t an alignment between the core team’s design vision and the community’s design vision.
Many of these factors can contribute to a sense of hostility between a core team and the community around it, especially when that core team is a startup and not simply a group of volunteer coders. As a measure against this, we attempted to hold weekly code chats on our IRC channel that was open for community developers and users to ask questions and give input.
Defining Identity
Many people had differing opinions about what Diaspora was and what it should be. To some end users, it was perceived as a sort of Occupy-centric answer to Facebook. To others, it represented a new kind of social experience that was only in the beginning stages of being defined. No matter which way you looked at it, though, Diaspora was being compared to Facebook. So, we explored ways to distance ourselves from that.
Here’s the thing: copying another product feature-for-feature doesn’t give people the incentive to switch. Google+ is a great example of this: when it launched, it functioned very similarly to how Facebook did. Even though Google+ has many more users today, most people stayed on Facebook.
To truly hit a tipping point between places online, Service B has to provide something more than what Service A does, but it’s less about the features and more about the way it is used. We tried to experiment with presenting Diaspora as something more than just a Facebook clone.
Much of this further design emphasis focused on making content more meaningful to a user. Max had posed the question several times — “What does it mean to really own your own data? What does data mean to you, and what can you do with it?”
We were curious about finding new ways to make content useful and meaningful. At the time, a lot of these redesigns appeared to make sense. We were thrilled to find new ways to make content more expressive, and we wanted to contribute to making an awesome social experience online.
Some members of the community really loved the new design. Others hated it and asked for a way to opt out of it.
Growing pains
Here’s an uncomfortable insight: a startup whose premise is centered around decentralization and user data privacy is not in and of itself profitable. Even if you’re offering a hosting solution, you’re probably eating a good amount of the costs until you get enough customers to validate your business model. At the moment, people are more compelled to stay put on social networks that they don’t have to pay for.
For the dedicated core team members to continue working on a day-to-day basis, we needed to figure out a good way to keep development funded. We weighed our options and looked at different opportunities. I recall at one point offering to forgo my paycheck if it were better served to our graphic designer and coders.
At the time, Y Combinator seemed like an obvious solution to go with. They’re essentially like a boot camp for startup companies, and Max was familiar with a handful of people that had gone through YC before. We looked into it, and found ourselves pitching the concept to them.
The goal was to highlight the various features that made people stay with Diaspora while also showing off some of the visual bling we had been putting together.
Our demo came and went, and soon enough Diaspora became a Y Combinator company.
Maker I Owe
The beta designs developed by the core team would one day branch off into a new development: Makr.io. The site initially started as an experiment to put all of our beta designs together on a fork of Diaspora, with the intent of merging the best improvements back in.
The initial vision was to take everything that was great about Diaspora, and turn it into a sleek, visually appealing playground for expressive content. Essentially, it turned into a spiritual successor to Cubbi.es, and worked in similar ways to it. At the same time, it retained all of its social networking capabilities.
A lot of Diaspora’s userbase gave feedback about Makr. Some liked it, some didn’t get it, and everybody else got pretty upset by it. In fact, this discussion thread I started holds the record for “longest conversation on Diaspora ever.”
Still, there was something appealing about collaboratively remixing content on the web together. The spirit of what we were trying to do with Diaspora — give value to personal data — remained largely intact in the early days of Makr. It started to look pretty nice, and had its own community of users that also happened to use Diaspora.
Then, something happened. It didn’t happen all at once, but at some point, Makr changed in the interests of redefining itself. There was some speculation as to why the core development was now focused on Makr when Diaspora still needed tending to.
Over time, Makr pivoted into calling itself a meme generator. We had developed a feature where users could remix each others’ posts, and we tried to throw little internet parties around it. I couldn’t shake a sinking feeling.
On its own, it wasn’t too bad. The remix parties were fun, and a few social media brands expressed interest in playing around with it. If Makr had existed as an app for Diaspora, that would’ve been fine.
After a while, I realized that I didn’t really care very much about Makr. I was kind of disappointed to see that this was where we were going. The app itself wasn’t bad, but it lacked the spirit of purpose that Diaspora had.
I found myself becoming very cynical. With all core development focus on Makr, I started to feel that Diaspora was dying from the inside out, and had grown into a sad state of affairs. The API needed to be rewritten, and Cubbi.es had stopped working. Half of the user interface was in Beta mode, half of it was using the old Diaspora style.
Late one night, I told Max that something needed to happen — I wanted to dedicate all of my time to Diaspora, and stop focusing on Makr. He agreed, and I began tending to the project on my own.
After observing enough conflicts and issues for long enough, I had a much clearer idea of what to do next. I drew up a game plan, rolled up my sleeves, and got to work.
This concludes Part I of Diaspora’s story — Part II will focus on how the community came together and moved forward. If you liked this, please check out my publications: We Distribute, and Antifiction.
You can also check out the latest updates on the Diaspora project at: https://blog.diasporafoundation.org/20-diaspora-version-0-5-5-0-released
