# Plume, after two years

Temps de lecture : 17 minutes 05/07/2020

Lire cet article en français : Plume, bilan deux ans après.

In March 2018, the idea of a new project came to my mind1. The ActivityPub specification has been made "official" a few months before, and quite a few people seemed to be interested. I thought it would be fun to make a small federated project.

At first, I thought about a photo gallery, à la Instagram (Pixelfed didn't exit yet, or wasn't known enough for me to have heard about it). But finally, what was the most motivating for me — and that seemed to be the easiest to implement if I only wanted to experiment with ActivityPub — was to build a federated blog engine. That's how the first version of Plume, in Crystal, was born. But quickly, I encountered issues with the language (it was still experimental, to be honest) and I decided to start over with Rust. I already wrote a few lines of Rust, but it was with Plume that I really discovered this language.

After some time, other people came to help me. We were a small motivated team at the beginning of the project, but since October 2019 (or around that time), it is harder and harder to keep working on the project (for various reasons, that are not the same for each person, and I'm only going to speak about my case here). We had a big slow-down for a few months, but I'm trying to find motivation again, to keep the project alive.

That was a quick history of the project, but that's not really what I want to talk about, it was for context. What I would like to do, is a summary of what this project has taught me, what it has brought to me.

## Rust

As I said earlier, I knew very little of Rust before I started working on Plume. I learned it on the fly, discovering concepts progressively.

I quickly fell in love with it. Even though in the beginning I had a hard time understanding some errors, some concepts (I was not familiar with low-level development, memory and pointers were quite new to me), I found solutions. With help or by myself. Most of the time quite ugly and not so optimized ones, but it was compiling.

Anyway, I'm not here to make Rust propaganda. I just wanted to say, it is a nice language, even if you don't get everything in the beginning (which doesn't mean that you can't do anything, you just have to go slowly, and write code that could be judged "inelegant" by more experienced people).

Beyond a new syntax, Rust taught me a lot of new concepts in computer science, and I made great progress thanks to this language. Everything about memory management, higher order functions, and types, which I discovered (or rediscovered) with Rust. Not that I never heard of it before, just that I didn't "explored" them that much.

## I met new people

If you ever contributed to Plume, this is going to be about you, so don't read if you don't want to.

Maybe it will sound cliché, but it was among the greatest part of my Plume experience.

Quickly after the beginning of the project, other people came to help me. It wasn't the first time I was working with something else on a remote project, but it was without a doubt the first time it lasted this long, and that there was so many people.

All the contributors didn't stay. Some of them made one change, and never touched the code again. All the people in the Matrix channel don't necessarily keep reading it2. But it's fine, it is great to see people wanting to help, to see that the project was attractive enough for them to contribute, even if it was only one time.

On top of that, quite a lot of contributors didn't stop after their first time. I had discussion with these persons, firstly to be able to work together, but slowly we got to know each other a little bit. We are probably not the best friends in the world, but we get on really well, and we sometimes chat about other topics that Plume.

## Managing a project

I also learned a lot about project management.

### "My" project?

With all those contributors, I had to organise the project, and to make their contributions possible. It was the first time I had to handle something that big, and I wanted to do it right. I didn't want it to be my project, but to see other people become part of it too.

In the end, it is not really a success I think: I announced a few month ago my will to stop working on the project — because I lack time and motivation — and to "give" it to someone else, but nobody in the community was really able to really take my place. I feel like without me the project can't continue to progress (and I feel like I'm giving myself too much importance by writing that, but the evidences seems to prove me right). Since then, I found some motivation back, and I think I will try to use it to do a smooth transition towards new maintainers rather than just completely abandoning Plume, as I wanted to do for a long time.

### About the code

This section is going to be technical, feel free to skip it.

Plume is a software project, code still has a quite central place. And I think one of the reason it is so hard for someone else to take over the project is because the code is too hard to understand, it is too hard to get familiar with.

There are various reasons to that, of which I'm more or less responsible:

