My last post was discussing the state of social media (and frankly, the internet), and a possible future. I feel like I can say relatively objectively that things are pretty broken as they currently stand, in an actively harming society sort of way. But when you’re entrenched, it can be incredibly difficult to see a way out, even if you know you need to. I wanted to take a minute to talk about some of the hurdles to moving on from this mess. (Fair warning, this is a little long.)
Money
“Money makes the world go ’round.” It’d be swell if we as a society weren’t so driven by financial greed, and instead worked towards a fairer, more equitable world for all. But for now, it’s the fuckin’ truth. Things cost money to function, and the people running those things need to make a living.
I hate to be mercenary about it, but a big reason developers (and support, and sales, and lawyers, and…) gravitate towards larger companies comes down to money. The larger corporations have the resources and wherewithal to pay at the top of the scale for those positions, and do so to attract the best talent they can. (Anecdotally, when I was at Dropbox, there was a policy to regularly assess pay rates compared to the rest of the industry, and to keep all employees in the top x percentile for their role. It’s been a few years, so I don’t know if that’s still the rule, but it does make the point that companies with the resources to do so aren’t afraid to dangle a juicier carrot.)
Even if you want to look at things more altruistically, it still largely comes down to money. Fresh engineers want to work with the best, for the opportunity to learn and grow. The “best” are financially incentivized to stay at these large corporations. Thus, the fresh engineers want to work at the large corporations. N’est-ce pas?
You might hear a lot of rhetoric about making lives better and changing the world and having an impact, and for a percentage of developers out there, it’s actually true. But let’s be honest: for a lot of folks, it’s just words. You’re not making the world better by improving clickthrough rates on a viral video. You could go work for a non-profit, or a small company working explicitly towards the social good. But they’re not going to pay nearly as well, and you’ve got student loans to pay, and also it’s just nice to not constantly be sweating over bills.
Also, there’s a certain amount of prestige to be able to say you worked for a major company. As much as we’re all loathe to admit it, we all have at least a little bit of ego, and it feels good when you can say you work at X, Inc and others immediately know who that is and what they do.
Bringing this back around to the topic of social media: decentralization, returning to a many-nodes version of the internet, also decentralizes the money (and the talent). A service with ten thousand users, or even a million, has a different financial profile than a site with fifty million users or five hundred million users (to speak nothing of the behemoth in the room, Facebook). You’re not going to attract investor capital for a service that size. Which means you’re relying on finding a monetization model that will allow the service to be sustained.
Let’s do some napkin-math. Let’s say you set up a Mastodon instance that serves a community of ten thousand users. Based on some (very helpful) stats provided by existing instances, this would cost around 250€ (~$285) per month, or 3000€ (~$3420) per year. That’s just to run the instance: that doesn’t cover the cost of moderation, maintenance, any custom development, or other human costs to maintaining that service. That means if you set up a Patreon, or a freemium subscription model (or other similar ways to take in some money), at $5/mo, 57 of your users would need to be throwing in some cash, just to keep the instance running. That’s ~.5% of your users, which seems pretty achievable.
Great! You can effectively keep a service running, sustainably. Now, let’s add a living wage for one developer/maintainer. The average pay for a system administrator in Portland, Oregon is somewhere between $58k and $65k, depending on which salary reporting site you listen to. Let’s call it $60k to make the math easy. That’s $5000 a month. At that same subscription cost of $5/mo, you need a thousand users to pay in, or 10% of your overall user population. That… feels a little less achievable. You can usually get that sort of surge in a pinch, but maintaining that percentage is significantly more difficult. “Successful” freemium models rarely break 10% (barring a few outliers, which really can’t be relied on), with most reported percentages being closer to 2-6%.
So, just to get to the average pay rate of a larger service in a similar role, your service needs to exceed expectations, and then stay that way. That’s a pretty strong disincentive for engineers and administrators to go start a decentralized service instead of working at a nice, kush, megacorp. (That isn’t even getting into benefits, the overall costs of which account for ~30% above your base pay, according to the US Department of Labor). Oh, and let’s not forget: that’s to pay one person.
Don’t get me wrong. Lots of sites and services out there manage to make it work, and will continue to make it work! But there should be no illusions about how that’s achieved for many of those projects: they are labors of love, where the costs of the service (in terms of time and manpower, if not infrastructure) are volunteered by individuals. There’s a limit to how far that can sustain itself, and is a major hurdle for broader adoption of decentralized services.
Technology
I commented before that I’m optimistic about decentralization+federation helping make a more useful, less toxic social media, and pointed to specifications like ActivityPub to help make that a reality. But this shift is still nascent at best. ActivityPub only became an official recommendation in March, 2017. It takes time to develop applications that follow this standard (and to adapt existing applications that may have implemented an earlier draft version of the specification), and we’re really just starting to see the first wave of these applications now.
In other words, the technology has potential, but it’s still early. Even what sort of applications can potentially be created is up in the air. This is potentially exciting for developers, but does very little for users who may want out of existing silos, but have nowhere to go.
Then there’s the issue of usability. Open source projects are notoriously bad at attracting designers who understand good user experience design, and especially in early development, features are coming quickly enough that the emphasis tends to be on “does it work?” rather than “does it work well?” So you end up with services and applications that are technically functional, but no one can figure out how to use. (This isn’t even getting into a11y, i18n, or l10n, which frankly even large corporations are frequently terrible at.)
Services are built on top of technologies. Both the technology being used and the service that is being created need development support (which ultimately means financial support). In some cases, these projects end up sponsored or supported by a larger corporation (for example, React is maintained by Facebook, as is GraphQL), but this becomes less likely for projects that would disrupt or compete with their existing services.
None of this is insurmountable. Bootstrapped, grass-roots, and open source projects can and do succeed. But it does need consideration, time, and resources dedicated to getting to where new technology is easy to adopt and to use.
Discoverability
Another significant hurdle to shifting back to a more decentralized web is discoverability. Services like Facebook or Twitter have spent considerable amounts of money in marketing and advertising to become ubiquitous and memorable. You only need to remember a small handful of domains to get by in the modern internet. Anything outside of those you’ll just Google. Bookmarks (and bookmarking services) have largely fallen out of vogue.
So, how does a smaller, more niche service get the attention of the users it wants to attract? Federation is a partial answer, with new services or ideas bubbling up through your existing contacts. Suggestion algorithms could be implemented within a federation, where services wishing to advertise their presence can opt-in to being a suggestion for a related content source. There have already been some experiments around adding “related content” suggestions in things like Mastodon.
Let’s be honest, though: a lot of people hate that. Even if the implementation is fairly innocuous, it feels invasive as an end-user. Part of the draw of moving back to a more decentralized web is make that kind of invasive targeting harder. So, how else do you get the attention of your potential audience?
I don’t really have a good answer. The immediate choices that come to mind are things like advertising (which gets back to money mentioned earlier), and improving your search rank. Neither of which feels like a great answer, nor sustainable in the long run. I wonder if it’s time to revisit the idea of aggregation services, something that could help provide some structure and improved visibility within different networks of federated services. We need to come up with some sort of solution: you can’t join a site or service if you don’t know it exists.
Bad Actors
The first image that comes to mind when I say “bad actors” are malicious hackers who want to compromise your site and steal your users’ data. And that’s definitely a concern: fledgling technologies are notorious for having security flaws, and even tried-and-true tech ends up with exploits pretty regularly. Federation, while useful, is a double-edged sword: while you might be keeping your software up to date and secure, there is no assurance others within the federation are doing so as well. Exactly how much this becomes an attack vector will depend on the implementation, of course, but it is another attack vector that will be probed. Not if. When.
There are other types of bad actors, though. There are a not insignificant amount of sociopaths on this planet (not using the term lightly: the number of people who actually wish harm on others is small, but the number of people who simply don’t consider or care who their behavior harms is significantly higher). Trolls (whether for the lulz or more malicious intent) are commonplace on the social internet, and any new social media service (decentralized or not) must consider how to mitigate the damage and toxicity they can inflict. This means investing in both moderation and the tools for moderation, among other things. (Which brings us back to time, money, and resources again.)
On top of trolls, you also have spammers, which can have impacts on your service, the larger federated network you’re part of, and your discoverability (surprise surprise, Google isn’t a fan of what could be construed as gaming search results, and can get you delisted/buried, even if it was just a user on your network, not you). Looking at how a service interacts within a federation, and how easy it is to block nodes run by bad actors, is something that will need to continue to be addressed.
It’s something that we all know we’ll need to consider, and continue to consider as bad actors adapt. Better to think about it from the start, rather than try to shoehorn an approach in later.
Inertia
This is sort of an implicit part of a lot of what I’ve talked about so far. How do you foster adoption for a new service? How shitty does an existing service need to get before the activation energy to switch is achieved? When you’re already set up, and everything is in one spot, it’s incredibly easy to become complacent – you may grumble about the changes, but you don’t actually do anything about it.
If a bunch of your friends have already moved to the new service, that becomes a draw, but how do you grab those early adopters and (as much as I loathe the term and concept) influencers? What can you do to make migration as frictionless as possible? Solid importers that can take exported data from major services is a step, but unless you’re planning to reinvent Twitter or Facebook (which, please don’t), that is going to inherently be a partial migration at best, and in the case of some services, may not make sense to do at all.
Also: lost trust. Your nice new service may be more secure, less invasive, friendlier, and just all around better than where users currently are, but disillusionment with social media at large is real and justified. Why should they switch to you versus staying with the devil they know (or stopping using social media at all)?
There’s also the inertia of implementation: is the technology compelling enough to justify the complexity of implementation? Can that complexity be reduced? How do you make the software approachable, both as a user and as an administrator? How’s your documentation?
Conclusion
This ended up stretching into a longer post than I was originally planning. There’s a lot of hurdles that need to be addressed for decentralized, federated services to gain broad adoption (let alone become a healthier social web). Some of my comments may come off a little dour, and I don’t really have clear solutions to a lot of the problems noted. I’m optimistic, though. People far cleverer than myself are thinking heavily about all this, and are in positions to do something about at least some of it.
I think centralized services are likely around for the long haul, but there’s room for a decentralized social web as well. I’m excited to see what new software people come up with based around new standards and ideas. And, ultimately, I think part of the answer will be to redefine what success means: shift the thinking away from explosive growth meaning success, and instead make success mean achieving sustainable, meaningful community for the people you care about.