FreeShow: a presenter for the room that has one screen and a laptop

The problem is a room with one screen and no budget

FreeShow is a free and open-source presentation program that makes it easy to show text on a big screen. The project documentation gives the origin plainly: the creator found that other similar programs were either expensive or complex to use, and wanted something easy to use and affordable for everyone, from small churches to large venues.

That origin shapes the whole scope. The feature list in the project topics is short and telling: church, lyrics, media, presenter, show, text. The core job is putting words on a screen, the words being song lyrics, and doing it in a way a volunteer can operate on a Sunday morning without training.

The application supports stage display, remote control, media, and a set of further features the documentation summarises rather than enumerates. Stage display is the part that matters most for the stated audience: the operator sees a private view on the laptop and the congregation sees only the output, which is the arrangement every church running projected lyrics already needs.

The project is written in TypeScript, licensed GPL-3.0, and published under the ChurchApps organisation with the site at freeshow.app. The last push to the repository was on 2026-10-19.

Electron shell, Vite frontend, and native modules that need rebuilding

The repository layout and the manifest describe a conventional desktop application stack. The package is named `freeshow`, marked private, with `build/electron/index.js` as the main entry, and the build tooling is Vite for the frontend with Svelte, given by `svelte.config.mjs` and `vite.config.mjs` at the root.

The interesting detail is the native module handling. The manifest has a `postinstall` script that runs `electron-builder install-app-deps`, and two explicit rebuild scripts, `rebuild-opus` for `@discordjs/opus` and `rebuild-osr` for `osr-capture`. Both of those are native dependencies that have to be compiled against the local Electron ABI, which is why they are separate steps rather than part of the normal install.

The `osr-capture` dependency in particular points at screen capture being handled natively, and `@discordjs/opus` points at Discord audio, which fits a program whose controls can be driven remotely.

TypeScript configuration lives under `config/typescript/`, with separate tsconfig files for the electron side, and the scripts directory holds the build and run helpers including `scripts/start.js`, `scripts/electronDevPostBuild.js`, `scripts/preBuild.js` and `scripts/postBuild.js`. A `makesnap` script and a `public/` directory sit at the root alongside the `src/` and `scripts/` trees.

Building from source needs Node, Python and a C++ toolchain

The development instructions are a numbered list, and they are specific about the native toolchain because of the native modules. You clone the repository, install Node.js, install Python 3.12 with the `setuptools` package, and on Windows install Visual Studio with the Desktop development with C++ workload and the Windows 10 SDK selected. On Linux, one library is needed:

sudo apt-get install libfontconfig1-dev

That library is a font configuration dependency, which makes sense for a text rendering program.

With the prerequisites in place, the install and the launch are two commands:

npm install

npm start

The manifest pins the Node floor, and it is a high one:

    "engines": {
        "node": ">=22.12.0"
    }

The `postinstall` hook runs during `npm install` and invokes `electron-builder install-app-deps`, so the native rebuild happens as part of that step. If you are on Linux or macOS and skip the Visual Studio step, that is fine; if you are on Windows, the C++ workload is not optional.

For most users none of this is necessary, because the project distributes releases on GitHub, and the README points at the releases page through its download badge.

Two run modes, and a production chain you can read in the scripts

The npm scripts expose two ways to start the app, and the difference is instructive. `start` runs `node scripts/start.js`, and the alternative `start:old` runs a parallel frontend build and the electron process through `cross-env` with `NODE_ENV=development` and `npm-run-all`.

The production path is longer and shows what the application actually is made of:

        "prebuild": "cross-env NODE_ENV=production node scripts/preBuild.js",
        "build": "cross-env NODE_ENV=production npm-run-all -s build:frontend:prod build:servers:prod build:electron:prod",
        "postbuild": "cross-env NODE_ENV=production node scripts/postBuild.js",

