On 17 October 2010 09:45, Michael Allan <<a href="mailto:mike@zelea.com">mike@zelea.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"> </div>It looks your plan is: 1. Remove Votorola from the current open, distributed architecture, or network of hosts, in which it is being prototyped; 2. Encase it in a Groovy shell; and 3. Insert it as a component in a newly designed closed, localized, or "vertical" system, running on a single host. The immediate aim is to deliver on a private venture. But overall, you believe this is "a better strategy" for delivering on the "horizontal market" too, meaning the open, distributed system of e-democracy in general. Is that true? </blockquote><div> Well put! But utterly wrong :) I'll see if I can lay out the elements and aims of the strategy as clearly as you have. So: The primary aims are to: <ol><li>Further open up the current open distributed architecture of Votorolla by making it easier for developers to integrate with their own projects.</li><li>Maintain and wherever possible strengthen the federated nature of the architecture - ie distributed pollservers</li> <li>Clarify and enhance the "protocol" aspects of the platform by using simple and more standard terminology understood by a wider range of developers. (ie Restful web services with explicit API's).</li><li> Get the software out there and tested by real groups, through the use of plugins for common platforms (WordPress, Drupal, FaceBook, Pligg etc...)</li></ol>The secondary aims are a bit more philosophical, and involve a strategy whose fundamental aim is to: <ol><li>Involve a greater number of stakeholders in the co-design of the architecture and implementations</li><li>Involve a wider range of stakeholders in the co-design of the architecture and implementations (so not just programmers, but community groups, designers, lawyers, architects etc)</li> <li>Broaden the relevance and the appeal of LD by seeing it as a relatively small part of a wider agenda of institutional change, which includes yes local and national governments, but also how groups work in the NGO sector, how scientists work, in fact how any group of people get together in an organised fashion to deliver a piece of work in common.</li> </ol>The problems that the proposed strategy is trying to address are: <ol><li>Over professionalising the development. Currently you need to be a Java developer, and have a good grasp of some fairly deep concepts and specialised terminology to participate in a practical way in developing the code base.</li> <li>A sole coder. Experience shows that any software project benefits hugely by having at least two programmers working together on a code base.</li><li>Architecture driven. the project is currently being driven too much by an idea, and an architectural vision, and not enough by real world use cases. This is not very satisfying for the developer, it does not help to develop momentum and users, and it misses out on deeper understandings that come from working with users and their problems which in turn end up affecting the architecture and not just the GUI. The process should be participatory design based, and so needs again "opening up".</li> <li>Not interdisciplinary enough. It is clear this is a complex domain, and the ideal team working on this would be involve a range of skills working together to design and shape the project.</li><li>No legal structure, making the project vulnerable to private organisations, making it harder to involve a wide range of stakeholders, and harder to raise resources of time and energy that would help with things like user trials. </li></ol>To achieve the above aims - which all are aimed directly at opening up the project to common ownership and the input of a wider group of stakeholders, I think there are four main parts: <ol><li>Bringing the software onto a shared server and inviting other related projects to work in the same virtual space.</li> <li>Adopting a clear and open legal structure, democratic, and open to all participants.</li><li>Developing a more intuitive language (DSL), that a range of stakeholders can use in order to express and design the type of fluid organisational arrangements that they together with their colleagues picture.</li> <li>Use a DSL and standard frameworks to open up the actual coding work of the project to as wider community of developers as possible, Java, Ruby, Python etc..</li></ol>Yes the vision differs somewhat in it's emphasis of the diversity and openess of all the structures involved, over the idea of achieving global unity within a common voting architecture - that is it's emphasis on the value of diversity and openess of people, organisational structure, technical, architectural, etc and the benefits of this openness and diversity to the development of the project. This does not discount the value of architectural unity, but sees the design of such unity as an emergent property of a participatory design process. </div></div> -- You received this message because you are subscribed to the Google Groups "Votorola" group. To post to this group, send an email to votorola@googlegroups.com. To unsubscribe from this group, send email to votorola+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/votorola?hl=en-GB.