OFN's community-led vision and strategy

This post is co-authored by @Mario and @Rachel

Hi @instance_managers

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 :right_arrow_curving_down:

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.

Thanks @Rachel and @Mario

Biggest frustration with feature development:

  • Small issues (s4, s5, simple/small wishlist items) not being worked on due to budget restrictions. I completely understand the need to prioritise s2 & up, and funded features, however an accumulation of small annoyances can have a big impact on a user. This is where I really see the value of the AI project in reducing the backlog of these small annoyances.
  • Lack of involvement in roadmap prioritisation - although perhaps this is because prioritisation is purely based on funding availability now, not community co-design

How do I wish to be involved:

  • I’m very willing to give my feedback on proposed development and roadmap prioritisation from a UK perspective.
  • I’m also happy to continue working on existing S4/S5s with AI - obviously these are self-selected, however we already have voluntary contributors doing the same :person_shrugging:
  • I try to keep my eye on issues being opened and contribute instance feedback where I can but I can try and do this more
  • I wonder if we brought back the instance voting for s3s, whether we could use these to identify candidates for the AI coding team
2 Likes

Thanks @Rachel and @Mario for summarizing all the history and evolution and starting this conversation.

As far as my biggest frustration - I would say that it is the time scale and waiting for new features/improvements to be realized.

As far as being involved, from my experience with the AI community of practice, I think there is a role for OFN support members, like myself (with no coding experience) to contribute to moving improvements along, and would be happy to be able to contribute more to this process in a way that doesn’t put extra strain on dev/reviewer time.

As part of the AI project, it was very interesting to learn more about the developer side of github and processes and it was empowering to be able to work on and fix small bug issues (s4, s5 and wishlist items). Going forward, I think it would be helpful if ‘AI ready issues’ were somehow incorporated in the roadmap/prioritization process, so those who want/are able to contribute with the help of AI would be contributing to issues/items that are already on roadmap and thus would help instead of burden the dev team workload. Perhaps, as @BethanOFN suggested this could include bringing back instance voting for S3s or papercuts to identify issues to prioritize as part of the roadmap.

2 Likes

Thanks @Rachel and @Mario for those explanations.

biggest frustration with OFN feature development

I share Bethan’s frustration regarding “minor” issues not being addressed. It’s hard to explain to users why new features are popping up while problems that annoy them on a daily basis remain unresolved. I’m jumping ahead to future discussions here, but I’d like to be able to keep using AI to handle these issues.
I also previously regretted that the work done on the order cycles admin was left hanging without any explanation (at least to me). I often find that timelines are too long across the different phases of our workflow. This also leads to wasted time and mental load from having to dive back into old topics.
Up until now, I haven’t felt like I’ve been part of the development choices, except for those recently funded by CoopCircuits.

How do I wish to be involved

I’m very interested in getting involved in OFN’s evolution, prioritization, and the choice of features to develop, but I also know that this requires time I don’t always have. I tend to trust those making proposals, but since we have to prioritize, it would be helpful to have a summary for each feature request explaining concretely what new things it will allow us to do and the dev effort required to get there.
As mentioned before, I’m interested in taking on certain S3/S5 issues like I did recently and maybe contributing to certain features with the help of AI.
I’d like to see the API improve, and I’m interested in developing features—connected to other open-source tools—that aren’t intended to be integrated directly into OFN.

That said, I’d also like to highlight the efforts made over the last few months to keep us updated and informed on the roadmap’s progress.

2 Likes

Thanks for this post and excellent summary of where we’ve come from.
I confess that over the past year, I have just stopped bringing new issues/suggestions forward from users, and I have even stopped doing bug reports if they seem minor and I’ve found a workaround. I know that’s not good, but it comes from feeling frustrated that issues i’ve brought forward in the past don’t seem to go anywhere anyway. When I bring forward an issue, it just takes people’s time to comment on it, and shape it up a bit - and then it sits. I can go back and see issues (bugs, wishlist…) i raised when I first started using OFN in 2016, and they are still there.

