Open source participatory budgeting software

Open source participatory budgeting software for public bodies that must prove who voted

A public body running a budget cycle where residents propose and vote needs results that survive a challenge. Decidim's participatory budgets and accountability components are the open-source route, but the legal and identity duties around the vote shape the build more than the feature list does. Decidim is licensed under AGPL-3.0, built on Ruby on Rails and PostgreSQL, and maintained by the Decidim Association together with Barcelona City Council, so the platform itself is a credible starting point for a self-hosted budget process. A generic voting tool counts ballots. A participatory budget has to answer more questions: who was eligible in which district, which vote rules applied to that district's budget, whether one person voted once, and how the final allocation was published and later tracked. Those answers depend on how the body verifies residents, which identity source it trusts, and what verification data it keeps and for how long. Decidim's authorization handlers and social login options cover part of this, but the body must confirm which handler matches its census or eID source before the budget opens, because a voting rule nobody can enforce is a reputational risk after the result is announced.

Platform choice follows from those duties. Confirm that the version you plan to run is still supported: Decidim supports only the last two minor versions with security updates until version 1.0, and at the time of writing that meant 0.32.x and 0.31.x, so 0.30.x and earlier need an upgrade path before go-live. Ask the implementation partner to show how each budget phase, from proposals through voting to project tracking, maps to a component and to a named role, and to test per-district vote rules with real eligibility data in a staging copy. Before committing, record three decisions in writing: which identity source proves residency, how long verification and vote data is retained, and who signs off the published results. These decisions drive the authorization setup, the database backup plan and the accountability pages, and they are the evidence an auditor or a court will ask for first.

Which legal and evidence duties change the participatory budgeting build

This table maps each duty that applies to a public body running participatory budgeting to what it changes in the Decidim build and the evidence the body should keep. Read each row as a question to settle before configuration starts, since the answer often decides hosting location, form design and retention settings.

Duty	What it means for the build	Evidence to prepare	Confirm before go-live
ADA Title II web rule (WCAG 2.1 Level A and AA)	Participatory budgeting pages, proposal forms, voting screens and custom themes must meet WCAG 2.1 A and AA, including those delivered through contractors	Accessibility test results for voting flows, remediation log, accessibility statement	Whether the body serves 50,000 or more people, which sets the 26 April 2027 date rather than 26 April 2028
ADA compliance date by population	Entities serving 50,000 or more people have until 26 April 2027, while smaller entities and special districts have until 26 April 2028	Dated compliance plan tied to the entity's population category	Population basis the jurisdiction uses for the rule and whether counsel agrees
NIS2 for public administration	Where the Member State extends NIS2 to local public administration, the platform may fall under national incident reporting and security measures	Risk assessment, incident response contacts, supplier security commitments	Whether national law extends NIS2 to the municipality and whether any voting function is excluded
Data protection and hosting location	Participant identities, verification data and votes need a hosting location and transfer position set by the local jurisdiction	Records of processing, hosting and sub-processor list, transfer documentation	Where map, geocoding, email and social login services process data
Voter eligibility rules	Verification handlers must match the jurisdiction's eligibility rules, such as residence or census checks, without storing more than needed	Eligibility rule statement, verification method description, census load log	Who may verify, how long verification records are kept and who can read them
Retention of vote and proposal records	Vote records and audit data follow a retention schedule that must be fixed before launch, since Decidim data changes after upgrades	Retention schedule, deletion procedure, backup policy	Legal retention period for votes and whether published results must remain online
Evidence and certification boundary	DeployOpen prepares controls, configuration records and evidence for assessments but does not issue audit reports or certifications	Evidence pack prepared with the client, independent assessor reports	Which independent auditor or certification body the jurisdiction will use

How proposals, district budgets and voting phases map to Decidim components

A participatory budgeting cycle becomes manageable in Decidim when each stage is mapped to a component before anyone configures anything. In Decidim, a process is a participatory space, and the budgeting stages sit inside it: idea collection and proposal review run through the proposals component, the vote runs through the participatory budgets component, and delivery after the vote runs through accountability tracking. The mapping decision is the first deliverable: write down which phase uses which component, which dates open and close each phase, and who can act in each one. Confirm with your Decidim implementer how the proposal phase, the voting phase and the results phase will be sequenced inside one process, because the dates and visibility rules you set for each component determine what residents see and when.