• first of all, I chose a language (Rust) and dependencies (Rocket, Diesel) that are quite uncommon for web development. These technologies are quite recent, only a few people know about them, and Rust can be scary (it has the reputation to be hard to learn at the beginning, even if there are a lot of benefits in the end). Maybe it discouraged people. However I know it also encouraged some of them: people who wanted to learn Rust and thought that Plume would be a good project for that purpose.
• the code I write is often not very clean. It works fine for small projects on which I work alone, but when there is a lot of people, it doesn't work anymore. The code I wrote in the beginning was far from perfect, but I thought I would fix that later. I never took time to clean it. There is also a lot of missing documentation and it is probably very hard to find your way in all those lines of Rust when you are not familiar with Plume's architecture.
• I made poor technical choices. To be more precise, there is only one that is blocking the project, as far as I can see: using WebAssembly for the front-end. I think I made that choice because I wanted to play with this new shiny technology, more than because it was the right choice. Indeed, it allows to share code between the back-end (in Rust), and the front-end (in Rust too), but it makes compilation a lot harder, for few benefits. And operations that are quite easy to do in JavaScript can be quite hard to do in Rust3. Fortunately, this choice is quite simple to revert, we could go back to JavaScript. But I don't feel like going the other way again, because maybe WebAssembly will soon become easier to use, and it will only be a benefit to use it. Who knows…
• to get back to dependencies, the fact that the Rust ecosystem is quite young (especially for the web), is also a drawback. There is no well-known patterns that we could lean on. And some of our dependencies have bugs that we can't do much about. An example of that is that Plume instances currently become unresponsive after a few hours and need to be restarted (which fortunately can be done automatically). This bug is not in our code, but in a dependency of one of our dependencies. It has been around for at least a year, and even if it should get fixed soon, it is a long wait4

### ActivityPub, for better and worse

Moreover, there is another factor that makes the project scary, and that personally discourages me a lot to continue to work on Plume. I'm talking about ActivityPub, the federation protocol of Plume (and Mastodon, Pleroma, Pixelfed, Peertube, Mobilizon, Funkwhale, and so many others).

The idea behind ActivityPub is nice: one standard federation protocol, flexible enough to meet all the needs. Using federation could really change the way we do information technology in my opinion, and make the switch to more ethical and privacy-protecting softwares easier.

But in reality, ActivityPub isn't that great.

First of all, the protocol have been designed with object-oriented languages in mind. It uses "inheritance", a concept that doesn't exist in other kind of languages, like most of functional langages, an Rust.

It was also designed for generic servers. These servers are ActivityPub implementations that would be able to handle any kind of content (or activity as they are called in this context). You could, with one instance, one account, manage private messages, blog articles, photos, videos, forums, etc. This idea is amazing, but quite hard to implement in reality, so that is not the way ActivityPub have been implemented so far. In practice, each implementation focuses on one activity (or at best, a few different activities) : Mastodon for short messages, Pixelfed for photos, Peertube for videos, and so on. In my opinion it is really unfortunate that we went that way, when we could have shared a lot of efforts by building a common generic server. It was quite tiresome to work on Plume after having realized that it was not the best way to build a federated server, that we could have built a server that was making more than Plume, and probably better than Plume. That's why I tried to start another project called RATP (Rust AcTivityPub), a generic server written in Rust. But I only made a prototype so far, and I didn't worked on it for a few weeks.

The protocol is also really imprecise on a lot of points. The security wasn't really in the creators' mind, and the various implementations did the best they could. The issue is that these additions to the protocol are not documented, and they are not necessarily the same everywhere. To be sure to be compatible with Mastodon and/or Pleroma, I had to read their source code a few times, because what the ActivityPub specification says is not enough to build a server that can communicate with the rest of the Fediverse.

ActivityPub globally isn't the easiest thing to implement (even if it is not the hardest either), especially if you want to do it right. It is quite discouraging to work with such a complex protocol when it would have been simpler without loosing any possibility.

### Learning from my mistakes

As I said, I never managed a project before, and that's something I learned on the go with Plume. The problem is that learning that way is fine for "technical" skills, but not in the case of project management where your decisions can impact other people. Learning by making mistakes in that case is not so great.

And I made mistakes. As I was kind of lost, I tried to follow the way other project were organizing, without necessarily thinking if it was the right thing to do in the context of Plume.

The first error I made, I think, was to copy what Pixelfed did about their logo competition. At the beginning of the project, Plume had no logo, and Pixelfed just found a solution to this same issue: they organized a competition during which anyone could propose an icon, the community would vote, and the winner would get some money.

The issue with that kind of contest is for all those that won't be selected: they did free work. Sure, in libre/free software communities (and in "non-profit" communities in general), free work is everywhere. But generally, when you propose changes to the code, you can be sure they will be accepted, with some potential minor edits. You don't work for nothing. The logo contest I organized is more the equivalent of hackathons that some companies do, where various developer teams work against each other, but in the end only one will be selected.

At that time, I wasn't really aware of this issue and I organized the contest. But I started to realize it was a poor decision, and I tried to limit the damage: I offered some money to all participants, selected or not, and we added an option to let instance admins select another logo if they didn't wanted the "official" one. This way it was easy to change to another logo proposal, or even to use a custom logo5.

