foss¶

Community contributions: sharing is caring

In English, there is this popular phrase "sharing is caring". For introverts, though, this often remains something very difficult to apply in real life. For example, one may hesitate to offer their work out of fear of being judged. Or, on the opposite side, one may find it difficult to accept collaboration from others, wondering what they might expect in return.

Working on apps like Raccoon-s (the Mastodon/Friendica client and the Lemmy one) was an opportunity to put myself to test and see how I would cope with those situations.

In today's article we'll see what kinds of contributors the projects attracted and how each one of them not only shaped the apps themselves but also turned me, as the main developer, into a richer person.

So let's start!

Different types of contributors

To begin, my work exposed me to public criticism. Trust me, a lot of criticism. Especially on Lemmy, where users are known for not being excessively polite or diplomatic.

I must confess that I've not always reacted well to it; e.g. when I closed and reopened the repository under a different organization (see What happened to Raccoon for Lemmy?).

Nonetheless, when this happened, I was surprised to see that there were also people who genuinely appreciated the project, some of them even volunteered to take ownership of it in case I decided to discontinue it.

1. Developers

That leads to the first type of collaboration I got from people online. That moment of crisis, when I was facing being harshly criticized for how a library I used rendered Markdown in August 2024, was also the moment when I met N7-X.

He helped me immensely, both with Markdown rendering and in general with some design decisions I am still applying today. I was impressed to see that someone (in another continent, with a totally different background) wanted to collaborate with me to make the app better, expecting nothing in return.

"Being impressed" is not even the right word, it was heartwarming. And I must admit it helped me get through that difficult moment and find the energy not only to continue working on the project, but also to start new ones.

2. Translators

Then there are translators. Before studying Computer Science and working as a software engineer, I was in the professional translation industry.

This is why I've always been attentive to offer support for localization and to choose the right tools to make localization easier for me as a maintainer and for translators.

Since I understand the struggles of localization, all translators are given credits in the acknowledgements screen.

Receiving new translations or proofreads for existing ones was, again, a motivation boost and it was surprising to see how people nearby (e.g., German or Romanian) and from far away (e.g., Tamil or Brazilian Portuguese) wanted to help expand the user base.

3. Accessibility experts

When working on apps / websites professionally, there are legal requirements about accessibility which must be met by all services (see earlier article about advanced a11y), so it should be taken as a given.

In an open-source "pet project", though, accessibility can be much more discretionary. For Raccoon, I remember making it the default behavior to open a dialog for alternative text and issuing a warning when a post is about to be published with missing alt text.

Then, I was relying on Compose Multiplatform for the heavy lifting of integrating with accessibility tools, provided that the guidelines and best practices are being followed.

Until one day a lot of unexpected help came from pvagner, who helped me understand some of the issues people using screen readers faced with the original timeline layout, fix them and avoid making the same mistakes again.

One of the purposes of the Fediverse is to create inclusive and diverse communities, and I guess this is also one of the reasons why we work on creating ecosystems for it.

Knowing that in some way I laid my brick to help build that was a sign that the direction is the right one and was a motivation booster for me personally.

4. Strategic advisors

The fourth kind of collaborators I met during my journey was what I would classify as "strategic advisors". For example, while working on the Lemmy client, I met the administrators of feddit.it which is the largest Italian instance.

One of them was the one who first talked to me about the unique features of Friendica and inspired me to create a new client for it.

This person also suggested emphasizing aspects such as rich text formatting and discussion groups, which became one of the most distinctive features of the app compared to similar ones in the open source ecosystem.

Engaging with this kind of input has always been a little challenging because it forced me to question the scope of my work over and over again, adjust the strategy to constantly meet new targets.

But, on the other side, I truly believe that what originates from a constructive discussion is greater than the sum of the components involved. Moreover, having this kind of advisory helped me to prioritize user requests and bug reports (see the next paragraph).

5. Feedback and bug reporters

Finally, there are the most common contributions an open-source project receives: feature requests and bug reports.

Having to deal with these helped me to develop both social and planning skills, which are crucial even in my professional job.

Wrapping up

Working on open source projects can be daunting for introverts, but looking back, it was one of the best decisions I made.

