So, it's been about 6 months since akkoma went stable for the first time. well ok, a bit less, this week marks the 4th anniversary since I started my instance (and probably like the 6th since I started using fedi). so it's basically the 4th anniversary of what would become akkoma. that's as good a point to do this as any.
i thought this would make as good a time as any to have a little bit of a sit down and think about how it's gone, and I am agile-brained at this point so I am using that as a template to try and organise my trademark aimless rambling into something less wending and winding.
this will be very personal, so please no bulli, as they say.
things that went well
getting a stable release out early
i reckon a lot of the early momentum akkoma had would have been lost if i had waited with only a "develop" branch for too long.
stable is a mild misnomer in our case and is only truly a snapshot of development which i've had a feature freeze
on for a week or so to check nothing breaks horribly.
there being a stable release probably assured people far more that the project was ready for use than if i'd said "just use develop" or something similar.
this leads directly into:
the release cycle
very early on i settled on a release cycle - the second saturday of the month would be stable day. this doesn't give a massive amount of wiggle room for massive work to be done, but that is potentially a benefit here. it has forced me to think of how i can improve the software given constraints, and made me avoid sinking my time into nice-to-haves that are far more difficult to accomplish.
this has given the project a real rhythm that pleroma lack(s|ed), with steady improvement over the months that keeps people involved with things rather than there being 3+ months of silence then a release out of nowhere. (or, like a year without a release in some cases).
velocity (zoom zoom)
say what you will about the benevolent-dictator-for-life model, it sure has made things go fast. whilst we're not in full "move fast and break things" territory, experimental changes have made their way into the core software much quicker than they would have ever in pleroma, and later become key features.
well, let's be honest here, the very first feature (custom emoji reactions) was an experimental change. so it's been the case since the start i suppose.
infrastructure and idea-sharing with foundkey
foundkey is a fork of misskey that shares a lot of the core values of akkoma. very early on we decided to share infrastructure with them. this has led to some level of support overlap as well - both projects very quickly managed to fix federation issues with the co-operation of everyone. it worked really quite well.
after the initial rush, there's also been idea sharing for the future of the fediverse (or, our part of it) so we can have features in two pieces of software at once, to improve adoption.
relations with other projects
let's not sugar-coat things here, pleroma proper torched quite a few relationships with other projects - instances are known to block pleroma instances on sight
akkoma's interactions with other projects are much less fraught, which is nice! there's even been some features leaking between them (eugen taking the deepl/libretranslate option is cool (though it was partially yoinked from misskey) but it would have been nice to make the URL compatible :((((()
getting new people involved with fedi dev
fedi development is a demanding task - the more people that share it, the less the burden is. i was lucky in that pretty early on, people from my corner of fedi started helping out doing bits and bobs. it really does help. plus nearly none of them had previous fedi dev experience, which means that the curse of activitypub can be spread to more people instead of remaining esoteric knowledge.
things that didn't go quite so well
the initial conflict
when I first forked, there were quite some tensions with the main pleroma dev group - although in retrospect i'm not quite sure why. there was seemingly simultaneous calls to "explain why" i wanted to (and to "collaborate" with pleroma), but at the same time utter dismissal of any grievance.
to my own discredit, i did not totally disengage from those arguments. i should have.
these days the conflict has entirely disappeared. well, either that or i've blocked the main instigator. either/or honestly. the vibes have improved immeasurably by now. there may be things i do not see (because they're over in the corner of fedi i pretend does not exist), but it's far better than it was.
handling my expectations
back in my original post, i did raise the question of if i could manage this. i thought i could, but i severely underestimated just how much pressure maintaining something like this puts you under. it was ok at first, but as the install base grew (and especially during the twitter migration) the stress really started to get to me.
i caught myself responding far more confrontationally than was in any way called for. this is something i need to work on. i must remember that i am but one person, and holding both a full-time job and maintainership is going to push me harder than i usually would be.
handling users' expectations
i never planned for akkoma to be as... popular as it has become (then again, who plans for this?). it was only really ever for instances i personally knew that had issues with pleroma. i tailored the features for our particular use case, which has proven to be controvertial in some isolated instances.
chat removal in particular has caused some sparks - nobody in our fedi bubble ever used them, and they were overly complex. hence, i removed them.
i should have made it more clear earlier on quite what akkoma was so that new people can tell how we differ from pleroma. i have since added to the readme to tell people that akkoma is not one-for-one with pleroma, but time will tell if that will be enough.
not getting a non-technical landing page up sooner
this is very related to the above. i never expected akkoma to spread beyond the confines of my corner of fedi. hence when it did and people messaged like "what even is this?", i had no prepared response. there was no way i could explain the concept of the fediverse and all of that to each person. i should have set up a proper landing page earlier and not expected only technically-capable people to find the project.
conflation of the personal and the project
from the start this project was "i personally am going to do pleroma but with blackjack and anime music" - this led to the lines between "maintainer!me" and "personal!me" blurring. whilst this wasn't a problem early on, as the userbase has grown, the number of people personally asking for support has grown, and i am ill-equipped to handle that level of interaction
this is something i'm really unusure how to handle, how do i keep my personal life and my "public" maintainer life seperate? is it possible?
things to improve by the next time I do one of these (next quarter?)
- documentation: whilst docs are ever-improving, they're still a far cry from what might be wanted.
- tighter integration of communications channels, instead of information being spread across the dev account, meta and gitea, we should try to unify comms
- releases, and more specifically specifying what is and is not supported. we do not have the devs available to act as first-line support to every possible installation
- maybe look into OS packaging. though i doubt we have the dev capacity to handle it
- funding; hosting is insanely expensive, and given the ever-increasing costs in real life, i'm not sure how long i can continue justifying hosting costs for everything
- definitions; even futher hammer home exactly what akkoma is meant for