Several decisions have to be settled before configuration starts. Define the district boundaries as the list of areas residents can select, and confirm whether each district gets its own budget line or whether the city uses a single budget with district tags on each project. Set the vote rules next: the number of projects a voter may select, the maximum combined cost per ballot, and whether unused budget can roll over. Decide the cap per district and who approves any change to these figures after launch, since a change made mid-vote is hard to explain publicly. Also name the moderators who will hide, flag or reclassify proposals, and the staff who will mark each funded project as planned, in progress or completed.

Two checks should run before launch. First, test a full dry run on a staging copy of the process with dummy accounts, confirming that a voter in each district sees only the projects eligible for that district and that the ballot rejects selections above the cap. Second, confirm that the accountability records will be published with the same identifiers used for the proposals, so a funded project can be traced from idea to delivery. Ask your implementer to document each setting in a configuration register, because Decidim releases change admin screens and the names of options between versions, and the register is what lets your team repeat the setup on the next cycle without guessing which defaults were changed.

Which open-source platforms fit participatory budgeting, and why Decidim leads

Several open-source tools can collect ideas or run a vote, but participatory budgeting needs proposals, phased rules, district budgets and published results in one place. The cards below compare the common alternatives with Decidim, which ships budgets and accountability components, and note where the choice depends on whether the body needs a full participation hub.

General-purpose form and survey tools

Survey and form tools collect ballots quickly and suit a one-off poll on a single question. They usually have no concept of a proposal that moves through phases, no per-district budget ceilings, and no page where residents later see which funded projects were delivered. Teams then rebuild comment threads, moderation and project tracking by hand. Check whether the tool can enforce one vote per eligible person and keep ballots separate from identity data. Check licence terms with the vendor, because these tools vary widely in licence model.

Headless CMS with custom voting logic

A headless CMS such as Strapi, Payload or Directus can model proposals and votes as content types, and its MIT or other licence terms allow a team to build what it needs. The gap is the participation logic itself: phase rules, vote caps per district, duplicate detection, proposal comments and public results pages all become custom code that your team must write, test and maintain. Ask who will own that code after launch and how security fixes reach it. Budget the build as a software project, not a configuration task.

LMS or ecommerce platform repurposed for voting

Moodle, Open edX or Canvas handle quizzes and enrolment, and Magento, WooCommerce or Saleor handle carts and checkout, so a team might map a ballot onto a quiz or a basket. This fits poorly. Learning platforms have no proposal lifecycle or public accountability pages, and commerce platforms treat each vote as a purchase with payment rules that do not match public consultation. Each adaptation also creates a permanent upgrade burden on a platform that was built for another job.

Decidim budgets and accountability components

Decidim is a purpose-built participation framework, licensed under the AGPL-3.0 and maintained by the Decidim Association with Barcelona City Council. Its participatory budgets component and accountability tracking cover the full cycle from proposal to funded project and published progress, inside the same platform as assemblies and processes. Confirm that the components you need, including vote rules and budgets per district, are in the release you plan to run, and test them against your own rule book before you commit.

Choosing between a tool and a full hub

A single budgeting cycle run once a year may fit a narrow tool, provided the body accepts manual reporting and separate identity checks. A city or region that runs several participatory processes, consultations and initiatives needs one hub with shared residents, moderation and publishing. Decidim suits the second case. Ask how many concurrent processes you expect, who will moderate them, and whether residents should keep one account across all of them.

Versions and support before selecting

Decidim supports only the last two minor versions with security updates until version 1.0, which currently means 0.32.x and 0.31.x. Any alternative you choose carries the same question: which release line receives security fixes and for how long. Ask your implementation partner to show the upgrade path from your chosen version, because Decidim's update guide asks teams to move one minor version at a time and back up the database first.

How a participatory budgeting rollout moves from scoping to published results

The sequence turns a set of budgeting rules and district boundaries into a hosted, tested and staff-trained platform, then into a public vote and published outcomes. Each phase closes with a written output that the next phase depends on.

