The vast majority of objects are directly compatible because they’re essentially mathematical, they don’t directly access hardware resources. Those can easily be merged in either direction at whatever frequency we like.
Incompatibility arises when objects directly access low level hardware resources. It shouldn’t even be designed this way. There needs to be a general API for accessing resources from object implementations that doesn’t know about the underlying processor.
Longer term, the Akso object format is going to change completely. The patcher is going to change completely as well. I don’t see making decisions in those areas based on trying to maintain compatibility with the existing Axoloti distribution directly. I think what makes sense is to allow people to run the Akso distribution on Axoloti hardware if they choose and be able to drive both pieces of hardware from the same patcher. That way we can have direct control over firmware and object compatibility; the firmware would keep track of what resources are available for each target. If people want to backport particular objects to the legacy Axoloti distribution, that will be possible.
I’m not totally satisfied with the contrib sharing mechanism itself. I think exposing
git details in the app is a mistake; most users don’t care about that at all. I see having more of a “sign in” mechanism somewhat like VCV Rack that is integrated with the object browser web interface where you can subscribe to objects and store work. Sharing objects should not require authorization to commit directly to a Git repository.
This is a longer discussion. Will return with more thoughts later!