openFrameworks: a self-contained C++ toolkit for creative coding

What openFrameworks solves, and for whom

Writing a graphics or audio program in plain C++ means assembling a window, a renderer, an input loop, a sound backend and a build system before you draw anything. openFrameworks exists to remove that assembly step. The README describes it as "a C++ toolkit for creative coding", and the folder structure makes the intent concrete: libs holds the libraries the toolkit uses, including the core itself, addons holds functionality that is not part of the core, and examples holds projects that show how to use it.

The audience is narrow on purpose. You need to be comfortable in C++ and in a platform toolchain, because the toolkit does not hide either one. In exchange you get native binaries rather than a runtime, and the same sketch structure across desktop, mobile and Emscripten targets. Artists, designers and researchers who build installations, audiovisual pieces or computer vision experiments are the people the folder layout is arranged for.

The self-contained release is the architecture

openFrameworks does not install into a system prefix and it does not resolve dependencies at build time. A release is a directory tree that you can put anywhere on your hard drive, and everything inside it refers to everything else by relative path. The README states this directly: releases are designed to be self-contained, it is not possible to mix different releases together, and there is extensive use of local file paths such as ../../../ throughout the toolkit.

That single decision explains most of the behaviour you will encounter. The project generator writes new projects into apps, where they sit at a known depth relative to libs, so the generated build files can point upward with fixed relative paths. The examples folder works the same way, which is why you can compile an example without configuring anything. It also explains the most common error the README names: moving a project one level above or below where it was, so that links such as ../../../libs break.

Two branches carry the code. The master branch holds the newest, most recently updated code and is packaged as the Nightly Builds on the download page. The stable branch corresponds to the last stable release. The build status table in the README covers Windows MSYS2, Windows Visual Studio, Linux 64 and Arm, Emscripten, macOS, and iOS and tvOS; the Android row is commented out in the README source.

Installing openFrameworks and running a first example

The README points new users at the download page for setup guides per platform, and recommends grabbing the Nightly Release from the GitHub releases page specifically to avoid submodule cloning. That recommendation matters: a Git checkout pulls submodules, while a packaged release already contains them.

Start by downloading the release archive for your platform from openframeworks.cc/download and unpacking it somewhere permanent. Do not unpack one release inside another. Then look at the folder you now have:

ls
# addons  apps  docs  examples  libs  other  scripts  projectGenerator

A packaged release includes projectGenerator, which the README describes as a GUI based tool for making new projects. Your own work goes in apps; the examples folder is for reading. Before writing anything, compile one example from the tree to confirm the toolchain works. The exact command depends on platform, and the README defers to the setup guides rather than listing them, so follow the guide for your system. What you should see is a native window opening and the example running.

For a new project, open projectGenerator, create the project inside apps, and let it generate the build files. The README notes that projects may generally work from release to release, but this is not guaranteed, so treat a project as belonging to the release that generated it.

Addons, and where the toolkit stops

The core covers windowing, graphics, audio, video, input, events, threading and math, which is what the examples folder demonstrates. Anything outside that lives in addons, described in the README as additional functionality that's not part of the core. Addons are not fetched by a dependency resolver; they are folders inside the release. That means the set of addons you have is exactly the set that shipped with your download, plus whatever you copy in yourself.

This is the point where openFrameworks asks you to make a judgement the toolkit will not make for you. If an addon is missing from your release, copying it from the master branch puts code written against a newer core next to a core that may not match it. The README's warning about not mixing releases is the same warning in a smaller form. Check the addons folder of the release you actually downloaded before planning work around a feature.

Where openFrameworks is the wrong choice

The self-contained design has costs that show up late. There is no package manager step, so there is no lockfile pinning a dependency version and no resolver telling you that two libraries disagree. Upgrading means downloading a new release and moving your apps into it, and the README explicitly does not guarantee that projects survive that move. If your team needs reproducible builds driven by a manifest, this is the wrong toolkit.

The relative path requirement is a second hard boundary. A project cannot be relocated out of the tree, and it cannot be developed in a repository layout of your own choosing without fighting the generated build files. Teams that keep every creative project in one monorepo will find this awkward. The README also points out that a common error is moving a project relative to the root of openFrameworks, which suggests how often this trips people up.

Finally, C++ is not incidental. If you want to change a parameter and see the result without a compile, or if the people maintaining the piece are not C++ programmers, the compile step is a real cost, not a detail.

openFrameworks against Processing and Cinder

Processing is the nearest comparison and the difference is the language and the output. Processing sketches are written in a Java-derived language and run on a runtime; openFrameworks sketches are C++ and compile to native binaries. That changes what you can link against, how you ship, and how long a build takes. It also changes who can read the code.

Cinder is the closer match in kind: another C++ toolkit for creative work. The practical difference visible from this repository is packaging. openFrameworks ships a self-contained release with a project generator, a large examples folder and an addons folder, and it documents builds for Windows MSYS2, Windows Visual Studio, Linux 64 and Arm, Emscripten, macOS, and iOS and tvOS in one table. Whether that packaging advantage matters depends on how much you value a working tree in ten minutes versus a dependency setup you control. The README does not compare openFrameworks to either project, so treat the choice as one about language, runtime and packaging rather than about features.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-15. Releases are cut from the stable branch, with 0.12.1 published on 2025-05-02, preceded by 0.12.1-RC1 on 2025-04-16, and nightly builds published from master. The gap between the last stable release and the most recent push is the practical planning number: stable code moves on release boundaries, while fixes land on master and reach you through a nightly build or the next release.

Upgrade cost is dominated by the release model. Moving an app to a new release means placing it in the new tree, regenerating or adjusting its build files, and rebuilding against the new core. The README says projects may generally work from release to release but this is not guaranteed, so budget for breakage rather than assuming it away. Addons you copied in are the most likely source of it.

The LICENSE.md file is present in the repository, but the repository metadata reports the licence as NOASSERTION, meaning no standard identifier was detected. Read LICENSE.md yourself before you rely on a particular permission, and note that bundled third-party libraries under libs may carry their own terms. That is a question for your own legal review, not something the README answers.

Editorial conclusion

Adopt openFrameworks if you want native C++ output on desktop, mobile or the browser and you are willing to keep every project inside the release tree that produced it. Do not adopt it if you need a package manager to pin versions, if your project must live in an arbitrary repository layout, or if you want a scripting language you can iterate on without a compiler. Before committing, verify three things: that the platform you target appears in the build status table, that your compiler toolchain matches the setup guide for that platform, and that the addon you need is present in the addons folder of the release you downloaded rather than only in the master branch.

Frequently asked questions

Official sources

1. Issues
2. openframeworks/openFrameworks on GitHub
3. Project website
4. README
5. Releases