Scope budgeting rules and districts
The organization's budgeting team and the implementation partner agree on who can propose, how many budgets run in parallel, the phases from proposals to voting, the vote rules, and the district or area boundaries that each budget covers. The partner documents these as a configuration specification and lists which decisions remain open. The step is done when the budget team signs off the specification and the written scope, which sets the timing of every later phase, is agreed in writing.
Decide hosting and identity arrangements
Infrastructure, data location, the choice between a manual or Docker installation, and how residents will sign in are settled in this step. The team decides where PostgreSQL, file storage, background jobs and outbound email will run, and whether verification will use a census upload, a government login through OmniAuth or another authorization method. The output is an architecture decision record and an identity design that names the data kept for verification. Confirm with your security and data protection leads before infrastructure is provisioned.
Configure budgets, phases and components
The partner builds the Decidim participatory space, sets up one participatory budget per district or theme, and enables the proposal, budget and accountability components with the phase dates and vote rules from the specification. Content such as help text, categories and notification templates is entered in the languages the city publishes in. The output is a staging instance that the budget team can walk through, with a record of every setting that differs from defaults.
Test accessibility on the configured site
Accessibility testing covers the proposal forms, the voting screens, the custom theme and any map or login pages, measured against WCAG 2.1 Level AA, which the ADA Title II rule requires for state and local government web content. Testers use automated scans and manual checks with keyboard and screen reader use, and log defects against the components that residents will actually use. The output is a defect list with fixes applied and a retest record. Compliance dates depend on the entity's population and are the organization's own determination to confirm with counsel.
Harden security and set up backups
The team applies the hardening baseline to the servers, database, file storage and admin access, restricts administrator roles, and configures logging and monitoring. Backups of the PostgreSQL database and uploaded files are scheduled, and a test restore is performed into a separate environment. The team also records the Decidim version in use, subscribes to its security advisories and agrees the patch windows that the security policy allows. The output is a hardening record and a tested restore, not just a backup job.
Run a pilot with budget staff
Staff from the budget office, communications and the district offices run a closed pilot that mirrors the live phases, including creating a proposal, moderating it, opening voting and exporting results. The pilot tests the email delivery, the verification path and the reporting views against the written specification. Defects and wording changes are logged, prioritized and fixed before launch. The step closes when staff have completed each phase and the budget team approves the go-live checklist.
Launch publicly and run voting
The public launch opens proposal collection on the production site, then moves through the agreed phases into voting. The operations team monitors availability, email delivery and verification requests, and the moderation team handles reports according to the published rules. The output is a launch log and a record of each phase transition, with any changes to dates made through the agreed change process. Vote counts and eligibility checks are reviewed before results are released.
Publish results and track projects
After voting closes, the results of each budget are published, and winning projects move into the accountability component, where the city posts status updates, costs and delivery milestones. The output is a published results page for each budget and a project tracking view that residents can follow. Upgrades to the platform happen between events, one minor version at a time, with the database backed up first and each release's upgrade instructions followed, because some releases change the database structure. Confirm the upgrade cadence and support terms in the written scope.

What auditors and oversight bodies ask for after a budget cycle

This table lists the evidence a public body may need to show after a participatory budgeting cycle, the component that produces each item, and what to keep. Read it as a starting inventory for your own records, not as a checklist of what an auditor will accept. The body's auditor or regulator decides what is sufficient, so confirm requirements with them before the cycle opens.

Evidence item	Produced by	What to keep and confirm
Accessibility test results against WCAG 2.1 AA	Test process (independent tester)	Scope of pages tested, including custom themes and voting forms, plus defect logs and retest results before launch
Vote rule and district configuration records	Decidim (budget and component settings)	Exported settings for each budget, vote rule, district allocation and phase dates, with change history and approver names
Eligible voter verification records	Decidim authorization handlers and hosting stack identity source	Verification method used per voter group, census import logs, and the retention period for verification data
Access control and authentication records	Hosting stack (reverse proxy, SSO or OmniAuth provider, logs)	Admin role assignments, login and failed login logs, and who can change budget settings during voting
Backup and restore test records	Hosting stack (database and file storage backups)	Dated restore tests on a separate environment, database and ActiveStorage file checks, and recovery time observed in the test
Patch records against Decidim security advisories	Hosting stack and maintenance process, informed by Decidim SECURITY.md	Installed version history, the minor branch in use (0.31.x or 0.32.x at time of writing), and dates each patch was applied
Published results and audit trail	Decidim (budgets and accountability components)	Archived copies of results, project status updates, vote totals as published, and a log of any edits made after publication
Vote integrity controls (one person one vote)	Decidim verification and vote logic, confirmed by the test process	Test evidence showing duplicate votes are rejected, and how the body handled exceptions