But even with that, the harm was done. What I should have done is to find a graphics designer willing to work with us, that we could have paid if they wanted, and that would have created one good logo that would fit our needs.

Something else I kind of regret is the fact that we used to market ourselves as an alternative. A lot of libre/free projects do that, but I believe it is not really a great way to communicate. Sure, it is simple to picture yourself what a "YouTube/Doodle/Office alternative" does. But in the same time it feels like you just copied someone else's work, that you don't bring anything original. I believe it discourages people from using these "alternatives": why would they change if the software is exactly the same? Once you know what the app does globally, you don't look for the small details that can make it better. You see Mastodon as a Twitter clone, and you don't have a look at the federation, or at the built-in content warnings. On top of that, if people give our service a try thinking it is "an alternative to…", they will necessarily compare the two, looking for what is missing in the alternative (and that would change their habits, which is a bad point in general).

Plume was first marketed as a Medium alternative. Medium is a centralized blogging platform, with a tendency to make you pay for a lot of things, that is popular for some reasons I still don't perfectly understand. It was not the best strategy according to me, Plume is not Medium on various aspects. I would even say the only common point is that you can publish blog articles on both apps, that's it. The community (or communities) that you can find on each platform is not the same, the design is different, there is no business logic behind Plume, Medium is not federated at all, etc. These two softwares are very different actually, and selling Plume as a Medium-like doesn't make sense.

Last regret in my choices, is the organisation I chose. As I said, I didn't wanted Plume to be "my project". I wanted other people to come and join me in this adventure. And Funkwhale, that was growing at the same time, wanted to go in the same direction, and it seemed to me they were quite successful in that. I decided to follow their example, trying to create the same dynamics in Plume.

For instance, I set up a Loomio group, where people could discuss about new features, vote or make polls. In the end, it was barely used, most of discussion were happening on Matrix or GitHub. I think Loomio was not really adapted for Plume, but I didn't ask myself this question before setting it up.

And I still feel like Plume is "my project". The community was probably less important than Funkwhale's one. Or maybe I made bad choices that I didn't saw and fixed. Or maybe it is not possible to create libre/free software that a true Common, belonging to everyone and not one person. This last possibility seems interesting to me: if we look at Funkwhale, it seems to me that if Agate6 disappeared tomorrow, the project would slow down a lot at best, despite all the efforts to make the development and the decision process transparent and open to everyone. Unixcorn, an online service hosting project was also abandonned for the same reasons: the will to make a community project never came true. And there is probably a link with the rock-star culture that we have in libre software, which makes us think always about the same few people. This bias would make us associate a project with one person rather than with a community: "Plume, Ana's project" and not "Plume's, the project of all the people who made Plume".

On the other side, maybe if I had kept Plume as "my" project (without especially discouraging other people from contributing) I could have been more efficient. I wouldn't have had to wait for someone else to validate my work, I wouldn't have had to discuss which functionnality to implement, I could have won time by writing code or documentation instead of setting up structures to make contribution easy. But I don't know if it would have been better, and I think I prefer to have failed to make Plume a community project after trying, rather than having been efficient but discouraging people from contributing.

The truth is, I don't even know if the efforts we made to make contributions more accessible to everyone were really useful. If we didn't do these efforts, would there be less contributors? Or maybe there would have been more? Maybe we didn't go far enough for these efforts to be really efficient? Unfortunately, I think we will never be able to answer these questions, we would have to try different strategies in parallel on the same project, which seems hard to do…

## Conclusion

I think I said all I had to say. I hope I didn't spoke too much about my life and that these few reflexions will be able to help other people to manage their own projects better (libre software project or not).

As I said, I will probably slowly quit Plume, if I can find someone else to take my maintainer role. In the meantime, I will continue to work on it, and I hope I will continue to discover and learn with this project.

1

Like every other day, but generally I forget them in ten minutes because it is not so interesting.

2

And I'm not even speaking about the Loomio, that is so useless that it will probably be deleted.

3

I think it will be better the day there will be a true Rust framework for WebAssembly, that tries to offer a different API, not just the DOM. But for the moment, everything is an Option or a Result, since in JavaScript everything can be null or throw an exception at any time, which is terrible.

4

Maybe I'm just very impatient.

5

Ideally, we should distribute other logo proposals with the source code, to make it really easy to make the switch.

6

Agate is the lead developer of Funkwhale, and she is the one who started the project.