I am considering formalizing a module called Cattle that “replaces” the more general animal module. This module would be specific to a cow calf cattle operation and maybe a backgrounder and finishing yard. The module will serve no purpose to anyone outside of the cattle industry.
Do you flesh out the animal module to handle all the specifics (probably around 200 fields) or start completetly from a blank asset named cattle that has nothign to do with animals.
1 Like
It is easy to add bundle fields and behavior that extend the existing animal module. It is also quite feasible to make a distinct “cattle” asset type and separate module for that.
So if both are viable, what are the considerations? (Sorry if some of this is obvious.)
At a code/feature level:
- Are any of the existing farmOS animal asset/module features useful for you?
- Do you foresee conflicts between the features in the animal asset/module and the ones you are hoping to develop?
At a community level:
- Who is your intended audience? Will they already have dependencies on using animal assets and want your module to play nicely by integrating with or being isolated from that?
- How do you see your module fitting with the ethos and ecosystem of farmOS? i.e. You presumably like the data-model and modularity of farmOS in general. How much of the custom stuff you’re imagining is actually cattle specific? Maybe swaths of it would also apply to sheep/goats/alpaca/horses/etc? Is it better for the community module ecosystem to have each of those siloed into “all in one” modules the provide all the features for that type of livestock (and presumably duplicate code where commonalities exist)? Conversely, maybe it would be better to break the features out so folks can mix-and-match the features they need for a given type of livestock - and/or regulatory environment/region?
1 Like