frab: a Rails system for conference submissions, scheduling and speakers

Built to replace pentabarf for open source conferences

frab is a web-based conference planning and management system that collects submissions, manages talks and speakers, and builds a schedule. Its origin explains its design. It was created for the organisation of FrOSCon 2011, which had previously used pentabarf, and although frab is a completely new implementation it borrows heavily from pentabarf. The README states plainly that pentabarf seems to be abandoned and that several problems make it hard to maintain, which is why the project was started. The scale it was built for is concrete: FrOSCon has used frab since 2011 for a conference with more than 100 talks and as many speakers across more than 5 parallel tracks plus devrooms over two days, and the Chaos Communication Congress used it until 2023. The audience is therefore organisers who want proven structure rather than a feature race, and the wiki even keeps a list of conferences running it.

Development happens on main, and releases only mark big jumps

frab's maintenance model is unusual enough to understand before you depend on it. The README states that frab is not under heavy development anymore, that releases merely mark huge updates and add a changelog, that there are no separate release branches, and that fixes and development happen in main with the goal that the main branch stays usable at all times. There is no patch release train to wait for, and there is also no cherry-picked fix branch to pull. The release history reflects that: v0.9.1 on 2024-04-11, v0.9.0 on 2023-01-30 and v0.8.1 on 2021-10-19, so version numbers move rarely. The last push to the repository was on 2026-08-02, which means the code is still being worked on even though the tags are old. For an operator, that means you pin to a commit rather than to a release, and you read the commit history to know what you are running.

Deployment paths: a standard Rails app, a container or a PaaS

The README describes frab as a pretty standard Ruby on Rails application and points at the wider ecosystem of Rails tutorials for installation, deployment and setup, with INSTALL.md holding the frab specific details. Beyond that there are three documented routes. The first is Docker, with a README.docker.md file and a published container image. The second is a PaaS, with a README.PaaS.md covering platforms such as heroku or dokku. The third is running it yourself on a normal host. The repository layout supports all three: a Dockerfile, a docker-compose.yml, a Procfile for PaaS deploys, a Capfile for Capistrano style deployments, a helm directory for Kubernetes and an env.example file listing the expected environment variables. The containerised route is the most self-contained, since the compose file wires the application to its own database service.

The compose file shows the environment frab expects

The docker-compose.yml in the repository is the clearest statement of the runtime contract. It defines two services, frab and db, and the application service looks like this:

services:
    frab:
        image: ghcr.io/frab/frab:latest
        build: .
        container_name: frab_app
        volumes:
            - public:/rails/public
        ports:
            - 3000:3000
        networks:
            - backend

The rest of that block pins the environment variables the application reads, a SECRET_KEY_BASE value, a DATABASE_URL pointing at the db service, a FRAB_CURRENCY_UNIT setting for the currency symbol used in the UI, FROM_EMAIL for outgoing mail, and FRAB_DEFAULT_LOCALE with FRAB_DEFAULT_LOCALE_FALLBACK. The database service is postgres:9.5 with its own user, password and database name, a named volume for the data directory and the same restart policy as the app. Both services use restart: always, which tells you how the authors expect these processes to be supervised.

Rake tasks carry the exports, the schedule and the mail

A large part of what a conference organiser does with a tool like this happens outside the browser, and frab keeps those operations as command line rake tasks. The README describes them as executing from the command line to export conferences and static schedules, to send emails, or to help with development, with a chapter on production rake tasks in the manual and a fuller list in the wiki. The same list can be produced on your own machine with rails -D, which is the documented way to discover what is available without reading the wiki first. The static schedule export in particular is what many teams need, since it produces artefacts that can be published from a static site rather than requiring visitors to hit the application.

Accept and reject mails go through a ticket server instead

frab supports OTRS, RT and Redmine ticket servers, and this integration changes how the acceptance workflow feels to a submitter. Instead of sending event acceptance and rejection mails directly, frab adds a ticket to a request tracker, so the conversation lives in the tracker with its own threading and status handling. The ticket server type is configurable per conference, which matters for an installation hosting several events with different organisers. If you use OTRS, the README notes that you need to install the iPHoneHandle support. The flip side is that the ticket server becomes a dependency of the workflow: if the tracker is misconfigured or unreachable, submitters stop seeing the decision, and frab does not describe a fallback path for that case.

A language-aware UI and per-field translations backed by mobility

Localisation is one of the more substantial parts of frab. The interface has been translated into several languages, listed as de en es fr it pt-BR ru zh. The language is chosen deliberately: frab looks at the ?locale= URL parameter first, falls back to the client's HTTP_ACCEPT_LANGUAGE header if that is unset or unsupported, and uses English if neither matches a supported language. Production systems fall back to the I18n.default_locale configured in config/environments/production.rb. Model fields get a second layer. Localisation for fields such as an event's title, subtitle, description and abstract, a person's description and abstract, and track names is handled by the mobility gem, which stores other languages in separate database tables while keeping the default language in the model's own column, a column fallback that avoids join statements when only one language is in use. Notification mails are sent in the language the speaker configured, with English as the fallback.

MIT for the code, with third-party assets under their own terms

The licence picture needs a careful read, because the two sources disagree in tone. The README states that frab is licensed under an MIT licence and adds that it bundles some third-party libraries and assets that might be licensed differently, pointing at the LICENSE file. The repository metadata reports a custom licence that GitHub cannot classify, so the LICENSE file itself is the document to consult for terms, particularly for anyone redistributing the bundled assets. On the dependency side, the Gemfile and Gemfile.lock are checked in, the application uses the mobility gem for translations, and the container image installs system packages for image handling such as imagemagick and libvips alongside database clients. Anyone running the container should expect a reasonably heavy base image rather than a minimal one.

Editorial conclusion

frab fits a volunteer-run conference that needs a call for papers, a schedule, speaker records and a stable timetable export without paying for a SaaS product, and that can host or containerise a Ruby on Rails application. It does not fit an event that expects a fast-moving product, a vendor support contract, or tickets and payments handled in the same tool. Before adopting it, read the INSTALL.md file, confirm the main branch is acceptable as your deployment source given the release policy, and check the licence terms in the LICENSE file, since the repository metadata and the README describe the terms differently.

Frequently asked questions

Official sources

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