Who runs the platform: the city team, a partner or a hybrid

In this model the city's own IT, digital and election or democracy staff run the Decidim platform from installation to decommissioning. The city owns the infrastructure, the Ruby on Rails application, the PostgreSQL database and the release calendar. This suits a body that already runs production Rails or Linux services and has staff who can follow Decidim's upgrade notes closely. The cost is mostly internal staff time and on-call capacity, and it recurs for as long as the platform runs.

Hosting: the city provisions servers or cloud accounts, maintains backups, and tests restores before each voting window.
Patching: the team tracks Decidim's supported branches, which the project's security policy limits to the last two minor versions until version 1.0, and applies patches within the disclosure windows the project describes.
Accessibility fixes: staff own WCAG remediation of custom themes and forms, and they must test changes after every update.
Support during voting windows: the city staffs a rota for residents, moderators and the budget team, and it defines escalation before voting opens.
Incident response: the city runs its own on-call, log review and public communication.

Before choosing this model, confirm that the team has skills in Ruby on Rails, PostgreSQL and accessibility testing, and that someone can take the upgrade path one minor version at a time.

What to ask an implementation partner before a budget cycle

How does a partner handle Decidim version support and security patching?

Ask the partner which Decidim minor version they will deploy and who applies security patches after go-live. Decidim supports only the last two minor versions with security updates before version 1.0, currently 0.32.x and 0.31.x, so 0.30.x and earlier are out of support. Ask for the written patch process, how the partner monitors the Decidim security channel, and how fast they apply fixes. Decidim gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed, so ask how the partner tracks those windows. Also ask how upgrades are scheduled: Decidim's update guide requires moving one minor version at a time, with a database backup first.

Is the implementation fixed-scope and agreed in writing?

Ask for a written scope that lists deliverables, environments, the phases to configure, integrations, testing and handover before any work starts. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing first, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ask what is one-time (installation, configuration, custom theme, data migration, training) and what recurs (hosting operations, patching, upgrades, support). Ask which changes are handled through a change request and how those are priced. Ongoing support, upgrades and continuous testing are available as retainers, so ask whether they are priced separately from the build.

How is accessibility testing evidenced for a participation site?

Ask the partner to show which accessibility standard they test against and what evidence they hand over. For state and local government web content, the ADA Title II rule requires WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Ask whether testing covers the standard Decidim components and any custom themes, the proposal and voting forms, and mobile views. Request the test method, the tools and manual checks used, the defect log, and how fixes are retested. Confirm with your legal counsel which rule applies to your entity and whether a published accessibility statement is also required in your jurisdiction.

How is voter verification data collected, stored and deleted?

Ask the partner to map every data item the verification step touches, including census files, identity provider attributes, authorization results and vote records. Verification usually relies on Decidim authorization handlers, census uploads or OmniAuth login. Ask where each data item is stored, which fields are kept after verification, who can read them, and how long they are retained. Ask whether vote secrecy is preserved so that a voter's identity cannot be linked to a ballot, and how one person, one vote is enforced. Request a written data flow diagram and a retention schedule that your data protection officer can approve. Also ask how the partner handles data deletion requests and backups that hold verification data.

What does hosting inside our own infrastructure involve?

Ask the partner to describe the target environment in your cloud account, data center or private network, and which parts they will build. DeployOpen plans, implements and hardens self-hosted platforms inside the client's own infrastructure. A Decidim production setup typically needs a Rails application, PostgreSQL, background jobs, file storage, SMTP, maps and geocoding, and any social login providers you enable. Ask which of these run inside your boundary, which call external services, and what data leaves your network. Ask for the backup and restore procedure, the monitoring plan, the access model for administrators, and who holds the keys and credentials after handover.

