There might be a bit of misunderstanding on what's in that git repo here. It actually contains the executor, state store, queue, and our production UI, plus the syncing, registration, and logic for functions.
Earlier this year we didn't want folks to roll their own production cloud due to queueing migrations. It would make your life hard. We're entirely responsible for that right now, as we discouraged self hosting.
That's actually coming to a close, and we'll make it easy to spin up prod clusters using this code and eg. MemoryDB, Dragonfly, or what have you.
Let me know when you do! I like the pattern and APIs you've designed for the SDKs—and would probably rely on a managed coordination layer like you've got. But, in order to build confidence in any product like this, we have to know that if something happened to the co, or you went another direction, we could fork the core and continue on.
Well, my experience has been closer to the "more eyes make for shallow bugs" school of thought, so opening the source to contributions would actually help that process, not hinder it
I've written quite a lot of CI for projects because it's something I believe in and am willing to roll up my sleeves to get done (as a concrete example). I believe strongly that being able to reference the canonical CI build helps contributors since they can see how it's built for different systems and also ensure they don't submit "works on my machine" patches
Earlier this year we didn't want folks to roll their own production cloud due to queueing migrations. It would make your life hard. We're entirely responsible for that right now, as we discouraged self hosting.
That's actually coming to a close, and we'll make it easy to spin up prod clusters using this code and eg. MemoryDB, Dragonfly, or what have you.