Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Demosplan Core Laravel Package

demos-europe/demosplan-core

Core library for demosplan, an open-source digital participation platform used in urban planning and public consultation. It provides shared domain models, services, and workflow logic for managing procedures, statements, and planning documents in PHP applications.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy vs. fork for civic-tech / public participation: demosplan-core is a working implementation of the domain behind formal public consultation — statement capture, categorization/clustering, document publication, procedure phases, participant roles, map/geo layers, and export of decision records. It's a concrete scoping baseline for anyone building a "Statements / consultation" feature, letting the team size effort against reality rather than a whiteboard.
  • Roadmap and feature prioritization for regulated products: use the package as a feature inventory. It separates legal table stakes (phases, roles, audit-relevant records, accessibility) from differentiators, and surfaces the compliance-adjacent work (retention, GDPR-by-design, BITV/EN 301 549, eID) that typically gets under-scoped.
  • Architecture and stack decisions: important nuance — despite the framing, this is a Symfony/PHP monorepo, not a Laravel package. That's a real input to the "adopt vs. wrap vs. reimplement the concepts" decision, and to whether your team's stack is compatible.
  • Procurement, licensing, and maintenance model: NOASSERTION plus an 11-star public repo means the decision is less "should we composer require this" and more "is the DEMOS ecosystem (not this repo) the right base, and who supports it long-term?" Drives due diligence on the underlying EUPL-style copyleft license and vendor/partner availability.
  • NFR backlog inputs: it's a template for GDPR, accessibility, and public-sector audit requirements, which can be lifted into your own NFRs whether or not you adopt any code.

When to Consider This Package

Consider it when:

  • You're scoping or building a citizen participation / formal consultation product for German or EU public administration (Bauleitplanung, Umweltprüfung, and adjacent procedures).
  • You need a reference implementation or selective fork base for statement and procedure workflows — not a drop-in library.
  • You have in-house Symfony/PHP capacity and are comfortable owning a monorepo.
  • You want to benchmark data model, permissions, and procedure state machines before writing your own spec.

Look elsewhere when:

  • You need a conventional, versioned package with a stable public API and active community — this is the opposite; 11 stars and NOASSERTION should be read as "reference material," not "dependency."
  • You're building a lightweight general-purpose feedback or survey tool — the domain model is heavy and opinionated, and the workflows assume statutory process.
  • You're outside DE/EU public sector, or legal cannot accept an ambiguous license without a commercial partner to de-risk it.
  • Speed to market on a general product matters more than domain fidelity.

How to Pitch It (Stakeholders)

To executives: demosplan-core is a publicly funded, working implementation of a legally mandated consultation workflow used in German public administration. We are not proposing to adopt it as a dependency. We are proposing to use it as a reference architecture, which buys three things: (1) a de-risked feature scope sized against a real product rather than estimates; (2) avoidance of re-learning compliance, accessibility, and audit requirements the hard way; (3) a credible build-vs-buy baseline we can take to procurement or to a delivery partner. The two risks — ambiguous licensing (NOASSERTION, needs legal review) and a small public maintenance footprint — both argue for study and selectively fork, not ship-and-depend. Note also that it's Symfony, not Laravel, so this is a domain decision, not a stack commitment.

To engineering: treat this as a Symfony/PHP domain model and workflow reference. Most valuable for the statement data model, procedure/phase state machines, and role/permission design. Do not plan on it as a package dependency: no stable public contract, minimal public activity, monorepo structure. Recommend a time-boxed 2–3 day spike to extract the data model and a workflow map into our own spec, plus a parallel legal and architecture review before any code is copied.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource