Tiny House
More About The National Coalition for Dialogue & Deliberation • Join Now!
D&D Community

Catalyst Entry: “Online Dialogue and Deliberation Infrastructure (ODDI)”

This proposal will facilitate the development of open source software tools to engage people in online deliberative processes. We will connect communities of D&D practitioners, software developers, and donors to design, build and fund online tools that will realize the transformative potential of the internet to increase public participation in community decision making.


Mark Frischmuth
DemocracyLab.org Board Chairman
Role: DemocracyLab will serve as the 501(c)(3) sponsor of the project, providing transparent project oversight, governance and accountability.

Jon Poland
Crowdegy President
Role: Through my work in designing deliberative decision systems, I’ve been working with the group to help define the structure and scope of ODDI. I consider helping communities/societies to make better collective decisions to be a major aspect of my life’s mission and so I’m happy to assist in any way I’m able to move the project forward.


Technology creates an opportunity to engage anyone with an internet connection in deliberative processes about issues that matter to them, but few solutions have emerged that apply wisdom from the D&D community to the online space. Our project will create a library of online tools that will grow and evolve, scaling best practices and providing fertile ground for experimentation with new methods.



Steven Clift
Executive Director, E-Democracy.org
We will continue to support this effort through the use of E-Democracy’s forums. We will also assist in assembling the technical committee that will be responsible for the project’s resource allocation decisions. We will serve as ambassadors for the project within our networks, and will strongly consider utilizing the software tools the project produces to augment engagement efforts with our existing online communities.

Ele Munjeli
Developer for CIRAL
As part of my research I’ve been working on a side by side analysis of available web frameworks for deliberation and doing logical analysis of deliberative processes. Anyone interested in a technical discussion of the tools we’ve discussed in this group (and how they might be programmed) can contact me directly to avoid cluttering this document with geekspeak.

Tim Bonnemann
Founder and CEO, Intellitics
I’ve been following this project and can see a lot of value for the field of online dialogue and deliberation in the work that is outlined here. To the extent possible, we would be happy to contribute, e.g. by sharing data models, online D&D use cases and concrete opportunities for third-party integration and tool interoperability. Resources permitting, we would be very interested in piloting some of the solutions that may come out of this effort.

Lucas Cioffi
AthenaBridge Inc
I will participate in the discussions about the first prototypes to emphasize building something that will meet the needs of a significant number of NCDD members; this means keeping the software as straight-forward and as process-agnostic as possible.

Additional NCDD Members Involved in Drafting the Proposal
Wayne Moses Burke and Kaliya Hamlin both provided valuable feedback on the ODDI email list that influenced this final proposal. This does not imply that they are supporters of this project (for them to decide), but merely recognizes the contributions they’ve made.


There are numerous online tools that allow people to connect over the internet, from Facebook and Twitter, to homegrown startups experimenting with innovative methods of engaging communities. Right now, all of these efforts are in competition. Over time, the marketplace should sort out winners and losers, and effective tools should emerge.

But is that the best way forward?

We propose cooperatively charting a more deliberative path. There is a wealth of accumulated knowledge in the D&D community, most of which hasn’t yet been translated to the online space. Our project will allow the D&D community to collectively design and build online infrastructure that adapts many of the best practices of in-person dialogue and deliberation to the virtual world.

This will be accomplished by convening communities of interested D&D practitioners, software developers and donors to collaboratively:

1) Identify the needs of deliberative online communities
2) Determine the technology architecture best suited to meet the majority of community needs
3) Specify specific software functionality to be adopted or developed
4) Select capable developers to integrate or build specified functionality
5) Engage donors to fund ongoing software development

An early iteration of the collaborative workspace envisioned to facilitate this process can be referenced at www.democracylab.org/oddi.

This process is already underway, sparked by connections from the 2012 NCDD Conference in Seattle and the convening power of the Catalyst Awards. E-Democracy.org’s forum software has been used to facilitate lively discussion on these topics. Archives of those conversations and a directory of members can be found at http://forums.e-democracy.org/groups/oddi.