Sorry to share a negative tone - but I needed to get that off my chest.

Trying to be more constructive - I think if the AI group can deal with old s3s… that have been hanging around forever, our users would be so excited. We could even ‘market’ this like a ‘program’ - ‘cleaning up’ - and then share it in newsletters with our users.

My other thought is that our support teams have a lot of knowledge about users and user experience. We (at least I) just am lazy about sharing this. I wonder if we need a bit more of a formal process for support people to help with community-led visioning. I’m thinking something simple like a couple of zoom meetings framed around particular themes or something. (I don’t know - its just a half-baked thought.)

Again - thanks for posting and opening this up. Its good to kick this off.

3 Likes

Hi All, it’s good to get some feedback from the community. I though I’d share my perspective as core developer.
It’s been great to see the community leverage AI to fix all those annoying issues we the core team don’t have time/budget to address. As it has been mentioned, these are often self selected, or even just created and worked on directly. While I understand why people are doing that, I still think we need to have some sort of curation. Sometimes, we ended with pull request that don’t really address the issue, or maybe the reported issue is a misunderstanding on how the OFN operate and not necessary a bug. I feel like we end up wasting a bit of time when we (the core team) come across these PR in the review process, for us to just send them back suggesting what should be done. It would more efficient if products or the dev team had had a look the issue in the first place and confirmed it’s an actual bug and maybe give pointer on how to fix the issue.

All this to say, I feel like we lost the “triaging” process we use to have, and we should try to bring it back, and make sure issues are vetted before work commence. We could also introduce the “AI ready” label as it has been suggested, but I feel like it might put off other contributor who may not want to use AI. Maybe project board, like the “Welcome new developers” one would be a better solution.

2 Likes

Hi,

Thank you very much for raising this topic @Rachel and @Mario I feel it is important to keep on questioning the processes and that the priority is to maintain the highest level of collective construction of the project.

My biggest frustations have already been listed :

How do I wish to be involved?

Difficult question for me because I never really understood “from inside” how these collective processes work. It is also maybe due to working in English and to the different timezones of the community.

But I feel aligned with the proposal of @tschumilas very “pragmatic” and users centered.

My proposal would be: let’s meet in Germany end of September and / or online during these days to create a momentum for exchange and making decisions about the processes and priorities regarding software developments. + continuying the process in this thread.

What do you think about?

2 Likes

@instance_managers thank you all for your feedback so far. If you haven’t yet contributed but would like to, we are leaving this conversation open for 2 more weeks before talking about potential next steps. Don’t hesitate to add your pov, even if you feel it has already been covered in previous posts!

I can speak to this as a software user (both customer and shop-owner), hub manager, and more recently as an instance manager.

When my farmer’s market (South Cumberland Farmer’s Market) joined OFN in 2022, we were able to do so because I built us several custom workarounds to deal with issues of scale – we are a large hub that does > $300K USD annually. However, a number of these workarounds were complicated by issues with the reports: fees were calculated incorrectly, no single report contained all the data I needed, and, indeed, some of the data I needed wasn’t in any of the reports. We had been told that features could be requested/funded, bug reports could be submitted, and that things generally happened slowly, but would eventually evolve and get fixed. That proved to be somewhat true, but the timeframe for bug fixes was much longer than I would have guessed, and I spent a lot of time developing workarounds and custom scripts/apps to deal with the lack of progress. When I became instance manager this year for OFN USA, I was quite excited for the chance to leverage my technical skills in the new world of AI coding so that I could help improve the software as one of its heaviest users. I have since spent a lot of time meeting with hubs in my network as well as the Canadian team in order to assess the needs and pain points of the North American OFN community, and I’ve heard echoes from many of them of the same frustrations I have worked through for years: bug fixes that never happen, funded features promised but un- or under-delivered, a roadmap that seems at times disconnected from the actual needs of the user base.

I’d like to be involved at all levels and stages of software development that my skill can accommodate. I am very invested in ensuring that OFN can scale with it’s users, that it remains a cost-effective online food sales platform that provides a quality UX/UI.

3 Likes