Okay, I finally did it… there is a new web site and all of the documentation from the old wikis has been moved to the git repository for the site so they can be more easily maintained together by pull request, can be cloned for offline reference, and so on.
This is a fully static HTML, Markdown, etc web site. The Markdown documentation files are rendered in the client browser. When cloning for offline use, there is a serve.py script the runs a little web server that will handle the markdown files for the docs.
I think that about covers it, this has been long needed, now it’s there. I’m also working on updating the documentation so that will be coming along soon.
On a side note, we’ve been talking about doing this sort of thing for a long time. It’s amazing that we’re in an era where a project like this can be knocked out in an evening instead of a week or two.
This probably looks better than it would if I had designed it, but it is AI designed with some basic suggestions from me, and I’m not attached to any of it. Feel free to propose changes, submit PRs, etc. I’ll keep an eye on it for a little while.
Using Moqui in this case adds no value, and takes away quite a bit versus documentation in a git repo like this. When our primary problem is serving static content, GitHub Pages are cheaper, and remove dependency from me personally. If I disappear the demo goes away, but now that’s about it. Michael is still providing this forum to the community, so that’s another individual dependency still in this project infra.
I think moqui is not exactly a static website generator, there are more focused solutions out there. Moqui is a powerful and robust business automation platform with at least 3 services launched to get anything going. Just because moqui can do it, doesn’t mean it’s the ideal fit for that usecase (content / documentation website).
Furthermore, the previous website had difficulty providing contributions, whereas now it’s a simple pull request, no need for user provisioning, security setup, and a whole bunch of stuff just to write some documentation.
So I think this is a very good direction, and we need to address the docs for moqui 4, and now upgrades to the framework can be accompanied with a PR to the website. So it’s easier to keep things in sync.
Given that I have a long history of not eating my own dog food… maybe I should comment on that. It simply has not been a business model that I’ve had the luxury of running much. My strategy with OFBiz and Moqui has not primarily been to eat my own dog food directly, but to do so vicariously through clients.
In other words, the dog food I make is primarily for others to eat, and direct client engagements have been the main way I get a taste. I don’t have a big company with elaborate information management needs, so to build that sort of software the primary mechanism of consuming dog food is direct client engagement, walking through the trenches with them.
With this model, the less the project infra depends on me the better. Heck, the less the project usage depends on me the better too. I know that it’s not very commercially savvy in a very real way, but my goals are mine to keep.