How things get built... (from ideas to code)

There have be a lot of great ideas, suggestions, and feature requests for improving farmOS over the years! And even more so since farmOS v2 was released. :slight_smile:

I think it is worth taking some time to provide an overview of “how things get done” in farmOS (and open source projects more generally). It may not be intuitive, especially in a world where so much software development happens “for free” in centralized, top-down, company-driven contexts.

All farmOS development happens either a) by volunteers who need/want features themselves, or b) by groups/individuals sponsoring a developer’s time to build something for them.

We have a small community pool of funds through our OpenCollective, which we have been using for infrastructure costs and community initiatives. It is not enough to sponsor ongoing development, however we hope that in time it will! If you are not already a backer, please consider becoming one!

In the meantime, if you have ideas for improving farmOS:

  1. Start a forum topic to discuss them! This is always the best first step, because it gets the ideas in front of the rest of the community, for feedback and other perspectives. You may find someone else who wants this too, and can either help develop it or pitch in to sponsor it. It also allows other perspectives to chime in - sometimes a great idea in one context breaks someone else’s workflow, so it’s good to get broad community eyes on ideas before starting any work.
  2. Offer to sponsor development! If you aren’t a developer, but you have resources that you are willing to put towards your idea, you may be able to find someone who can help with the implementation. The core farmOS maintainers are often available for sponsored work (that’s how we pay our bills!) and we have also talked about starting a new forum category for job-post-related threads.
  3. Build it yourself! If you are a developer, and you want to build a feature, go for it!

An important point: because farmOS is “modular”, features do not need to be built directly in the core codebase. They can be built in modules that are maintained by anyone! This has a number of benefits:

  • Anyone can experiment without needing to go through an approval process for core changes.
  • The core farmOS maintainers don’t need to maintain everything! (this is a big one)

Lastly, a quick note on “feature requests” and “issue queues” specifically: Lately I have been refraining from opening new issues in our issue queues for every feature request that comes up in the forum, simply because it only adds to our issue queues without any guarantee that it will be implemented (issue queues require our attention and maintenance too!) So moving forward I intend to reserve those for features that are actually funded or being worked on. Until then, incubation of the ideas can happen in the forum.

Hopefully this post helps to clarify how development happens in farmOS, and how you can help push things forward! :smiley:

6 Likes

Does it make sense to have a consolidated list of feature request somewhere? Just to keep track of them all. Possibly a forum post that is a wiki. It could provide a link to the forum discussion on feature request for a deeper dive. Or possibly adding a discourse “feature request” tag?

2 Likes

+1 - I was thinking this as well! It seems that we have tags disabled altogether right now. It may be useful for other scenarios like “support request”, “feedback” and “contrib module”. Tags would be visible here: https://farmos.discourse.group/tags

2 Likes

+1 I think tags are a great idea!

I enabled tags and created feature-request and support-request. Easy to expand as needed!

2 Likes