Identifying the needs of deliberative online communities is the first task on our list and was the hallway conversation that led to the initiation of this project. Our initial assessment of the infrastructure needs of deliberative online communities is represented in the following diagram. (Please view this diagram at our collaborative drafting page: http://tinyurl.com/aqw7avv.)

As work on this project continues, the specific technologies and standards to be adopted or developed will be collaboratively determined by the community, guided by the principles of Lean Startup Methodology. Our intent is to build on the substantial work already being done by others in these areas, adopting and integrating existing tools whenever possible so that we can rapidly produce a Minimum Viable Product for evaluation and use by community members. To review our developing thinking in each of these areas, please visit our collaborative workspace at www.democracylab.org/oddi.

The structure of how ODDI will manage the platform and interact with developers is pictured below. (Please view this diagram at our collaborative drafting page: http://tinyurl.com/aqw7avv.)

With input from the developer and D&D communities, we will develop a common data model that is flexible enough to accommodate the needs of the majority of community engagement applications. The data model will be accessed, updated and managed via special code called an application programmer interface (API). The API will consist of rules for what is allowed and (more importantly) what is NOT allowed in relating to the data. This will provide protection from fraud, identity theft, spam and other forms of abuse.

Beyond the technical rules of the API, licensing rules in the form of a developer agreement will further enforce consumer protections as well as outline how app developers can sustain themselves within the software-as-a-service (SaaS) business model. This will create what Thomas Friedman refers to as a golden straightjacket of regulation that is a necessary foundation for a robust ecosystem.

In addition to making it as easy as possible for developers to create new applications built atop the project’s infrastructure, the interoperability of data is an intriguing aspect of our proposed approach. By creating a shared identity architecture and data model, it will be possible for data collected by one application to be represented in another. This will allow developers to experiment with new data visualization techniques with robust sets of existing data, rather than having to do the hard work of building community and encouraging participation in order to test their approaches. We believe that this structure will be extremely appealing to digital democracy experts and enthusiasts, allowing for rapid deployment and testing of new applications, rather than forcing developers to recreate the wheel and attempt to build community and users in order to validate their approaches.

Steps to implementation are as follows:

1. Form a technical committee from the developer community
2. Agree on an open source license for the API code
3. Write a developer agreement (so developers know their rights/responsibilities)
4. Encourage developers of civic engagement applications to submit their data models
5. Consolidate data models into a common model
6. Clarify functional requirements with the developer/D&D communities
7. Agree on a framework/libraries for developing API (will rapidly accelerate development)
8. Write an RFP to develop API (if sufficient volunteers can’t be found)
9. Manage API development contract
10. Host the platform as a web service and regulate its use

To avoid a conflict of interest and to further encourage the developer community to participate (both proprietary and open-source), ODDI will refrain from developing its own application. ODDI will purely function as a web service platform and technical/regulatory body.

Project Governance…

DemocracyLab will be the 501(c)(3) sponsor of the project, providing transparent oversight, governance and accountability. DemocracyLab’s board of directors will approve members of an ODDI Technical Committee, which will be responsible for approving feature specifications and selecting qualified developers to execute them. Other committees and working groups will be established as needed to achieve the project’s goals.

Technical Considerations…

Please reference the glossary below this section for definitions of unfamiliar terms.

ODDI seeks to define a Use Case with NCDD in order to develop a software platform for online deliberation. A Use Case describes how a user would interact with the software. It is the top layer of software design documentation created in Unified Modeling Language (UML) used foradvanced software engineering. The Use Case is a specification to inform developers of the necessary functionality to support NCDD streams of engagement in the online environment. The resulting Use Case Specification Document would be open-source and available to all interested parties. NCDD would determine the unified standard that would drive development of an advanced voting API and common data model that would bootstrap development of deliberation applications using Rapid Application Development principles.

The goal is to build a backend solution which can be installed with any User Interface to support complex deliberative processes including Decision Making and Collaborative Action which demand ratification. The platform might include identity verification and a sophisticated voting API with options for iterative ternary voting (parliamentary procedures), elections, or surveys. A complex voting API can also be leveraged internally for surveys to narratively define values (for value based decisions) and reputation systems (rankings).

We are following with great interest Google.org’s donations to support civic innovation and engagement. We believe the work of recipients Sunlight Foundation and mySociety bookend the work that we are doing and represent opportunities for integration and collaboration, which we hope to pursue. For more information, please see: http://techcrunch.com/2013/01/16/google-org-donates-a-total-of-3-6m-to-spark-civic-innovation-using-technology/.


API (Application Programming Interface): A protocol intended to be used as an interface for software components. In the case of a Multi-tier Architecture, the API is usually control code which handles the data exchange from a Client to a Database. A Database can be made available to Clients with authorization via the API, a collection of ‘calls’ or lines of code which enable the Client to query the Database for specific data.

Application Software: Known as an application or app, a computer software made to help the user accomplish a specific task. A package of code ‘applied’ to accomplish a specific task by running on a computer.

Client Application (Client): A web application that runs in a browser on the user’s local computer. The Client Application is the View of a MVC design pattern, and displays the information returned by a Web Service from a Database.

Multi-tier Architecture: In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client–server architecture in which presentation, application processing, and data management functions are logically separated. In a web application, the part which you see in your browser is the client application. There may also be a Database running on a cloud (server) which is a container for the information the user wishes to access; and Control Code, an application on the server which handles the exchange of data from the Client to the Database. Together, these applications maybe referred to as MVC (Model-View-Controller), a design pattern for software where the Model is the Database, the View is the Client application (viewed by the user) and the Controller is the code which handles exchange between the two.

Open Source: Computer software where the source code is publicly published and made available to anyone to study, change and distribute. Open source code is often licensed to prohibit free commercial use, but it may be profitable with a SaaS business model (see SaaS).

Open Standards: A standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed.

SaaS (Software as a Service): Sometimes referred to as “on-demand software”, this is an application delivery model in which software and data are hosted on a server. SaaS is typically accessed via a Client application via a web browser. A SaaS is often an application with a Multi-tier Architecture which includes a Client (the User Interface, or View); a Web Service (Control Code to handle data exchange on the server); and a Database. Examples include Gmail and online banking applications. Many kinds of SaaS charge a fee per use or are sold by monthly subscription for instance: Spotify Premium.

Web Service: An application (computer software) designed to support interoperable communication machine to machine over the World Wide Web. A Web Service can be considered an application component of a Web App with Multi-tier Architecture. It represents the Control Code in an MVC design pattern. A Web Service runs on the server, and returns raw data as XML or JSON from a data via the API. A Web Service may consist of the code for an API; it is queried by the Client application and returns data from the Database. A Web Service can function without a Client application, but it returns data in bundles of unformatted text, without a user interface.

Link to your Catalyst Awards page on CivicEvolution:

Questions? Email Mark at mark@democracylab.org.