You have no idea how good it feels to create, little by little, something useful (hopefully) for myself and for others.

Plus, this was the occasion to open up to other people, share thoughts, and collaborate to create something together in a period where individualism seems to dominate relationships.

In a word, I would say this felt like "healing" a little bit from the scars of life.

The Raccoon's Dilemma: Balancing Features, Maintenance, and Sanity

The idea of writing about the balance between features and maintenance in our apps has been lingering in my mind for over a year. But it never felt like the right moment, so I kept putting it off… ironically, somehow like the maintenance tasks I'm writing about.

This procrastination alone says a lot about my way of managing open-source side projects. It's a delicate dance between personal life and professional obligations. Days only have 24 hours, weeks only have 7 days (trust me, I've checked)!

Between family, a full-time job, and trying to be a functional adult in these chaotic times, maintaining apps can feel like a secondary full-time job, just without any paycheck.

One might wonder: Why on earth do I do this? It's a fair question. In today's article, I want to pull back the curtain on why Raccoon exists and why our development roadmap looks the way it does.

Longing for the Wild

I've worked as a developer for more years than I'd like to admit (let's say my early code belongs in a museum, or perhaps a dumpster). Throughout that time, I often struggled to find room to experiment. As a junior, every choice was made for me. As I moved into mid and senior roles, I was often tethered to legacy systems or constrained by "steering committees" which is often corporate-speak for «we don't like change».

I don't blame them: companies avoid risk because a bad tech choice can haunt a team for years. So, I was usually left playing in the safe corners of projects.

Even while bouncing between backend, web, iOS, and Android, something was missing. I missed the thrill of building from the ground up. I wanted the freedom to choose a foundation, evaluate it in the real world, and pull a complete U-turn on failure without causing a financial crisis for my employer.

The Perfect Storm

In 2023 the stars aligned. Kotlin Multiplatform¹ transitioned from Beta to Stable(and Compose Multiplatform was in Alpha for iOS and stable elsewhere).

Meanwhile, the "Reddit API Apocalypse" killed off third-party clients, driving a massive migration toward the "threadiverse" (Lemmy, Kbin, Sublinks, Friendica, etc.).

On a personal note, in early 2023 I had finally switched to a job that actually respected my evenings and weekends, no more unpaid overtime!

These factors converged into a single goal: build a Lemmy client for Android and iOS using KMP. A year later, the Friendica client followed.

This was my playground. I could try libraries, break things, and discard what didn't work for my use cases (like Koin or Ktorfit).

So, finally, I had:

• total tech freedom: I was the lead, the junior, and the steering committee.
• continuous learning: hands-on experience with the bleeding edge.
• purpose: contributing something useful to an ecosystem I actually believed in.

The "Why" Behind the Trash

Even without a paycheck, the ROI on these projects is massive. It's professional growth and psychological satisfaction rolled into one. It's a process of hypothesis and experimentation, not unlike academic research, but with more raccoons and fewer lab coats.

This also explains why instead of always going on and pile new features one on top of the other, sometimes the development process seems to go in circles: e.g. switching from a network library to another, rewrite the app navigation system, migrate localization from a framework to another, etc.

But why talk about this right now?

Recently, I hit a milestone: version 1.0.0 of the Mastodon/Friendica client. A local admin wrote an announcement about it (in Italian). Then they ran it through machine translation and posted an English version.

You know, the Fediverse is federated, so this propagated to Lemmy, where naturally critics arrived:

The "proofs"? The word "finally" appeared in the middle of a list. Apparently, to some, using transition words is a sign of a robotic takeover rather than, you know, being relieved that a some longed-for feature is available to end users.

The Human (and Raccoon) Element

This brings us back to sustainability. When we maintain open-source projects, we aren't just pushing code; we're managing a community and navigating the weirdness of the Internet.

The "AI slop" accusation stung, but it also highlighted the irony: I do this work specifically to keep the human element alive in tech. I build these apps so we have independent, non-corporate ways to communicate and I do so because I love software development and learning new technologies.

So, to the "lemming" who thought I was a bot: I'm not. I'm just a developer who likes KMP, hates unnecessary API fees, and occasionally enjoys a piece of "trash" code that eventually may turn into treasure.