Carlo von Lynx is a member of the Berlin chapter of the German Pirate Party and of the Italian Pirate Party. A Pirate since 2009 (the year in which the German Pirate Party saw its membership spike from 1,000 to 11,000 members) Carlo remains a staunch supporter of Liquid Democracy and of its first working implementation, the software LiquidFeedback (LQFB). In this extended interview, which was held in Berlin in several rounds on June 7-9, 2017, Carlo gave me further insights on the inner workings of LQFB and on the political processes that the platform set in motion both in Berlin and at a national level.
In the first part of the interview, we focus on the software usability. In particular, von Lynx notes how, far from being an objective property of the UI design, usability can be facilitated by the particular motivations that users may have in using the software. Simply put, if users know that the stakes are high (i.e. the decisions are binding) they will be encouraged to learn the inner workings of the software even if they have relatively low digital skills. This suggests that a software affordance is never just an objective property of the software, but a third space (I call it a zone of indetermination) emerging at the intersection of the user subjective capacities and the material properties of technical systems.
A second point that striked me is Carlo’s insight on how LQFB could allow those who want to amend a proposal to compete on an equal foot with the initiator of the proposal. Borrowing from the free and open source (FOSS) development process he calls this idea of having alternative proposals to compete side by side, a fork. Interestingly, I have used this same term in a theoretical article on technopopulism where I argue that LQFB sets in motion an agonistic politics of forking, by which I mean that the risk that your proposal may be slightly amended and duplicated forces initiators to retain a cooperative attitude towards potential and actual supporters–something that is typical of the FOSS development process–so as to attract resources (and brainpower) in order to compete with alternative initiatives on the same topic.
This means that these platforms do not only shape participation processes, but they also enable the emergence of distinctive technopolitical cultures, which appear to be translations of preexisting sociotechnical cultures such as the one of the FOSS development world.
Marco Deseriis (MD)
The first question is something I ask to all my interviewees. Now that you can look at the experience of your participation in the Piratepartei from the rear mirror–at least at the most intense moment, which dates back to 6-7 years ago–how do you think it affected you politically? Do you still consider yourself a supporter of LD/LQFB?
Carlo von Lynx (CVL)
I participated in the initial LQFB. We discussed [the software] in 2009 and launched it in 2010. I have to say, it went really really well. There were people with political visions and proposals that were quite innovative. And all participants started with the right questions, with a desire to dig deeper, improve, and refine the proposals. This collective intelligence-effect emerged, which was unexpected. Initially we only wanted a tool to write a political program, but we ended with results that went well beyond our expectations.
For example, I arrived with my own conceptual schemes, my preconceptions. But then I would read these proposals that changed my opinion. I was quite against both drug consumption and the liberalization of drugs, but I would be exposed to these anti-prohibitionist arguments that were absolutely convincing. Similarly, on the unconditional income (in the Italian PP we call it existence income) my first instinctive response was that it was impossible to give a thousand euros to everybody. I mean, how do we pay for it? But then if you dig deeper, you understand that there is a rational approach to it, that it can be done. The tool [LQFB] is not designed to make quick decisions, on the contrary, it invites you to go in depth before you make a decision.
MD. These discussions that you are mentioning, where they happening all inside LQFB or was the debate happening both online and offline?
CVL. Here in Berlin it was well integrated. There were physical meetings in the neighborhoods every week, where we would talk about questions that required a decision. There was a back and forth between physical and online spaces. LQFB structures processes formally, it gives you an idea of the status of consensus and knowledge sharing, it makes the democratic state of things transparent.
But it is not the right tool to ask a million questions. For that kind of activity we did not have a specific tool. We had connected LQFB to the party wiki and sometimes questions would show up in the wiki.
MD. Tell me a little more about the software interface and its usability. In some of the interviews I made, I received different, if not openly contradictory answers on this point. Some interviewees told me that difficulty of LQFB lies in understanding the process but not the interface. Others underscored that the UI is not very user-friendly. What is your take on this?
CVL. I believe that the criticism that the software was not ve ry user-friendly can be applied to the first version. But then the software has evolved and the interface has become much more intuitive. The LQFB developers have certainly improved it. In the Italian Pirate Party we have pensioners of various backgrounds use it (pensioners are the backbone of politics in Italy). The fact that there was no alternative made them overcome the initial unfamiliarity, to then find that it is not complicated at all, really.
They may not even have read our introductory manual. The fact that the software is binding is what motivates people to use it.
MD. So you are saying that usability is not only a byproduct of the interface but also of the users’ motivations.
CVL. Yes, when the software is binding it creates motivations that are completely different. The main difficulty of using LQFB does not derive from the UI but lies in the apprehension of the entire parliamentary process.
Basically, people learn how to use a parliament, because the software simulates procedures that you would learn if you were to be elected at the house of delegates. There are many parallels. And it is not so difficult, if you are motivated, you do it. It is not a technical question, but only of will.
MD. You said that LQFB is not the right tool to ask a million questions. As a matter of fact the Public Software Group never designed it for extended conversations (after all LQFB is a decision-making software). But can users ask questions in LQFB if they need to? After all, if I need to know something factual, that is strictly related to the initiative I am supporting or amending, it makes no sense to ask it in a discussion forum…
CVL. In theory it would be better not to ask questions in LQFB. In practice, however, users often ask questions, using the amendment feature. This creates a bit of confusion between the actual amendments, or “suggestions” as they are called, and the questions and comments. If the amendment [suggestions] become too many then the initiator of the proposal may not consider them all with the same degree of accuracy. That’s why I think it would be better to separate these two aspects. It would be sufficient to split, from a technical point of view, the table of the amendments from the table of the general discussion. Technically speaking it would be the same thing, these [the amendment suggestions] are contributions that you could display as text notations on the side of the text.
MD. What is the current format in which they are displayed in the UI?
CVL. They do not have a specific format. The developers of Parelon [an Italian fork of LQFB] had thought of using Akoma Ntoso, a technical standard that allows you to present documents in a structured manner. In this way, when you modify a text, an amendment appears as something that is physically perceptible. You can easily juxtapose the different versions of the text, and use colors to immediately mark the difference. If an amendment could be visualized as such it would be more accessible, rather than appearing at the bottom, as it is now, where you have to reconnect it to the parts of the document to which it is linked.
At any rate, the most important thing about amendments is that they receive a democratic and transparent evaluation. This is an aspect that is often undervalued but it is really important. It would be ideal if all users could work on a proposal while they always indicate the amendments that they like and the ones they do not like so that the initiator has a clear sense on how to proceed. Or, if there is a user who launches an alternative proposal, it would be useful if she could reference the democratic evaluations of these amendments, so as to demonstrate that she is using them because the initiator did not do it.
MD. But isn’t one of the key functions of LQFB to allow users to introduce alternative proposals when the initiator does not want to change her initial proposal? The software allows all users to do that in the verification phase. Isn’t it clear that the alternative proposals are introduced precisely to collect suggestions that have been ignored?
CVL. Yes, if the alternative proposal collects suggestions that have not been accepted from the original author, it often ends up being the winning proposal. But it is not sufficiently obvious at the level of the interface. I would like to have the possibility to visualize immediately the differences between proposals that are very similar. When we wanted to co-author a text, it happened frequently that each activist wrote his own version, and we ended up with eight versions of the same text. It would be really useful if one could be able to compare the proposals–make a “diff” has we say in technical terms in the Unix world–visualize the differences between the two versions and see immediately how to make changes.
As Pietro Speroni (Vilfredo) has noted, LQFB is a “feudal system” because it gives too much power to the initiator. Whoever makes a proposal first has an advantage when compared to anyone who wants to introduce a competing proposal. The competitor will have to make more work than the first proponent to collect a higher support. The software could be reworked to make this feature/aspect more flexible.
At the moment, LQFB sends you a notification when the author of the proposal that you are supporting changes it. But one could introduce a function to create an actual fork of the original proposal, that is, the option of modifying the original proposal while having the same level of privilege, including the notification.
MD. Do you think that the proposals that are well structured have on average an advantage as compared to the proposals that are less elaborate? Or are the latter capable of triggering more participation due to their incompleteness, as in the case, for example, of a Wikipedia article?
CVL. The situation is quite different from Wikipedia. The proposals that are well structured have a clear advantage in LQFB. Sometimes the public decides to support a five-line proposal while the one that is well structured does not pass. There are many factors that may play into this decision. It would be good to work not only on the software but also on the organizational processes to avoid demagogical votes, similar to direct democracy, which can happen. Although LQFB can motivate a type of debate that is more rational and reasoned, the discussion can take on unpredictable twists. For example, if everybody is angry at a person, it is unlikely that they will read his proposal, no matter how structured it is.