I've come and gone from Micro.blog several times before. I joined long before the Kickstarter, when barely anyone was there. I tried it again after the Kickstarter, when the community looked more like it does today. And I came back again a few weeks ago for the most fun, if not the longest, period of time I've spent there.
Like many other people, I really like the community on Micro.blog. I like that it feels like a nice, friendly place to hang out, and that mostly people post content thoughtfully, even if it's short or just a photo. While I recognise that these things aren't true in every case, I've been lucky to enjoy mostly positive interactions with the community, and have always been made to feel welcome.
Unfortunately, I have a lot of issues with the service itself and how it's run. I've put off talking about these until now, because I know how hurtful it can be to hear criticism about something you made or love to use. But I've tried many avenues to do my small part to improve the things I don't like about Micro.blog and I no longer feel that's a viable approach. I'm leaving Micro.blog despite the great community, because I'm frustrated and disappointed, and I don't feel I can effect change in these areas.
The idea and business model
Manton wrote a post recently about what he believes is the four-part solution to "this mess with massive social networks". He makes some great points, such as the fact that multiple small networks may be healthier than one or two huge networks with millions of users.
One of his main points was that users should own their content, which is possible with Micro.blog:
Content ownership: Controlling the writing and photos you post online isn’t about open source or the technical experience to run a server. It’s about using domain names for identity, so that you can move your data in the future without breaking URLs.
In a related post (linked in the one above), Manton goes a little further on this topic:
If you can’t use your own domain name, you can’t own it. Your content will be forever stuck at those silo URLs, beholden to the whims of the algorithmic timeline and shifting priorities of the executive team.
For hosted blogs on Micro.blog, we encourage everyone to map a custom domain to their content, and we throw in free SSL and preserve redirects for old posts on imported WordPress content. There’s more we can do.
I have two issues with this point.
First, Manton's business model is for users to not own their content. You might be able to own your domain name, but if you have a hosted Micro.blog blog, the content itself is hosted on Micro.blog servers, not yours. You can export your data, or use an RSS feed to auto-post it to somewhere you control directly, but if you're not hosting the content yourself, how does having a custom domain equal self-hosting your content and truly owning it? Compared to hosting your own blog and auto-posting it to Micro.blog, which won't cost you and won't make Micro.blog any revenue, posting for a hosted blog seems to decrease your ownership.
Manton makes no secret of the fact that he wants you to pay for a hosted blog on Micro.blog, as this is the main way to financially support the service, but doing so means you no longer own your content any more than on another service that provides exporting or RSS feeds. To say owning your content is what makes Micro.blog great and simultaneously push the idea that users should pay to give up that ownership is disingenuous. Not to mention Manton himself recently moved his blog to Micro.blog, so he's not even leading by example anymore, since anyone but Manton (i.e. those who don't have ownership of Micro.blog itself) must host their blog elsewhere in order to own their content.
Secondly, Manton suggests all users should want to own their content. This seems to be a blanket statement about Manton's own values and how they should apply to others. I have plenty of friends and relatives who don't care about owning their content, and in fact, don't want to do so. Just because I want to, and I think it's important for the open web that more of us can—and do—own our content, doesn't mean everyone who wants to connect to others online should necessarily be doing the same. There are also plenty of people who'd like to own their content but for whom it's more important to hang out where their friends and family are—people who perhaps don't care about content ownership. For those reasons, they stick with social networks that don't care about empowering users to own their content, because content ownership is a lower priority than connecting with people they know.
Manton's post was short, and I know he's thought about these ideas a lot, so I'm sure there's more he didn't say, but I'm disappointed in how hypocritical this particular point seemed to be. I find it hard to feel confidence in a platform that pushes a business model that seems opposed to its public values.
Even more of an issue for me is how Manton is in control of Micro.blog and Manton has different priorities to me. This is inevitable with any social network, I'm sure, but since Micro.blog is closed-source, and my attempts to contribute to the direction of the service have been largely unsuccessful, I'm no longer willing to accept our differences in priorities and contribute to the growth of the service by being a user.
For example, I know I'm not the only person who feels left out and uncared-for because I use Android. Manton has gone further than the common scenario of only building an official iOS app and leaving Android out in the cold, and built two more iOS apps for the service as well. That's an extremely strong signal to Android users that the service's creator doesn't care as much about you and your experience. The excuse that the team is small and there's no time to put into Android (which is oft-used and usually completely fair for such a tiny team) doesn't hold up here, because Manton is showing how much time he has for mobile development by pouring it all into iOS. He's even got another developer helping out (not full-time, but more than zero time) on some of those iOS apps. And nothing for Android.
So, as a developer, rather than simply complaining about this state of affairs, I took advantage of the Micro.blog API and learned Android development so I could write an Android client (I should note here, a third-party Android client already existed in public beta, but it didn't allow for creating new posts except replies, and hasn't been updated since May).
Creating Pico has been a lot of fun, but again, I struggled in my efforts to improve Micro.blog. The API docs are extremely sparse and sometimes unclear. Since they're technically open-source, I opened an issue asking Manton if I could add code examples to make the docs more useful, and how he'd like me to format them. My issue was opened on August 28th (27 days ago as I write this). There was another issue already opened in the docs repo on August 24th. Neither has had any response so far. I also recently opened a pull request to adjust the wording of one sentence in the docs after Manton clarified it for me directly. That PR hasn't had a response.
The API itself also tends to be confusing and inconsistent at times. For example, sending a new post to the API requires the post content parameter to be called
content, while sending a post as a reply requires the content to be in a parameter called
text, which is inconsistent. When sending an invalid token to the
/account/verify/ endpoint, I receive a
200 response, indicating the request was successful. I have to parse the "successful" response to check if I actually received an error, despite the success status code. And when requesting an endpoint like
/posts/all/ (to show the user's timeline) with an invalid token, I receive a
500 internal server error instead of what should be something like a
400 bad request or
API design is as important as having an API in the first place. Manton likes to point to Twitter's mistreatment of third-party developers as part of their failings, but then offers a half-hearted attempt at API docs, a confusing and inconsistent API, and no support to developers who try to improve the situation by contributing to the one place that's actually open-source within Micro.blog. He also likes to push the idea of using open standards, and yet the Micro.blog API shows disregard for the W3 status codes spec (by returning a
200 success response when the request actually failed)—one of the most basic open web standards there is. To be fair, this is likely just an oversight, but when I mentioned it to Manton, his response was that changing the API might break it for existing third-party apps. It's never a good idea to break your API if you can avoid it, but how can Manton proudly proclaim Micro.blog's insistence on using open standards at the same time as ignoring these errors in the API?
Now, if you're not a programmer you might have no idea what I'm talking about. That doesn't mean this isn't important for you. If you're a non-technical person who uses an iOS app like Icro, that's made by a third-party developer, it's important for you that the developers behind those tools have everything they need to make an experience just as good as the official apps. If you're a non-technical person who doesn't use iOS, this is especially important for you, because you have no official app to use on your Android or Windows phone (or any other place you can't use the web or Mac apps). You have to rely on third-party developers to help make your experience of Micro.blog better, so it's imperative for your experience that third-party developers enjoy working with the platform and feel they're welcome and encouraged.
Of course, Manton is just one person, and he's taken on a lot with Micro.blog, so I'm not surprised that open issues in the docs repo go unanswered while he works on updates to Sunlit. What's disappointing is that Manton insists on maintaining control by keeping everything under his command and closed-source, so none of us can help with the workload. We have no choice but to sit and wait, and hope that one day our priorities will line up with Manton's, and if they don't then that's too bad.
Discovery and diversity woes
Discovery gets a lot of meta-discussion on Micro.blog, especially from new users who are frustrated at how hard it is to populate their timeline with like-minded folk. Micro.blog moves extremely slowly, so it's even more important to find lots of interesting people to follow, or you'll go for hours without having any new posts in your timeline.
Right now you can discover people by:
a) seeing those you follow reply to people you don't know
b) looking at which users other people are following
or c) looking at the Discover timeline.
The Discover timeline is human-curated, which means you don't have to worry about spam or junk or rudeness showing up there. This is really nice. The downsides of this curated approach, however, are that it updates extremely slowly (a few times a day a whole bunch of new posts will appear, but in-between those times it doesn't change), and the posts that show up there reflect the interests, ideas, and values of Manton and Jean who curate it. For example, around the time of Apple's hardware announcements recently, I checked out Discover, hoping to get away from my Apple-centric timeline and find something else to chat about, and found there were often plenty of Apple-centric posts in the Discover timeline, too. There have also been periods where the new batch of posts added to Discover are 100% authored by men, with nary a woman in sight. Of course, there are plenty of other ways to represent diversity besides gender, but it's a good starting point, especially since the tech industry has a well-known lack of gender diversity.
For a service that purports to care about inclusion and diversity, it's disappointing when I have to point out this kind of extreme lack of diversity in an area that's completely curated by those declaring these values in the first place.
I've discussed lack of diversity with others in the community in the past, and the best I was offered in terms of contributing to changing this issue was a suggestion to join a Slack channel to discuss it further. I don't use Slack and don't want to, but being open to, and even suggesting, other ways for the community to improve the diversity of the Discover timeline didn't open up any opportunities. I can't help but feel Manton and Jean aren't fully committed to this issue based on the evidence I've seen, and that's a shame, whether it's truly the case or not.
As every time before when I've left Micro.blog, I wish I didn't feel the need to leave. I wish I could continue enjoying being part of this great community, but my frustration with how the service is run is too much for me to enjoy it anymore.
It feels to me like we're all at a party at Manton's house. Unlike a public, community-run event, where you can have a say if you think things could be done better, if you don't like how a host runs their house party, you just leave. And those who agree with how the host does things, or like the rest of the people at the party enough to put up with it, stay.
I'm most sad that there's not really anywhere else like Micro.blog for me to hang out. Like lots of other people in the community, I don't get the same feeling from Instagram, or Twitter, or Mastodon, or anywhere else. Micro.blog is unique in a great way. Since I like to take action when I'm disappointed by something and have a chance to change it, I've considered creating a place for microblogging that focuses on the areas I care about, like solid tools for developers, open-source where possible, and formal ways for the community to contribute in the governance of the service. I'm unsure right now whether enough other friendly people care about these things the way I do, and thus whether the workload and responsibility of starting a project like this is worth it. But I'm still considering it.
Either way, I hope one day all the great parts of the Micro.blog community will find a home on a service that gives them a voice in how the service is run.