I find it very tempting to go for the “one Omeka S to rule them all” scenario, and build all exhibits based on a single instance. After all this seems to be one of the driving ideas behind the project.
I feel however that this can lead to confusion as we add modules and themes, users experiment with items, resource templates, etc. Things can become quite bloated and confusing. Permissions do not always allow us to separate projects the way users would want, etc.
I am curious to know what people have been doing to manage this! Which approach seems the right one to you and why?
We do a little of both. We have a sandbox installation where authors can experiment with different modules before building their exhibits in the production system. Only modules and themes we trust and need end up in production.
In both installations, we use a module we developed that creates teams inside Omeka. With the module, the sites and resources that users see in the admin interface depend on the team they belong to. They can switch into any team where they are a member to change the items and sites they see. And users can have different roles/permissions in each team. It cuts down on the clutter users have to wade through if you have a lot of people working on unrelated projects.
Our main concern was bloat and authors accidentally deleting or modifying content they shouldn’t.