Q1: Why did you decide to create a Liquid Democracy solution for parties?
Which parties did you have in mind?
Back in 2009, politics looked at the dangers but not so much the chances of the internet. The potential of the internet for the enhancement of democracy had yet to be discovered by the political class. We observed a discrepancy between what seemed to be the will of the members of main stream political parties and the actions their leaders took. To a certain extent this is expectable but we got the impression of a more general detachment rather than exceptions. Transitive proxy voting – also referred to as Liquid Democracy – looked like a very powerful way to allow proportional representation of all members of a given political party.
The Berlin Pirate Party was already looking for ways to avoid a classic delegates system by applying Liquid Democracy.
Apart from this existing demand, LiquidFeedback has always been intended as an offer for every (democratic) political party: conservative, liberal, or progressive. All these parties have a function and represent parts of the population and would ideally strive for the best solutions for the entire society from their specific perspective.
“[…] political parties have the ambition to govern states, but they are often poorly governed themselves.”[SPPP2013] say Hans Bruning[Bruning] and Vidar Helgesen[Helgesen]. We hope LiquidFeedback can be part of the solution as it allows for a dynamic division of labor based on individual choice.
Q2: What do you think about application fields other than political parties?
Meanwhile LiquidFeedback has also been used in other contexts such as civic, constituency, and corporate participation. We didn't expect this development but welcome and support it as long as the operators of these instances are clear on the purpose and the limitations of the specific use case to avoid false expectations and care about verifiability to create somewhat meaningful results. For a closer look at a civic participation project, check the article on LiquidFriesland by Jan Behrens in this issue of the Liquid Democracy Journal.[Friesland]
Q3: Which practical experience could you make use of?
Which scientific works influenced the development of LiquidFeedback?
Is there cooperation with scientists and practitioners in the field?
We already had experience in implementing complex workflows and were familiar with certain effects of internet communication. Knowing what we want to avoid and some common sense helped to define the challenges, and more than once we found answers in computer science, history, jurisprudence, mathematics and social choice theory. The development was influenced by previous research e. g. by Kenneth Arrow, Thomas Schwartz, Nicolaus Tideman, Markus Schulze, Condorcet, and by historical experience (e. g. the 1969 Thunder Bay amalgamation referendum[PLF, section 4.11]). By definition, our work is multidisciplinary. We work with everybody who can contribute and of course we share our results with the scientific world.
We also discuss with and learn from practitioners in foundations and intergovernmental organizations around the globe.[Myanmar] Typically cooperation is based on joint convictions such as improving instead of replacing representation, the key role of political parties for revitalizing democracy, and the necessity of changing political parties to overcome the democratic fatigue.
Q4: How important is the discourse?
Why did you chose such a formal design for the discussion process?
Does LiquidFeedback replace “real life” discussions?
What do you think about less formal online discussions?
The discourse is essential for informed decision-making. In order to provide a fair process for decision-making that scales up to thousands of participants, LiquidFeedback employs a structured discussion where it is not possible for every participant to reply to any contribution. Instead, LiquidFeedback employs a system for exchanging arguments which agitates people to make constructive proposals in order to gain other people's support. This way, LiquidFeedback organizes the discourse by not only providing the pre-defined timing but also fulfilling a central announce and quantified feedback function for ideas.
The discourse in LiquidFeedback is not meant to completely replace other discussion forms.
The diverse real life discussion formats, e. g. between co-workers, in town halls, in talk shows, have their own pros and cons. They are either limited in the number of (active) participants or they are moderated which limits the ability of participants to speak as they see fit. They usually also don't deliver a quantification of the support for the points of view being expressed. On the other hand, these comparatively unstructured discussions have a great creative potential. We think it is a perfect symbiosis to see results of all these discussion formats reflected and measured in LiquidFeedback's structured discourse.
Something similar could be said about unstructured, not quantified online discussions if they were not mostly dysfunctional as soon as real conflicts between participants are involved.[PLF, subsection 4.10.4]
Q5: You seem to count on competition rather than cooperation?
Why don't you try to reach a consensus?
We don't call for competition but we factor it in. We encourage everybody to cooperate. Looking at politics, we just don't believe you can always count on (bipartisan) cooperation. So there has to be a mechanism to deal with conflicting interests.
A consensus is nice if it actually exists, but demanding a consensus (in the meaning of “unanimity”) is undemocratic because the majority can be taken hostage by a minority (which would assign more power to members of the minority than to other individuals). In return, minorities could feel presumed or actual pressure for conformity. Consensus requirements increase the risk of resentment, hidden conflicts, and stagnancy.
Compulsory consensus as well as (the more moderate approach) supermajority requirements are no suitable strategies to achieve minority protection. Only majority rule satisfies political equality[McGann] notwithstanding other measures to provide minority protection.[PLF, sections 4.10 and 4.13] Even if decisions have to be made by majorities, LiquidFeedback's structured discussion process still enables its participants to work towards a solution where all minority points of view are considered.
Q6: You claim that LiquidFeedback enables participants to organize a collective moderation process where no privileged moderator or request commission is needed.
Why is an initiator in LiquidFeedback allowed to
(a) freely choose the subject area for his or her proposal, even if this has effects on vote counting due to different delegations, and
(b) decide by him- or herself whether a proposal shall be a mutually exclusive alternative to another proposal?
Isn't a request commission needed to decide these issues?
One of LiquidFeedback's design goals is indeed to provide a discussion process where all participants are treated equally. Nominating a moderator with special privileges or a request commission would thwart this goal.
Therefore, its up to the respective initiator to (a) choose a subject area and to (b) post the proposal as competing or not competing. A request commission is not necessary due to the following considerations:
Letting an initiator freely choose the subject area for their proposal is not a problem if there is a previous agreement on which kind of resolutions may be enacted in which subject areas. Whenever the participants in a particular subject area decide on something that is not to be decided in that subject area, such a resolution must be void, just like when a committee is exceeding its authority.[PLF, sections 2.3 and 4.8] The decision whether the subject area was correct may not be determined by a computer algorithm, but always needs to be decided by humans. This decision, in turn, may be made either outside or inside the system (“decisions in this context may also be made within LiquidFeedback using a designated subject area”[PLF, p.28]).
The question whether a proposal is mutually exclusive to another proposal should always be answered prior to voting, because LiquidFeedback's voting algorithm is designed in such a way that only one initiative of a group of competing initiatives may win. Also in this case, we recommend not using a request commission but to let the participants decide whether they accept a proposal as competing: nobody is forced to support or vote for a competing proposal if it has been obviously misplaced by the respective initiator. In addition to that, it is always possible to discuss these meta questions (including the proper choice of subject area) by altering or creating initiatives in the same group of competing initiatives and extending them with arguments on the correct or incorrect placement of the other initiatives in this issue.
Dealing with meta questions is a necessity of democratic decision-making. Those meta questions (e.g. which proposals are competing with each other) always have to be answered by humans and cannot be determined by a computer algorithm. LiquidFeedback just provides a framework in which humans can deal with all those questions. While moderation tasks are often delegated to a small group of elected persons, LiquidFeedback, in contrast, allows for a truly collective and self-organized decision-making process where everyone has equal rights and where delegation is always voluntary and can be revoked at any time.
Q7: Which projects do you support?
Anybody can use and customize LiquidFeedback which is published by the Public Software Group.[License]
The developers also teamed up in the Interaktive Demokratie association to promote the use of electronic systems for democratic processes by offering workshops and lectures.[IADfound] We offer consulting for projects but we only endorse participation projects conducted with a minimum of seriousness in terms of access control, meaningful results and defined purpose. So we had to turn down cooperation with some participation projects which were sure to go south like the participation approach of the Internet Enquete Commission of the German Parliament.[EIDG]
Q8: How do you decide about implementation of new features and other changes?
Many requirements don't even need changes to the software as LiquidFeedback comes with numerous parameters to configure the decision-making process; e. g. it is possible though not suggested to completely turn off the topic spam protection by setting the admission threshold to zero which essentially eliminates the admission phase.
If an idea needs programming, there are several aspects including but not limited to foundation of a change request based on a (mathematical) proof or evidence, implications for the process in terms of conceptual conformity, and/or implementation complexity.[FeatureReq]
Many changes to the core were triggered by the valuable input of experts. We usually didn't go for try and error proposals, proposals which would increase complexity at almost no return, or proposals which would jeopardize the scalability of the Liquid Democracy approach.
However, the Public Software Group publishes LiquidFeedback under the most liberal MIT license[License] which allows any modification and recombination of the software and it is not unusual for organizations to make minor changes to their LiquidFeedback system.
It is even possible to change the very character of the decision-making process and to create a derivative. In fact even this has already been done and there are LiquidFeedback derivatives being used for binding decisions.