Three products are built in sequence: the frontend, the servers, and the electron main process. The presence of a separate servers build in the chain is the structural fact about this application that the rest of the documentation only hints at. FreeShow is not only a local slide viewer; it contains server components, which is what makes remote control and stage display possible, and it is presumably also what allows a phone or another device to drive the show.

The development path mirrors that structure: `start:electron` runs a watch-mode TypeScript compile of the electron tsconfig alongside the electron process itself, with `electron .` as the final step.

A local server means the remote control is part of the architecture

This is where the design becomes more than a slide viewer, and it is also where a security question appears that the README does not answer.

A presenter that supports stage display and remote control has to be reachable. Either the remote device talks to the running Electron app over the network, or it does not, and the presence of a servers build in the production chain says the first. A church with a laptop in the sound booth and a phone in the pulpit is the classic arrangement, and it works because the app is running a server alongside the interface.

The documentation does not describe that server: no port, no authentication scheme, no firewall guidance, no note about which interfaces it binds. That silence is the practical risk to weigh. A program that is installed on a laptop and left running for hours, reachable by anything on the same network, is a different security posture from a closed application, and the people deploying it are often volunteers. If the deployment matters to you, the right move is to check the behaviour of the servers build directly rather than assume it is loopback only.

What the documentation does cover is community. There is a user group on Facebook, a Slack channel, GitHub issues for bugs and feature requests, GitHub discussions for feedback, and a mailing address at [email protected]. Translations are handled through Transifex.

Free because of sponsorship, and GPL-3.0 on top of it

The project states the funding model directly: the only reason this program is free is because of the generous support from users, and the README points to ChurchApps as a partner and to GitHub Sponsors. There is no advertising, no telemetry, and no paid tier described anywhere in the documentation.

The licence is GPL-3.0, stated in the manifest and in the licence badge, with the `LICENSE` file at the repository root. For a church or a small venue running the software as downloaded, that is unremarkable. For an organisation that wants to modify it and keep the modifications private, it is not, and that is a licensing question to read rather than assume. This is not legal advice, it is the ordinary reading of a copyleft licence applied to a desktop application, and the file itself is the only authority.

The project also lists its community entry points in the readme, which is a sign of a project that expects user support rather than just user adoption: Facebook for end users, Slack for contributors, GitHub Discussions for feedback, and Transifex for translation.

Beta tags, a weekly cadence, and no documented extension point

The release history shows a busy project. v1.6.6 was published on 2026-10-09, v1.6.6-beta.4 on 2026-10-02, and v1.6.7-beta.1 on 2026-10-14, with the last push to the repository on 2026-10-19. Beta tags are used alongside stable ones in the same line, which means the repository's default branch can be ahead of what most people would consider a safe deployment target.

The gap between the project and its users is the other thing to look at. The README documents installation, the development setup, the community channels and the feature areas in one paragraph each. It does not document a plugin API, a scripting interface, a file format for show files, or an API for driving the app from another system. The topics confirm the audience: churches, lyrics, media, presenters. This is a purpose-built tool for a specific job rather than a general presentation platform.

That makes the adoption decision straightforward in one direction and awkward in another. If your need is exactly projected lyrics plus slides plus a stage view on one machine, the tool is well matched and free. If you need to script the show, integrate with a mixing desk, or pull content from another system, the project offers no documented way to do it, and the honest channel for that is a feature request in the issue tracker rather than an integration you can build today.

Editorial conclusion

FreeShow fits a volunteer or small team running a service or event on a Windows or Linux machine that needs lyrics, slides and media on a projector with a private stage view, and it fits a venue that cannot justify a licence fee for presentation software. It does not fit a workflow that needs a documented plugin API, a scripting interface or an automated show rundown, because the project documentation describes none of those, and it is a poor fit for an organisation that cannot accept GPL-3.0 copyleft on a modified build. Before you deploy it, note that the current tag is v1.6.7-beta.1, so the stable artefact is v1.6.6, and check that your machine meets the Node 22.12.0 floor if you intend to build from source rather than download a release.

Frequently asked questions

Official sources

1. ChurchApps/FreeShow on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases