Using Mobilizon for regional leftist subculture calendar platforms

tl;dr: We love using Mobilizon, but need/did some changes for it to fit our needs and are wondering wether these changes would be in scope for the project as a whole.

We are a somewhat losely connected group of people that got to know each other through operating regionally specific Mobilizon instances in germany, that strive to attend to a leftist-alternative audience in the corresponding cities:

Calendar platforms like ours are a lot more widespread, but are usually run on self-written software. One of our members created an overview of comparable calendar platforms in the GSA region (germany, austria, switzerland).

We are big fans of Mobilizon as a project and believe that these well-established platforms (some of them exist for more than a decade) could benefit from migrating to Mobilizon.

  • Using only one codebase would ensure less maintenance work and better features, also in regards to accessibility.
  • Finding and using a calendar platform in a different city would be easier, as the interface wouldn’t change much (e.g. when people move or are on vacation).
  • Having a unified set of APIs would make it easier for producers and consumers of the data to build specialized tooling (e.g. a night club could integrate their Mobilizon events into their own Wordpress site).
  • Having events available in the fediverse would allow people to follow their favourite event location and see their events in their social media timeline.

At the same time, we had to modify the Mobilizon frontend somewhat heavily for it to be suitable to our needs. The codebase for that can be found here. We see maintaining our own fork as an unnecessary bourden though, which even negates the mentioned benefits of introducing Mobilizon to these platforms. Our favourite outcome would be therefore for mainline Mobilizon to accomodate for our use case.

But let’s first talk about, what exactly that use case would be. In order to work out for our audience, we developed the following key design changes. Many of these are already proposed/being worked on in some way upstream. We try to mention all affected issues.

All of these design changes are already implemented in our codebase. For getting a better feel for what these changes mean in practice, we recommend having a look at, which is still based on Mobilizon 2.1.0 for now. A wip instance that follows our current main branch is available here.

Additionally to these core design goals we worked on the following adaptations:

  • No decorative pictures – We felt like these were too distracting for our use case.
  • Two changes to the german translation, that would both make Mobilizon appear less politically conservative, language wise:
    • Change the address to a colloquial Du instead of Sie: This is pretty much the norm for interactions online, see e.g. the Mastodon website: Mastodon - Dezentrale soziale Medien
    • Use degendered language, e.g. Nutzer:innen instead of Nutzer. While being debated in german society as a whole, usage of this language is pretty much the standard in our audience. Even some government websites adapted to it.

Our question would be now, wether this scope that we developed would be in line with the idea of the Mobilizon project as a whole? If yes, we could start upstreaming our changes, or work on making them configurable, so users of mainline Mobilizon could configure their instance to fulfill our scope. The reason we just didn’t start doing this right away, is because we aren’t sure wether our usecase is actually in line with the goal of the project.

Also looking at the at the announcement, that Framasoft won’t fund the development of new features starting 2024, some of us see us in the position to maybe contribute to the project long-term?


It’s great to hear from other big fans of Mobilizon and to discover your instance, which looks very nice.
My association is running few instances (one for family events, one for our city associations and a generic one We also had to tweak them and same as you we’re using version 2.
For now onlyTcit who’s the developer and project manager could answer about the roadmap, but we’ve offered to Framasoft to go on with Mobilizon and keep improving it. There should be some transition to us after they release their last version. At least, we should be able to integrate contributions in the main branch, so that all the community can benefit from them. We’d be glad to integrate your changes and collaborate with you on the roadmap. All you explained make sense to us and we value your experience with Mobilizon.
If you’d like to discuss further with us, I suggest you reach out to @setop who’s worked on our instances.


Yes, we are very curious about the answer of @tcit . :blush:


to keep the topic current, I would like to express my interest in the modification as well. Additionally, I would like to draw attention to another feature that has been implemented on There seems to be the option to hide the number of participants, which I find very practical.

Thank you for all the work you put into this!


I feel very in line with your use case and homepage.
I agree with your « average user point of view » design choices. They need to find the informations they want as easily as possible with as little distraction as possible.

Thanks for your code base, I’ll try to use it to enhance my local instance.


Thanks for the responses so far, everyone!
We now are running our current code base (based on the upstream main branch) in production:


It is great to see this. I have started with Mobilizon v3 but I share many of your wishes for UI changes, so I think I may start over with your codebase instead. I hope the transition of Mobilizon to Kaihuri is successful and your contributions are viewed positively. They are very important and useful.

1 Like

@potsdamn many thanks for putting that together, it’s of great value.
I’ve tried to list those changes and identify them with tag « upstream » in the git, you can have a look and check if it’s thourough, if not let me know: Issues · Framasoft / Mobilizon · GitLab

Hi @Felix0815
I’m working on upstreaming existing developments to the latest version, I will take it into account: Option to hide the number of participants (#1403) · Issues · Framasoft / Mobilizon · GitLab
I had a look at, it’s neat, do you know who runs it? Do you think they would mind sharing their developments as Potsdamn did?
Thanks for your answer.

Hi @potsdamn,

That means, that federated events should only be visible on the homepage, if the admins explicitly allowed it.

It is implemented on one of your instances ? I haven’t been able to find it in your repo.