What support runs during voting windows?

Ask for a written support calendar that covers the days before a voting window opens, the window itself, and the days after results are published. Ask who is on call during voting hours, what response times are committed in writing, and how incidents are escalated to your staff. Confirm whether load testing is done before the window, whether a change freeze applies while voting is open, and how a rollback would work. Ask how the partner would handle a failed email or verification step that blocks voters. Service levels only count if they appear in the signed agreement, so ask for them in writing with the scope.

Can our own staff run the platform after handover?

Ask the partner what knowledge transfer is included and what your team must be able to do without them. A realistic handover covers administrator training for phases, budgets, vote rules, districts and results publishing, plus runbooks for deployments, backups, patching and incident response. Ask for the documentation set, the list of administrator accounts and secrets that transfer to you, and the skills your team needs in Ruby on Rails, PostgreSQL and Linux. Ask whether the partner will support your staff on a retainer after launch, and what that costs relative to the build.

What licence obligations come with Decidim?

Ask the partner to confirm how the AGPL-3.0 licence applies to your deployment, including any custom modules or theme changes you commission. Decidim is free and open source under the AGPL-3.0 and is maintained by the Decidim Association together with Barcelona City Council. Ask whether custom code will be published under the same licence, how third-party gems and services are tracked, and whether any paid add-on or hosted service is part of the proposal. Confirm the terms in writing with your procurement and legal teams before the budget is approved.

Questions for an implementation partner about voter checks and open results

A partner's answers to a few precise questions show whether the build will meet the body's duties after the voting period closes. Start with who owns the data once the cycle ends. Ask which personal data is kept after results are published (accounts, verification records, vote-linked identifiers), where it is stored, who holds administrator access to the database and file storage, and how the partner will delete or pseudonymize it on the retention schedule you set. A partner that cannot name the Decidim components and database tables holding this data is not yet ready to sign a data processing agreement.

Next, ask how results will be published and what the partner will hand over as evidence. The budgets component and accountability tracking should be configured so that each published figure can be traced back to the vote count it came from. Ask for a written export procedure, a sample results report from a test cycle, and the audit trail of changes made during the cycle, including who changed a vote rule, when, and why. Confirm whether the partner will deliver these records in a format your auditors can read without the partner's tools. Also ask how long the partner keeps its own deployment and change logs, since those logs are often the only record of configuration changes.

Finally, ask how vote rule changes are logged and approved. Each change to thresholds, district allocations or eligibility settings should go through a documented request, a second reviewer, and a log entry that survives a version upgrade. The partner should also explain how it applies Decidim upgrades one minor version at a time, backing up the database first, so that a migration cannot silently alter a closed budget's records. Request the partner's written procedure for these steps and treat a vague answer as a gap in your readiness plan.

How DeployOpen scopes and runs a participatory budgeting build

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For participatory budgeting on Decidim, that means agreeing a written scope for phases, vote rules, district budgets and voter verification before any build work starts, then delivering the configuration, integrations and evidence that scope names.

How we scope

Map each budgeting phase, from proposal collection to voting and project tracking, to the Decidim components your process will use.
Record vote rules, budget amounts per district and eligibility checks in the written scope before configuration begins.
Confirm hosting location, identity sources and the legal duties that apply to your organization, then agree the fixed-scope deliverables and timelines in writing.

How we build

Deploy Decidim in your cloud account, data center or air-gapped network, with the database, background jobs, file storage and mail configured for production.
Configure budgets, participatory spaces and authorization handlers, and connect verification to your census or SSO through OmniAuth where agreed.
Test vote rules, district splits and results publication against the scope, and document each configuration decision for your review.

How we hand over

Deliver runbooks for staff roles, moderation, phase changes and results publication so your team can run each budgeting cycle.
Provide backup and restore procedures, including a database backup before every Decidim upgrade, with tested restore steps.
Hand over documentation of configuration, integrations and retained verification data, so auditors and oversight bodies can review how the process ran.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, covering the Decidim minor versions that receive security updates.
Plan upgrades one minor version at a time, following each release's instructions, since some changes alter database structures.
Run security testing of the live site and integrations after launch, and agree response expectations in the retainer terms.

Open source participatory budgeting software