# OpenSlides: running the agenda, motions and votes of an assembly > OpenSlides is a free web based system for managing and projecting the business of a deliberative assembly, deployed as a set of separate services under a Go workspace and driven through Docker Compose. It is niche software for a specific civic job, and the cost of adoption is dominated by the Docker deployment rather than by the code. **OpenSlides/OpenSlides** — The digital motion and assembly system - Repository: https://github.com/OpenSlides/OpenSlides - Website: https://openslides.com - Stars: 655 · Forks: 186 - Language: Shell - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/openslides-openslides ## An assembly system, not a slide deck tool The README describes OpenSlides as a free, web based presentation and assembly system for managing and projecting agenda, motions and elections of an assembly, and points at openslides.com for more information. The word assembly is the key to the scope. This is not a conference presentation tool with a vote button bolted on. The domain objects are the agenda of a sitting, the motions put to that sitting, and the elections held within it, and the system has to project all of that to the room. A debate or a committee session is the use case, with a chair, a list of motions, and a voting procedure that people have to be able to follow while it happens. That also explains the repository structure, which is not a single application. The top-level entries are ten service directories, each with its own name: openslides-auth-service, openslides-autoupdate-service, openslides-backend, openslides-client, openslides-icc-service, openslides-media-service, openslides-projector-service, openslides-proxy, openslides-search-service and openslides-vote-service, plus openslides-cli. The Makefile lists the same set as the service targets: ``` .SERVICE_TARGETS := auth autoupdate backend client icc media projector proxy search vote ``` The voting, the projector, the authentication and the media handling are separate processes, which is a reasonable decomposition for a system that has to keep the projector running while the room talks about a motion. ## The Makefile is the developer interface For a project of this size, the Makefile is the most useful file to read, because it is where the intended workflows are named. The paths are set at the top, with the development Docker directory, the script directory and the makefile script directory, and two compose files are defined for the two modes: ``` override DC_DEV=docker compose -f $(DOCKER_PATH)/docker-compose.dev.yml ``` The Go version is taken from the first line of the workspace file, which is why the Go build metadata lives in go.work rather than being repeated in every service: ``` override GO_VERSION=$(shell head -n 1 go.work) ``` The service targets themselves are thin wrappers. The dev family of targets, which includes dev, dev-help, dev-detached, dev-attached, dev-stop, dev-exec, dev-transient, dev-enter, dev-clean, dev-build, dev-db, dev-log, dev-log-attach, dev-restart, dev-full-restart, dev-docker-reset and devstop, all do the same two things, first rewriting the Go version into the workspace files of the dev directory and then handing over to a shell script: ``` @sed -i "1s/.*/$(GO_VERSION)/" $(DOCKER_PATH)/workspaces/*.work @bash $(MAKEFILE_PATH)/make-dev.sh $@ "$(filter-out $@, $(MAKECMDGOALS))" ``` So `make dev-backend` and `make dev-log` are the same script with a different argument, and the sed line exists because the container images are built against a specific Go version that has to match the host toolchain. ## Two ways to run it locally, with different trade-offs The Makefile offers two local stacks and the difference between them is a real design choice rather than a naming detail. The first is the dev stack, the one driven by the make-dev.sh script with the per-service targets listed above. It is the flexible one. You can start, stop, restart, exec into, follow the logs of or reset any individual service, and there are flags for it, including no-cache, compose-adapt-branch, no-log-prefix and debug-dry-run. That is the mode you want when you are changing one service and want the rest of the stack to keep running. The second is localprod, which is a single compose file you bring up directly: ``` @if [ ! -f "dev/localprod/docker-compose.yml" ]; then echo "No docker-compose.yml exists in dev/localprod. Have you run setup.sh yet?" && exit 1; fi docker compose -f dev/localprod/docker-compose.yml up --build ``` Note what that guard does. It checks for the compose file and, if it is missing, tells you to run setup.sh and stops. The localprod path is a one-command bring-up of the whole stack with the images rebuilt, with no per-service control and no script layer in between. The practical difference is that the dev stack optimises for iteration on one component, while localprod optimises for getting a full working instance in front of you quickly. For a first evaluation of OpenSlides, the second is usually the faster route, and for working on a single service the first is the one you will keep. ## Tests run in containers and in GitHub Actions locally The testing story is visible in the same Makefile, and it says a few things about how the project is maintained. There is a run-tests target that delegates to a script which walks the submodules: ``` bash dev/scripts/makefile/test-all-submodules.sh "$(filter-out $@, $(MAKECMDGOALS))" ``` And there is a test-ci target that runs the CI workflows on your own machine: ``` bash $(SCRIPT_PATH)/act/run-act.sh $(FOLDER) $(WORKFLOW_TRIGGER) ``` That second one is worth pausing on. The script is named after act, the tool that runs GitHub Actions workflows locally, and the README badges confirm the shape of the pipeline: separate workflows for tests and for building images, each split into a stable and a staging variant, giving four badges, tests-stable, tests-staging, build-stable and build-staging. So a contributor can run the same workflow definition that CI runs, and the split into stable and staging channels is how the project tests a release line and the moving branch separately. The submodule structure is also visible in the repository layout, with a .gitmodules file at the root and a test script that iterates submodules, which matches the service-per-directory layout. ## Installation is documented separately, and 4.3 broke things The README does not contain installation instructions, and that is deliberate. To set up an OpenSlides 4 instance you are pointed at the install instructions in INSTALL.md, and for further information about developing OpenSlides you are pointed at the development readme, DEVELOPMENT.md. The repository root is organised around that split. There is INSTALL.md, DEVELOPMENT.md, an UPDATE_TO_4.3.md, a CHANGELOG.md, a VERSION file, a SECURITY.md and an AUTHORS file, alongside the Makefile, the go.work file and the service directories. There is a `lib` directory for shared code, an `i18n` directory for translations, a `dev` directory holding the Docker and script trees, a `patchnotes` directory, and a `logo` directory. The one warning in the README is worth repeating. Updating to OpenSlides 4.3.0 introduces breaking changes, and the README points at a dedicated info document for the details. A project that keeps a legislative record, a set of motions and a voting history has data with a long life, and an upgrade that changes how that data is stored or read is not something to do on a Friday afternoon without reading the document first. The i18n directory and the .tx configuration directory at the root also tell you that the interface is translated, which matters if your assembly operates in more than one language. ## MIT licensed, and released every couple of weeks OpenSlides is described as Free/Libre Open Source Software, distributed under the MIT License, with the LICENSE file at the root and the authors listed in the AUTHORS file. That is a permissive licence with no copyleft obligations, which for software that a council may deploy, fork or vendor into its own environment is usually what is wanted. The release cadence is steady. The recent versions are 4.3.5 from 2026-10-09, 4.3.4 from 2026-09-23 and 4.3.3 from 2026-09-16, so three releases in a month on a 4.3 patch line. The repository is not archived and the last push was on 2026-10-19, so the branch is ahead of the newest tag by a couple of weeks, which is the normal state for a project where releases are cut from a moving branch. The default branch is main, and the .github directory holds the workflows whose badges appear at the top of the README. One structural note for anyone reading the repository rather than the documentation. The primary language recorded for the repository is Shell, which is a signal about the visible surface of the codebase: the Makefile, the scripts under dev/scripts and the compose orchestration are what you read first, and the Go services themselves live in their own directories behind a go workspace file. The build system is the entry point to the code, not the code itself. ## Conclusion OpenSlides fits a parliament, a party conference, a union branch or a municipal council that wants its motions, roll call votes and agenda handled in one place and projected in the room. It is the wrong choice for a slideshow tool, since the motion and election machinery is the product and not an add-on, and the wrong choice if you cannot run a Docker Compose stack. Verify first the 4.3 breaking change, since the README points to a dedicated document for it, read INSTALL.md for the deployment path you will actually use, and check how the ten services are split before you commit to the architecture. ## FAQ ### What is OpenSlides used for? The README describes it as a free, web based presentation and assembly system for managing and projecting agenda, motions and elections of an assembly. It is aimed at deliberative bodies such as councils, parties and unions, not at slideshows. ### How do I install OpenSlides? The README does not contain the steps and instead points at the install instructions in INSTALL.md for setting up an OpenSlides 4 instance, and at DEVELOPMENT.md for working on the project itself. ### Is there anything to know before updating OpenSlides? Yes. The README warns that updating to OpenSlides 4.3.0 introduces breaking changes, and points at a dedicated info document, UPDATE_TO_4.3.md, for the details. ### What are the separate services in the OpenSlides repository? The top-level directories cover auth, autoupdate, backend, client, icc, media, projector, proxy, search and vote, plus openslides-cli. The Makefile lists the same set as its service targets, which drive the development stack through dev/scripts/makefile/make-dev.sh. ### How do I run the OpenSlides tests locally? The make run-tests target runs dev/scripts/makefile/test-all-submodules.sh across the submodules, and make test-ci runs the CI workflows on your machine through dev/scripts/act/run-act.sh. The repository also publishes separate test and build workflows for stable and staging channels. ## Sources - [License: MIT](https://github.com/OpenSlides/OpenSlides/blob/main/LICENSE) - [OpenSlides/OpenSlides on GitHub](https://github.com/OpenSlides/OpenSlides) - [Project website](https://openslides.com) - [README](https://github.com/OpenSlides/OpenSlides/blob/main/README.md) - [Releases](https://github.com/OpenSlides/OpenSlides/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openslides-openslides