This post is co-authored by @Mario and @Rachel
We are feeling OFN features and evolution decisions start to be less co-designed and more individually thought (funded features are more easily funded than shared roadmap items, AI-assisted development contributions start to be based on the uncurated wishlist or on issues directly created and then picked up).
This creates confusions: most instance managers don’t know anymore how decisions on features are made.
We also start to see features being worked on without any community endorsement, which is a deviation from the previous model OFN collectively agreed on.
Maybe this is the way to go, we just want everyone to be fully aware this is happening.
Community endorsement is necessary on a shared solution. But maybe this is not what OFN needs anymore and a different set up needs to be found.
There are several paths forward possible, but before jumping towards solutions, we would love to hear from everyone.
What’s your biggest frustration with OFN feature development?
How do you wish to be involved in these processes?
To help everyone understand the journey on the topic so far, we’ve added below an overview of how OFN’s software processes changed over time and why ![]()
Click to unfold
2017 - 2021
When the first instances started to use the OFN software built in Australia, they funded their own local teams, putting all the effort on recruiting developers, as this was a skill not present in most of the instance managers.
Each local team hosted and maintained their own server, but the software code remained unique.
Even if each team shared what they were doing, the software soon started to have a lot of features, not all of them being the highest priority to build for a project like OFN.
So after a gathering in Australia in 2017, the community decided 3 main directions:
-
collectively learn how to prioritize software features (UX design methodologies were introduced, community facilitators started to ensure user needs were properly discovered and no one was jumping too quickly on solutions). see summary here
-
the team working on the software (core delivery team) was created and started to work together towards a shared roadmap. The global budget spreadsheet was introduced in order to track money coming in and out and the pledge was modified accordingly
-
work on automating the server updates was done and the delivery team started to maintain a selected pool of OFN instances
The roadmap was prioritized at a global level, with discussions involving everyone, whether they had been able to raise money for the global pot or not.
Given OFN has always operated on a low budget, allowing only part-time work with no long term engagement, the roadmap was very slow to progress.
This was not a problem for the bigger pieces of work, which needed that time to move from inception, through MVP to maintained version.
It was an issue however for 3 work items: low-hanging fruits, low-severity bugs (s3-s4) and the ability for instances to send quotes to their users who have asked for a particular feature.
This is why the community introduced the following processes to balance these issues: papercuts, s3 selections (on a similar process than papercuts) and funded features.
These processes were still built on the principle of co-design, ensuring that no features are individually built (and therefore a nightmare to maintain).
What held this together was what we often label “core” tasks: community facilitation, product & design, code review and tests + shared maintenance: even if the feature was funded individually. In other words: the budget used for these actions was still a shared budget.
2023 - now
The last papercut and s3 bugs selection occurred on July 2023. This is the first type of core task that was put on hold due to OFN global budget problems.
The pause was thought as temporary, but as OFN budget problems keep worsening, the budget cut into additional core tasks until April / June 2024 when it was decided that the OFN core team should only dedicate their time on funded features.
Most of the current instance managers haven’t experienced any of these processes. The community started to forget they existed or where they were documented.
When OFN Australia announced their new funding in October 2025, a lot of instance managers thought that this new funding would cover core tasks like it used to do.
The reality is different. While this funding is targeting core tasks (fundraising, some tech debt and contributions’ code review and test) some other core tasks are still relying on volunteer contribution since 2023, like:
- Facilitating and funneling user feedback into potential software work
- Product and design facilitation for good first issues and volunteers’ contributions (code reviews and testing are mostly paid work, using core budget)
- Wishlist curation
- S3 bugs review and fixing
This list excludes tasks not entirely linked to the software like general community facilitation and gardening, among others which still remains volunteer-based.
Papercuts selection by instances were not re-introduced, which means low hanging fruits can only be delivered through good first issues processes (which are not well maintained under voluntary contributions only).
In parallel we are seeing more contributions coming from the AI working group. This is a mix of bug fixes, wishlist items, and new issues created from scratch and pushed through the pipe.
It is great to have folks contributing in such a meaningful way and volume, but this is a shift from a collectively curated list coming through the pipe and it’s important to acknowledge it.