One of my freelance roles at the moment is as Developer Relations lead on the Mastodon project. It is a project and platform I’m really passionate about – I use it every day, it is Open Source and based on an open standard, and I strongly feel that federated platforms like this are the key to enabling everyone to own their own content, networks, and experiences beyond the direct reach of commercial interests.

At this stage in its history, Mastodon would I think count as an established and mature OSS project. It has been around since 2016, there are over 10,000 running instances / servers with the software, and over a million regular active users of the platform (plus, it interoperates with a much wider set of other platforms in the Fediverse, and carries posts and content from them as well. There are a number of large repositories that make up the GitHub organisation. There’s a – in my opinion – healthy and diverse set of third party apps that plug in to the network.

One of the things that some folks would say that the project has not always been great at, is communicating with the broader developer community. My own observation is that this is a large and widely-deployed codebase, and at a certain scale, stability and reliability become paramount, and it can be less straightforward to accept pull requests for new features (over prioritising security reports, for example). It is a small team supporting this project, largely underfunded1 if you look at the need to maintain the code, and to pay at least some of the folks involved to work on things full-time so that they can get by day-to-day, and that the core functionality gets the attention it deserves. When you’re coding, you may not have time to do other things like writing documentation, discussing roadmaps, and answering general questions – that’s partly where I come in, but even then, I still need to get help from the core developers to understand some of the questions…

I started working part-time with the core Mastodon team last year, with the goal to improve the experience for developers building on the platform, and also to bring my experience in working with diverse OSS projects and communities to support the Mastodon core team. As an example, last year I overhauled the existing list of known third party API libraries on the documentation site, and also updated the third party client apps page. Towards the start of this year, we started to make a few choices to improve the cadence and – I hope – quality of our external conversations further: we brought the whole team to meet the community at FOSDEM for the first time, for instance, which was a big step for the project.

Visit us at #FOSDEM, building H, level 1! You can say hi to our team or tell us what you’d like to see in Mastodon next. Mugs, t-shirts, enamel pins, and even free stickers available! #Merchtodon

— Mastodon (@Mastodon) 2024-02-03T08:56:41.576Z

Eugen and I also had the opportunity to meet with a few folks working on related Fediverse projects, as well as some Mastodon contributors and instance owners, during a whirlwind visit to the Bay Area back in May.

In the last 4 months, Renaud (the Mastodon CTO) and I have been collaborating on an engineering blog series called Trunk & Tidbits. We both strongly believe that explaining what we are working on is an important element in building greater engagement and community around the project. I chose the title for the series as (what I thought was) a clever play on words, but maybe you need to be old enough to remember when source control systems like CVS used “trunk” as in tree trunk as terminology, that we now tend to call “main” in the world of Git! The name is supposed to point to the blog series content being about what we have worked on and merged into the trunk of the code, and some “tidbits” or bits and pieces of other news from around the developer community – plus, of course, our mascot The Mastodon has a trunk of its own… 🦣 😄

Here are links to the April, May, and June posts, if you are interested. We post retrospectively, looking back at progress each month.

One thing to note from these past editions is that I also posted a completely rewritten and overhauled Contributing guide in the past couple of months (mentioned in Trunk & Tidbits); this lives at the organisation-level in our GitHub setup, and is intended as the main starting point if you want to contribute to the code.

Today, we published the July edition of Trunk & Tidbits. tl;dr we’re a bit behind where we had hoped to be towards releasing the next version of Mastodon, v4.3 – but we are really close to getting the beta out, and the “delay”2 is because of some feedback and performance improvements identified in early testing on our own instances, so we’re hoping that when the beta is released, things should be in quite good shape.

I’m hoping that with more regular communications via the blog; interactions with the community via the Fediverse itself and at events (I’ll once again be at Fediforum in September, for example); one-to-one conversations; and a willingness to engage in more conversations where time and resources allow – we can help folks to feel more informed about what we’re working on. It is still a small core team, and it is a busy time as the Fediverse grows… we need to keep things running, stable, and reliable… and there are always going to be features and changes that we cannot get to, or requests we cannot support at short notice… but I can assure you that it is a team effort, we discuss what’s possible, and that, I believe, we’re moving things forward3.

That’s all a personal perspective on what I’ve found, in working with the Mastodon project and team. Let me know if you have feedback on the Trunk & Tidbits series, as I’d love to keep improving these posts, and learning from the folks that read them.

1. I am also pretty happy with the fact that the project has made a conscious decision to not go down a road of accepting capital investment, and remains a not-for-profit funded by donations. YMMV, this is a personal opinion. ↩︎
2. Note “delay” against an undated release schedule; the release will ship when it is ready to ship. ↩︎
3. A footnoted mea culpa / things I personally wish were better if I had more time on the project / there was more scope for them more quickly! I’d prefer it if there was a machine-parseable API specification, and that more Fediverse formats / standards / protocols might be supported in future, and that the developer documentation was even more complete and nicer and better etc etc.. Hopefully, we’ll get nearer to some of those in the future, as time and resources allow. ↩︎

Share this post from your fediverse server
https:// Share

This server does not support sharing. Please visit .

andypiper.co.uk/2024/08/13/the…

#Blaugust2024 #100DaysToOffload #activitypub #Coding #community #developerRelations #developers #devrel #fediform #fediverse #mastodon #openSource #oss #projectManagement #trunkTidbits

Andy Piper

2023-12-27 14:58:44

I was… Continue reading Six (and a bit) months on Team Mastodon →

andypiper.co.uk/2023/12/27/six…

Episode 249 of The Linux Lugcast Podcast is out – Olympic Lugcast

This episode we talk about the movie Sci-Fighter, real time audio effects for Linux, Cynthia Rothrock, Star Labs, Linux Hardware, shitty movies, reverse proxies, nginx proxy manager, and much more.

Podcast

YouTube

PeerTube

Clips of the show:

Youtube

Peertube

tech.minnix.dev/episode-249-of…

#bmovies #hardware #linux #linuxpodcast #nginx #nginxproxymanager #podcast #starlabs

minnix

2024-08-05 23:24:47

The Olympic Lugcast - The Linux Lugcast Ep 249 for 8.2.24

Welcome to Episode 249 the LinuxLUGcast

We are an open podcast/LUG that meets at 9 PM EST every first and third friday of the month using mumble.
We encourage anyone listening to join us and participate on the podcast. Check out linuxlugcast.com/ for the server details.

If you have any questions, comments, or topic you would like us to discus and are unable to join us during the live show you can
send us email at feedback@linuxlugcast.com

Lemmy community at lemux.minnix.dev/c/linux_lugca…
Join in the conversation at matrix.to/#/#lugcast:minnix.de…
Join the Jitsi meeting at jitsi.minnix.dev/lugcast
Youtube Channel
youtube.com/@thelinuxlugcast
Peertube Channel
nightshift.minnix.dev/c/linux_…

Previous movie:: Sci-fighter 2004
imdb.com/title/tt0117566/

Next Movie: Virtual Death Match 2020
imdb.com/title/tt8444510/

Minnix: EasyEffects
github.com/wwmm/easyeffects
reddit.com/r/linuxmint/comment…

Joe
aliexpress.us/item/32568060450…

amazon.com/802040-Battery-Rech…

Mordancy
Feedback from Star Labs
Vim talk

Cynthia Rocthrock

Honkey
blog.lopp.net/death-of-decentr…

lsix
linuxlinks.com/lsix-ls-images/

Linux is free
howtogeek.com/linux-is-free-bu…

Apache Foundation Says ‘Goodbye’ to Iconic Feather Logo
fossforce.com/2024/07/apache-f…

minnix
top 5 olympic list

Our next recording date will be Aug 16, 2024
Our music is "Downright" provided by Klaatu and Broam
and we would like to thank Minnix for the mumble server

AAXtoMP3[1] fails to split up AAXC files to chapters. The reason for this is due to an error in the RegEx Find command to pick up the extra cover image in better quality. Audible-cli dumped two jpg files for the cover: One 500×500 pixels ($bookname_(500).jpg) and the other 1215×1215 pixels ($bookname_(1215).jpg). The find command picks up _both_, which introduces a linebreak resulting in a stat error breaking the script. Creating the chapters comes after this step and while the resulting MP3 is fine in itself I really do prefer chapter files over one huge blob.

Since the AAXtoMP3 project is archived I can’t report any bugs to it but this is my dirty fix adding tail to the mix to only get the last result:

diff --git AAXtoMP3 AAXtoMP3
index 0a6c2e0..98a30ce 100755
--- AAXtoMP3
+++ AAXtoMP3
@@ -467,7 +467,8 @@ validate_extra_files() {

# Cover
extra_dirname="$(dirname "${extra_media_file}")"
- extra_find_command='$FIND "${extra_dirname}" -maxdepth 1 -regex ".*/${extra_title##*/}_([0-9]+)\.jpg"'
+ extra_find_command='$FIND "${extra_dirname}" -maxdepth 1 -regex ".*/${extra_title##*/}_([0-9]+)\.jpg" | tail -n1'
+
# We want the output of the find command, we will turn errexit on later
set +e errexit
extra_cover_file="$(eval ${extra_find_command})"

Happy backing up your audio books 👏

[1] The purpose of this software is to create a method for you to download and store your books just in case Audible fails for some reason.

beko.famkos.net/2024/08/12/156…