Yeah ! I feel like until we figure out the correct UX for non-technical people the right way would be a sort of hybrid. Where you'd set it up on a remote server (if you know opencode you know openwork) and you just then have non-tech people do a one time setup to connect to the remote and from then on you can easily extend capabilities.
This is the approach that I've taken with Open WebUI. It's a great piece of software for exposing a shared GPT interface but of course that's pretty primitive in the grand scheme of things compared to something like this. But I completely agree with what you're suggesting and I think it's the only practical way to get a multi disciplinary team collaborating with this kind of a tool.
I used "open" because:
- it's open source
- built on top of open source (opencode)
- it's built-around extensibility via plain-text files (skills) and open-source plugins
There's first-class integration of https://github.com/enulus/OpenPackage and we provide a ui to install from a list of skills easily as well as add your own.
First obvious stuff like getting the dmg notarized having easier install.
Then after it will be about optimizing onboarding. One of the core goals is to help Susan do 1 small task in under 5 min.
To do that we will need to:
- have some prepackaged configs for folks like starter template
- ship opencode within the app itself so users don't need to manually install it
- and get rid of the technical jargon that is cluttered in the app.
Right now it's really quite barebones and basically just abstracts the openai embeddings api & pinecone, but we're planning on making it easy to work with whatever database or auth mechanism.
reply